Доклады

В каждой развивающейся компании вместе с увеличением штата сотрудников появляются нормативная и техническая документации. С течением времени они разрастаются и появляется многоуровневая иерархия. Всё это приводит к чрезмерным тратам времени и снижению производительности новичков и DevOps-составителей, к которым адресуются все вопросы.

На воркшопе мы вместе разработаем умного и вежливого чат-бота на базе LLM, исчерпывающим образом отвечающего на вопросы по документации от DevOps-инженеров, и поговорим о применённых технологиях.

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

Обсудим наболевшие и животрепещущие вопросы относительно использования ИИ в работе DevOps:
- А правда можно?
- А точно безопасно?
- А хотя бы помогает?
- А нас всех заменят роботы?

L1-инженеры 50 000 раз в сутки решают, что делать с событием мониторинга — добавить к открытому инциденту или создать новый, а может, добавить к только что закрытому или вообще это просто шум. А, может, случился экосистемный сбой и нужно оповестить большую часть из 500 наших продуктов.

В докладе мы расскажем, зачем мы решили автоматизировать группировку событий мониторинга, как мы внедряли изменение, что это нам дало и какими Open Source решениями нам удалось достигнуть точности выше 80%.

С увеличением уровня внедрения LLM в процессы DevOps возникает ряд этических вопросов, касающихся их использования. Мы должны осознавать, что автоматизация процессов и генерация кода с помощью LLM могут привести к нежелательным последствиям, если не учитывать аспекты инженерной этики.

В докладе я поделюсь опытом по выявлению и минимизации этических рисков, связанных с использованием LLM в DevOps. Обсудим безопасность языковых моделей, важность прозрачности алгоритмов и необходимость создания этических норм для разработки и внедрения таких технологий. Вместе определим, какие вопросы необходимо задать себе и коллегам прежде, чем внедрять нейросетевые решения в инфраструктуру.

Мы рассмотрим ключевые идеи, такие как обеспечение безопасности конфиденциальных данных, предотвращение предвзятости в моделях и необходимость постоянного мониторинга и оценки результатов работы LLM. Также уделим внимание тому, как открытая дискуссия может помочь создать более этичные и ответственные решения в области DevOps.

Проблемы, с которыми можно столкнуться на разных этапах зрелости команд, организации и практик

В начале 2024 года мы собрали команду и начали разрабатывать своё приложение для проведения хаос-тестирования. Поговорим о том, почему мы решили так делать, вспомним про то, что такое хаос тестирование, чем хуже другие инструменты. Расскажем про то, как команды отреагировали на наше решение, чего мы хотим добиться. Немного про планы развития нашего продукта.

Что такое хаос? Когда и почему стоит его делать? Есть ли готовые решения, которые можно взять и использовать или стоит написать свое?

Расскажу про подход на масштабе Яндекса.
Как мы чуть не развалили продакшен при внедрении, факапы с учений, чему мы научились и главные выводы.

Спойлер: Мы ломаем сервисы в продакшене на 100% пользовательского трафика.
Слабоумие и отвага? Узнаем в докладе :)

Многие слышали о 1С.
Но что вы знаете о программных продуктах 1С?
Уверен первое что всплывает в головах, что 1С - это бухгалтерия, зарплата - сервак на базе i5, 10-15 пользователей...
Но это далеко не так.
В нашей конфигурации 1с работают тысячи пользователей, наша база занимает почти 40Тб пространства, это одна из самых крупных баз 1с в России.
И в своей работе мы используем не только штатные средства 1С, но и многое многое другое...
Если интересно, приходите я расскажу много интересного!

1. Разбиваем стереотипы
1.1 Linux vs BSD - что использовать, и почему и то и другое вместе и одновременно
1.2 Доставка пакетов - как не утонуть в вопросе
1.3 Нужно ли соблюдать внешние стандарты, в том числе стандарт Linux?

2. Существующие практики, и почему они не подходят
2.1 Linux from scratch
2.2 Gitian
2.3 FreeBSD ports collection
2.4 Как найти то, что заработает именно в Вашем случае - критерии отбора

3. Как это работает на практике
3.1 CI/CD и что обычно нехватало в нём для реализации из коробки
3.2 Довешиваем GitLab до рабочего и полностью автоматизированного решения
3.3 Debian_GNU/kFreeBSD - почему провалился и как не повторить его ошибок
3.4 Собственные компоненты - как не изобрести велосипед, но что действительно должно быть "самописным"

4. Анатомия минимального решения - заглядываем под капот

Исторически было известно, что кластер Kubernetes может поддерживать до 5000 узлов при оптимальном количестве подов на каждом равном 110. Недавно Google опубликовал статью о кластерах с 65000 нод. А сколько нод может поддерживать ваш кластер?

Хороший вопрос, но для такого тестирования нужно огромное количество ресурсов. В своем докладе я расскажу, как мы в Yandex Cloud тестируем наши кластера на масштабируемость, используя минимум ресурсов. Поговорим о том, какие факторы влияют на масштабируемость и что можно сделать с кластером k8s, чтобы он поддерживал столько нод, подов, секретов и других объектов, сколько вам нужно.

В этом докладе (похоже, что впервые на русском языке) мы поговорим о Puppet Bolt - системе оркестрации из экосистемы Puppet, но достаточно универсальной, чтобы использоваться и вне её. В первой части доклада будет дано краткое введение в Puppet Bolt. Во второй части будет представлено несколько примеров использования — как обычных, так и весьма нестандартных.

Сеть доставки контента RUTUBE — это 250+ железных сёрверов, расположенных по всей стране и даже ближнему зарубежью, сети операторов, много nginx и самописное ПО, которое всем этим управляет.
Данная сеть раздаёт 5 тбит/с данных не только для национального видеохостинга RUTUBE с 65 млн пользователей в месяц, но и для некоторых других цифровых активов Газпром-Медиа Холдинга.
Поговорим о том, как устроен CDN RUTUBE с инженерной точки зрения: аппаратной, сетевой и программной.

Что такое секционирование и каким оно бывает.
Пробемы больших таблиц и INHERIT-секционирования.
Виды декларативного секционирования.
Преимущества и ограничения декларативного секционирования.
Автоматизация для использования декларативного партиционирования
Наш опыт перехода на использование декларативного партиционирования для хранения данных.

Puppet остается одним из основных инструментов подхода IAC, но информации о нем, особенно в рунете, по-прежнему мало. Мой доклад поможет аудитории восполнить некоторые пробелы в этой теме, причем я дам и вводную информацию, и погружу слушателей в нюансы работы с Puppet.

На примере задач Авито рассмотрим особенности администрирования инфраструктуры и обсудим наши собственные инструменты для оптимизации работы с Puppet. Кейсы наших задач в докладе доказывают, что не всегда важно, какой инструмент вы выбираете. Важно, как вы адаптируете его под свои нужды.

Как и в фильме «Матрица», реальность не всегда такова, какой кажется. Данные систем мониторинга могут создавать миражи, которым мы доверяем без лишних сомнений. В докладе рассмотрим, что на самом деле скрывается за графиками и как не поддаться «иллюзиям», которые они могут создавать.

В первой части обсудим, почему визуализированные метрики могут дать искажённое представление о реальности. Как и в «Матрице», данные — это не объективная истина, а интерпретация, которая зависит от множества факторов. Наш анализ покажет, что проблема "ложныхметрик" — не в технической ошибке, а в особенностях их представления и восприятия.

Затем мы погрузимся глубже — в архитектурные особенности систем мониторинга на примере Prometheus. Как и Нео, который осознал, что мир «Матрицы» — это симуляция, мы разберёмся, как происходит чтение в Prometheus.

В заключении поговорим о том, как «проснуться» и начать воспринимать метрики систем мониторинга правильно. А также разберём особенности, которые надо учитывать, чтобы не попадать в ловушки ложного восприятия.

Работа с логами может быть удобной не только для разработчиков, но и для эксплуатации, нужно только договориться.

Представь: ты видишь, как сервисов в компании становится больше, команд больше, логов больше. И вот уже есть инженеры, которым нужно находить и понимать логи многих сервисов. Какие у нас варианты?

Дать волю. Все будет гибко и удобно для разработчиков, логи пишут, как хотят, сами читают, знают, где найти. Это до тех пор, пока разработчик не перешел в другую команду или пока ночью дежурному не потребовалось искать логи совершенно новых для него сервисов. Затраты времени могут быть огромны.

Договориться об общих правилах. Да, будет меньше свободы художникам, но для общего дела будет гораздо лучше. Вспомним про правила дорожного движения, ведь они есть и для пешеходов, и для водителей. С логами тоже самое. Это помогает порядку и предсказуемости при функционировании сложной системы.

