🖐 Ловите анонс докладов, которые начнутся в 15:50
⠀
🔸 Зал «Конгресс-холл». Анна Гобрусева (Ozon) «Alerts-Registry. Одно место управления алертами»

Доклад для тех, кто уже построил у себя систему алертинга и упёрся в проблемы её сопровождения. Как определять/удалять неактуальные алерты, как их версионировать, etc...
⠀
🔹 Зал «Кейптаун». Александр Бычук (VK, VK Tech) «Open Source как часть R&D»

Мы тут ждём рассказ про то, сколько на самом деле стоит свободное ПО и как принимать решение о том, покупать или брать бесплатное и допиливать.
⠀
🔸 Зал «Сингапур». Михаил Марченко (билайн) «Путь от "хаоса" к облачной инфраструктуре»

Доклад про развитие и эволюцию инфраструктуры и внутренней разработки в большом телеком-операторе, про переход к внутреннему облаку, автоматизацию и предоставление платформенных сервисов.
⠀
🔹 Зал «Уфа». Константин Ожерельев (Ozon) «DevOps для 1C-приложений»

Превосходный обзорный доклад про DevOps и 1С. Как и зачем совместить, на первый взгляд, несовместимое. Рекомендуется, если вы DevOps и хотите расширить кругозор.

🔸 Зал «Дели+Калькутта». Георгий Абрамов (АО "СберТех") «CUE — лучшая альтернатива для работы с манифестами K8s»

Если вы испытываете трудности с использованием Yaml, Helm или Kustomize, то этот доклад о CUE будет вам полезен. В нем рассказывается о базовых принципах работы с CUE и о том, как начать использовать этот инструмент.
⠀
🔹 Зал «Пекин». Сергей Губарев (Cloud.ru) «Подготовка SecChamp’ов: как обработать все проблемы и не сойти с ума»

В данном докладе вы узнаете, как в Cloud.ru попытались решить проблему отсутствия большого количества AppSec-специалистов, обучить команды и переложить на них задачу работы с инструментами безопасной разработки на команды.

В 16:20 приходите в Зал «Шанхай» на мастер-класс от Ирины Николаевой (Raft) «Локальные LLM: как с легкостью применять большие языковые модели в ежедневных задачах»
⠀
Искусственный интеллект ближе, чем кажется! Присоединяйтесь, чтобы узнать, как использовать открытые локальные LLM в повседневной работе на твоём обычном ПК. Откроете завесы над миром LLM-моделей и попробуете их в бою для анализа ошибок и поиска решений, соблюдая лицензии и требования к оборудованию.
⠀
✋ Обратите внимание, что на данный мастер-класс необходим свой ноутбук.

✋ Друзья, если вы были на докладе Антона Алексеева и по техническим причинам у вас не получилось проголосовать за доклад, пройдите, пожалуйста, по ссылке, чтобы поставить оценку:

https://conf.ontico.ru/online/dc2024/details/5393175

🖐 Дорогие участники, в 17:00 ждём вас на последних докладах DevOpsConf 2024
⠀
🔸 Зал «Конгресс-холл». Кирилл Ильин и Артем Поддубный (СберАвто) «Все как код»

Из доклада вы узнаете, как сделать архитектуру ваших сервисов в виде кода и как на это наложить техники из матрицы MITRE ATT&CK для оценки безопасности продуктов.
⠀
🔹 Зал «Кейптаун». Алексей Шкирмановский (Vi.Tech) «Переходим на мульти-ЦОД-архитектуру»

Рассказ о том, когда архитектура решения с двумя ЦОДами может не подойти и почему. И что надо учесть вашему бизнесу и вашим сервисам, если захотелось жить в трёх.
⠀
🔸 Зал «Сингапур». Максим Бочкарев (ЕВРАЗ) «DevOps в металлургии, история про большие и сложные задачи IТ в производственной отрасли»

Из доклада вы узнаете про пройденный путь и развитие DevOps в реальном секторе, опыт взаимодействия с консультантами и интеграторами, внедрение и развитие Azure DevOps, стандартизацию, автоматизацию проектов и процессов в разработке и эксплуатации.
⠀
🔹 Зал «Уфа». Максим Нифонтов (Programming Store) «DevOps приходит в 1С»

