Доклады

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Многие слышали о 1С. Но что вы знаете о программных продуктах 1С?

Уверен, первое, что всплывает в головах, что 1С — это бухгалтерия, зарплата — сервак на базе i5, 10-15 пользователей... Но это далеко не так.

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

Если интересно, приходите я расскажу много интересного!

Вряд ли найдётся человек, которому в любом стандартном дистрибутиве Linux — даже в его любимом — нравится абсолютно всё. Однако на сегодняшний день ОС Linux уже настолько широко применяется, что под задачи приходится использовать разные дистрибутивы, и — самое главное — нередко ещё и каждый раз донастраивать, в том числе в целях экономии ресурсов. Поэтому особенно в малых и в средних по масштабу проектах это порождает достаточно объёмный фронт работ, так как тяжёлые вещи вроде Ansible и K8s не ставят своей главной целью оптимальное расходование ресурсов. И именно так и начал создаваться дистрибутив в рамках проекта Hypersphere — это максимально настраиваемая и автоматизируемая Hypersphere OS.

Попытки унифицировать разные задачи и подходы предпринимались неоднократно, но особого распространения и жизнеспособного конечного продукта с открытым исходным кодом, доступного каждому, не получали — взять тот же kFreeBSD. С этим непросто что-то сделать, но удалось сделать дистрибутив с ядрами Linux или BSD на выбор, к которому под капот мы и заглянем. Так же станет логически понятно, почему предыдущие попытки «не взлетели» в нужном направлении.

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

Приходите со своими задачами и вопросами — посмотрим на них со стороны Hypersphere OS на практике!

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

В первой части доклада будет дано краткое введение в Puppet Bolt. Во второй части будет представлено несколько примеров использования — как обычных, так и весьма нестандартных.

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

Как эффективно управлять большими объемами данных и не потерять в производительности, как адаптировать инфраструктуру под такие объемы и нагрузки?

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

Сеть доставки контента RUTUBE — это 250+ железных серверов, расположенных по всей стране и даже ближнему зарубежью, сети операторов, много nginx и самописное ПО, которое всем этим управляет.

Данная сеть раздаёт 7 Тбит/с данных не только для национального видеохостинга RUTUBE с 70 млн пользователей в месяц, но и для некоторых других Цифровых Активов «Газпром-Медиа Холдинга».

Поговорим о том, как устроен CDN RUTUBE с инженерной точки зрения: аппаратной, сетевой и программной.

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

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

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

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

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

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

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

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

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

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

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

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

В докладе мы разберём, что такое распределенный трейс, из чего он состоит и как собрать все его части воедино, чтобы получить цельное представление о запросе. Обсудим, почему сбор и хранение всех трейсов не всегда оправданы и как семплирование помогает снизить нагрузку на систему без потери ключевой информации. Рассмотрим два основных подхода — head-based- и tail-based-семплирование, разберём их принципы работы, алгоритмы реализации, преимущества и ограничения.

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

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

Также рассмотрим различные принципы сбора телеметрии для систем, откуда и какие данные мы сможем достать без модификации приложения.

Mimir – относительно молодой инструмент от разработчиков целого стека observability. Почему так мало о нем известно? Он хороший или плохой? Чем отличается от уже известных решений, нужен ли вообще?

Когда мы говорим о long-term, что мы имеем в виду? Долго или много, если долго, то как часто, если много, то сколько это?

В докладе расскажу:
* почему мы выбрали mimir, какие рассматривали альтернативы;
* что нужно, чтобы использование инструмента было удобным;
* с чем придется столкнуться при внедрении mimir, подводные камни;
* наш опыт, и что мы планируем дальше.

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

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

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

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

О том, как получать, хранить и анализировать метрики «с того конца», поговорим в этом докладе с CDN-сетью в качестве наглядного примера.

Думали о том, как сделать отказоустойчивый распределенный master-master-кластер Кubernetes? Вот и я думал.

Обсудим, почему так сложно взять и «размазать» кластер К8s на несколько ЦОДов и какие есть нюансы у service mesh. Рассмотрим компонент Cilium для создания распределенных кластеров — Cluster Mesh, его архитектуру. Пройдемся по шагам создания cluster mesh, а также сломаем межкластерную связь. Погоняем бенчмарки и попробуем ответить на вопрос: «Готов ли Cluster Mesh для прода?».

Все мы пользуемся DNS, но не все автоматизируют управление. От этого во внутренних (и иногда внешних, sic!) инструкциях появляются "echo '1.2.3.4 my.demo' >> /etc/hosts".