Я расскажу, как в прошлом году мы реализовали унифицированную работу с логами с применением "готовых правил дорожного движения" из OpenTelemetry на базе Vector.dev и Clickhouse, какой опыт мы получили за 2 года и как развили это решение.

Что такое семплирование и зачем оно нужно?
Метрики и трейсы на основе семплированных данных. Бесполезная игрушка или рабочий инструмент?
Head vs Tail. Отличия и сценарии использования.
Реализация и алгоритмы head-based семплирования.
Реализация и алгоритмы tail-based семплирования. Подводные камни и способы их обхода.
Применение семплированных трейсов в разборе реальных инцидентов.

В докладе рассмотрим, как построить современную систему наблюдаемости от уровня кода до систем кластерного уровня, что и на каких этапах необходимо реализовывать. Тех стек в докладе будет Java, но полученные знания применить и реализовать вы сможете на любой системе, которая у вас под рукой - принципы те же. Также рассмотрим различные принципы сбора телеметрии для систем, откуда и какие данные мы сможем достать без модификации приложения.

1. Цели и задачи внедрения сервиса
2. Что такое Mimir
3. Параллельные решения
4. Почему мы выбрали Mimir
5. Особенности развертывания и тестирование
6. Опыт использования Mimir
7. Дальнейшее развитие

В каждой компании есть необходимость выстроить систему observability. В своём докладе расскажу, как мы прошли несколько вариантов реализации пайплайна сбора и хранения трейсов. Посмотрим, почему отказались от jaeger, elastic, cassandra, opentelemetry agent/collector.

Поговорим о том, как мы несколько раз перестраивали нашу архитектуру под большее количество данных. Много ли сейчас у нас данных? Имеем на входе 24к RPS, 1 миллион спанов в сек., 5к инстансов сервисов. Рассмотрим плюсы и минусы трейсинга без семплирования.

И в заключение посмотрим, как сделать свой анализатор причин даунтаймов на основе трейсинга.

Задачи мониторинга лежат в фундаменте DevOps, и хорошо налаженная система, которая решает их на своей инфраструктуре – предмет гордости для любого инженера. Но нередко бывает так, что все лампочки у своих инфраструктурных компонентов светятся зеленым, а интернет-юзеры сообщают о проблемах доступа к сервису… Сбои во внешних системах, сетевые аномалии и некорректно работающий фронтенд можно отследить только расположенными снаружи инфраструктуры глазами. А кто может дать более точную информацию, чем сами страдающие пользователи? О том, как получать, хранить и анализировать метрики “с того конца”, поговорим в этом докладе, с CDN-сетью в качестве наглядного примера.

Давайте посмотрим на относительно новый компонент Cilium - Cluster Mesh.
Рассмотрим его архитектуру, построим и сломаем межкластерную связь, а также погоняем бенчмарки и попробуем ответить на вопрос: "Готов ли Cluster Mesh для прода?".

В докладе разберём, каким требованиям должны соответствовать современные приложения и средства оркестрации и каков «джентльменский набор» для удобной работы с Kubernetes. А ещё на конкретных примерах рассмотрим, какие трудности и проблемы возникают при поддержке собственного решения на базе Kubernetes.

В докладе будет рассказано о том, как работает File.d, из каких частей состоит и как его можно использовать на примерах конфигов отдельных компонентов и пайплайнов. Также будут затронуты темы скорости работы, гарантий доставки и механизмов защиты системы логирования от внезапных увеличений объемов данных.

Все мы пользуемся DNS, но не все автоматизируют управление. От этого появляются во внутренних (и иногда внешних, sic!) инструкциях "echo '1.2.3.4 my.demo' >> /etc/hosts".
В докладе расскажу и покажу с ready to use примерами:
- автоматизацию управления DNS-зоной через git;
- как сделать собственный no-ip сервис в закрытой сети;
- плагины CoreDNS для Kubernetes;
- собственный плагин для CoreDNS - это просто.

В своем выступлении «загляну под капот» одного из самых популярных Ingress контроллеров в k8s – Nginx Ingress. Материалы доклада помогут вам добиться желаемых результатов при работе с данным инструментом.

В докладе рассмотрим архитектуру и управление различными реестрами Docker-контейнеров с акцентом на инфраструктуру, узкие места, защиту доступа к реестру, устройство Docker-образов и выявление уязвимостей до запуска в production. В сессии подробно рассмотрим механизмы аутентификации и авторизации для Docker-трафика, уделим внимание продвинутым аспектам управления образами Docker, включая создание мультиплатформенных образов, получение SBOM отчетов, а также перечня уязвимостей при помощи инструментов сканирования. Обсудим возможные сложности при эксплуатации реестров, а также при реализации сканирования на уязвимости.

Это обязательная для посещения сессия для профессионалов, желающих углубить свои знания в области управления образами Docker и безопасности.

- Анализ проблем утилизации GPU в контексте подходов single-model и multi-model inference.
- Сравнительная оценка аппаратных и программных решений для оптимизации использования GPU.
- Глубокое понимание реализации концепции vGPU в Kubernetes и её архитектурных особенностей.
- Практические подходы к устранению дефицита CPU, возникающего при перераспределении ресурсов GPU.
- Рекомендации по эффективному управлению ресурсами GPU в контейнеризированных окружениях.

Круглый стол будет посвящен мультиоблачным стратегиям и их реализации в контексте импортозамещения, а также коснемся гибридных инфраструктур. Рассмотрим миграцию данных в облаках, переход на отечественные решения и управление данными между различными облачными провайдерами и OnPrem сетапами. Спикеры расскажут как они управляют данными и обсудят безопасность в мультиоблачной среды. Примеры успешного перехода на российские облачные платформы подчеркнут актуальность темы и практические аспекты миграции.

2025 год, а мы все еще настраиваем локальное окружение и тратим на это много времени? Пишем много инструкций как сделать это на разных ос? Или запрещаем определенные операционные системы потому что на них что-то не работает?
Инфраструктура как код сегодня позволяет настроить и локальную разработку тоже! Девконтейнеры уже зрелая технология, и сможет решить целые классы проблем, а именно:

– Уравнивание окружения между всеми разработчиками через докер (общий знаменатель) – больше никаких cmd-скриптов рядом с sh. А также можно работать с любых девайсов и любых операционных систем, и даже аппаратных платформ.
– Онбординг одной кнопкой – вместо недель настройки окружения для разработки каждым новым разработчиком, всё можно настроить одним человеком и лишь один раз, а работать будет у всех и всегда. Все, что вам нужно – это ide с поддержкой девконтейнеров и докер.
– Поддержание актуальности инфраструктуры рабочей среды одним человеком. Всего один разработчик может описывает актуальное состояние всей инфраструктуры, и у всех, кто перейдет на его коммит, будет ровно такая же инфраструктура. До последнего байта. И никаких поисков багов между двумя разработчиками, из за разных версий ЯП СУБД и прочего.
- Упрощение работы с разными аппаратными архитектурами, не важно mac m+ у вас на arm или x86 вы всегда можете работать со всем окружением, вообще не задумываясь об аппаратных ограничениях.

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

Картина:
- Ручная доставка изменений
- Команда 40+ разработчиков
- 4 связанных системы в доработке.
- Большой объем интеграций
- Два релиза в параллельной разработке без гита (с альтернативной системой хранения версий)
- Ручное тестирование
- Тестирование на пользователях

Что из этого вышло:
- Пилот на не готовой системе
- Срывы сроков
- Низкое качество разработки

Что надо было изменить:
- Ретро
- GIT
- Sonar
- Smoke

Три года мы помогаем сопровождать продукт российской ВКС одному из наших заказчиков. Мы прошли тернистый путь от стартапа “прод на коленке за две недели” и каждый день “ложились в прайм тайм” до геораспределенного по трем ЦОДам конкурентного продукта.

Наш рассказ будет о боли, которая испытывалась все это время, о том, как мы “придумывали заново” каждое популярное решение и через “нетиповые” решения приходили к типовым. Как боролись с проблемами инфраструктуры за пределами нашей зоны ответственности, и как нам в этом помогали разработчики.

Из продукта, к которому не было доверия на старте, мы стали бизнес критичной системой, с подтвержденным уровнем доступности 99.99% в 2023 году.

Автомасштабирование узлов кластера Kubernetes и горизонтальное масштабирование подов позволяют быстро расширить ресурсы при пиковых нагрузках. Но сложные приложения могут не нагружать поды или узлы максимально, но требовать дополнительных ресурсов, например, для параллельной обработки нескольких объектов в очереди. То есть триггером масштабирования кластера может быть не утилизация, а события от внешних систем — очереди сообщений Kafka, системы мониторинга Prometheus или, например, от платформы CI/CD. Мы вместе попробуем запустить такое приложение, посмотрим, как с ним работают классические подходы автомасштабирования и попробуем масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler).