Доклад содержит разбор инструментов для построения DevOps в 1С, но культура DevOps забыта тоже не будет. Если вы работаете где-то рядом с реальным сектором и хотите помочь коллегам улучшить жизнь в 1С, то обязательно приходите!

🔸 Зал «Дели+Калькутта». Илья Лесиков (Флант) «От доработки Helm к разработке Nelm: эволюция развертывания в werf»

Helm стал стандартом упаковки приложений для Kubernetes. Но так ли он хорош, как кажется на первый взгляд? Какие проблемы есть в Helm и как их решить? Nelm — движок развертывания в werf, в будущем — drop-in-замена Helm, решит многие проблемы Helm и добавит недостающие ему возможности.
⠀
🔹 Зал «Пекин». Антон Гаврилов (Инфосистемы Джет) «Kyverno: старт без грабель»

Данный доклад будет отличным началом погружения в тему PolicyEngines на примере инструмента Kyverno и его возможностей.

#DevOpsConf Екатерина Лысенко из RoboGate. Неизбежность, или Как приучить Devops-инженеров к проектированию. В докладе две части: почему надо проектировать, вторая - что такое - проектирование. И были примеры из реальных кейсов, одни - сквозные по докладу, другие - локальные.

Итак, почему надо проектировать? Есть два подхода к работе: в рамках должностных обязанностей и в рамке бизнеса в целом. Первый вариант проявляется, когда команда работы с платежами считает, что фискализация - за пределами ответственности, или busdev полагает, что его задача ограничена коммутацией контрагентов с бизнесом.

Если приземляем на devops, то работа в рамках должностных обязанностей приводит к тому, что вы все время тушите пожары, которые непрерывно возникают из-за динамики бизнеса. Но когда devops говорят о бизнесе в целом, то они часто все равно ограничиваются автоматизацией и своим пониманием, что они могут сделать. А на вопрос "почему так" отвечают "бизнес так хотел" или "100 лет работает, не трогай". И с такими невозможно говорить.

Проблема, почему devops действуют так, отчасти, в образовании - молодая специализация, университеты не готовят, они самоучки или кончали курсы, где им дали инструменты. И в результате devops не участвуют в архитектурных комитетах, а если участвуют - то не имеют права вето при принятии решений, то есть их приглашают для информирования. И в вакансиях проектирования не требуют.

На мой взгляд, тут определенный логический провал в рассуждении: почему выход за границы специализации непременно означает проектирование, и наоборот, почему работа в границах специализации не включает проектирование, ведь конвейер поставки ты же делаешь не ad hoc. На мой взгляд, ответ дает системный подход: когда ты создаешь подсистему, в данном случае - конвейвер поставки, ты, прежде всего, должен вписать ее в надсистему, а надсистемой в данном случае является работа бизнеса в целом. Внутри подсистемы можно оставаться, только если интерфейс уже кем-то определен, при чем с учетом потенциала подсистемы, а это знает именно devops. F иначе вписывание будет кривое. И в примерах необходимость проектирования была понятна, если devops не участвует, то бизнес прибегает с неразумными решениями.

Проектировщик решает следующие задачи:
* разработка продукта в соответствии с бизнес-вызовами
* поддержка и развития уровня качества продукта
* исполнение технической стратегии
* взаимодействие между бизнес-юнитами

Для решения ему надо понимать 5 проекций. Катя показывала их как уровни, но, на мой взгляд, это не совсем верно.
* Business vision. Полный, включая цели и не автоматизированные сценарии. Именно на этом уровне часто есть альтернативные варианты решений
* System vision. B тут часто надо обобщить разнородные частные решения, которые дали разные команды
* Integration vision. API, и там важно описывать содержание, бизнес-логику взаимодействия, которые лежат за пределами swagger
* Infrastructure vision. Он проявляется наверх, например, есть платежный провайдер, в какой-нибудь стране, где странно пополняют счета меняет json - и сообщения перестают проходить из-за кем-то поставленного ограничения в 1мб.
* Management vision: стратегии, культура. Компания меняет культуру от хакеров с крафтерам: не давай-давай, а тщательно делаем с архитектурой и рисками. И это - напрямую влияет на devops.