В своем докладе я поделюсь ready to use-примерами и расскажу про:
* автоматизацию управления DNS-зоной через git;
* создание собственного no-ip-сервиса в закрытой сети;
* плагины CoreDNS для Kubernetes;
* собственный плагин для CoreDNS — это просто.

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

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

Также обсудим возможные сложности при эксплуатации реестров, вопросы масштабирования. Рассмотрим преимущества и ограничения как self-hosted-решений (Artifactory, Nexus, GitLab Registry, Harbor), так и облачных сервисов контейнерных реестров.

Эта сессия обязательна к посещению для профессионалов, желающих углубить свои знания в области управления образами Docker, построения и эксплуатации реестров контейнеров, а также защиты доступа и эффективной интеграции реестров в CI/CD-процессы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как масштабировать инженерные практики в условиях крупной компании? На воркшопе вы узнаете, как создавать, внедрять и измерять практики, которые ускорят Time to Market, улучшат процессы и повысят качество продуктов. Вас ждут реальные кейсы, шаблоны для разработки и работа в группах над созданием новой практики.

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

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

Что подготовить?
Мы предоставим все материалы для работы, включая шаблоны и раздаточные материалы. От вас — только активное участие!

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

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

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

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

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

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

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

Хотите раскрыть безграничный потенциал Jenkins и превратить его в универсальную платформу? На моем докладе вы узнаете, как с помощью JavaScript, Groovy и других языков создавать внутри Jenkins всё — от параметризированных сборок до собственных веб-приложений. Забудьте о сложных инструкциях: пользователь нажимает кнопку, а Jenkins решает все остальное. Я покажу секреты кастомизации и безопасности, чтобы ваша система была и удобной, и надежной. Приходите — и вы сможете делать в Jenkins всё!

Автоматизация генерации release notes — это хорошо, а можно ли лучше?

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

tbd

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

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

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

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

Уже давно все оценили преимущества и удобства Gitlab. Даже пришли к тому, что хотим использовать бесплатную версию.

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

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

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

«Devcontainers — ваш ключ к унифицированному и безопасному окружению для разработки».

Представьте, что у вас есть универсальный инструмент, который решает сразу целый класс проблем команды разработки:
* настраивает локальное окружение проекта одной кнопкой;
* унифицирует окружение для всех разработчиков на разных операционных системах и аппаратных архитектурах;
* обеспечивает безопасность инфраструктуры;
* упрощает CI;
* позволяет строить крутые платформенные решения;
* помогает контрибьюторам опенсорс-проектов быстрее начать работать с кодом;
* открывает возможность для разработки в облачных IDE.

Всё это — девконтейнеры! Да, мы начинаем программировать прямо в контейнере. Такой подход позволяет создавать готовые к работе окружения, которые содержат всё необходимое для разработки, управляются из кода (IaC), версионируются и быстро стартуют, а также работают на любых ОС и аппаратных платформах (arm/x86). С их помощью можно не только унифицировать окружение для всех разработчиков, но и обеспечить безопасность инфраструктуры на уровне базовых образов, а также строить крутые платформенные решения внутри вашей организации и, конечно, упростить работу с опенсорс-проектами. И всё это бесплатно и без необходимости развертывания новых сущностей в вашей организации. О такой кнопке «сделать хорошо» мы и поговорим в докладе.

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

Совершенно неожиданно мы столкнулись с проблемой продления лицензии на Gitlab EE и озадачились вопросом, а как жить дальше?

В своём докладе я расскажу:
* как мы выбрали Gitlab CE и почему именно его;
* как мы компенсировали недостающие фичи;
* как мы управляем гитлабом as a code;
* как задача миграции в новый гитлаб вылилась в аудит всей разработки компании.

Будет много боли, сомнительных решений и удивительных открытий!

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

Совершенно точно нужно обеспечить ученикам комфортную, технически исправную и одинаковую среду обучения. Совершенно точно нужно помогать ученику. Кажется, не выглядит как работа для DevOps? Нет, как раз самое оно.

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

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

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

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

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

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

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

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

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

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

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

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

Мы в Туту 6 лет назад командой из пяти инженеров построили с нуля и с тех пор продолжаем развивать IТ-платформу. У нас был гринфилд, бэкендеры переходили на Go и строили под себя новые процессы разработки.

В докладе с примерами из нашего опыта я расскажу:
* когда есть смысл вкладываться в платформенную разработку с нуля;
* без чего точно не получится хорошая IТ-платформа;
* какие архитектурные решения нужно принимать в начале;
* почему нам нужен Kubernetes и как мы его используем;
* почему мы используем Tekton для CI/CD;
* как выстроить коммуникации с продуктовыми командами: code of conduct, зоны ответственности и SLA;
* как договориться с бизнесом и посчитать эффективность IТ-платформы.

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

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