Любая инфраструктура включает в себя множество инфраструктурных сервисов, например, графана, прометеус, гитлаб, докер режистри. Каждый сервис требует аутентификации и авторизации. В идеале это стоит централизовать. Одним из самых популярных сервисов является Keycloak.

Цель данного воркшопа - на базовых примерах показать настройку OIDC коннектора для инфраструктурных сервисов через Keycloak. Разберем основные сущности в Keycloak - realms, clients, client scopes, users, roles, groups. А также аутентификацию в графане через Keycloak.

Отвечу на вопросы:
- Как мы включали авторизацию на кластере, переваривающем 17млн сообщений в секунду
- Strimzi провайдер — продакшен-решение без логов
- Как разделение авторизации и аутентификации позволило запуститься на полгода раньше
- Проблемы со стороны клиентов — как расследовать
- Как потери единичных пакетов дестабилизируют всю систему и что с этим делать
- Как организовать переход нескольких тысяч микросервисов на четырех языках на походы в кафку с авторизацией

Расскажем про то, как мы решали проблему целостности собираемых docker-образов для stage и prod окружений, когда они собираются и деплоятся независимо друг от друга. Ведь когда сборка происходит независимо, есть вероятность того, что для stage и prod будут собраны разные образы с разными системными зависимостями.

Разработали механизм вычисления хеша репозитория и использования его для поиска и переиспользования уже существующего артефакта, аналогично тому, как это делает сам docker. Как итог - получили не только защиту от ошибок на prod, но и значительно уменьшили количество сборок в случаях, когда в репозитории менялись файлы, не важные для сборки.

При росте объемов данных и требований к ускорению времени вывода на рынок (TTM) невозможно обойтись без современных инструментов, в том числе и ИИ. Автоматизация развертывания сложных окружений всегда сопряжена с трудностями, особенно когда важна скорость. В этом докладе мы рассмотрим подходы и технологии, которые обеспечивают типизацию и быстрый деплой окружения с учетом специфики вашей инфраструктуры — сети, балансировки, отказоустойчивости и распределенности.

Доклад посвящен популярному GitOps-инструменту ArgoCD, который помогает унифицировать и автоматизировать процессы развертывания приложений в Kubernetes. Обсудим различия между Pull- и Push-моделями, особенности установки и преимущества ArgoCD, а также организацию GitOps-репозиториев и использование Flow разработки. Кроме того, кратко обсудим организацию доставки секретов для такой модели.

- Сравнение Pull и Push-моделей
- Особенности установки ArgoCD
- Преимущества ArgoCD
- Организация GitOps-репозиториев
- Flow CI/CD
- Организация контроля доступа
- Организация доставки cекретов

Наш типовой минимальный сетап для bare metal-инсталляций — 3 железки, на которых бегает как control plane, так и боевая нагрузка. Чтобы разграничивать всё это дело, приходится использовать виртуализацию.

В докладе расскажу про исторический путь к тесному взаимодействию процессов виртуализации с контейнерами. А также упомяну о нюансах, которые возникают при запуске виртуализации в Kubernetes с различными типами storage.

Мой рассказ будет полезен:
- Тем, кто планирует переходить от классических монолитных приложений к микросервисным и постепенно переносить нагрузку в кластер K8s с виртуальных машин или bare metal.
- Тем, у кого есть потребность запускать много кластеров на железе.
- Тем, кому требуется нарезать «жирное» железо под K8s.

Воркшоп: Разработка инженерных практик для крупных компаний

Приглашаем принять участие в воркшопе, посвящённом созданию и внедрению инженерных практик в крупных организациях.

Что вас ждет:

- Обсуждение лучших практик: Узнаем, как глобальные компании адаптируют и внедряют современные подходы к разработке и эксплуатации (CI/CD, DevOps, SSDLC, API-first, cloud-native).

- Инструменты и процессы: Разберём ключевые инструменты автоматизации, мониторинга и их интеграцию в ежедневные рабочие процессы.

- DORA метрики и RED подход: Погрузимся в метрики производительности команд разработки и эксплуатации для достижения высоких бизнес-результатов.

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

- Реальные кейсы: Изучим примеры компаний, успешно реализовавших переход к продвинутым инженерным практикам, и разберём их на конкретных примерах.

Для кого этот воркшоп:

- Руководители технических команд
- DevOps инженеры
- Технические лидеры и архитекторы
- Инженеры по качеству и безопасности

Результат:

После воркшопа участники смогут применить полученные знания для выстраивания инженерных практик, улучшения процессов разработки и эксплуатации, а также повысить уровень автоматизации и гибкости своих команд.

Высокий ТТМ, долгие сборки, много ручной работы, несколько параллельно живущих staging-окружений, непредсказуемость
времени выкатки – всё это влияло на частоту и скорость наших релизов.

В этом докладе я хочу рассказать про наш опыт ускорения релизов и стандартизации этого процесса в сервисах Mail.ru и поделиться подходами и инструментами, которые практически каждый сможет внедрить в собственные проекты.
– Почему мы за это взялись
– Как правильно организовать выкатки? Какие есть подходы и что выбрали мы
– Как устроен пайплайн: сборки образов, мерж веток, джобы, механизм раскатки, виды апрувов и другое
– Как мы следим за пайплайном: графики, алерты и нотификации
– Особенности организации пайплайнов в GitLab CI
– Результаты, которых мы достигли, и ближайшие планы по развитию
– Как внедрить себе

Мы понимаем, какие метрики можно собирать для измерения DevOps, и чаще всего это DORA.
Но как быть с культурой, которая тоже важна в DevOps?
И вообще, что такое "инженерная культура"?

Сначала мы попробуем договориться о понятиях. Потом поговорим, почему инженерная культура важна.

Расскажем о том, через какие этапы мы шли, чтобы научиться измерять инженерную культуру в банке.
Поделимся инсайтами последнего исследования.

Для желающих повторить это дома представим систему Pulsar-Analytics - инструмент анализа пользовательских ответов.
Её сердце - OpenSearch, который мы используем не для хранения логов, а как базу данных с широкими возможностями для аналитики.

Каждый высококлассный инженер, приходя в компанию, сталкивается с необходимостью освоить процесс поставки бизнес-ценности в продакшен. Хотя у многих он экранирован, но знание и понимание того, как управлять собственной инфраструктурой, бывают бесценны.

Методы управления инфраструктурой развиваются: от ручной конфигурации и bash-скриптов до подхода Infrastructure as Code (IaC), декларативного (Terraform) и библиотек описания инфраструктуры (AWS CDK, Pulumi, TFCDK). Однако сложность и объем инфраструктуры растут быстрее, чем появляются новые инструменты.

Относительно новая концепция Infrastructure from Code (IfC) создает инфраструктуру непосредственно из кода приложения, интегрируясь с ним или анализируя его для автоматического определения инфраструктуры.

В докладе мы пройдем сложный путь становления инструментов управления инфраструктурой. От обычных скриптов до IfC. И разберемся, что такое относительно новый IfC, его преимущества и недостатки, отличия от IaC и его дополнения.

Интерфейсы нового уровня: как создать визуально привлекательные и удобные интерфейсы в Jenkins, которые заменят старые, сложные системы.
Минимум действий от пользователя: никакой путаницы или инструкций — пользователю нужно лишь нажимать кнопки, всё остальное происходит автоматически.
Красота и автоматизация в одном флаконе: интеграция с Git, автоматическое подтягивание данных и полное отсутствие ручного ввода, что упрощает и ускоряет работу.
Безопасность прежде всего: расскажу, как сделать платформы не только удобными, но и защищёнными, чтобы минимизировать риски.
Удобная разработка без шишек: я покажу, как организовать процесс разработки этих платформ так, чтобы избежать проблем, на которых я уже сам учился.
Обучение и поддержка: научу вас, как воплотить всё это в жизнь — от создания красивого интерфейса до безопасного и удобного рабочего процесса.

Автоматизация генерации release notes это хорошо, а можно ли лучше?
Осветим тему о том, как можно отследить какие изменения выезжают в прод добайтика.
По пути затронем DORA метрики и удобство работы программиста в условиях максимальной гибкости.

tbd

Бизнес растет, с ним растет число проектов, и вот мы получаем ситуацию, когда нужно организовать эффективное управление 15 000+ инстансами баз данных для более 100 инженеров проектов. Столкнувшись с такой необходимостью, наша инфраструктурная команда реализовала многопользовательский подход к ansible inventory, и настройка и обслуживание кластеров баз данных значительно упростились.