Проектирование - не только в крупном. Когда вы делаете анализ инцидента и пишете PIR, то там не так важно, как прошел инцидент. Важно - как не повторить, что изменить, какие меры применить. А это - проектирование.

Для архитектурных решений важно писать ADR - architecture decision report: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.

Когда ADR нужны?
* Необходимо встроить новый продукт в архитектуру
* Реинжиниринг домена сервисов
* Выбор новой технологии
* Есть задачи на реализацию технической стратегии - она долгосрочна и меняется, надо понимать куда шли
Примеры: Единый клиент, оптимизация под рост нагрузки х10, перенос отчетов в BI...

В конце из зала был вопрос: как начать проектирование? На него было два исключающих ответа.
* Просто начните. Кто разрешит? А кто запретит, идешь и делаешь! А руководству показать пользу - на паре инцидентов.
* Если в компании культура тушения пожаров, то в одиночку это не изменить, и в любом случае изменение - не простое.

На этом - все.

🙌 Друзья, ловите фотографии с конференции в альбомах ВКонтакте:

День 1

День 2

Друзья, конференция DevOpsConf 2024 завершилась!

Мы благодарим каждого из вас за участие: кто был на площадке, в онлайн, спикеров и партнёров 🧡 Эти два дня были очень насыщенные и мы надеемся, что для вас они прошли плодотворно и интересно.

До встречи на DevOpsConf 2025 🙌

#DevOpsConf Константин Ожерельев из Ozon. DevOps для 1C-приложений. Если кратко, то доклад был о том, что DevOps для 1С - есть. Нужен ли он - вопрос к бизнесу, у них создание DevOps инициировано требованиями аудиторов по устойчивости процессов обновления софта для публичной компании. Но эффект не ограничивался удовлетворением аудиторов, реально получена устойчивость прода за счет автоматизации доставки обновлений и разработки автотестов, выполняемых в конвейере доставки.

И в докладе были подробности - за счет каких именно средств это достигается, и как организовано. Конвейер доставки есть для обоих вариантов разработки: EDT + Git и Конфигуратор + Хранилище (собственная система контроля версий от 1С). Вариант Конфигуратор + Git формально существует, но фактически рабочим не является, поэтому не рассматриваем. Стартом для процесса DevOps в обоих случаях служит Git, просто при использовании хранилища синхронизация с Git обеспечивается отдельной утилитой GitSync. При этом не получается использовать feature branch, разработка ведется в единой dev-ветке, а чтобы иметь возможность исключать функционал отдельных фич из обновления используют стандартный паттерн feature toggle. А дальше все стандартно: dev - test - release со своими средами развертывания и тестирования. Для того, чтобы в конвейере процессе сборки выполнять скрипты, в том числе специфичные для 1С используется OneScript - продукт, который позволяет писать скрипты на языке 1С, исполняемые вне среды, работает поверх .Net и .NetCore. Смысл OneScript в том, что язык получается знаком 1С-разработчиком и их может поддерживать сама команда 1С. В мире 1С принято, что развертывание поддерживает команда, а не отдельные devops. Об остальных средствах - смотри презентацию на слайдах.

На этом про доклад - все, а от себя отмечу, что первый доклад про реализацию CI/CD для 1С я слышал уже лет семь назад, другое дело, что сам вендор не торопится с полноценной поддержкой, и разработчики консервативны. Но технические возможности - есть и они совершенствуются.