В процессе роста и развития dev-окружений мы пришли к интересной реализации внутренней платформы разработки,
которая соответствует требованиям ИБ, инженеров и разработчиков.

В докладе я расскажу, как мы прошли путь от виртуалки к vCluster и автогенерации Kubernetes-кластеров. Мы подробнее остановимся на вопросах внутреннего устройства vCluster и практиках его применения. Я поделюсь опытом, как мы смогли справиться с очередью к dev-стендам и сделать масштабируемое решение.

Два извечных вопроса: кто виноват и что делать? В своем докладе я хочу рассказать про культуру без обвинений и смещение фокуса с вопроса «кто виноват?» на «что делать?».

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

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

Я порассуждаю о любви к ближнему своему, о психологии и о том, как это все связано с инцидент-менеджментом.

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

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

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

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

Уже давно не секрет, что в Т-Банке есть своя observability-платформа Sage. Внутри банка мы предоставляем сервис мониторинга, у которого ежедневно более 7000 активных пользователей (DAU). И, как это принято, у нас есть SLA с нашими пользователями, но «как понять, предоставляем ли мы сейчас услугу или нет?» — именно с этого вопроса начинается мой рассказ о построении SLOs/SLIs для нашей платформы Sage. Метрики для метрик.

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

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

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

Lamoda, как один из крупнейших игроков на рынке e-commerce, накопила значительный опыт в решении инцидентов и их последствий. Нам удалось существенно сократить downtime, уменьшить бэклог пост-инцидентных задач на 200% и увеличить скорость решения инцидентов.

В рамках доклада мы разберём:
* как использование эффективных ролевых моделей может кратно сократить решение инцидента;
* почему следует разделять роли, а не совмещать их;
* как мы сократили время митигации инцидента на 70%;
* как добиться 100% точной информации в инциденте в Jira и исключить ошибки и неверную статистику на выходе;
* как «Учения» помогут уменьшить время эскалации на 50%.

Подход Lamoda Tech применим не только для крупных компаний, но и для тех, у кого нет большого штата IT OPS. Наш опыт поможет вам построить инцидент-менеджмент, даже если вы всего один и вы стартап.

Вы убедитесь, что даже с минимальными вложениями можно значительно повысить эффективность управления инцидентами и снизить их влияние на бизнес. Как именно? Расскажем на докладе.

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

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

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

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

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

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

В докладе я расскажу, с какими вызовами мы столкнулись на пути внедрения единой системы эскалации алертов. Нырнем в прошлое и посмотрим, как алерты обрабатывались годом ранее, вернемся в настоящее и детально рассмотрим весь путь автоматизации эскалации алертов. Поделюсь с вами tips and trick в надежде обезопасить ваш путь в автоматизацию OnCall :) И бонусом затрону тему, как маленький алерт вырастает в большой инцидент, и расскажу, как мы сократили время сбора команды для устранения инцидента.

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

Расскажем о нашем подходе и его эволюции:
* от индивидуальных DRP-планов систем к BCP/BCM, построенному от рисков;
* важность актуального DRP, и что бывает, когда его нет;
* SRE-практики — рядом, но совсем не то же самое;
* наш путь в создании DRP, его этапы — что мы переосмыслили и переделали;
* DRP каждой системы — как относительно быстро и просто это можно сделать;
* риск-ориентированный подход и комплексный DRP компании;
* что общего между AD&D и DRP;
* жизненный цикл DRP и в условиях динамических ландшафтов.

Для корпоративных систем телекома и не только требуется высокая доступность с неизменным качеством.

В докладе говорится о том, как в сервисах МТС применяются практики SRE, проводится параллель с практиками в Google, основываясь на Google SRE book.

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

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

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

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

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 могут быть скомпрометированы. Как защититься от угроз в таких системах если не полностью, то хотя бы минимизировав риски? Какие опасности таит EBPF? Пристегните ремни — мы отправляемся в глубины ядра!

В докладе мы затронем следующие темы:
* что такое EBPF как технология, почему она настолько популярна, какие преимущества дает;
* как EBPF помогает нам решать проблемы безопасности систем (реализация SDN (Software-Defined Network) без использования прокси-агентов, LSM API, присоединение к внутренним функциям ядра на базе Tetragon);
* BPF для пентестов;
* сетевой BPF: атаки и способы обнаружения BPF вредоносов в сети;
* руткиты и BPF: как писать и как детектить;
* как можно ограничивать доступ к ресурсам Linux вместе с BPF;
* EPF Security Threat Matrix (какие угрозы существуют, как с ними бороться, и какие атаки с нами уже в одной комнате).

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

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

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