В докладе поговорим о структуре multi tenant ansible inventory, инструментах автоматизации (генерация переменных, применение изменений), интеграции с GitLab CI. Также рассмотрим подходы к уменьшению когнитивной нагрузки на инженеров, работающих с кластерами баз данных.

Написать документацию - сложная задача? А ещё непонятно, почему документ ждут именно от Вас? Да и вообще Вы не техпис и не аналитик, а от Вас ждут какие-то статьи в базе знаний? В докладе поговорим о том, почему инженеру важно участвовать в наполнении, верификации и актуализации базы знаний.

Уже давно все оценили приимущества и удобства gitlab. Но если вы еще не выбрали необходимую инсталяцию под ваши цели - попробуем разобарться что лучше всего подойдет

В прошлом выступлении про NextOps я показал, куда движется DevOps как профессиональное движение и как будет решаться проблема взаимодействия между разработкой и эксплуатацией. В этот раз предлагаю детальнее погрузиться в инжиниринги, дать определение, рассмотреть отдельные направления инжиниринга, разобрать публикации, поискать лидеров и обсудить состояние на начало 2025 года.

One gitlab to rule 'em all
Принимаем решение о переезде в новый гитлаб
ﾠВыбираем целевое решение
ﾠﾠсравнительный анализ: gitlab CE, gitea-based, покупка EE через прокси, "русские EE", что-то совсем иное (gitflic)
ﾠﾠ Выбираем CE - причины
ﾠ Гитлаб CE и как с ним жить
ﾠﾠ Как подеплоили
ﾠﾠ Как делали HA (а точнее Failover)
ﾠﾠ Компенсация недостающих фичей
ﾠﾠﾠ Подходы к компенсации:
ﾠﾠﾠﾠ Правка кода гитлаба
ﾠﾠﾠﾠ Костыли и велосипеды
ﾠﾠﾠ Multiple Approvers
ﾠﾠﾠ Codeowners
ﾠﾠﾠ Push rules
ﾠ Gitlab As a code
ﾠﾠ Как и что мы описываем, как код
ﾠﾠ Почему Pulumi
ﾠﾠ Ломаем ручное создание того, что описываем через код (создание проектов/права)
Технические сложности - самые простые
ﾠМиграция разработки в новый гитлаб
ﾠﾠОсознаём весь масштаб проблемы
ﾠﾠ Запускаем аудит всей разработки
ﾠﾠﾠ Соответствие разработки стандартам практики
ﾠﾠﾠ Использование типового ci и cd
ﾠﾠ Актуализация, рефакторинг или создание CiCd сниппетов
ﾠﾠ Самостоятельная миграция продуктовых команд

Что нужно, если ты хочешь учить людей техническим навыкам, например, разворачивать Kubernetes или повелевать Docker? А если еще хочешь это делать онлайн?

Совершенно точно нужно обеспечить ученикам комфортную, технически исправную и одинаковую среду обучения. Потому что у одного MacBook на М2, а у второго ThinkPad, который ему в наследство оставил дедушка с процессором i386. Как ты не пиши требования к оборудованию, обязательно где-то что-то будет не так.

Совершенно точно нужно помогать ученику. Ну вот пишет он "kubeadm init ..." и делает опечатку в параметре "--pod-network-
cidr": преподаватель увидит это моментально, а глаз ученика с этим будет бороться долго.

Кажется, не выглядит как работа для DevOps? Нет, выглядит.

Для каждого ученика создадим LXC-контейнер. Или виртуалку. А что удобнее? Для курса по Kubernetes удобен контейнер, чтобы в нем запустить VirtualBox и создавать виртуалки, по количеству нод. А в курсе по Docker лучше дадим виртуалку и будем в нее ставить, что нужно.

Дальше к этому контейнеру мы сделаем VNC. Но он небезопасен и не очень удобен, поэтому возьмем Guacamole и завернем это в TLS. А еще поставим Epoptes, чтобы преподаватель мог быстро подключаться к ученику.

А теперь мы это автоматизируем. Почему? Потому что если ты проводишь 50+ групп в год, то разворачивать тебе все эти штуки должен бездушный CI/CD-пайплайн. На чем? Конечно, на Astra Linux.

Создать кластер Kubernetes – не самая сложная задача, но что делать, если их требуются тысячи?

Расскажу о том, как мы в Сбере пришли к идее создания Managed-сервиса и как это позволило не сойти с ума и справиться с обслуживанием огромного количества кластеров. Также разберёмся в ключевых особенностях и плюсах нашего решения и посмотрим на его возможности.

Доклад про особенности продуктового подхода и работу с пользователями. Если вы продуктовый менеджер, управляете платформой и тонете в бэклоге с непонятными проблемами - вам будет интересно послушать. Расскажу, как выстроить основные процессы, как и о чем говорить с пользователями, на какие метрики смотреть и как сделать счастливыми людей с другой стороны вашего продукта.

Как получить обратную связь о своем продукте и выявить самые коварные баги еще до официального релиза и при всем при этом поднять уровень корпоративной культуры?

В своем докладе я поделюсь как мы организовали сервис для продуктовых команд dogfooding as s service и что все это значит.

Чем дальше, тем больше мы говорим о платформах и платформенных командах. Где-то рядом с платформенными командами, в далёком космосе, летает книга Team Topologies. На жестокой земле же, среди людей, нам не до того: то тут, то там горит, разработчики тупят, тестировщики хотят странного, а безопасники закручивают очередную гайку. Отдел эксплуатации сидит за стеной из регламентов и отстреливается тикетами. В этой битве нет победителей, только выгоревшие. Но что, если решение проблемы ближе, чем мы думаем?
В докладе расскажу, как вывернуть инфраструктурный тулинг мехом наружу, перестать страдать, и понять что первые шаги к платформе уже сделаны.

Обсудим развитие , причины неудач и возможные пути построения платформ в компаниях.

Больше 6 лет назад я с небольшой командой из пяти инженеров начал строить ИТ-платформу в Туту. Мы создавали ИТ-платформу с нуля: у нас был гринфилд, картбланш на любые решения и большой кредит доверия от руководства компании. Интерес разработчиков компании к платформе был огромным: до этого архитектура была монолитной, а мы начали создавать новый мир Kubernetes для микросервисов с новыми инструментами, технологиями, процессами и практиками. В итоге у нас получилась современная и хорошо автоматизированная ИТ-платформа, которая обеспечивает всем необходимым разработку в Туту.

Из доклада вы узнаете, какие архитектурные и технические решения мы используем в нашей ИТ-платформе в масштабе 2000 продуктовых микросервисов, 600+ пайплайн-ранов в день в 5 baremetal-кластерах и 4 разных ЦОДах. В докладе так же затронем темы: почему мы используем Tekton для пайплайнов, какие решения кардинально улучшили DX и зачем нам оператор для проверки качества сервисов и проектов.

Вы узнаете, как сделать платформу, которая ускорит разработку и избавит от головной боли эксплуатацию.

Платформы - тренд последних лет. Многие компании идут в их разработку, но положительного эффекта не наблюдают. Либо вообще выкидывают через некоторое время. Хочется порассуждать, а когда и, главное, зачем такие платформы нужны (как IDP, так и внутренние бизнесовые) и обсудить, что может привести их к провалу.

- Путь развития dev сред: от виртуалки и очереди из разработчиков к vCluster и автогенерации Kubernetes кластеров.
- Об устройстве vCluster и практике применения.
- Опыт построения внутренней платформы разработки.

Поговорим о том, как внедрить лучшие SRE практики.
Как избавиться от избыточного мониторинга и контролировать продукт с одного экрана.
А также о реализации работающего маппинга в высоконагруженном приложении.

Два извечных вопроса: кто виноват и что делать? В своем докладе я хочу рассказать про культуру без обвинений и смещение фокуса с вопроса "кто виноват?" на "что делать?"
Чаще всего виноваты именно процессы, а не люди, и внедрение культуры без обвинений может сильно поднять моральный дух и сплоченность команды.
Посмотрите: со всех сторон нам рассказывают про невероятный кадровый голод. Компании бьются за людей, рекрутеры и HR-специалисты строят сильный бренд, придумывают кучи плюшек, но так ли они нужны в токсичной атмосфере? И что происходит дальше, после испытательного срока?
Я порассуждаю о любви к ближнему своему, о психологии и о том, как это все связано с инцидент-менеджментом.

ВК - большая компания с множеством разных БЮ, в каждом БЮ разные системы мониторинга и алертинга. В рамках доклада пройдемся от того, как было, что с алертом случалось, когда он зарождался и как доходил до человека, который мог починить проблемы, и как стало сейчас с внедрением автоматизации во все БЮ. Используем Grafana oncall + сильно допиливаем ее саму + вокруг выстраиваем разные вспомогательные сервисы. Обсудим, какие кейсы эскалации алертов, как мы избегаем шума алертов, а также что можно еще сделать с алертом. Например, алерт может вырасти в полноценный инцидент, с jira-таской и чатом инцидента со всеми заинтересованными лицами. Рассмотрим, как чатом можно управлять используя бота и какой у нас флоу инцидента в рамках автоматизации.