#DevOpsConf Владимир Утратенко из Uzum Market. Древние свитки CI/CD: смыслы, которые мы потеряли. Это был доклад за все хорошее против всего плохого. О том, что не взирая на лучшие практики, многие по-прежнему работают по-старому. Хранят код, конфигурации, тесты и описание конвейера в разных репозиториях с непонятной синхронизацией, а кое-что может лежать вообще вне репозиториев. Что запуск тестов, особенно нагрузочных, и разворачивание среды для этого может быть магией, доступной отдельному инженеру. Что патчи могут собираться вручную и пересылаться по почте. А если тесты запускаются автоматом и падают, то разработчики могут их отключать, а не чинить, или просто игнорировать. Что никакой integration в рамках CI не происходит, а просто сборка отдельного продукта. А реальный continuous delivery - вообще редкий зверь, потому что на пути к проду часто стоит ручной регресс, который делают много месяцев. Что несмотря на рекомендации делать частые коммиты и мержить ветки, разработчики накапливают изменения несколько месяцев в стремлении сделать все-все-все, а потом мерж фичи занимает несколько недель и приводит к переписыванию заново, потому что этот же код активно правили. И вообще, CI/CD для части людей превратились в buzzword, смысла которого они не понимают. И все это - с одобрением аудитории, которой эти проблемы известны.

К сожалению, от того, что людям лишний раз напоминаешь про хорошие практики, они начинают их использовать. Сколько человек по утрам делают зарядку или ходят в фитнес? А скольких можно побудить к этому, рассказав про ожирении и разные проблемы, которые ждут в будущем, или даже в настоящем? Увы! Так что тут, по-хорошему, нужен серьезный разбор причин и способов работы, включая методы изменения привычек и культуры - ведь проблема-то в них. Впрочем, доклад был хороший и с юмором, так что, не исключаю, что, слушая его, участники увидят на свой портрет в сатирическом зеркале и решат измениться.

#DevOpsConf Сергей Реусин из СберМаркет. Инженерия устойчивости как основной инструмент выживания вашей организации: история, подходы и примеры внедрения. Это был доклад первого дня, на который я забыл опубликовать конспект. Доклад концептуальный, он принципиально меняет точку зрения на ошибки и сбои: мы не стремимся уменьшить их до нуля, увеличив время между ошибками, а определяем допустимую зону и фокусируемся на способах быстрого восстановления в случае сбоев. И это дает устойчивость системы в целом. Это подход resilience engineering, основанного на работах ряда исследователей. В их числе Richard Cook, на работы которого Сергей много ссылался. Предлагается определить зону сбоев, которая является приемлемой, и держаться в ней, в том числе - за счет быстрого восстановления, а не только за счет снижения количества ошибок. Подробнее про подход можно посмотреть в stella.report. Идея состоит в том, что мы предусматриваем универсальные способы восстановления, которые сработают в широком спектре ситуаций. И что наоборот, частные способы могут перестать работать. Например, практика канареечных релизов, при которой новые фичи сначала предоставляются малому числу пользователей для проверки работоспособности, могут перестать выполнять свою функцию, если разработчики начнут применять feature toggle, включаемые сразу и для всех, а не постепенно - сначала релиз раскатят на всех, а потом этот флаг возьмут и включат, и проблемы посыпятся.

Это - интересный взгляд. Потому что в погоне за высокой доступностью часто применяют сложные и дорогие технические решения, и несут неоправданные затраты. В то время как альтернативные способы могут быть гораздо легче. Я тут поделюсь своим опытом. В свое время мы проектировали систему розничного магазина для Спортмастера, и спросили их - а могут же быть разные проблемы с работой системы: электричество, сеть и так далее. А они рассказали, что на этот случай есть план-Б: автономный сканер ШК (ТСД), в который загружен каталог с актуальными ценами, и который умеет фиксировать продажи, сканируя ШК, и простая дешевая касса, на которой можно пробивать чеки в автономном режиме и которая работает от обычного бесперебойника, и в результате при любых проблемах магазин 6 часов способен вести продажи. Что позволяет не слишком заморачиваться с доступностью именно информационной системы. И аналогичный подход у них дальше применялся при переходе на централизованную систему лояльности: при сбоях интернета владельцам карт предоставлялась специальная скидка, размер которой их обычно удовлетворял, так что проблемы не вызывали негатива. И как побочный эффект такое решение снижало требования к доступности централизованной системы лояльности - план-Б со специальной скидкой работал и в этом случае.