В своем докладе я расскажу про сложности, с которыми можно столкнуться: большое количество «окон для работы», нюансы нормализации и дедубликации, расстановка приоритетов по устранению ИБ-дефектов, управление задачами и т. д.

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

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

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

Доклад полностью посвящен работе с секретами. Мы узнаем, какие угрозы существуют, рассмотрим атаки на компрометацию секретов, разберемся, от всего ли спасет Vault, затронем вопросы доставки секретов в k8s, узнаем, как дизайн работы с секретами влияет на безопасность приложения.

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

В рамках своего доклада расскажу, как мы в Магнит OMNI:
* решили вопрос предоставления доступов для сотрудников разных направлений;
* научились выдавать консистентный доступ в разные окружения;
* сократили время выдачи доступов с нескольких дней до 15 минут;
* автоматизировали настройку Netbird VPN и превратили его в платформенный ВПН.

Также расскажу про факапы, связанные с обновлением Netbird, пользователями, маршрутами, шлюзами, etc.

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

Вы узнаете о типичных ошибках при настройке mTLS в Service Mesh, познакомитесь с механизмами проверки и отзыва сертификатов, а также получите практические рекомендации по построению действительно защищенной инфраструктуры.

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

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

Через незакрытые уязвимости часто происходит взлом той или иной компании.

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

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

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

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

Также мы рассмотрим, как совместно с данными департаментами принимать решения об использовании SaaS-сервисов, облаков, мерах по достижению надежности, защите персональных и детских данных.

Попытаемся определить error budget для юридических рисков и методы оценки их в деньгах.

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

Развертывание больших языковых моделей (LLM) на локальных ресурсах — это путь от экспериментальных скриптов к промышленному сервису, где стабильность и скорость критичны. В докладе мы разберем, как превратить «сырую» модель в предсказуемый MaaS: от настройки параметров модели и конфигурации оборудования до проектирования инфраструктуры с балансировкой нагрузки. Вы узнаете, как избежать типичных ошибок — от перегруза серверов до неконтролируемой генерации — и обеспечить низкий latency даже при пиковых запросах.

Основой выступления станет реальный кейс: развертывание LLM для задачи суммаризации в корпоративной среде с демонстрацией метрик «до» и «после».

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

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

Мы поговорим о проблемах, которые возникают у достаточно большого числа команд при работе с AirFlow, в особенности при построении платформ по машинному обучению на базе Kubernetes.

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

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

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

В ходе воркшопа мы разберем основные шаги STATIK и попробуем спроектировать Канбан-систему. Все практические задания и теория, как вы догадались из названия воркшопа, будут метафорическими и построенными на основе известного мультфильма «Кунг-фу Панда».

После воркшопа вы сможете применить STATIK в своем сервисе и начать эволюционные улучшения. Так что — вперед, мир Кунг-фу и Канбан ждет вас!

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

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

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

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

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

Расскажу о процессах, которые удаляют от ситуативных реакций и фокусируют на пользе:
* доставка ценности: как мы подошли к организации работы с собственной поставкой, целеполаганием и синхронизацией со смежниками (разработка);
* регулярные каденции: почему ретро полезно в SRE-команде? Как мы используем его с инцидентами и привлекаем смежников;
* управление аварийными ситуациями: как подготовиться к «пожару» ДО принятия сервиса на поддержку и минимизировать влияние человеческого фактора на его решение;
* нагрузочное тестирование: типичный инструмент для продуктовой команды — когда и зачем он полезен SRE;
* дежурства: стратегии организации, как построить работу с дежурствами так, чтобы команда не выгорала;
* онбординг: когда в компании много инструментов, в команде десяток сервисов и несколько десятков контактов — новички очень дороги. Поделюсь лайфхаками, как нивелировать эти проблемы;
* выхлоп из деятельности команды: ранбуки, постмортемы и другие артефакты — как организовать их полезно и нужно ли их выпускать.

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

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

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

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

Главное: онбординг — это задача команды, а не менеджера или HR-отдела!

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

Темы воршопа:
* передача ответственности за онбординг от HR к команде;
* почему бадди — это не «опция», а ключевая роль в процессе онбординга;
* создание, актуализация и геймификация плана онбординга (руками команды);
* Self-assessment как основа эффективной адаптации.

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

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

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

Поделюсь нашими планами и видением развития нашей Enabling-команды.