Как свести к минимуму негативное влияние возможных аварий на работу ИТ инфраструктуры крупного финтеха?
Как построить процесс подготовки и поддержки актуальных планов DR для динамических ландшафтов?

Расскажем наш подход:
- итеративное создание DRP - от частных планов систем к общему плану бизнес-услуги
- чеклист анализа системы и создание плана восстановления
- ключевое - восстановление основной функциональности, точка готовности системы
- общий план восстановления бизнес-услуги и работа с зависимостями
- планы требуют учений (бумажных и реальных)
- изменяем архитектуру систем / услуг
- доопределяем риски, их источники и признаки их реализации
- выравниваемся с требованиями регуляторов
- услуги и системы динамически изменяются - внедряем гигиену SRE команд по поддержке планов в актуальном состоянии

Для корпоративных систем телекома и не только требуется высокая доступность с неизменным качеством.
В докладе говорится о том, как в сервисах МТС применяются практики SRE, проводится параллель с практиками в Google, основываясь на Google SRE book.
Автор является CTO одной из высоконагруженных телекомовских платформ с повышенными требованиями к скорости и надежности, где четко определен SLO и существуют обязательства перед потребителями. На примере данной системы в докладе развивается мысль чем и как обосновывается достижимость SLO по доступности в 3,5 девятки. Приводится пример того, какие потребуются мероприятия и какими станут трудозатраты, если потребуется повысить доступность до 4 девяток и если более. Как это повлияет на архитектуру, инфраструктуру и команду эксплуатации. И почему подавляющему большинству сервисов в реальности не потребуется более высокого процента доступности чем 99.95.

Аптайм — это функция от количества инцидентов, времени их починки и влияния на пользователей. При этом время инцидента зависит от основных действий по поиску и устранению проблемы и вспомогательных процессов по уведомлению ответственных, сбору их в едином пространстве, быстрому добавлению новых людей, а ещё общению с поддержкой и PR. И починку можно рассматривать как алгоритм действий, который можно оптимизировать глобально или проводить локальные оптимизации в самых проблемных местах.

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

Фича флаги позволяют изменять поведение системы без правки кода и повторного развертывания. На нашем проекте мы могли бы их имплементировать сами, но, как говорят ребята из Unleash, "друзья не позволяют друзьям создавать свою собственную систему фича флагов", поэтому мы взяли их Open Source решение. И не прогадали!

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

Уже давно не секрет, что в Т-Банке есть своя observability-платформа Sage.
Внутри банка мы предоставляем сервис мониторинга, у которого ежедневно более 7000 активных пользователей(DAU).

И как это принято, у нас есть SLA с нашими пользователями, но "как понять предоставляем ли мы сейчас услугу или нет?" - именно с этого вопроса начинается мой рассказ о построении SLOs/SLIs для нашей платформы Sage. Метрики для метрик.

На примере подсистемы метрик в Sage, из моего доклада вы узнаете:
* какой подход мы применили к пониманию критериев надежности и как мы его масштабировали;
* как мы работали с нашими клиентами, чтобы выявить их ожидания от нашей надежности;
* как мы строили SLOs/SLIs;
* как выглядит архитектура подсистема метрик в Sage на сегодняшний день

Доклад будет интересен как экспертам, так и людям, которые только погружаются в тему надежности и построения SLOs/SLIs

Как делиться результатами Postmortem с командами
Эффективная ролевая модель во время инцидента
Метрики успеха: как измерить достижения

В управлении инцидентами уже собрано много практик, в докладе расскажу про две, на мой взгляд, самые важные задачи на старте процесса — ролевую модель при инциденте и Postmortem с командами.

В докладе расскажу как эффективно делиться результатами Postmortem с командами, чтобы что сократить их бэклог, эффективнее управлять проблемами (правильно приоритизировать, заносить в команды, давать инструменты в виде дашбордов для отслеживания, добавлять новые активности в виде комитетов и review) и тратить меньше времени на управление. А также как выстроить эффективную ролевую модель во время инцидента (назначение, функции, резолвинг).

Измерим результаты использования эффективной ролевой модели: время на митигирование, резолвинг, количество повторений и время реакций.

В мире высоких требований к надёжности платформ часто бывает так, что SLA становятся больше головной болью, чем инструментом стабильности. Создание SLA, которые действительно работают, а не просто выглядят красиво на бумаге, требует глубокого понимания архитектуры систем и грамотного управления ожиданиями клиентов.

В своём докладе я поделюсь, как мы прошли путь от неэффективных и бессмысленных метрик, родившихся из попыток «угодить всем», к архитектурно обоснованным SLA, которые реально работают. Вы узнаете, почему классические SLI вроде Latency и доступности прокси могут быть пустой тратой ресурсов, и как инженерное видение помогло нам найти баланс между техническими возможностями и потребностями бизнеса.

Я расскажу, как анализ компонентов платформы позволил выстроить последовательность работы, связать это с метриками и алертами, и создать план внедрения адекватных SLA. Поговорим о непростых технических компромиссах, неожиданностях, и почему инженерные лидеры не должны бояться отказаться от "фальшивых" метрик. Этот доклад — для тех, кто хочет научиться строить SLA, которые защищают ваши системы и бизнес, а не становятся причиной бессонных ночей.

Расскажу о метриках доступности: что мы меряем на фронтенде.

Основная проблема мониторинга фронтенда: большая часть кода фронта выполняется на клиенте. Но у нас есть еще и SSR.

Расскажу о том, как окутывали метриками фронт: в начале SSR, потом статика, затем пользовательские метрики.

Расскажу:
-как мониторим раздачу статики с помощью Openresty,
-что делаем для мониторинга клиентских метрик и как учитываем их при вычислении SLO,
-по каким критериям выбирали метрики доступности.

Hashicorp Vault является стандартом де-факто хранения чувствительных данных. Интегрируется он примерно с чем угодно и, естественно, с другим фактическим стандартом размещения нагрузки - Kubernetes.
Инструментов для интеграции Hashicorp Vault с Kubernetes существует немало и каждый обладает своими примуществами и недостатками, поэтому в докладе рассмотрим и сравним популярные инструментов доставки секретов из Hashicorp Vault:
- External Secrets Operator
- Hashicorp Vault Secrets Operator
- Hashicorp Vault Agent Injector
- Hashicorp Vault CSI Provider
- (Banzai Cloud) Bank Vaults-Vault Secrets Webhook
Для каждого из инструментов приведу пример настройки, рассмотрю, как именно доставляется секрет до приложения и принцип работы инструмента. Сравню инструменты с точки зрения механизмов ротации секретов, а также удобства использования. Подсвечу ограничения инструментов.

Про зеротраст говорят много. Западные решения нам недоступны, как все же сделать аналоги в России?

Новая жизнь бросает нам новые вызовы - и вот уже CNI и Service Mesh-и с EBPF под капотом это не что-то из области фантастики или экспериментов, это уже повсеместно внедряется на production инфраструктуру. Однако не так много инженеров понимают, что происходит под капотом этой системы. И еще меньше инженеров знает, как системы на базе eBPF могут быть скомпроментированы и как защититься от угроз если не полностью, то хотя бы минимизировав риски. И сегодня я расскажу вам об этом.

В докладе мы затронем следующие темы:
- Что такое bpf как технология
- eBPF и как это работает
- Атаки на удаление ключей из ebpf maps
- Kernel exploits by eBPF
- Вызов незапланированных syscalls
- Falco bypass
И другие виды атак

Astra Linux содержит ряд инструментов для обеспечения информационной безопасности, которые не всегда хорошо понимаются. Например, мандатный контроль целостности (МКЦ), который совершенно не про контрольные суммы, а про то, что даже root не всегда root. Или приносит с собой мандатный контроль доступа (МКД), который крайне непросто понимать тем, кто не занимался этим вопросом никогда.

Посмотрим на практике, что означают механизмы МКЦ и МКД, своими руками потыкаем в Astra Linux и научимся понимать, где и что нам нужно из этого использовать.

Тематика безопасной разработки становится все более и более актуальной год от года. Многие Компании реализовали несколько практик (таких, как SAST, SCA и т.д.) и вопрос управления срабатываниями сканеров становится все более значимым.

В своем докладе я расскажу про нюансы, с которыми можно столкнуться - от нюансов дедубликации срабатываний сканеров до подготовки отчетности и про возможное решение: AppSec Platform (ASOC, ASPM), какие задачи они решают, каким функционалом обладают и как они могут быть использованы для оптимизации процессов безопасной разработки