3 года назад от СТД «Петрович» отделилась продуктовая IТ-компания «Петрович-Тех». Понадобилось масштабировать процессы под показатели уровня и доступности сервисов. Как перестроиться под новые отношения с заказчиком? Мы нашли ответ в адаптации ITIL и готовы поделиться маршрутом: на примерах и с результатами.

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

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

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

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

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

Я расскажу о Netbox как о точке правды по «железной» и серверной инфраструктуре. Как мы добились действительно правдивой информации в Netbox. О процессах вокруг Netbox, построенных нами для этого. И об автоматизации вокруг Netbox.

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

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

Рассмотрим мы следующие вопросы:
* скрытые затраты миграции, сколько на самом деле стоит это мероприятие;
* метрики: как оценивать ROI миграции;
* временные проблемы или сигнал к миграции;
* инфраструктурные риски;
* влияние облака/on-prem на обновление/устаревание технологий;
* управление и мониторинг: чем отличается контроль инфраструктуры в on-prem и облаке;
* архитектура отказоустойчивости: кто справляется лучше — облако или on-prem.

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

В докладе подробно расскажем про все сложности, которые встретились на пути запуска собственного on-premise-автоскейлера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Делюсь своим опытом и решениями по процессу доставки и поддержки коробочного продукта у клиентов по всему миру.

Я затрону следующие темы:
* выбор базовой ОС: как этот выбор помог стандартизировать процессы и обеспечить совместимость с различными средами. Сравним Flatcar/Ubuntu/Bottlerocket/Kairos/Talos;
* преодоление сложностей установки: как мы справились с ограничениями доступа и другими препятствиями, характерными для отчуждаемой инфраструктуры;
* 2-й день эксплуатации: как мы построили систему поддержки, доставки обновлений (продукта, инфра-слоя и К8s) и решения проблем, основанную на Flux CD;
* борьба с «эффектом снежинок»: как OCI + Flux CD помогли нам избежать создания множества уникальных конфигураций в исходном репозитории и упростить поддержку.

Наверняка вы все работаете с K8s и используете Ingress Controller для публикации сервисов наружу. Уверен, что у большинства из вас — Ingress Nginx. И вы, конечно же, сталкивались с ситуациями, когда вы задеплоили манифест, но что-то пошло не так, как вы ожидали.

В моем докладе мы разберем:
* как работает Ingress Nginx-контроллер;
* почему это не совсем стандартный nginx;
* как реализована балансировка (спойлер: пробежимся по дебрям Lua-кода);
* коснемся sticky-sessions и сниппетов;
* а также рассмотрим несколько интересных практических кейсов, которые помогут лучше разобраться, как работает ingress-nignx и как его готовить.

Далеко не многие знают, как ломать Kubernetes, а тем более как ломать Kubernetes, когда его и вовсе еще не существует.

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

Яндекс Облако практически с первых дней следовало парадигме self-hosting'а: развертывания компонентов облака в самом облаке.

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

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

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

В докладе мы разберем, как решить эту проблему с помощью личных стендов «по требованию»:
* про наш опыт создания автоматизированных стендов «по кнопке»;
* почему мы выбрали kyverno для автоматической очистки и поддержки стендов;
* разберем сложности реализации: создание интерфейса, пайплайнов, управление ресурсами.

Предоставить пользователям аналитическую базу данных — это не просто поднять гринплам, кликхауз или купить на них подписку. На примере внедрения в платформу данных базы нового поколения Starrocks (https://www. starrocks.io) расскажу про обеспечение необходимого минимума функционала и автоматизации для потребителей — инженеров данных, инженеров-аналитиков или разработчиков DWH.

Постараюсь ответить на вопрос — каким требованиям должны удовлетворять инсталляции и движки баз, особенно, если вы хотите спать по ночам и не вздрагивать при словах «обновление», «блокирующие операции ddl» или «отказ мощностей».

В докладе будет K8s (куда же без него в современном мире), сервисы миграций, аутентификации и авторизации, dbt как сервис — и все это приправлено щепоткой Golang и GitLab CI.

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

В этом докладе мы поговорим о том, как построить эффективный пайплайн на основе GitLab CI/CD, Poetry, Alembic и Helm, автоматизировать работу с миграциями, оптимизировать управление артефактами и внедрить комплексный подход к тестированию с Allure и SonarQube.

Вы узнаете, как:
* организовать CI/CD-процесс с разными стратегиями деплоя (test, preview, production);
* автоматизировать создание и откат миграций через Alembic;
* управлять кэшем Python-зависимостей для ускорения сборок;
* внедрить динамическое управление ревьюерами в пайплайне;
* эффективно работать с артефактами и очисткой хранилищ.

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

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

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