Все, что вам нужно знать про секреты, как их хранить и как обращаться с ними.

Когда у тебя большая распределенная инфраструктура, выдавать доступы разработчикам, лидам, аналитикам становится все интереснее. Конечно же, у нас есть OpenVPN, Wireguard и прочие всем знакомые инструменты, но они подходят не всегда.
В рамках своего доклада я расскажу, как мы, Магнит Омни:
-- решили вопрос предоставления доступа для разработчиков/лидов/etc. для разных окружений
-- как мы научились выдавать консистентный доступ в разные окружения
-- как нам удалось сократить время выдачи доступов с нескольких дней до 15 минут
-- как мы автоматизировали настройку Netbird VPN и превратили его в платформенный
-- и про наши "факапы"

Использование генеративных нейросетей внутри компаний дает большие преимущества бизнесу в решении определенных задач. При этом уже известны инциденты безопасности, связанные именно с пайплайном нейросетей: инъекции вредоносного контента, искажение запросов, генерация неэтичного контента, кража обучающих данных и кража моделей.

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

Доклад посвящён особенностям работы с сертификатами в среде Service Mesh. В нём обсуждаются вызовы, связанные с коротким сроком действия сертификатов, их своевременным обновлением и валидацией, включая использование CRL, OCSP и OCSP Stapling. Особое внимание уделяется влиянию истечения срока действия сертификатов на доступность сервисов и предотвращению сбоев. Также рассматриваются ограничения и возможности проверки сроков действия сертификатов на примере Istio Service Mesh.

API – это ключевой инструмент для предоставления сервисов в B2B и B2C, обеспечивающий удобство и масштабируемость. Однако даже крупнейшие компании, такие как Apple, Google и Mercedes-Benz, сталкивались с серьезными проблемами при разработке и публикации API. Эти ошибки демонстрируют, насколько важно уделять внимание безопасности и правильной организации работы с API.
Я расскажу про причины возникновения проблем с API, как их можно избежать и что вы можете повторить у себя для защиты своих API.
Эта тема актуальна для всех, кто работает с API, ведь ошибки даже крупных компаний показывают, насколько важно подходить к этому вопросу с максимальной ответственностью.

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

Работа в много-продуктовых компаниях, которые находятся под требованиями регуляторов разных стран, значительно отличается от моно-продуктовых компаний ограниченного рынка, поэтому CTO активно взаимодействует со всеми департаментами, особенно с финансовым и юридическим. Мы рассмотрим сложные кейсы, которые влияют на техническую архитектуру (сети, датацентры, средства кибер-безопасности), продуктовое развитие и которые могли бы быть упущены, если бы CTO не интересовался бы юридической частью или финансами, а финансы и юристы не взаимодействовали с CTO на постоянной основе. Также мы рассмотрим как совместно с данными департаментами принимать решения о использовании SaaS сервисов, облаков, мерах по достижению надежности, защите персональных и детских данных. Попытаемся определить error budget для юридических рисков и методы оценки их в деньгах.

В этом докладе расскажу про DevOps сообщество Сбера, посмотрим, что поменялось по сравнению с прошлыми моими выступлениями. Какие задачи сейчас решает сообщество. Кратко расскажу про реальное применение практик Platform Engineering, Internal Developer Portal и текущие вызовы в этих условиях для Operational Enabling Teams. Как обстоятельства повлияли на органичное изменение парадигмы и переход от подхода DevOps-инженер в каждой продуктовой команде к подходу сервисные DevOps команды в Трайбе. Как Operational Enabling Teams помогли сервисным DevOps командам. И традиционно по всем затронутым темам сделаю обзор граблей на которые мы наступили, какие надежды оправдались, и какие решения привели к серьезным вызовам.

Множество платформ по машинному обучению строятся на основе популярного инструмента AirFlow. Но действительно ли он так хорош или все-таки есть подводные камни?

В данном докладе я поделюсь тем, как мы решили отказаться от AirFlow и подобных ему инструментов по типу Dagster, в которых DAG/пайплайны пишутся на Python, в пользу ArgoWorkflow с написанием всего в yaml формате.
Мы поговорим о проблемах, которые возникают у достаточно большого числа команд при работе с AirFlow, в особенности при построении платформ по машинному обучению на базе Kubernetes.

"Оптимизация локальных LLM и Vision Transformers: практические аспекты быстрого и надежного инференса"
В этом докладе мы рассмотрим, как эффективно развернуть большие языковые модели (LLM) и Vision Transformers на локальных ресурсах. Вы узнаете о настройке моделей и серверной инфраструктуры, организации очередей запросов и применении структурированного декодинга для достижения высокой производительности и стабильности. Доклад предоставит практические рекомендации по созданию "Model as a Service", обеспечивающего быстрый, предсказуемый и надежный инференс.

Сейчас очень многие используют Airflow как продакшен-реди решение для оркестратора обучения ML-моделей. Все, что надо сделать пользователю - это скопировать свои даги в нужную папку. Но что делать, когда команд, использующих Airflow кластер, становится не 1, а 10, а дагов - не 100, а тысяча! В докладе расскажу, какие проблемы начинают выстреливать вместе с ростом масштаба и как их решать. Попробуем применить best practices микросервисной разработки для airflow-сервисов и превратить Airflow в удобный инструмент ML-платформы.

Канбан-метод — это метод для постоянного совершенствования любых сервисов, связанных с интеллектуальным трудом, таких как разработка ИТ-продуктов. Канбан-метод состоит из более 150 инструментов и практик, одним из которых является STATIK (Systems Thinking Approach to Introducing Kanban) - cистемный подход к применению Канбан-метода. STATIK помогает начать использовать Канбан-метод и выявляет многие неочевидные факты и детали Вашего сервиса. В ходе воркшопа мы разберем основные шаги STATIK и попробуем спроектировать Канбан-систему. Все практические задания и теория, как Вы догадались из названия воркшопа, будут метафорическими, и построенными на основе известного мультфильма "Кунг-фу Панда". После воркшопа Вы сможете применить STATIK в своем сервисе и начать эволюционные улучшения. Так что - вперед, мир Кунг-фу и Канбан ждет Вас!

Однажды мы заметили, что платформенные и стримовые команды тратят довольно много времени на выяснение потребностей заказчиков, а также на исследования способов решения проблем. При этом основная работа простаивает. Так и пилотные запуски технологий силами платформенных команд отвлекают от основного вектора работ. Чем больше становится техническая команда, тем больше возникает сложностей в том, чтобы сориентироваться в коммуникациях и процессах. Помимо снятия когнитивной нагрузки с товарищей, команда enable занимается тем, чтобы наладить процессы взаимодействия с инфраструктурой.

Если вы задавались вопросом, куда вам расти как инженеру и каким образом — этот доклад для вас.
Если задумывались, как строить модель грейдов в компании — для вас тоже.
Если ломали голову над проблемой, как при росте избежать превращения хорошего инженера в плохого менеджера — вы тоже найдете для себя пользу.

В докладе я разберу модель деятельности, построенную на базе нескольких измерений: уровень ответственности, умение решать разные классы задач, знание предметной области, экспертное знание инструментов.

Модель универсальная, рост по любому измерению приведет вас к профессиональному росту в какой компании бы вы ни находились. Тем не менее, в разных компаниях карьерные пути разные, и профессиональный рост не всегда приводит к росту грейда или зарплаты— сопоставить модель с контекстом вашей компании вам придется самостоятельно.

Вынесем операционные процессы сервисной команды из-за закрытых дверей.

Расскажу о процессах, которые удаляют от ситуативных реакций и фокусируют на пользе:
- Доставка ценности: Как мы подошли к организации работы с собственной поставкой, целеполаганием и синхронизацией со смежниками (разработка)
- Регулярные каденции: Почему ретро полезно в SRE команде? Как мы используем его с инцидентами и привлекаем смежников?
- Управление аварийными ситуациями: Как подготовиться к "пожару" ДО принятия сервиса на поддержку и минимизировать влияние человеческого фактора на его решение;
- Нагрузочное тестирование: Типичный инструмент для продуктовой команды - когда и зачем он полезен SRE?
- Дежурства: Стратегии организации, как построить работу с дежурствами так, чтобы команда не выгорала
- Онбординг: Когда в компании много инструментов, в команде десяток сервисов и несколько десятков контактов - новички очень дороги, поделюсь лайфхаками, как нивелировать эти проблемы
- Выхлоп из деятельности команды: ранбуки, постмортемы и другие артефакты - как организовать их полезно и нужно ли их выпускать

В нашем круглом столе постараемся максимально затронуть и разобрать такие болезненные темы, как:

- как организовать онбординг для новичков
- лидерство-служение миф или реальность?
- как выбраться из своего колодца и донести свою точку зрения?
- кто же такой DevOps? Должен ли DevOps уметь общаться?

Я — Engineering Manager, и я из той самой касты людей, которые достают вас вопросом "Какой статус?".
Поверьте, на самом деле я не хочу его задавать. И я не хочу мешать вам работать. Давайте я расскажу вам, как сделать так, чтобы я от вас отстала.

Ответ лежит в организации работы над вашими задачами и коммуникациями о них.
В докладе поговорим про три типа таких задач:
- Рядовые;
- Критичные;
- С высоким влиянием на ландшафт и потребителей.
Вы узнаете, как при работе с такими задачами сохранить свои нервные клетки, рабочее время и хорошие отношения с коллегами других профессий.

Расскажу о трехлетнем опыте использования Канбан-метода в небольшой команде DevOps-инженеров. Отвечу на самый главный вопрос "Зачем?" Расскажу с чего начали, как провели воркшоп STATIK (Systems Thinking Approach to Introducing Kanban) - cистемный подход к применению Канбан-метода, какие инсайты обнаружили в ходе STATIK и чем он помог. Поделюсь возникшими трудностями на пути применения Канбан-метода в нашей команде и как их решали, чего достигли и что не получилось. Покажу, какие метрики эффективности выполнения задач мы считаем и насколько помогают для этого Канбан-инструменты. Обсудим, что может помешать прозрачности работы и как работать с заказчиками, вырабатывать правила и достигать соглашений.

Главное: онбординг – это задача команды, а не менеджера или HR-отдела!
Почему? Потому что именно с командой новичок будет работать, усиливать ее и делать жизнь проще и продуктивнее. Перекладывать ответственность на тех, с кем он не будет тесно взаимодействовать, – не только неэффективно, но и просто глупо!

Темы семинара:
• Передача ответственности за онбординг от HR к команде.
• Почему бадди – это не “опция”, а ключевая роль в процессе онбординга.
• Создание, актуализация и геймификация плана онбординга (руками команды).
• Self-assessment как основа эффективной адаптации.

Вы узнаете, как сделать так, чтобы онбординг стал мощным инструментом не только для адаптации новичков, но и для укрепления самой команды. Это не только про то, чтобы “обучить нового сотрудника”, но и про то, чтобы с первых дней строить продуктивное, сильное взаимодействие внутри команды.

В докладе мы покажем, в чем основное различие Enabling-команд и команд с "Инженерами на час"?
Расскажем о нашем видении того, какие типы команд наиболее востребованы в Enterprise.
Разберемся: взаимоисключают ли друг друга эти типы команд или можно построить что-то среднее?
Поделимся нашим опытом построения Enabling-команды.

Часто слышу миф, что Docker Swarm давно забросили, а также неподдельное удивление в сообществе, что Docker Swarm всё же жив. Хочу разобрать, откуда возникли данные мифы, когда стоит реально выбрать Swarm, какие плюсы и минусы данного решения, best practice и DRP-план.

Около 2 лет назад от СТД “Петрович” отделилась продуктовая ИТ-компания “Петрович-Тех”, созданная для закрытия потребностей СТД. Бывший ИТ-департамент стал полностью самостоятельной единицей, а также значительно вырос - и по численности сотрудников, и по уровню решаемых задач.
Уровень сервисов и их доступность стали ключевыми показателями, под которые появилась необходимость перестроить процессы молодой ИТ-компании.
Как масштабировать и перестроить процессы бывшего департамента под структуру компании и новые отношения с заказчиком? Ответ мы нашли в адаптации ITIL под наши потребности и готовы поделиться своим маршрутным листом: на примерах и с кейсами.

Т-Банк известен тем, что у нас нет отделений, а все наши клиентские продукты и их поддержка опираются на ИТ-решения, в основе которых лежит ИТ-инфраструктура — серверы, хранилища, сетевое оборудование и так далее. На инфраструктуре работают десятки тысяч виртуальных машин и сотни тысяч контейнеров. Инфраструктура динамически меняется каждый день, удваивается год к году, а затраты на ресурсы составляют десятки миллиардов рублей в год. Каким командам принадлежат эти тысячи ИТ-объектов? Как эти объекты нагружены? Сколько стоят ресурсы для каждого продукта и как эти затраты влияют на его юнит экономику? Достаточно ли командам ресурсов для масштабирования ИТ-систем при взрывном росте клиентской базы? Нам было важно знать точные ответы на эти вопросы, чтобы эффективно управлять нашими мощностями и расходами.

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

Доклад посвящен переходу от Billing к Capacity Management в сложной инфраструктуре Kubernetes.

Я расскажу, как мы в условиях многокластерной архитектуры и множества команд внедрили прозрачные процессы учета ресурсов, оценки их использования и нахождения точек для оптимизации.

Доклад затронет текущие вызовы, подходы к решению сложностей подсчета ресурсов и примеры внедрения инструментов для анализа и прогнозирования потребностей.

Netbox - точка истинности или стейт

Что выбрать в качестве источника правды об инфраструктуре? А если инфраструктур несколько? А еще у нас несколько разных гит и разные подходы по формированию гит репозиториев, где необходимо использовать знания об инфраструктуре - тут оставлю вопрос открытым. У нас netbox и все :) анализ и выбор это отдельная тема. Оставлю на ваше самостоятельное исследование.

Netbox как инструмент по хранению знаний про железную часть инфраструктуры и про виртуальную часть. ИП адреса, кабели, серверы, стойки и прочее. Сразу есть API по работе со всем этим.

Дает ли внедрение ощущение спокойствия и точки истинности?
Система по хранению информации - Netbox.
Синхронизация информации из реальной инфраструктуры в Netbox и уведомление о не соответствии.
Процесс работы с инфраструктурой - нет в Netbox нет в инфраструктуре. Создаем объект в Netbox и на основе данных из netbox создаем реальный объект инфраструктуры.

Netbox дает информацию начиная с групп серверов. Выше уже другая система, Backstage - информация о продуктах, информационных системах и на каких они группах серверов работают.

Какие проблемы сейчас решаем в использовании Netbox в нашей инфраструктуре:
- Облако и невозможность использования ansible для создания и управления конфигурацией ВМ. Как подружить terraform и получение данных о ВМ из Netbox, да еще Netbox практически «стейт».
- Многие продукты инфраструктуры хотят в Netbox хранить свои переменные, но в Netbox нет нормальное ролевой модели.
- Netbox и масштабирование нагрузки на него.

Что может побудить нас переехать в облако? А обратно? Достаточно ли хорошо мы понимаем, какие подводные камни обнаруживаются в любом из этих путей? В докладе я бы хотел затронуть тему не самых очевидных нюансов, с которыми столкнется инженерная команда, которая выбирает ту или иную дорогу. Как водится, с каждой из сторон множество плюсов и минусов, поэтому мы с вами попытаемся понять, как выбрать вариант подходящий именно для вас, а не только потому, что так модно/молодежно, и обратим внимание на скрытые факторы, с которыми мы столкнулись благодаря большому опыту миграций различных инфраструктур в обе стороны.
Рассмотрим мы следующие вопросы:
- Скрытые затраты миграции, сколько на самом деле стоит это мероприятие?
Детализация этапов миграции: анализ затрат на подготовку, миграцию, обучение комманды, перестройку процессов
Сравнение реальных расходов с ожидаемой экономией
Примеры кейсов компаний, которые столкнулись с неожиданными затратами
Метрики: как оценивать ROI миграции
- Временные проблемы или сигнал к миграции?
Анализ “тревожных звоночков”: рост требований к производительности, устаревшая инфра, трудности масштабирования
Сценарии выбора: когда временные проблемы действительно требуют миграции, а когда можно обойтись оптимизацией текущей инфры
- Инфраструктурные риски
Категории рисков: физические (отказ оборудования), программные (устаревший софт), киберугрозы
Риски при переходе в облако: зависимость (вендор-лок)
- Влияние облака/on-prem на обновление/устаревание технологий
Жизненные циклы инфры, как меняется подход к обновлениям
Стоимость обновлений в обоих сценариях
Как облако решает “устаревания”
- Скрытые (неочевидные) ограничения облаков
Технические ограничения: специфика работы с API, зависимость от скорости ответа
Ограничения на перенос данных между регионами
Кейсы, когда облачные сервисы не подходили для задач компании
- Эффективность затрат: когда “дешевле” в облаке не значит “дешевле”
Сравнение моделей: pay-as-you-go vs. капитальные вложения в on-prem
Штрафы за превышение лимитов или несоблюдение контрактов, перенос данных, лицензирование
- Юридические и контрактные ограничения, которые приходят вместе с облаком
Соблюдение законодательства (о перс. данных, etc..)
Кто несет ответственность за инциденты (учетка данных, сбои в работе)
- Управление и мониторинг: чем отличается контроль инфраструктуры в on-prem и облаке
Автоматизация: как облако упрощает мониторинг и управление
Сравнение инструментов: традиционные vs. облачные
- Архитектура отказоустойчивости: кто справляется лучше — облако или on-prem?
Параметры отказоустойчивости: что включает в себя архитектура в обоих случаях
Кейсы: примеры успешных и неуспешных решений в облаке и on-prem
Гибридные варианты
- Качество сервисов: почему SLA облака не всегда соответствует реальности
Анализ: что включает SLA и как его интерпретировать
Всегда ли оператор выполняет свои обещания
Независимый мониторинг, стресс-тесты инфры

Островок растёт семимильными шагами как в плане бизнеса, так и с точки зрения инфраструктуры. Начиналось всё с десятка серверов в одной стойке, а сейчас это свыше 500 серверов в нескольких локациях, поддерживаемые небольшой командой.
В докладе расскажу, как мы попробовали облака и отказались от них. Как пережили ковид и бурный рост. Какими инструментами мы управляем всем нашим парком серверов, а также какие планы на будущее и почему всё-таки железо с примесью клауда.

On-premise инсталляции K8s и похожи, и непохожи на обычные облака. Базовые механизмы одни и те же, но условия эксплуатации совершенно другие. В on-premise невозможно быстро докупить ресурсы, чтобы повысить эффективность использования ресурсов, надо гибко управлять тем, что есть в наличии. Нам казалось, что самое сложное - это придумать и реализовать эффективный алгоритм перераспределения ресурсов, но оказалось, что это только начало пути. В докладе подробно расскажем про все сложности, которые встретились на пути запуска собственного on-premise автоскейлера.

Расскажу о нетворкинге (не путать со смол-током):
* ЗАЧЕМ?!
* что это за общение и как быть целеустремленным в любой коммуникации,
* с чего начать разговор,
* чем продолжить,
* как закончить,
* как обменяться контактами,
...произведя правильное впечатление.

Участники мастер-класса унесут с собой
* наброски рассказа о себе несколькими способами,
* понимание ЧТО, КОМУ, О ЧЁМ и КОГДА рассказывать,
* какие и кому задавать вопросы.

Сколько часов в день вам не хватает, чтобы всё успеть?
Насколько вы довольны своими навыками управления временем?

За последние 15 лет я побывал в роли предпринимателя, CTO, продакт-менеджера, программиста, консультанта. Нехватка времени - это моя большая боль. И я перепробовал десятки инструментов тайм-менеджмента.

Исследуя проблему нехватки времени, я пришёл к выводу, что нехватка времени — это не про время. Это симптом, за которым скрывается настоящая причина: нехватка энергии, прокрастинация, расфокус и несколько других.

Я поделюсь результатами своего исследования, и расскажу, какие системные причины приводят к нехватке времени.

Также, я поделюсь инструментами, подходами и лайфхаками, которые лично мне помогают управлять своим временем - просто и достаточно эффективно.

Помимо этого я расскажу, как понимание нейробиологии и физиологии поможет лучше управляться со временем.

Идеальным результатом выступления для меня будет, если ты найдёшь для себя один подходящий инструмент, и внедришь его в этот же день.

На круглом столе обсудим состояние и проблемы DevOps сообществ в России.

SLO и SLI. Надежность - это не ответственность SRE, а инструмент и показатель всей команды. Так ли это?
Как готовить SLO. Работает ли бюджет ошибок в реальном мире?
SLO - когда их можно/нужно пересматривать?
Бюджет - Плохая минута или бюджет ошибок ? Когда что использовать?
Когда минута считается плохой, если в это время пользователь не пользовался услугами вашего сервиса?

Поговорим, обсудим что получилось и что нет.
Обсудим темы на следующую конференцию, на что надо уделить внимание, а что и так хорошо.
Любые другие вопросы на тему конференции тоже можем обсудить.

Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!

В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.

Далеко не многие знают как ломать Kubernetes, а тем более как ломать Куб, когда его нет. В докладе я поделюсь своим опытом проведения аудита кластеров еще на стадии проектирования, когда на руках есть только Cluster API манифесты будущих Kubernetes. Подсвечу интересные моменты, что там можно найти, а чего нельзя, и конечно же расскажу как автоматизировать этот процесс.

Описание личного опыта реализации процесса по созданию и поддержки инфраструктуры k8s различных уголках мира.
В своем докладе подробно раскрою темы
- Выбора единой OS для Kubernetes для разных типов установки
- Анализ и типы развертывания которые пришлось реализовать в примерах
- Смена парадигмы с GitOps на OCIOps
- Вся правда о fluxcd
- организация проекта
- поэтапной процесс тестирования и деплоя в разрезе региона/зоны/типа кластера (с примерами и визуализацией)
- организация процесса за ошибками
- Как реализовать поддержку кластера и баз данных если к нему нет прямого доступа через агенты
- Как обеспечить декларативное обновление ваших кластеров k8s

Ситуация: вы разработчик, который хочет протестировать новую фичу, но интеграционный контур занят коллегами. Вы вынуждены ждать, и это замедляет работу. Плюс, когда наконец удается провести тест, что-то ломается из-за изменений других разработчиков.
В докладе мы разберем, как решить эту проблему с помощью личных стендов:
— про наш опыт создания автоматизированных стендов "по кнопке"
— как внедрить kyverno для автоматической очистки и поддержки стендов
— Разберем сложности реализации: создание интерфейса, пайплайнов, управление ресурсами

Предоставить пользователям аналитическую базу данных - это не просто поднять гринплам, кликхауз или купить на них подписку. На примере внедрения в платформу данных базы нового поколения Starrocks (https://www.starrocks.io) расскажу про обеспечение необходимого минимума функционала и автоматизации для потребителей - инженеров данных, инженеров-аналитиков или разработчиков dwh.
Постараюсь ответить на вопрос - каким требованиям должны удовлетворять инсталляции и сами движки баз, особенно, если вы как поддержка хотите спать по ночам и не вздрагивать при словах "обновление", "блокирующие операции ddl" или "отказ мощностей".
В докладе будет k8s (куда же без него в современном мире), сервисы миграций, аутентификации и авторизации, dbt как сервис - и все это приправлено щепоткой golang и gitlab-ci.

Kubernetes отлично подходит для оркестрации, масштабирования и управления контейнерезированными приложениями, но всегда ли он нужен?
В докладе я расскажу о кейсах из практики, когда внедрение Kubernetes для проектов не оправдало ожиданий или пошло во вред. Отдельно остановлюсь на технических и экономических плюсах и минусах Kubernetes.

В современном мире разработки ПО системы CI/CD играют ключевую роль в обеспечении качества, надежности и скорости релизов. На основе реального примера пайплайна для Python приложений я расскажу:

Архитектура пайплайна:
- Структура и ключевые этапы: подготовка, тестирование, миграции, сборка и деплой.
- Управление версиями и хранилищами образов, подходы к публикации сборок.

Оптимизация использования кэша:
- Эффективное использование poetry.lock для кэширования окружения помогает сократить время на установку зависимостей.
- Генерация уникального ключа для кэша и ускорения сборок

Миграции базы данных:
- Как организовать автоматизированный процесс создания и отката миграций.

Тестирование и покрытие кода:
- Использование pytest и Allure для контроля качества на каждом этапе.
- Автоматическое управление отчетами Allure через настройки пайплайна

Особенности релиза и деплоя:
- Как разделять окружения (test, preview, production) и эффективно использовать Kubernetes.

Динамическое управление ревьюерами:
- Автоматическая привязка ревьюеров на основе группы и списка для ускорения code review

Комплексное управление артефактами:
- Чистка артефактов на основе регулярных выражений и ограничения количества
- Разделение артефактов для миграций и основной сборки

Результаты: Участники узнают, как построить CI/CD-процесс с учетом особенностей Python приложений, включая безопасность, миграции и многоэтапное тестирование.

Что если нам нужно билдить, а раннер занят, что если ждать не выход? Нужно начать оркестрацию раннеров? А можно и сделать что-то похожее. Если у нас не хватает ресурсов на поддержание K8S кластера для автоскаллирования раннеров, то нам на помощь может прийти небольшой Nomad. Рассмотрим как же экономно скаллировать раннеры без особого вреда для ресурсов нашей инфраструктуры. В каких случаях это полезно, а в каких лучше не прибегать к такому решению. Рассмотрим то, что нужно сделать, чего стоит избежать и на чём особенно заострить внимание. В итоге, скаллируем раннеры при помощи Nomad, практически в авто режиме.