Доклады

1. Постановка задачи
1.1 Что есть дистрибутив сегодня?
1.2 Что есть firmware сегодня?
1.3 Copyarism как то, что поделило неделимое
1.4 Переизобрести distro - зачем? И почему это пришлось сделать

2. Кейс OpenWRT
2.1 История проекта как образец правильных решений
2.2 Ограничения прошивки - как они повлияли на развитие проекта
2.3 OPKG vs APT - плюсы и минусы
2.4 Реализация поддержки периферии = epic fail

3. Транзит пакетов OpenWRT в HyperSphere OS
3.1 Необходимость или копипаст?
3.2 Что нельзя переносить как есть из OpenWRT вообще куда-либо во вне
3.3 Разбиение LuCI
3.3.1 REST API Daemon - как не создать второй Webmin
3.3.2 PWA - как единственный GUI
3.3.3 CLI - must-have, но как его реализовать правильно?
3.3.3 API - публикация и защита, как не пересолить и не сделать швейцарский сыр в электронном виде

4. Физический девайс
4.1 Предыстория появления и выбора платформы
4.2 Спецификации и что под капотом
4.3 Поднимаем капот вживую :)
4.4 Интерфейсы в действии(CLI, PWA)
4.5 IT Security Paradigm
4.5.1 firewall
4.5.2 fail2ban
4.5.3 LUKS локально и по сети
4.5.4 WAF на примере mod_security
4.5.5 Tor и I2P как примеры внешних блоков безопасности
4.6 NginX - как не наступить на грабли pfSense и OpenSense
4.7 Mesh-сети и как их правильно готовить

Кто-то рассматривает Ceph как «магическую черную коробку» для хранения данных, кто-то его панически боится. На Highload’2024 я рассказывал, какие практики и инструменты мы разработали для эксплуатации Ceph’а. А в этом году хочу рассказать про наши приключения спустя год.
Это не очередной рассказ о том, «как мы подняли Ceph по мануалам». Это ретроспектива «год в бою» на реальной высокой нагрузке. Мы прошли путь от уверенного старта до спорадических деградаций производительности, замены контроллеров дисков во всем кластере и выработке новой референсной архитектуры для нашего SDS на базе Ceph — одного из флагманских продуктов группы — Рег.облака.
Расскажу про наш подход к выбору конфигурации, покажу какие ошибочные и не очень решения мы принимали в процессе развития.
Если вы планируете внедрять Ceph или уже работаете с ним, этот доклад сэкономит вам часы отладки, подсветив некоторые не самые очевидные места. Это честный разбор полетов, подкрепленный практическим опытом и проверенными решениями.

В этом докладе я расскажу, как мы в стартапе построили мультитенантную систему для B2B-платформы коммуникаций, где каждый тенант соответствует компании или её продукту. Мы использовали Keycloak как центр управления пользователями, ролями, политиками доступа и интеграциями со сторонними IDP.

Система создаёт и настраивает тенанты через IaC, а фронт полностью управляет этой магией через наш backend, который в свою очередь общается с Keycloak.
По пути мы прошли через ад из тонкостей конфигурации Keycloak, проблемы с консистентностью, пересечениями политик, масштабированием реалмов, безопасностью и многим другим.

Доклад будет полезен тем, кто хочет понять, как строить мультитенантные решения на Keycloak (и чего лучше не делать), как автоматизировать управление тенантами через IaC и как связать всё это с живыми бизнес-системами, не потеряв разум.

Я хочу рассказать о том, как давным-давно, когда только появился Kubernetes, и все еще боялись Docker-контейнеров, мы все равно ставили Kubernetes на железо. Прошли через Kubespray, пытались делать IaaS под Kubernetes. Какие инструменты мы использовали, что мы делали. Не было еще придумано слова GitOps, но уже были CI-системы. Какие CD-системы мы строили. Если поговорить про CI, то оно плюс-минус одинаковое у всех. Но мы пришли к достаточно качественному Continuous Delivery. Какой путь мы прошли. Какие беды мы пережили. Зачем мы это делали, что требовал бизнес.

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

Рынок Kubernetes в России сегодня — это зона турбулентности.
Одни строят платформы своими силами, другие полагаются на вендоров, третьи только начинают путь. Как сделать осознанный выбор с позиции CTO, Head of DevOps или инженера? Какие факторы реально влияют на решения в отрасли? И что вас ждёт в крупной компании, если вы заходите как специалист? Ответы больше не строятся на догадках. Мы провели первое фокусное исследование российского Enterprise-сегмента, опросив 252 компании с оборотом от 10 млрд ₽, чтобы рассеять «туман войны» и показать реальную картину Enterprise Kubernetes в России.

Доклад посвящён практическому опыту построения масштабируемой платформы данных в Kubernetes. Расскажу, как мы интегрировали Spark, Trino, Airflow, Iceberg и Apache Ranger в единую отказоустойчивую систему, обеспечивающую аналитикам и дата-инженерам paas-сервис. Расскажу про архитектурные решения, и результаты— от сокращения времени запуска задач до полного контроля над вендор-локом.

Многие команды уверены, что для отказоустойчивости между двумя ЦОДами нужно растягивать кластер Kubernetes на оба дата‑центра. На практике это приводит к нестабильной работе control plane и падению сервисов при отказе одного из ЦОДов. В докладе разберём, почему это происходит, и покажем, как достичь устойчивости сервисов без растягивания кластера — за счёт проектирования на уровне приложения. Рассмотрим архитектуру, где каждый ЦОД имеет свой независимый кластер, а отказоустойчивость обеспечивается балансировкой нагрузки между ними. Поделюсь реализацией на примере реального сервиса и разберём типичные грабли.

За 5 лет наша команда прошла путь от первых прототипов до третьей версии собственной Internal Developer Platform. Мы общались с разными командами разработки и узнали, для каких сценариев в действительности используют подобные платформы, какая функциональность важна и востребована, а какая — не очень.

В докладе поделимся накопленным опытом, который будет полезен, если вы планируете разрабатывать свою IDP или хотите вывести существующую на новый уровень. Покажем, как компании внедряют IDP и постараемся ответить на главные вопросы: кому вообще нужна IDP, какая именно и какие подводные камни поджидают на пути её развития.

Рассмотрим что есть дистрибутив, с чем его едят и как его правильно готовить :) Для запуска контейнеров и подавляющего числа ПО на самом деле необходим минимальный обвес между платформой запуска и предметом запуска - и как тут не пересолить как обычно есть тот ещё квест. Пройдёмся по тонкой грани undistribution, посмотрим как создавать пакеты и запускать процессы. Так же рассмотрим GitLab vs Jenkins для задачи: и у того, и у другого - есть свои изюминки, как их применить правильно?

IDP: «Золотая клетка» для разработчиков. Что скрывается за блеском? Она обещает рай: один клик для деплоя, самообслуживание и порядок. Но за высокими стенами платформы можно потерять гибкость и свободу.

Доклад о том, как построить не тюрьму, а мощный каркас, который не мешает творить.

В Т-Банке мы активно развиваем **ML Core** — нашу собственную ML-платформу на базе Kubernetes, где всё взаимодействие скрыто за простым и надёжным API. Однако, несмотря на автоматизацию, некоторые команды продолжают активно использовать **dev-тачки с SSH-доступом**: они удобны, гибки и позволяют быстро экспериментировать.

Мы решили предложить альтернативу: **ML Core DevBox** — виртуальную ML-среду "по требованию", которая сочетает удобство dev-тачки и преимущества платформы:
- Полный контроль: GPU, IDE, дебаг - почти как на локальной машине
- Персистентность данных и гибкое управление ресурсами
- Интеграция с внутренними системами
- Безопасность, мониторинг и автоматическое управление жизненным циклом

В докладе я расскажу:
- Почему dev-тачки до сих пор популярны — и какие у них скрытые издержки;
- Как родилась идея DevBox и какие технические и организационные вызовы мы преодолели;
- Как устроена архитектура: от кастомного 'devbox-agent' до автоматического разогрева хранилищ;
- Как DevBox уже используется в продакшене, какие метрики показывают успех — и что ещё предстоит сделать.

Если ты строишь ML-платформу, поддерживаешь ML-команды или ищешь баланс между свободой разработки и централизованным контролем — будет интересно.

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

На примере высоконагруженного облачного BI-конструктора разберем практический подход к построению системы мониторинга, которая является одновременно эффективной для анализа быстро меняющейся нагрузки и экономически оправданной. Обсудим, как выбрать минимально необходимый, но достаточный набор метрик из сотен доступных для кластера Trino (десятки тысяч подов в Kubernetes) и собственных Java-плагинов, как организовать их экспорт в Prometheus и наглядную визуализацию в Grafana для оперативного принятия решений.

Многие платформенные команды сегодня фокусируются на построении надежной инфраструктуры k8s, на автоматизации сценариев развёртывания приложений и самообслуживании. Но что делать, когда это уже работает? Куда направить усилия зрелой платформе в 2026 году? PaaS в Туту это инфраструктура на базе OKD, CI/CD Tekton и широкий набор сервисов для управления более 2500 микросервисов.

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

В докладе будет:
— AI Gateway это новый слой платформы. Расскажу, как платформа становится точкой контроля для всех ИИ-решений в компании.
— Защита для vibe-кодинга. Мы создаем Quality Gates, которые ловят проблемы ИИ-кода до попадания в мастер-ветку. ИИ-код имеет специфические ошибки, которые обычный линтер не ловит.
— Строим архитектурный реестр ИТ-систем, делаем платформу центральным инструментом для работы с архитектурой в Туту.
— Платформа становится центром управления конфигурацией приложений. Покажу как мы реализовали управление динамическими флагами и статичными опциями приложений.

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

В докладе я расскажу, как мы перепроектировали архитектуру: вынесли ядро в отдельный NPM-пакет, описали все параметры конфигурации в TypeScript, а в CI автоматически генерируем JSON Schema и версионируем её. На базе схемы сделали админку для Sales/Product на Monaco Editor с live-валидацией и предпросмотром, где можно включать фичи флагами, настраивать внешний вид и брендировать под клиента без участия разработчиков.

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

Фронтенд-приложения редко задумываются как монолиты — они вырастают в них со временем. Когда накапливается сложность, командам приходится идти на болезненные компромиссы и бесконечно рефакторить. В докладе я разберу, как пошагово выбраться из монолита: начать с ADR (Architecture Decision Records), чтобы фиксировать обоснование решений; применить паттерн Strangler для замены легаси-частей; поэкспериментировать с новыми архитектурными стилями, например «матричной» архитектурой и тд.

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

Готовить кафку в кубере как продукт.
Какие проблемы и боли это решает.
С какими подводными камнями придется столкнуться.

Однажды мое внимание привлек пост в блоге одной инфраструктурной компании, которая жаловалась на производителя каких-то прокладок для аэрокосмической отрасли США. Суть жалобы была в том, что этот производитель, несмотря на федеральный контракт, бессовестно регистрировал одну за другой ознакомительные лицензии на управляющую веб-консоль их решения для виртуализации. Несмотря на то, что эту веб-консоль можно тривиально собрать из исходников в полной версии без ограничений. При чем здесь Kubernetes, спросите вы? Пристегнитесь, наша ракета называется "Dell R815" и целиком собрана из переработанных индустрией компонентов.

Мы расскажем, как в большом зелёном банке заново изобретали Internal Developer Platform: от сбора сценариев и перестройки процессов до проектирования архитектуры OneWork. Покажем, какие задачи решает IDP в нашем исполнении, как развивается тренд в мире и #КаквСбере. Разберём ключевые компоненты платформы, интеграцию AI-ассистента, а также построения сквозных сценариев, которые радикально улучшают Developer Experience.

Итак, ты автоматизировал управление кластерами Kubernetes через Cluster API в двух ЦОД. Конфигурации катятся из git, тебя больше никто не будит, если кто-то случайно грохнул узел у кластера - все само. Приложения переживают отказ как платформы виртуализации, так и ЦОД целиком. Но что делать, если откажет сама платформа или ЦОД, в котором она развернута?
Расскажу как реализовано в двух ЦОД в одном банке, с чем столкнулись и как повторить у себя дома.

Infrastructure as Code solved configuration drift. Declare state, apply state, done. The talk from 2015 was convincing. It's 2026. Someone still clicked in the console last week. Your Terraform says one thing. AWS says another. The security group has a rule that nobody can explain. The network ACL was "temporarily" modified during an incident six months ago. Your IaC pipeline runs green because it's checking what it manages. It doesn't check what it doesn't know about. Drift is not just infrastructure. Security policies drift. Network configurations drift. Compliance settings drift. Each team detects their own domain. Nobody detects drift that crosses boundaries. The tooling exists. State comparison is automatable. The problem is organizational. DevOps detects infrastructure drift. SecOps detects security drift. NetOps detects network drift. The drift that causes incidents usually spans all three.

This session covers building unified drift detection across operational boundaries. We'll explore detection pipelines, spanning infrastructure, security, and network configurations, state comparison strategies beyond single-tool approaches, alert routing that reaches the right team without flooding everyone, remediation workflows that cross team boundaries, and governance for manual changes that maintain audit trails.

1. Постановка задачи
1.1 Определение пакета прикладного ПО
1.2 Определение пакета драйвера/модуля - нюансы
1.3 Определение пакета программно-аппаратного комплекса
1.4 Зависимости - как на них не зависнуть

2. Кейсы
2.1 Python
2.1.1 pip
2.1.2 то, что в него не влезает - на примере HuggingFace
2.2 PHP
2.2.1 Composer
2.2.2 Drush
2.3 NodeJS

3. Предлагаемое решение
3.1 Количество vs Качество - логическое завершение
3.2 Оркестрация
3.2.1 Главный менеджер - каким он должен быть
3.2.2 Взаимосвязи языковых менеджеров - как сделать это правильно
3.3 Архитектура EPT
3.3.1 Общая парадигма
3.3.2 Паттерны взаимодействия
3.3.3 Где необходимо останавливаться и передавать задачу? Наверх ли её передавать?

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

Несмотря на колоссальное количество сложных уязвимостей, которое есть сейчас, статистика показывает, что компрометация инфраструктуры происходит методами куда более тривиальными - забытые SSH ключи, закомиченные в Git или оставленные лежать на машинах, слитые и слабые пароли или неотозванный ключ давно уволенного сотрудника. А еще хочется иметь аудит действий пользователей в терминале, единый инструмент для получения доступа в БД, Kubernetes и SSH, гибкую ролевую модель для предоставления и отзыва пользователей и ее прозрачность для аудита. А еще, чтобы решение было Open Source. И такое решение есть! Имя ему - Teleport!

На конференциях Оптико уже были доклады от моих коллег, посвященные Teleport с точки зрения пользы для процессов ИБ, его гибкости и встраиваемости в существующие процессы. Однако с тех пор прошло почти 3 года. Настало время посмотреть, как повела себя система за годы ее эксплуатации, как пережила бурный рост, с какими проблемами мы столкнулись и как их решали. А еще - как внедрили Teleport уже в другой компании и что изменили. Этот доклад - история проб и ошибок, а также о поиске правильных (или не очень правильных) решений при внедрении с одной стороны очень полезного, и с другой - крайне компромиссного Open-Source решения

Мы расскажем о нашем исследовании по сравнению eBPF агентов мониторинга безопасности (Tetragon, Falco, и т. д.) . Исследование главным образом сфокусировано на сравнении производительности агентов при высоких нагрузках. В частности будет представлен подход, позволяющий провести замеры потребления CPU eBPF-программами и представлен соответствующий инструмент для проведения измерений.

Расскажем о необходимости автоматизации процессов безопасности при разработки ПО. Как мы используем ИИ для безопасности разработки и анализа кода в режиме реального времени. Выполняя этим концепцию shift left и соответствую ГОСТ Р 56939-2024.

В современном проде 70–90 % всех операций выполняют не люди, а машины: сервисные аккаунты, CI/CD-раннеры, микросервисы, Lambda-функции, GitHub Actions, Terraform-провайдеры. Non-Human Identities (NHI) не проходят онбординг, не меняют пароли, не увольняются и живут в инфраструктуре годами с избыточными правами.

Именно проблемы с защитой и аутентификацией NHI — главные причины многих громких взломов за последние годы: Microsoft (2023), Cloudflare (2024), Okta (2023–2024), десятки утечек через GitHub Actions и токены в публичных Docker-образах.

В докладе разберём, почему даже зрелые DevSecOps-практики (SAST/DAST/SCA, signed containers, policy-as-code) перестают работать, если не встроен полный жизненный цикл NHI (нечеловеческих учетных записей): от безопасного bootstrap без «секрета нулевого дня» до автоматической ротации и отзыва.

Рассмотрим архитектурные пробелы и дыры в популярных решениях: от облачных провайдеров IAM с Workload Identity Federation до локальных хранилищ динамических секретов.

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

Мы расскажем о том, как обезопасить кластера k8s компании, потратив 20% времени общения с командой ИБ на споры, сохранив при этом 80% нервных клеток всей компании

Управление секретами является важнейшей частью любой инфраструктуры. А что нового могут предложить криптографы для решения этих задач? Доклад описывает современные алгоритмы, позволяющие избавиться от прямой передачи и хранения секретов, обеспечивающие устойчивость систем к прямому взлому любого из серверов. Некоторые алгоритмы уже широко применяются в инфраструктуре (например Fiat-Shamir Secret Sharing), а некоторые только начинают свой путь (Multi-Party Computation, Threshold Signatures и др.) и имеют огромный потенциал. Об этих алгоритмах и пойдет речь в этом докладе.

Your security policy requires 90-day credential rotation. Your last rotation caused an outage. The application cached old credentials. The service account was used by three systems no documented. The network appliance needed manual intervention. You rotated the secret. You broke production. Security policy met operational reality. Reality won. Secrets rotation is a checkbox compliance exercise until it is not. Then it's an incident. The credential expired. The application didn't reload. The deployment pipeline failed at 2 AM because the service principal expired and nobody noticed. Your vault rotates secrets. Your applications don't know. This crosses every boundary. DevOps owns application credentials. SecOps owns rotation policy. NetOps owns network device credentials. Database teams own connection strings. Each domain rotates independently. The dependencies between them are not mapped. Rotation in one domain breaks another.

This session covers building secrets rotation that doesn't cause incidents. We'll explore rotation architectures where applications detect and reload credentials automatically, dependency mapping for credentials spanning team boundaries, staged rotation strategies that validate before committing, network and infrastructure credentials beyond application secrets, rollback patterns when rotation breaks something anyway, and cross-functional coordination when credentials touch multiple domains.

Нередко нам кажется, что у нас все очень секьюрно, но так ли это на самом деле?
Количество киберугроз только растет, а ценность практик безопасной разработки понятна и легко измерима. Самое время внедрять DevSecOps системно и повсеместно.

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

Что получат участники воркшопа:
• Референсную архитектура безопасной разработки
• Роадмап внедрения практик по разным уровням зрелости
• Базу знаний по релевантным материалам

- экосистема бесплатных инструментов на платформе МосХаб для полного цикла безопасного создания и развития ПО;
- доступность и защищенность платформы МосХаб;
- трассировка требований в экосистеме МосХаб при создании ПО;
- совместная работа над проектами создания, развития и эксплуатации ПО на платформе МосХаб.

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

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

Поговорим про реагирование на шелл, левый код и процессы на сервере.
Хонипот — как и с чем его есть.

* Свой WAF и краткий обзор отечественных NGFW. Расскажем, как локально поставить Ideco, и сравним его с нашим решением.

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

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

Мы собрали pipeline в GitLab CI, но точно ли мы это сделали безопасно? Разберем основные появившиеся риски, пути их митигации, на какие trade-off нам придется пойти и составим чек лист правил гигиены в CI/CD.

Ролевая модель хорошо работает для систем, но ломается, когда речь заходит о данных:
таблицы, витрины, датасеты, BI — всё это порождает тысячи исключений, и RBAC
перестаёт быть управляемым. Self-service порталы обычно создаются для упрощения, но
превращаются в болото заявок и бесконечных согласований.
В докладе я расскажу:
● почему доступ к данным принципиально сложнее обычных доступов;
● где и почему ролевые модели перестают работать;
● почему self-service порталы часто оказываются бесполезными;
● как устроить быстрые и безопасные согласования;
● практические кейсы упрощения жизни разработчиков, аналитиков и владельцев
данных.

Разберем подход к оркестрации DevSecOps инструментов путем создания единой точки входа на базе n8n

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

Решения на основе HashiCorp Vault прочно заняли свою нишу на рынке ИТ. Большое количество компаний и отдельных проектов используют их как систему для централизованного хранения инфраструктурных секретов или как систему PKI. В Vault архитектурно заложена невозможность повлиять на состояние прав доступа в хранилище в обход его политик безопасности, а значит, извлечь данные в обход политик тоже невозможно. Но что, если злоумышленник вооружится такими инструментами, как strace, gcore, gdb, или вообще сделает снапшот виртуальной машины? Устоит ли защита?
В докладе мы разберём потенциальные проблемы утечки данных, если злоумышленник уже получил административные права в ОС, где запущена система хранения секретов, или получил доступ к системе виртуализации, а также поговорим о способах защиты данных в такой ситуации.

Процессы разработки и эксплуатации всё чаще становятся частью атак: злоумышленники используют их как точку входа или способ развития атаки. Угрозы могут поджидать нас на каждом этапе — от инцидентов, связанных с недобросовестными сотрудниками, до 0-day уязвимостей и supply chain атак. Из-за этого случаи, когда атакующие получают доступ к машинам разработчиков и инфраструктуре, происходят всё чаще.

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

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

В начале года вышло Информационное сообщение ФСТЭК России № 240/24/38 о повышении безопасности средств защиты информации, в состав которых разработчики включают средства контейнеризации или образы контейнеров. Мы разложим по полочкам, что и как надо делать разработчикам «СЗИ в контейнерном исполнении», чтобы было все как надо.

Определим технические и «бумажные» процессы, уберем бумаги за скобку и рассмотрим на примере CI/CD пайплайна, что хотят видеть испытательная лаборатория и Регулятор в артефактах для соответствия новым требованиям.

• Как и почему возникла идея self-service ASOC: реальные проблемы, которые не решались существующими инструментами
• Архитектурные и организационные решения: что выбрали, от чего отказались и почему
• Ошибки и переделки: что не взлетело с первого раза
• Как платформа выглядит для разработчика и для AppSec

Наиболее приемлемый способ добавления Sec в DevOps - это внесение инструментов обеспечения безопасности в пайплайн разработки. Мы возьмем в качестве примера веб-приложение на Python в Docker-контейнере и посмотрим, как обеспечить в пайплайне на GitLab сначала простые вещи (SAST, DAST), а потом подключать инструменты для управления SBOM и обеспечения взаимодействия по управлению уязвимостями в DefectDojo. Все используемые инструменты будут OpenSource и доступны бесплатно.

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

В докладе я покажу результаты технического анализа их защищённости и разберу поверхность атаки: от тривиальных prompt-инъекций в нетривиальных контекстах до сложных, но критичных атак через межагентное доверие и общие инструменты. Мы посмотрим, как архитектурные компоненты MCP и RAG открывают дополнительные векторы влияния на поведение агента, определим ландшафт угроз и оценим, сколько уязвимых компонентов уже доступно в открытом доступе.

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

Яндекс 360 — это бренд, объединивший 13 продуктов с разной историей и набором технологий. Мы быстро растем и запускаем много новых фичей, что требует поднятия новых микросервисов.

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

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

Базовая поставка включает в себя:
Создание балансеров, DNS
- Три окружения: testing, prestable, production; PR окружение по кнопке
- CI/CD для всех сценариев
- Интеграция с трекером задач
- Интеграция с внутренний системой инфровых событий
- Интеграция с Vault
- Создание и настройка кластера в системе observability
- Базовые дашборды и алерты из коробки
- Создание стораджей логов и настройка процесса поставки и храния логов

Микросервис генерит спеки, мониторинг и CI/CD из общих шаблоновв позволяет стандартизировать процессы и доставлять обновления инфраструктуры сразу до всех сервисов.

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

Расскажу для чего создавали эту платформу, как она помогает инженеру с выбором технического решения для решения своих задач опираясь на такие функции платформы:
1. Автоматическое сканирование уязвимостей решений
2. Статистика скачиваний
3. Статус решения в технологическом радаре
4. Рейтинговая система: звезды и комментарии к продукту
5. Описание документации к решению
6. Возможность публикации своего технического решения
Все это должно помочь с быстрым и осознаным выбором решения, избежать создания ведосипедов.

В публичном облаке нельзя просто отключить зону доступности — клиенты этого не простят. Как тогда проводить учения на отказоустойчивость? Мы адаптировали Chaos Engineering под себя: тестируем деградацию на препроде, осторожно проверяем региональные сервисы на проде и разрабатываем публично доступные инструменты для управляемого хаоса (например, ручное отключение балансировщиков).

Какие инструменты, помимо Ansible Molecule, вам известны? На самом деле выбор довольно широкий. Начну с обзора инструментов для разных систем (Ansible, Puppet, SaltStack, Chef) и проанализирую их преимущества и недостатки.

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

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

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

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

В условиях реальных бизнес-задач DevOps-инженеры часто сталкиваются с приложениями без четкой документации и архитектурных схем. В таких случаях специалистам приходится совмещать роли разработчика, архитектора и технического писателя, чтобы быстро развернуть приложение в Kubernetes и автоматизировать его деплой с помощью GitOps.
В докладе мы расскажем о практическом опыте решения подобных задач:
Как анализировать и понимать границы сервисов в монолитном или плохо документированном коде
Как адаптировать архитектуру под реальную структуру кода, а не на основе документации
Как использовать анализ кода и логи для восстановления недостающей информации
Как построить процесс CI/CD и GitOps-деплой для приложений без документации
Какие инструменты и подходы помогли нам минимизировать риски и ускорить вывод приложений в продакшн
Доклад будет полезен всем, кто сталкивался с необходимостью разворачивать и поддерживать приложения без документации, а также тем, кто интересуется реальными кейсами применения GitOps и автоматизации в сложных условиях.

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

Сегодня многие компании строят микросервисные платформы и API-сервисы, но в повседневной работе DevOps- и SRE-инженеров всё равно остаются задачи, которые проще и быстрее решать через консольные инструменты. Как спроектировать такой CLI так, чтобы он был удобным, понятным и поддерживаемым? И почему Go стал фактическим стандартом для разработки CLI-утилит?

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

Доклад будет полезен Go-разработчикам, DevOps- и SRE-инженерам, которым приходится автоматизировать инфраструктуру, упрощать внутренние процессы и создавать удобные инструменты для команд.

Когда я реализовывал DevSecOps задачи в CI/CD я сталкивался с тем, что очень много инструментов есть (особенно в SAST) и не понятно, что выбрать.
При этом очень часто у них есть ложные срабатывания, что затрудняет эксплуатацию.

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

В рамках развития централизованной платформы разработки мы выполняем поэтапную миграцию Git-инфраструктуры ВКонтакте на единый GitLab. Речь идёт о репозиториях, которыми ежедневно пользуются тысячи разработчиков и которые отражают многолетнюю историю развития продукта.
В докладе я расскажу, с какими инженерными ограничениями мы столкнулись при переносе крупных GitLab-проектов: почему стандартный export/import перестаёт работать на большом объёме merge requests, как влияют LFS-данные и интеграции вокруг репозитория, и почему миграция Git — это не только про Git.
Отдельное внимание будет уделено организации поэтапной миграции без остановки работы команд, роли автоматизации, интеграции CI/CD и управлению переключениями. Доклад основан на практическом опыте развития Git-инфраструктуры в крупной продуктовой компании и будет полезен инженерам, работающим с GitLab, CI/CD и большими кодовыми базами.

Мы расскажем, как избавились от громоздких статических инвентарей Ansible, переведя конфигурации инфраструктуры на собственный формат динамического инвентаря. Раньше наши инвентари занимали тысячи строк, а любое изменение сопровождалось болью и риском затронуть соседние инстансы. Мы построили плагин, который по краткому YAML-описанию формирует полноценный инвентарь для Ansible, устраняя дублирование и автоматизируя вычисление зависимых параметров.
В докладе покажем, как структурируется наш динамический инвентарь, какие секции (constants, servers, components) отвечают за разные уровни описания системы и как мы используем Python-классы для генерации подходящих для разных продуктов конфигураций. Разберем, как такая архитектура ускоряет развертывание, уменьшает человеческий фактор и дает прозрачную систему значений по умолчанию.
Мы сравним наш подход с существующими open source-решениями и обсудим, какие из идей можно масштабировать в других командах. После доклада участники смогут спроектировать аналогичный уровень абстракции для своих Ansible-инвентарей и сократить время поддержки инфраструктуры на порядок.

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

Но мы же инженеры, правда? Давайте посмотрим, как правильно их взломать и показать менеджменту ту картину, которую менеджмент хочет увидеть.

Time to Market — это не только про скорость бизнеса, но и про зрелость инженерных практик.

В докладе мы разберём:
• какие инженерные практики напрямую влияют на скорость доставки ценности (CI/CD, автоматизация тестирования, качество кода, культура Code Review);
• как метрики Lead Time, Cycle Time, Process Time и Delay Time помогают найти «узкие места» в процессах разработки;
• как мы внедрили автоматический сбор данных через связку GitLab и Jira;
• какие результаты получили на практике: как зрелость CI/CD и тестов снижает Cycle Time, а системный Code Review — Delay Time;
• как интерпретировать TTM через уровни зрелости (от Low до Elite) и построить план развития инженерных практик.

Доклад будет полезен инженерам, тимлидам и техлидам: вы увидите реальные данные и узнаете, какие практики быстрее всего дают эффект на Time to Market.

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

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

Если ваша цель:
- текучка devops отдела при хорошей зп
- понижение SLA/SLO
- раздутие расходов на инфру
- тест компании на устойчивость

То добро пожаловать на доклад - все собития и лица почти(зачернуто) выдуманы ;)

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

За 5 лет мы превратили DevOps-сообщество из маленькой инициативы в движущую силу инженерной культуры.

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

Мы не просто обменивались знаниями — мы влияли на стратегические продукты: участвовали в развитии Tech Radar и инженерных практик.

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

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

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

В Островке мы используем несколько типов балансировщиков - от Nginx до Traefik и HAProxy - каждый для своих задач и разных типов трафика. Это не цепочка, а набор инструментов, которые взаимозаменяют друг друга и компенсируют индивидуальные ограничения.

В докладе я расскажу:
- почему одного балансировщика нам оказалось недостаточно;
- как разные инструменты дополняют друг друга и закрывают разные сценарии;
- какие настройки и оптимизации мы применяли для снижения нагрузки и повышения отказоустойчивости;
- как строить метрики на основе логов Nginx.

Work in progress

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

Доклад бросит взгляд на централизованное управление маленькими техническими несовершенствами в разных сервисах разных команд разработки. Про SLI и SLO мы все знаем, но поговорим о том, как быть, если хочется подсвечивать командам то, что может стать проблемой, но не влияет на пользователя прямо сейчас. Например, уязвимости, ошибки настройки внутренних объектов, нездоровую динамику в сервисах, техдолг и т.д. Даже если удалось все нужные данные собрать - как эту гору цифр представить командам и бизнесу, чтобы было полезно?
Расскажу как мы построили систему, в которую вписали и "несовершенства", и SLO. Увидим, как для инженеров она превращается в простой action-план, а для бизнеса - в понятные верхнеуровневые метрики.

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

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

1. Сейчас разные продукты используют разные подходы к деплою: часть хранит Helm-чарты в infra-репозитории, часть — в продуктовых репозиториях из-за канареек.

2. Канарейки нужны только фронтовым системам, а внутренние сервисы работают через версионирование API и feature toggles.

3. Разнообразие подходов приводит к фрагментации CI/CD, разным пайплайнам и отсутствию единого стандарта деплоя.

4. Цель — хранить все Helm-чарты централизованно в infra-репозитории, сохранив возможность для отдельных сервисов иметь stable и canary версии.

5. Это позволит унифицировать GitOps, упростить сопровождение и сделать деплой предсказуемым для всех типов продуктов.

Инженеры — мощные пользователи сложных технических продуктов, но их потребности в UX часто игнорируют, принимая за данность, что "они разберутся" и "им всё равно". На самом деле их рабочий опыт напрямую влияет на качество продукта и его стабильность.​

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

Расскажем о том, как разные операторы PostgreSQL в Kubernetes реализуют резервное копирование и восстановление, поделимся своим опытом и причинами, по которым решились написать своё opensource-решение для бэкапов PG в кубере.

Все в SAFe, а как быть нам? Enabling-команда DevOps на все поезда (ART), стандарты и шаблоны для команд, контракт сервиса, поставка в PI и обратная связь через CoP.
От «хранилища 1С» к полноценной работе с исходниками. Что пошло не так в первый раз, и как со второй попытки мы перешли на Git.
Уже не помним, когда последний раз останавливали ERP из-за кода. Качество и стабильность к которым мы идём. Покажем, что было до и что есть сейчас.
Почему часть команд перешла на XML-поток, а другие остались на берегу, а также какие тактические ускорители нам помогли наладить процесс.

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

На практике по шагам создадим свой дистрибутив Linux на базе Linux From Scratch. На примере Linux From Scratch пройдёмся по всем стадиям декомпозиции последовательной сборки в модульный дистрибутив. Рассмотрение начнём с создания сборочного стэнда, потом из классической связки GitLab+agent добавим подачу собраных пакетов в репозиторий. Так же рассмотрим создание установочного образа для первоначальной установки: как собрать? как подать? как доставить?

Elixir — мощный язык для создания отказоустойчивых и высоконагруженных приложений, однако построение CI/CD для его экосистемы имеют свою специфику, которая может стать «бутылочным горлышком» в процессе разработки. Долгая компиляция, прогон тестов, использование инструментов экосистемы приводят к тому, время пайплайна исчисляется десятками минут. Мы расскажем, как мы построили и оптимизировали CI/CD для высоконагруженного проекта на Elixir, сократив его время с 40+ до 10 минут, и какие подходы применимы для большинства проектов, использующих GitLab CI/CD.

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

- Как реализовать эффективное кэширование в GitLab CI для _build и deps.
- Как ускорить тестирование с помощью стратегии stale.
- Что может случиться с компиляцией при миграции с Docker-раннеров на Kubernetes-раннеры.
- Как развернуть локальное хранилище пакетов.

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

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

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

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

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

А нам всё ещё нужно быстро найти руткоз. Давайте разберемся, как превратить observability-платформу в интеллектуальную систему APM, которая решает сразу несколько задач:
* Даёт быстрый старт в новом окружении и замониторенность из коробки.
* Автоматизирует drilldown сценарии и поиск корневых причин.
* В конечном счёте сокращает TTRC/TTR в инцидентах.

В каждой компании есть необходимость выстроить систему observability. В своём докладе расскажу, как эволюционировал пайплайн сбора и хранения логов. От ElasticSearch к файлам на дисках и к clickhouse.
О том, как мы перестраивали нашу архитектуру под большее количество данных. Много ли сейчас у нас данных? Имеем на входе 24к RPS, 1 миллион спанов в сек., 5к инстансов сервисов. Рассмотрим особенности таблиц с логами в clickhouse.
Также затронем долговременное хранение в hadoop

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

В Kubernetes все начинают с хаоса, а заканчивают политикой. Kyverno позволяет управлять правилами в кластере без строчек кода: декларативно, предсказуемо и гибко. Но как сделать так, чтобы политики помогали, а не мешали? Чтобы безопасность росла, а ненависть разработчиков нет?
В докладе разберёмся, как выстроить «правовое государство» внутри кластера: когда нужны мягкие предупреждения, а когда — жёсткая автократия, ломающая билд. Покажу, почему постепенное ужесточение правил снижает конфликты и помогает внедрять стандарты без сопротивления команд.
Отдельный блок будет посвящён компромиссу между безопасностью и скоростью. Как дать командам свободу, но удержать их в границах? И как, используя Kyverno, сделать так, чтобы стандартам следовали по умолчанию, без превращения разработчиков в заложников инфраструктуры.

О чём поговорим конкретно
Чем Kyverno отличается от OPA и почему иногда он проще и эффективнее.
Типы политик и как они влияют на поведение команд.
«Мягкие» политики как инструмент обучения и культурных изменений.
«Жёсткие» политики: когда пришло время бить по рукам.
Как внедрять стандарты постепенно, без революций и саботажа.
Как писать политики, которые помогают, а не тормозят процессы.
Реальные кейсы внедрения в боевых кластерах: что сработало, а что нет.

Практический подход к построению Единого Источника Истины для микросервисной архитектуры.
Как заставить CMDB работать на скорость, а не против неё.
Метод автоматизации сборки сложных Helm-чартов для распределенных приложений.
Как предоставить самостоятельность десяткам команд, сохранив общие стандарты и контроль.

Сейчас почти все используют CI инструменты, где распараллеливание шагов сборки - это обычное дело. Но что делать, если инструмент так не умеет, а очень хочется?
Ответ: сделать всё на этапе сборки Docker образа.
В докладе покажу, как мы из последовательной сборки на одном агенте пришли к параллельной и создали универсальный шаблон, который пережил добавление 4 новых проектов без изменений.

Ежегодно сложность внедрения DevOps-практик возрастает, выдвигая требования к повышению уровня информационной защиты. Данный доклад посвящен современным методикам хранения и доставки секретов, интегрированным в GitOps-подход. Будут рассмотрены оптимальные способы надежного сохранения конфиденциальных данных непосредственно в Git-репозиториях с использованием инструментов шифрования типа SOPS, а также использование централизованных хранилищ вроде Vault. Особое внимание уделено процессу безопасной передачи этих данных в Kubernetes-кластеры с соблюдением принципов GitOps.

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

- Что такое service mesh и зачем они нужны?
- Разбираем service mesh на istio и какие у него есть проблемы
- Раскатываем linkerd и разбираем функционал

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

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

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

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

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

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

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

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

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

В докладе обсудим:
— как организовать перенос виртуальных машин с Docker-контейнерами, какие подводные камни могут возникнуть и как их избежать;
— как правильно мигрировать базу данных PostgreSQL и обеспечить целостность данных;
— нюансы переноса MinIO и возможные проблемы с объектным хранилищем;
— особенности миграции Kubernetes-кластера и как сохранить его стабильность в процессе.

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

DevOps-команда нашего департамента в YADRO поддерживает больше десяти команд разработки. Нередко от разных команд приходят схожие задачи по изменению инфраструктуры: нужно выделить виртуальные машины для экспериментов, создать базу данных в PostgreSQL и т. д. Раньше большинство подобных задач отправлялись в Infra-часть нашей команды или решались DevOps-инженерами самостоятельно, причем вручную. Нам удалось упорядочить этот хаос и прийти к единообразному управлению инфраструктурными сервисами с помощью Infrastructure as Code подхода на основе Terraform/OpenTofu.

В докладе я поделюсь опытом перехода на Infrastructure as Code и выделю преимущества подхода для DevOps-команд. Проиллюстрирую сказанное примерами реализации Infrastructure as Code для популярных инструментов: OpenStack, DNS, PostgreSQL, S3, Apache Kafka, Ansible AWX и других.

Vector.dev комбайн для работы с логами становится все популярнее и востребован, потому что помогает значительно экономить ресурсы (в десятки раз). Однако Vector это не только сам программный продукт, но и сопровождение его эксплуатации - это изменения кода трансформов их CI, автоматические тесты, развертывание и мониторинг.
У нас большая конфигурация с Vector для обработки логов в которой есть агенты и агрегаторы vector. Рассмотрим автоматизацию тестирования и развертывания агрегаторов vector при помощи Ansible, как мы мониторим развертывания в Grafana. Расскажем как решение эволюционировало, где мы поели кактусов и как решили проблемы.

В итоге поделимся с вами нашими наработками, которые вы сможете адаптировать для себя (Ansible роли, доски для Grafana).

Ваш лучший инженер не отвечает в мессенджере — всё рушится.
Вот как это исправить?
Сценарий узнаваем: единственный инженер во всей команде, который знает CI/CD, разбирается в Kubernetes и управляет инфраструктурой. Уходит в отпуск — инфраструктура встаёт. Уволился — остаётся миллион строк технического долга. Вы нанимаете нового «супер-инженера». И всё повторяется.
Это не DevOps. Это ботлнек, который тормозит весь бизнес.
Конечно, когда вас в команде 10 человек и столько же продуктов, то вопрос может быть решён внутренней ротацией. Но когда требования бизнеса и систем растут в разы — ситуация становится неконтролируемой.
X5 Tech столкнулась с этой болью в 2022 году.
Вместо того чтобы искать следующего незаменимого инженера — сделали кардинальный ход, превратив DevOps из роли в продукт.

Результаты:
Команда выросла в разы — связка инженер+определённая компетенция больше не причиняет боль
Kubernetes и Terraform полностью скрыты — разработчик просто пишет код
Отпуск или больничный сотрудника больше не трагедия, т.к. разработка больше не зависит от единственного специалиста

Из доклада вы узнаете:

Как разрушить культ супер-инженера
Какие метрики действительно важны
Как масштабироваться без хаоса

Этот доклад — must-see для CTO, руководителей инженерных команд, DevOps и SRE, а также продуктовых менеджеров внутренних платформ. Узнайте, как выстроить DevOps, который масштабируется и приносит реальную бизнес-ценность.

В своем докладе на прошлой конференции DevOps Conf 2025 я делился пытом использования в нашей DevOps-команде практик и инструментов Канбан Метода. И мы совсем по верхам затронули очень важную практику из Канбана: "Сделай правила работы явными". Правила... Это то, что мы все так одновременно и любим и ненавидим. Но как же сделать так, чтобы правила работали на нас, а не наоборот? Об этом расскажу в своем докладе, основанном на опыте работы нашего DevOps-сервиса. Мы окунемся в правила работы команды, как их "доставать" из голов участников :-) как формировать, как развивать, какими они должны быть. Отдельно поговорим о правилах взаимодействия с заказчиками. Печально, если вы оперируете понятием Lead Time от DORA, а заказчик - от адептов Канбан Метода. Остановимся на типовых ошибках при формировании правил и подходах к их минимизации. А в качестве подарка участники получат полноценный шаблон Team Work Agreement.

В IT-компаниях ownership часто сводят к лозунгу «будь владельцем задачи», но за этим скрывается гораздо более сложная система — ценностная, организационная и эмоциональная. В докладе разбирается, как формируется подлинное чувство собственности у инженеров и менеджеров: через доверие, границы, среду и смыслы. Как отличить ownership от выгорания и подмены ответственности. Почему культура ответственности — это не контроль, а зрелость системы, и что происходит, когда компания строит её по-настоящему.

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

Методики скрам мастера.

Частые релизы ускоряют развитие продукта, но приводят к стрессу, конфликтам и выгоранию в командах.

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

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

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

В докладе я расскажу о простых, но действенных способах наладить коммуникацию и совместную работу между dev и ops частями команды

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

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

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

- Доклад основан на практическом опыте построения и управления продуктовыми командами с высокой неопределённостью, AI-компонентами и жёсткими SLA.

В докладе покажем, как мы трансформировали SRE-команду в коммунальную DevOps-службу, способную поддерживать 30–40 проектов силами 12–15 инженеров, а также рассмотрим подход к малобюджетному внедрению ML и AIOps для повышения эффективности эксплуатации и DevOps-процессов.

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

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

Расскажу как в компании внедряли SLO/SLI так, чтобы они работали предсказуемо, не ломались от человеческого фактора.
Разберём кейс: от отсутствия метрик и неудобных дашбордов до разработки собственной системы на Go + Jsonnet + Grafonnet.
Разберём, как автоматизировали генерацию метрик, упростили жизнь DevOps/SRE и сократили инциденты вдвое.

Мы расскажем, как встать на правильный путь по достижению высокой стабильности, надежности на уровне. 99.99% и выше

Node.js сервисы падают не от "слишком много трафика", а от бесполезной работы по aborted requests: handler продолжает жечь CPU, коллить backends и блокировать event loop после того, как клиент ушёл.

Я покажу реальный production-кейс из Yandex Maps: как перестроили Node.js + Express сервис за Nginx (SSR + несколько backends) под graceful degradation:
- req.aborted + socket.on('close') — ранний выход из handler'а
- Пропагация cancellation через HTTP clients и тяжёлые операции
- Nginx rate limiting + app-level emergency switches (отключение SSR/backends)
Как результат: сервис живёт под DDoS и пиковыми нагрузками. Обсудим код и метрики до и после.

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

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

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

Итак, в вашей должности есть слово "старший". Куда теперь? Обычно все говорят: ну, теперь - в руководители! Но точно ли это то, что вам нужно?
На круглом столе поговорим:
- Есть ли жизнь после "старшего" грейда
- Какие опасности и радости поджидают инженера на лидерском пути
- А что ещё можно делать с карьерой кроме роста в управление

Когда у гугла спрашиваешь, что нужно знать DevOps-инженеру, AI-ассистент сразу выдает массу аббревиатур: CI/CD, IaaS, PaaS, Docker, K8s. Но DevOps – это прежде всего образ мышления.

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

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

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

За последние несколько лет мы в Лемана Тех начали активное движение от «встреч комьюнити по четвергам» до полноценного Центра Компетенций DevOps&SRE . Как однозначно понять какие задачи ставить в ИПР? Как определить что нужно для перехода на новый уровень? Как понять чего недостаточно для перехода на другую роль? Какое обучение нужно заказать для профессии, а какое для конкретного инженера?
В докладе я отвечу на эти вопросы и расскажу, как мы пришли к матрице компетенций для DevOps/SRE. Расскажу с какими проблемами столкнулись, как выделялся набор необходимых компетениций, как договорились о граничных значениях и что пошло не так на первых итерациях.
Покажу на примерах, как матрица может помочь сотруднику планировать развитие, выстраивать карьерные треки. А так же как матрица помогает компании управлять бюджетами, наймом и обучением.

DevOps — это не только про инфраструктуру, CI/CD и мониторинг, а люди, чья работа строится на постоянном взаимодействии, доверии и эмпатии..

В этом докладе мы соберём живой, честный FAQ от реальных DevOps-инженеров:
Как сохранять внутреннее равновесие, когда весь мир требует «быстрее, надёжнее, дешевле»
Как не превратиться в вечного пожарного?
Как говорить с менеджментом на одном языке — без жертв и героизма?

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

Цель — показать, как Центры компетенций (ЦК) помогают системно развивать инженерные и DevOps‑практики в крупных компаниях.

Вместе пройдемся по гипотезами и их результатам:
* DevOps‑Kitchen (мероприятия и воркшопы),
* архитектурные дорожки,
* Платформенные и Core команды
* экспертные TG‑группы,
* система грейдов и матрицы зрелости команд.
* Экспертный совет ЦК с участием HR и R&D
* Использование GenAI и MLOps
* Интенсив-недели DevOps
* Тигриная команда
* Отличия в процедуре оценок Junior / Middle специалистов и Senior +
* и многое другое.

Если вы планируете миграцию из on-prem инфраструктуры в облако, то вам точно понадобится мирировать и данные. Одна из наиболее популярных реляционных СУБД - это Postgresql. В своем докладе я расскажу об опыте миграции нескольких больших (4-7Тб) и множества не очень больших баз данных из On-prem Postgresql в Yandex Managed Postgresql используя Yandex Data Transfer. Причем не только про миграцию "как есть", а с рядом особенностей, таких как:
- Частичный перенос данных (не все таблицы)
- Практически бесшовный переезд с одновременной записью в БД источник и назначение
- Особенности переноса таблиц без Primary Key
- Долгоживущие трансферы и что делать если нужно изменить структуру данных на источнике
- Как правильно разнести схемы из одного источника в разные инстансы-приемники

А так же отвечу на вопросы:
- Как трансфер переживает перебои в работе сети?
- Что может пойти не так во время работы трансфера? Спойлер: очень многое!
- Как можно уронить прод 3 раза за день?
- И даже: как траблщутить трансфер с помощью tcpdump?

Если вы архитектор, которому необходимо спланировать миграцию данных, или DevOps, который который организует процесс миграции, или DBA который участвует в процессе - обязательно приходите послушать, будет интересно!

- Ограничения безопасности заказчика делают невозможным использование облаков и managed-сервисов.
- Отсутствие у заказчика команды администрирования усложняет эксплуатацию и поддержку.
- Эволюция инфраструктуры от Docker Swarm к kubernetes (k3s).
- Опыт построения CI/CD и GitOps-процессов без Git и внешнего доступа.
- Применение helm и umbrella-чартов для дистрибуции продукта.
- Практические проблемы эксплуатации k3s на RedOS.
- Сетевые и организационные изоляции контуров (preprod / prod / infra).
- Как выстроить стабильный релизный процесс в условиях полной изоляции.
- Компромисс между best practice и реальными ограничениями заказчика.
- Результаты: что сработало, какие ошибки повторять не стоит.

Добрый день!
Приглашаю познакомиться с гибридной инфраструктурой!
Мы погрузимся в ее основы и изучим ключевые принципы на примерах.
Поговорим о том, что такое гибридная инфраструктура и какие варианты гибридности существуют.
Затем разберем управленческие фреймворки, помогающие строить гибрид.
В заключение немного похоливарим на тему: что, если не гибрид?

Цифровой двойник прикладного проекта в K8s

1. Представление докладчиков

2. С чего все началось
2.1 Попытка создать "предиктивный автоскейлер" для проекта в K8s
2.2 Причины неудачи (Стоимость сбора и хранения информации превышает ее ценность)
2.3 Разработка on-premise автоскейлера
2.4 Где и как проверять политики автоскейлинга, почему не подойдет стенд нагрузочного тестирования

3. Цифровой двойник проекта в K8s
3.1 Основная проблема - как учитывать постоянные изменения в проекте
3.2 Что у нас есть в наличии
3.3 Цифровая архитектура (архитектура как код)
3.4 Телеметрия K8s, Istio, метрики утилизации, метрики запросов, трейсы
3.5 Основные элементы цифрового двойника (компоненты, внешние ресурсы, связи, описание входных нагрузок)

4. Модель Pod-a
4.1 Исследования отдельного компонента с помощью локального нагрузочного тестирования
4.2 Требования к заглушкам
4.3 Обработка результатов исследования: апроксимация полиномами
4.4 Основные типы компонентов
4.5 Формат хранения модели Pod-a
4.6 Версионирование модели Pod-a

5. Модель внешнего ресурса
5.1 Данные для внешнего ресурса
5.2 Формат хранения модели внешнего ресурса
5.3 Особенности использования асинхронных ресурсов в модели

6. Цифровая архитектура
6.1 Описание всех компонентов системы
6.2 Описание связей между компонентами
6.3 Формат для обработки в модели
6.4 Версионирование архитектуры

7. Описание нагрузки
7.1 tps и трафик

8. Собираем все вместе
8.1 Алгоритм работы симулятора
8.2 Нагрузочное моделирование вместо нагрузочного тестирования
8.3 Что можно увидеть в симуляторе
8.3.1 Отклонение во времени отклика
8.3.2 Увеличение входного/выходного трафика
8.3.3 Изменение трафика при обращении к внешним ресурсамbelet)
8.4 Наша модель
8.4.1 Сравнение результатов разных систем
8.4.2 Точность попадания
8.4.3 Перспективы развития

9. Заключение

Что такое Workload Identity Federation и зачем он нужен
Как настроить интеграцию с типичными CI/CD в GitLab/GitHub/SourceCraft

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

В докладе разберём реальный кейс импортозамещения BigQuery и построения собственного data lake на базе S3 и ClickHouse. Покажем, как сохранить ключевые преимущества облачных дата-лейков – разделение хранения и вычислений, гибкое масштабирование и оплату «по факту расчётов» – без постоянных затрат на дорогую инфраструктуру и команду из Hadoop/Spark-специалистов.

Мы расскажем, как декомпозировать классический data lake на два слоя: дешёвое объектное хранилище (S3) для тяжёлого процессинга и ClickHouse как витрину для OLAP-запросов.

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

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

1. Эволюция инфраструктуры
- На ранних этапах проекта достаточно одного окружения (prod), но с появлением клиентов и команды разработки требуется разделение: dev, demo, окружения под конкретных заказчиков.
- Инфраструктура постепенно усложняется: появляются отдельные кластеры, изоляция, резервирование по регионам.
- Отсутствие стратегического подхода к именованию приводит к хаосу и усложняет сопровождение.

2. Типовые ошибки при масштабировании
Несогласованное именование ресурсов.
- Неочевидная структура стендов и их назначение.
- Конфликт имен при миграциях или масштабировании.
- Недостаточная гибкость схемы именования — необходимость переименования существующих ресурсов при добавлении новых.
- Избыточное дублирование в именах (example-prod-prod-*).

3. Потери от неструктурированного подхода
- Увеличение времени на онбординг и передачу знаний.
- Ошибки в навигации по инфраструктуре, особенно при ротации сотрудников.
- Нарушения SLA из-за некорректных алертов, связанных с неправильной категоризацией окружений.
- Рост технического долга: невозможность безопасного переименования, необходимость в обходных решениях.

4. Методология проектирования
- Разделение на логические контуры (infra, nonprod, prod) упрощает управление доступами и ресурсами.
- Именование должно быть масштабируемым, человекочитаемым и отражать назначение, окружение, регион, тип ресурса и его принадлежность.
- Важно формализовать правила именования и зафиксировать их в глоссарии.
- Учитывать регион/датацентр, чтобы упростить диагностику и автоматизацию.

5. Практические рекомендации и инструменты
- Использовать Infrastructure as Code инструменты (Terraform, Pulumi, Crossplane, Ansible) для внедрения стандартов и шаблонов.
- Внедрение валидации и автогенерации имен на уровне CI/CD.

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

Как собирать системные логи, когда у тебя несколько тысяч сёрверов? Как это делать эффективно? Расскажем о том, как мы собираем со всей видеоплатформы RUTUBE системные логи: и операционной системы, и оборудования. Покажем, как избежать узких мест в Rsyslog и анализировать их в VictoriaLogs. Поделимся опытом, как построить систему сбора логов, которая будет ресурсоэффективная и быстрая.

Сегодня разработчики перестают "просто писать код". Они становятся полноценными участниками создания ценности для бизнеса. Фокус команд смещается - вместо абстрактных технических KPI, таких как uptime сервера, количество ошибок в сервисе, среднее время отклика приложения и тд, все чаще в приоритете такие бизнес-показатели как количество затронутых клиентов при сбоях, конверсия критичных шагов процесса, здоровье бизнес-транзакций и всего бизнес-процесса.

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

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

Главная цель любого мониторинга — сделать вашу систему наблюдаемой. Для обеспечения её корректной работы вам необходимо иметь доступ ко всей измеряемой информации.
Не смотря на то что системы мониторинга должны уметь собирать большой объем информации, множество программных решений не предлагает единообразного метода их сбора. Эту проблему и решает Alligator, который с одной стороны выступая универсальным агентом, доставляет эту информацию до prometheus.
Полагаю, что подходы, описанные в статье, применимы к любым другим инструментам мониторинга. Alligator - инструмент, который может упростить этот процесс.

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

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

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

Основных проблемы мы видели две:
1. Огромные портянки Prometheus Alerting Rules, в которых черт ногу сломит, и которые бездумно дублируются в десятках разных репозиториев и сотнях кластеров
2. Никакой унификации и единого понимания, что именно нужно отслеживать, и на каких порогах алертить
3. Ну и конечно же лень, забывчивость и безответственность, куда без них.

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

На докладе мы вместе с Евгением Баулиным (техлид и Java-разработчик) расскажем, как мы формировали спецификацию CRD, с какими подводными камнями столкнулись при разработке оператора, как шаблонизировали алерты, чтобы разработчик или инженер мог настроить все необходимые (и не очень) алерты, используя Kubernetes-ресурс со спецификацией в десяток строк.

В Туту команды разработки живут в парадигме YBI/YRI. То есть, 30 команд сами делают алерты для себя самих. Как итог - Графана, в которой 5 тысяч очень разных алерт-правил от сотен авторов. Расскажу, как мы управляем ими, как показываем командам что можно улучшить, а бизнесу - где красные зоны. Коснемся доставки и пользы от самой нотификации, обсудим проверку качества правил и их автоматическое создание. Покажу, какую аналитику собираем, и как это помогает.

Делимся опытом внедрения единого решения для метрик

AI-агенты все плотнее входят в нашу повседневную жизнь и встраиваются в бизнесы компаний, где мы работаем. Если год назад приложение, плотно интегрированное с LLM, было чем-то особенным, то сейчас этим никого не удивить. И с ростом популярности AI-агентов растет и значимость темы мониторинга их работы - а как понять, что AI-агент работает как надо? И как вообще мониторить интеграцию с большим "черным ящиком" под названием LLM, от которого может зависеть так многое?

В этом докладе вы узнаете о том, как правильно организовать observability для LLM-агентов. Мы разберём принципы работы агентов и покажем, что за кажущейся магией стоит обычная инженерия. Вы познакомитесь с базовыми подходами к мониторингу через трейсы, метрики и evals, а также узнаете о ключевых проблемах: незрелость OpenTelemetry в этой области, отсутствие единых конвенций и сложности визуализации больших текстовых данных.

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

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

1. Постановка задач
1.1 Цикл разработки AI+ML решений
1.2 Цикл сбора, хранения и использования знаний
1.3 Edge VS Local VS Remote

2. Как сделать доступнее разработку AI+ML
2.1 Рабочая среда: Python
2.2 Рабочая среда: TF+PT+CUDA
2.3 Рабочая среда: модели
2.4 Как не решать не свои задачи И DevOps/MLOps И разработчикам

3. Архитектура
3.1 Среды и экземпляры - тонкая грань между ними и почему она часто рвётся
3.2 Хранение моделей: исходные и дообученные
3.3 Хранение знаний: правильное разделение и защита

4. Практические кейсы
4.1 Добавляем голосовые команды: софт + железо
4.2 Добавляем голосовой ответ: софт + железо
4.3 Почему Local = must have
4.4 [Edge vs Local] -> [Edge + Local]
4.5 Remote: как правильно добавлять внешние данные и что действительно для этого нужно по софту и железу

Построение ML-платформ внутри компании - амбициозная задача для сокращения time-to-market выкатки моделей в продакшен, времени проверки новых гипотез, централизованной утилизации таких дорогих ресурсов как GPU. С такими вызовами может столкнуться как компания уровня бигтеха, так и небольшая команда, активно использующая ML в своих продуктах.
В докладе я разберу практический опыт построения ML-платформ разного масштаба: пройдем путь от платформы для команд с десятками дата-сайнтистов до больших компаний уровня Авито, где сотни DS и аналитиков ежедневно запускают сотни пайплайнов.
Где можно обойтись сборкой и конфигурацией opensource (Clearml, Keycloak, Jhub), а где нужно внедрять мультитенантный Kubeflow на 1500 уникальных профилей и 500 MAU и иметь собственную команду разработки.
Как организовать инференс моделей? Использовать существующий PaaS компании или поднять собственную инференс-платформу?. Сравню существующие open-source решения (Kserve, Yatai, BentoML, Seldon) и PaaS уровня компании. Разберу отличия инференса классических ML-моделей и современных LLM, плюсы и минусы объединения их в одну платформу.
В докладе:
разберём ML-платформы “на коленке” и масштаба компании в сотню пользователей;
обсудим инструменты, которые позволяют решить проблемы утилизации ресурсов, скедулинга ворклоудов, инференса моделей;
Что заберете с собой:
примеры построения ml-платформ;
решения различных болей (управление пользователями/командами, скедулинг ворклоудов, доступ к общим ресурсам GPU) при построении платформ для десятков и сотен пользователей;

Развертывание и управление кластером Kubernetes с поддержкой GPU в изолированном контуре — это вызов, особенно когда нужно обеспечить низкие задержки InfiniBand и изоляцию для множества команд.
Мы расскажем, как решили эту задачу, построив полностью автоматизированный стек на базе операторов. Вы увидите, как:

- “GPU и Network Operator” - берут на себя всю сложность настройки драйверов, SR-IOV VF и сетевых партиций (pkey).

- “Автоматизация на основе квот” - предоставляет разработчикам изолированные неймспейсы с гарантированной долей GPU и высокой производительностью сети.

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

Доклад о том, как CI/CD и подходы к автоматизации позволяют сделать деплой данных стабильным, а качество — предсказуемым.
На примере dbt поговорим:

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

numpy - библиотека, применяемая в научных исследованиях, data science, machine learning и big data. Данная библиотека используется для реализации оптимальных решений. А можно ли быстрее? Можно!

Сложно представить себе кластер Kubernetes без образов из больших зарубежных реестров вроде ghcr.io или docker.io. Выкачивание образов напрямую из этих реестров несёт за собой зависимость от чужой инфраструктуры, которая может оказаться нестабильной во время технических сбоев или быть недоступной в определённых окружениях, допустим air-gapped или со слабой связанностью. Также для прохождения многих сертификаций вроде внесния в реестр отечественного ПО требуется расположение подобных артефактов на территории РФ.

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

Доклад будет полезен Platform Engineer'ам, DevOps-инженерам, SRE, разработчикам IDP.

Требования полной изоляции сборочных сред от внешнего интернета – повседневная
реальность для многих команд. Закрытые контуры, регуляторные ограничения и требования
ИБ ставят вопрос: как строить CI/CD, если внешнего интернета нет вовсе, а пайплайн при
этом должен быть воспроизводимым, проверяемым и стабильным?
На круглом столе мы соберём инженеров и архитекторов, которые уже прошли этот путь, и
обсудим реальные практики построения изолированных CI/CD-процессов:
1. Верификацию изоляции: Практики проверки «чистоты» сборки (mitmproxy, анализ
сетевого трафика, инструменты вроде Ansible для конфигурации).
2. Архитектуру зависимостей: Как создать и поддерживать внутренние зеркала для
пакетных менеджеров, Docker-образов, системных репозиториев?
3. Инструментарий и пайплайны: Git, Jenkins и другие инструменты в условиях офлайн.
4. Работающие практики: управление зависимостями, настройка пайплайнов и проверка
среды в условиях «нулевого» исходящего трафика
Формат – инженерный разбор полетов с открытым микрофоном. Приходите с вопросами,
своим опытом или скепсисом. Будем разбирать живые кейсы, спорить, искать решение для
одной из самых нетривиальных задач в DevOps.

У нас специфичный проект эмуляторов сетей для тренировки и прокачки навыков студентов, который жил на обычных Ubuntu. Времена меняются, технологии развиваются, а конфигурировать инфраструктуру контролировать хочется из кода максимально просто. Разберём первые попытки запуска комплекса на стареньких физических серверах, покажем, как развивается ALT Linux, какие проекты он предоставляет, покажем как внутри кубернетеса можно разворачивать виртуальные коммутаторы и маршрутизаторы, а самое главное, управлять самим кубом из пары YAML файлов. После этого доклада, вы захотите перейти на эту (не) перечеркнуто идеальную систему TALOS

Будут подготовлены и представлены Антону Быстрову до 27.11.2025 года.

В докладе Дмитрий Бобров расскажет, как на практике проектировать и эксплуатировать продуктовые AI-агенты и голосовые ассистенты — от архитектуры и инфраструктуры до MLOps и надёжности.

Будут разобраны:

- архитектура платформ для AI-агентов и голосовых ассистентов
- пайплайны обработки речи: ASR, NLP, LLM, TTS
- интеграция AI-агентов с бизнес-системами и API
- инфраструктура для real-time inference
- MLOps-практики для обучения и обновления моделей
- деплой, масштабирование и отказоустойчивость
- мониторинг, логирование и контроль качества диалогов
- типовые ошибки при запуске AI-ассистентов в продакшене

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

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

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

TBD

В докладе разберём путь Мир Plat.Form от построения прототипа и запуска пилота до передачи в эксплуатацию собственного production-ready решения “Аист” по генерация кода в контуре компании. Из доклада узнаете, как построить архитектуру сервиса, предоставить разграниченный доступ к локальным LLM, и какие кейсы это решение позволило автоматизировать.

AI generates your Terraform now. LLM writes the module, Checkov scans it, PR gets merged, infrastructure deploys. Beautiful workflow. Then drift happens. Someone clicks in the console. A security group gets modified. A network ACL changes outside version control. Your AI-generated infrastructure, your security policies, and your network configurations diverge from declared state. Now what? Drift is not just an infrastructure problem - it's a security incident waiting to happen and a network outage in progress. The generation problem is solved. The operations problem crosses team boundaries. Modern observability stacks, policy engines, and agent frameworks have matured. OPA can enforce policy continuously. State comparison can be automated. LLMs can analyze drift and generate remediation. The engineering challenge is building systems that work across DevOps, SecOps, and NetOps while keeping humans in control.

This session covers the building of unified drift detection pipelines, spanning infrastructure, security policies, and network configurations. We'll explore AI agents that analyze root cause and generate domain-specific remediation PRs, governance guardrails for AI agent behavior using policy-as-code, and GitOps integration with cross-team approval workflows. We'll also cover failure modes: remediation loops, alert fatigue from noisy detection, and compliance risks of over-automation.

Большинство разговоров про AI в разработке крутятся вокруг ускорения: быстрее писать код, быстрее прототипировать, быстрее выпускать фичи. На практике же мы столкнулись с тем, что настоящий эффект от AI может начаться тогда, когда он ломает привычные процессы, а не просто встраивается в них.
В этом докладе — реальный кейс Bitrix24, где одна из команд, отвечающая за интеграции и тиражные приложения, была полностью переведена на AI-ассистированную разработку. Это решение оказалось настолько disruptive, что мы были вынуждены отказаться от дальнейшего развития значительной части существующего кода: старые приложения остались на поддержке и багфиксах, а новый функционал стал разрабатываться уже в другой технологической парадигме.
Мы полностью сменили фреймворки, пересобрали архитектурные подходы, изменили требования к качеству кода и документации и, по сути, пересобрали саму модель работы команды. В результате каждый разработчик в такой модели стал выполнять роль тимлида: управлять спецификациями, принимать архитектурные решения и работать с AI как с полноценным участником процесса.
В докладе будет показано, почему привычный «вайб-кодинг с AI» не работает в production, какие архитектурные и процессные ограничения накладывает ассистированная разработка и почему переход на неё — это не про удобство, а про осознанный технологический выбор. Мы разберём, какие решения оказались успешными, какие — болезненными, и за счёт чего команда в итоге вышла на новый уровень эффективности.
Доклад будет полезен разработчикам, тимлидам и менеджерам, которые хотят понять, что на самом деле происходит, когда AI перестаёт быть экспериментом и становится основой процесса веб-разработки.

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

В докладе я разберу реальный кейс разработки production Kubernetes-оператора за 7 дней вместо привычных 2–3 месяцев. Я покажу, как LLM использовался не сам по себе, а внутри инженерного процесса: с декомпозицией задач, поиском контекста в репозитории, проверкой решений и явными точками, где окончательное решение принимает человек.

Доклад будет полезен инженерам, которые работают с Kubernetes и инфраструктурным кодом (в том числе операторами и контроллерами) и хотят понять, в каких задачах LLM реально экономит время, где создаёт риски и почему без процесса и контроля такой подход не даёт устойчивого результата.

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

Словосочетание «вайб-кодинг» появилось в феврале 2025 года и быстро стало популярным в инженерной среде. Мы задаём контекст, ограничения и формат артефактов, а AI помогает наращивать решение шаг за шагом. Такой подход позволяет DevOps-инженерам и разработчикам быстрее находить баги, вносить небольшие ценные изменения и собирать прототипы автоматизации.
На примере разработки KeyVal Operator — Kubernetes-оператора для управления Redis и ValKey в кластере — я покажу, как формировать правильный «вайб». Вы узнаете, как можно планировать итерации, декомпозировать задачи и разбивать их на шаблоны, строить фундамент тестов и держать качество под контролем. Отдельно разберём совершённые ошибки и то, как процессы и тесты помогают контролировать качество.

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

Мы расскажем о том, как SRE и DevOps инженеры могут избавиться от рутины и автоматизировать RCA с помощью AI SRE.
Разберем, как мы создали AI сервис, и как он помог нам упростить обслуживание и эксплуатацию облака.

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

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

С лидерами индустрии обсудим практики инцидент-менеджмента в различных компаниях

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

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

Кажется, ещё чуть-чуть — и DevOps можно выкидывать: GitLab сам пишет пайплайны, облака собирают инфраструктуру «по описанию», LLM-ы генерируют Terraform и Helm, а в LinkedIn каждые две недели выходит пост «AI заменит X к 2030 году».

Обсудим за столом и разберёмся, что из этого правда, что хайп, и как вообще будет выглядеть работа DevOps-инженера в мире, где AI умеет писать код, YAML и даже иногда его запускать :)

Идеи разные, тезисы потом сформулировать точные

Синдром самозванца 2.0: Стыдно признаться, что практикуешь «vibe‑coding» ?
Обсудим, в каких задачах LLM‑модели приносят реальную пользу, а где они создают техдолг. Как junior и senior по-разному относятся к AI-инструментам.

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

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

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

Юмористический технический интерактив. Директор колхоза им "Алертинга" хочет настроить мониторинг своих сотрудников...Петровича, Михалыча и Зинки. Задача проста - получать оповещения, когда кто-то из этих сотрудников явно собирается не работать.

Интерактив нацелен на веселое представление и построение архитектуры алертов, поиска контекста и предположений "Какой же алерт нам нужен"

Ingress NGINX всё, Kubernetes SIG выпустили официальный deprecation notice на 2026 год. Попробуем разобраться в альтернативах самому популярному решению и сравним трудности перехода на 2-3 основных кандидата.

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

Запустим приложение в кластере Kubernetes и разберемся, когда ему становится "тесно" внутри одного кластера и уже нужен мультикластер. Обсудим, что такое Karmada, основные принципы работы этого инструмента и его архитектуру. Проапгрейдим наше приложение — установим Karmada, добавим в нее кластеры-участники, мигрируем наше приложение в мультикластер и настроим мультикластерные автомасштабирование и отказоустойчивость.

Краткое описание:
Микросервисы обещали нам независимость, но вместо этого мы получаем «ад зависимостей» в Helm-чартах и непрозрачные счета от облачных провайдеров. Почему изменение в логике «Уборки номеров» требует пересборки всей системы, а падение «Биллинга» кладет поиск отелей?
Пора переходить от нано-сервисов к Packaged Business Capabilities (PBC). Это не просто архитектурный паттерн, это способ организовать код, инфраструктуру и затраты вокруг бизнес-ценности.

На этом воркшопе мы проведем инженерный спидран: возьмем систему бронирования отелей и за 45 минут отрефакторим её из «распределенного спагетти» в набор автономных PBC. Мы будем работать не только с кодом, но и с Terraform, K8s манифестами и FinOps-тегами.

Что мы сделаем за 45 минут:
- Infrastructure Co-location: Вынесем роуты, DTO и Terraform-модули из «общих свалок» в изолированные директории возможностей (Capabilities).
- Tiered Infrastructure: Настроим разные стратегии деплоя. Почему «Поиск» живет на дешевых Spot-инстансах с HPA, а «Финансы» — на Reserved-нодах с гарантированным RPO/RTO.
- Contract Design (Security & Resilience): Спроектируем контракты так, чтобы Guest PBC не зависел от доступности API Finance, и внедрим Network Policies на уровне неймспейсов.
- FinOps в коде: Внедрим автоматическое тегирование ресурсов. Превратим абстрактный счет за облако в отчет о Unit-экономике одного бронирования.
- CI/CD Optimization: Настроим пайплайны так, чтобы билд и тесты запускались только для измененного PBC, экономя время и деньги на раннерах.

Ценность воркшопа:
- P&L Архитектура: Мы доказываем, что архитектурное решение (например, Coarse-grained API) — это не вопрос вкуса, а вопрос снижения Latency на 30% и Egress-трафика на 15%.
- Unit Economics: В конце воркшопа мы получим формулу: Cost per Booking = (Infra Guest + Infra Finance + Infra PMS) / Total Orders. Это святой грааль для CTO.
- Безопасность как Capability: Изоляция на уровне неймспейсов и секретов (Vault) в PBC подходе минимизирует Blast Radius при взломе или ошибке.

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

Проще говоря, мы с вами на примере тестового куб кластера совершим атаку на наши сервисы и затем с помощью средства мониторинга рантайма контейнеров вместе отследим по каким косвенным или прямым уликам можно наглядно увидеть действия злоумышленника.
В ходе практического занятия все участники смогут примерить на себя роль пентестера и самостоятельно реализовать один из заложенных векторов атаки. После мы поймем и пройдем путь детектива-безопасника, а также рассмотрим, как грамотно организовать защиту периметра, если в нем есть контейнеры, включая расследование, алертинг и реагирование.
Для работы потребуется ноутбук с одной из виртуализаций - UTM (для маков), WSL2 (для винды), KVM (для линукса). Также мы ожидаем от участников базовое знание командной строки ОС Linux (умения открыть консоль и знание базовых команд, например, whoami, base64, id, ls и telnet) и базовые представления о k8s (знание о сущностях k8s - pod, deployment, service, ingress и базовое умение пользоваться любым менеджером для управления кластером kubectl/k9s/lens для вывода списка подов, проваливания в шелл выбранного пода).

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

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

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

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

Расширенная версия бизнес-симуляции FeatureBan, от Майка Барроуз. В данной игре мы проводим симуляцию взаимодействия не только внутри команды, но и между командами, ПМ и ПО. В ходе воркшопа сформулируем и проверим гипотезы для наиболее эффективной координации команд.

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

Важно! Для участия требуется ноутбук с предустановленными WireGuard и SSH-клиентами.

В наше время существует очень много практик по предотвращению инцидентов и по ведению процессов вокруг них. Однако никто не умеет учить самому ТУШЕНИЮ инцидентов.

Мы считаем, что по-настоящему научиться локализовывать и решать проблемы во время инцидента можно только набивая шишки.

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

Формат игры:

Всем участникам выдадут заготовленный стенд, где будет развернут сервис, на который будет подаваться нагрузка, эмулирующая реальных пользователей. В сервисе будут заложены проблемы, которые будут активироваться с течением времени. Помимо сервиса стенд будет в себя включать базовую инфраструктуру, необходимую для выявления аномалий и их устранения: пайплайн доставки кода (GitLab), метрики (Victoria Metrics + Grafana), логи (Vector + Victoria Logs + Grafana).

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

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

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

Мастер-класс для демонстрации перехода от Ingress к Gateway API на примере миграции с Ingress nginx Controller на NGINX Gateway Fabric

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

На воркшопе мы разберём готовые сценарии для etcd кластера (распределённое key‑value хранилище), покрывающие эти случаи. Вы узнаете, как настроить удобную среду для тестов, обходить типичные проблемы с идемпотентностью, отлаживать тесты без лишних перезапусков и верифицировать взаимодействие с инфраструктурой мониторинга. Применение этих практик экономит 2–3 дня на настройке тестовой инфраструктуры и повышает надёжность Ansible‑ролей за счёт автоматической проверки сложных сценариев. Подход применим для любых ролей, работающих с распределёнными системами и требующих тестирования кластерных взаимодействий, обновлений версий и интеграции с внешними сервисами.

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

Открытое общение про подходы в обеспечении надежности, доступности и инцидент-менеджмент.

Расскажу как мы справились с переносом Kafka под управлением strimzi оператора из одного облака в другое и почему мы выбрали rsync вместо mirrormaker.

Расскажем, как мы считаем количество мощностей для AI inference cluster и совпадает ли это с реальностью

- Общие принципы и корпоративные стандарты
- Методы обхода ограничений облачных провайдеров

Расскажем о том как с 0 построить свою собственную облачную (и не только) инфраструктуру для небольшой ИТ компании в 50-100 человек. Какие нюансы необходимо учесть, на какие грабли не наступить и как выстроить все процессы максимально эффективно.

Что делать, если нужно запустить сложные действия в нужном порядке на тысячах и десятках тысяч серверов? Как быть, когда ssh уже не выводит, а от SaltStack сводит олдскулы? Возможно, этот доклад покажет вам путь в чуть более светлое будущее!

Расскажу про Kerberos, как он устроен, процесс аутентификации, частые ошибки, различные трюки.

Год назад компания Perforce по сути закрыла исходный код Puppet. В ответ на это коммьюнити создало проект OpenVox, в рамках которого была продолжена разработка Puppet Open Source. Что произошло на год, каковы успехи и планы — обо всем этом в моем докладе.

Расскажу о полезных в повседневной работе инструментах экосистемы Nix — от пакетного менеджера и репозитория nixpkgs до home-manager.

На практических примерах покажу, как воспроизводимость окружений помогает отлавливать баги и делает CI/CD надёжным. Разберём, как организовать dev-среды для C/C++-проектов и даже виртуальные машины, и почему даже bash-скрипту стоит явно указать зависимости.

Сравним Nix с привычными менеджерами пакетов — cargo, npm, poetry, conan — и обсудим, чем философия Nix отличается: почему это не просто инструмент, а другой способ мыслить о сборке и управлении системой.

- Что такое eBPF и как он работает
- Как технически определить блокировку ресурса
- Пишем модуль и обвязку
- Визуализируем через Prometheus & Grafana

Microservices were an application architecture decision. Then networking got involved. Fifty services. Each talks to twelve others. mTLS everywhere. Network policies per service. Service mesh handles it. Beautiful diagrams. Then an incident happens. Service A can't reach Service B. Is it a network policy? The mesh config? The certificate? The load balancer? DNS? The sidecar? Debugging requires expertise in all of them.

Your DevOps team owns the services. Your NetOps team owns the network. Your SecOps team owns the policies. The incident spans all three. Mean time to resolution is measured in hours while everyone checks their own domain. The service mesh abstracted the network. It didn't eliminate it. It moved complexity from one layer to three. Your developers don't think about networking. They shouldn't have to. But when it breaks, someone needs to understand the full stack. This person doesn't exist.

This session covers network operations at microservices scale. We'll explore observability strategies spanning application, mesh, and network layers, debugging workflows for cross-domain connectivity failures, policy management that scales without becoming unmaintained, certificate lifecycle across hundreds of services, and cross-functional incident response when nobody owns the full path.

Мы расскажем об эволюции сети в bare metal кластере K8s от IPv6 к dualstack.
За время жизни кластера был мы встречались с разными челленджами: разнородные среды сети (IPv6 only и Dualstack) и неготовность openSource к IPv6, сложный IPAM для проектов и интеграция с внутренним файрволом. Из презентации вы узнаете, как мы преодолевали все проблемы, и какие решения придумывали.

Istio Service Mesh является основой для сетевых взаимодействий между сервисами в современной cloud native среде, но использование сайдкаров istio-proxy требует больших вычислительных ресурсов. Чтобы сократить расходы, мы обратили внимание на Sidecarless архитектуру – Ambient Mesh. В этом докладе мы поделимся опытом внедрения Ambient Mesh: от пилотирования до решения возникающих проблем, а также расскажем о результатах – сколько ресурсов нам удалось сэкономить...

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

Disclaimer. Докладчик - независимый (безработный) эксперт, который точно не рекламируют ни одну компанию

Я расскажу, как мы живём и работаем с огромной базой Ansible-кода (~300 плейбука и ~150 ролей) и VK Cloud. Про сложности разработки, синхронизации инвенторки к новому коду, ошибках и о том, как мы всё это переживаем

Расскажу о практическом опыте миграции крупной высоконагруженной eCommerce-системы из Яндекс.Облака в Cloud.ru в условиях «сжатия» рынка и с жёстким сроком реализации в 12 месяцев.

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

Узнаем ошибки и уроки, выявленные в ходе миграции, включая проблемы с расчётом ёмкости, mesh-сетями, базами данных, брокерами сообщений, объектными хранилищами и непрерывностью сервиса.

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

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

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

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

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

Что значит создавать инфраструктуру под облако: основные принципы и особенности.

Поддержка инфраструктуры в разных окружениях: продакшн и предпрод, особенности работы и управления.

Какие альтернативы Ansible мы рассматривали для решения этой задачи.

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

Провиженинг облачных ресурсов: эволюция инструментов, от динамического инвентаря до Terraform.

Перечень реализованных функциональностей, существующие ограничения и причины, почему bare-metal тестинги остаются важны.

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

Все мы знаем классическую схему окружений: prod, stage и dev. Но когда в компании много команд и разработчиков, работающих над микросервисным продуктом, начинают возникать трудности. Каждый хочет выкатить свою фичу на dev (чаще всего это комбинация микрофронта и нескольких бэкенд-микросервисов) и передать её тестировщикам. При этом важно, чтобы на стенде оставались стабильные версии всех остальных микросервисов и микрофронтов. Поднимать отдельный стенд для каждой фичи — возможный путь, но он очень ресурсозатратен.

С ростом системы линейно увеличивается количество разработчиков и фич в работе, а также возрастает число микросервисов, что приводит к квадратичному росту затрат на инфраструктуру. Мы поделимся, как этот момент можно обойти более элегантно. Наша идея: поднимать только те сервисы, которые изменяются в рамках фичи, а для остального использовать stage окружение. Этот подход уже год успешно работает у нас.

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

Введение: контекст и ожидания
• После 2022 года ИТ-рынок живёт под лозунгом «импортозамещения и суверенных технологий».
• Параллельно — стремительный рост интереса к ИИ и облачным платформам.
• Результат — пересечение трёх трендов, где маркетинг часто опережает реальные внедрения.
• Ключевой вопрос: что из этого работает в реальных компаниях, а что — «для галочки»?
2. Облака: зрелость и реальность
• Реально работает: корпоративные частные и гибридные облака, Kubernetes-кластеризация, облачные VDI, резервное копирование.
• Импортозамещение в облаках: отечественные провайдеры (VK Cloud, Selectel, SberCloud, Yandex Cloud, МТС Cloud) уже закрывают 80–90 % базовых сценариев IaaS/PaaS.
• Хайп: заявления о «полной независимости» — большинство решений всё ещё завязаны на open-source-компоненты зарубежного происхождения (Ceph, Postgres, Kubernetes).
• Основной вызов: интеграция и эксплуатация, а не технологии как таковые.
3. Импортозамещение: где получилось, а где нет
• Успешно: офисные пакеты, ECM/EDMS, BPM, СЭД, CRM, BI-платформы — появились зрелые отечественные аналоги (Р7-Офис, Docsvision, Naumen, PlatformaBI).
• Проблемы: промышленный софт, PLM, SCADA, CAD/CAM, решения для высоконагруженных систем.
• Парадокс: компании закупают «отечественные оболочки», но внутри остаются компоненты PostgreSQL, Redis, Elastic, Python — что не делает систему полностью импортонезависимой.
• Вывод: импортозамещение — не одноразовая акция, а процесс построения компетенций и экосистемы.

4. Искусственный интеллект: от хайпа к пользе
• Работает:
o Компьютерное зрение (контроль качества, OSA, ритейл).
o NLP-модели для анализа обращений, ассистенты операторов, чат-боты.
o Рекомендательные системы и LTR (Learning to Rank).
• Хайп:
o Беззастенчивое внедрение «ИИ-помощников» без данных, инфраструктуры и KPI.
o Использование LLM без учёта приватности и стоимости эксплуатации.
• Ключ: ИИ — это не «продукт», а часть цепочки автоматизации, где важнее качество данных и бизнес-метрики.
5. Где сходятся три тренда
• ИИ требует облачной инфраструктуры и производительных вычислений.
• Импортозамещение требует локальных дата-центров и компетенций, что снижает гибкость.
• Реальность: большинство крупных компаний идут к гибридной модели — локальные мощности + частное облако + российский стек (Linux, Postgres, Python, Kubernetes).
• Конкурентное преимущество сейчас не в «чистом» импортозамещении, а в гибком сочетании подходов.
6. Практические выводы
• Не ставьте задачу «заменить всё», ставьте задачу обеспечить устойчивость и контроль.
• Облака и ИИ эффективны только при зрелом data governance.
• Импортозамещение — это управление зависимостями, а не только смена логотипов.
• Измеряйте результат в терминах бизнеса: ROI, сокращение времени, снижение ошибок, улучшение клиентского опыта.

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

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

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

На воркшопе для инженеров и управленцев в IT разберем поэтапный подход к DevOps-трансформации, основанного на реальном опыте масштабирования. Научим, как из хаоса с 200+ оркестраторами стать управляемой компанией с едиными процессами и централизованными инструментами. Объясним, как избежать перегибов и получив лояльность команд. По итогам участники воркшопа получат референсную дорожную карту по внедрению изменений.

Как часто вы сидели над кодом, который достался вам от предыдущих поколений разработчиков и не могли понять, почему оно вообще работает и как это дальше развивать?
А видели ли вы код, который в принципе не должен был работать, но работал?
Замирали ужасе от процессов, которые не подчиняются никакой логике, но все равно приводили к результатам?
Добро пожаловать в бигтех! Здесь вас ждет неутомимая энергия WAAAGH и знания из Темной Эры технологий. Проведем увлекательную экскурсию в невероятный мир веры и безумия.

Расскажем, как обосновать расходы на эксперименты с AI, заложить бюджет на «костыли» и при этом сохранить доверие финансового директора.

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

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

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

Что такое "Эффективное ИТ"?
Как управлять потоком задач и ответить на вопрос "когда будет сделано"?
Как создать "Прозрачность" в ИТ понятную всем?
Что такое Flow Framework и почему организация - это сеть?
Говорим с заказчиком на языке Time to Market, ROI, eNPS
Если по-простому:
Закопаем стюардессу с именем Scrum, а откопаем c именем Kan-ban, дадим ей стероидов и умчимся в прекрасный новый мир метрик потока, предсказуемых сроков и ясных целей.

К чему может привести неправильный подход к созданию тестов. Как их не допустить. Шутливый доклад на важную тему

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

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

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

Мы все привыкли к тому, что у нас есть облака и можно легко что - то задеплоить в облако.
А что делать, если мы должны задеплоить само облако, как и куда? Это неординарная техническая задача.

Дефакто стандартом индустрии стал Kubernetes, но как быть, если ваш k8s кластер такой, что kubectl get nodes выводит 5‑значное число узлов? Вот и мы в Yandex Cloud в команде Cloud Foundation Services создаем и поддерживаем кластера размером на 10 000+ нод и почему их разделить нельзя расскажу в докладе.

Деплой облака не самая тривиальная задача и в силу особенностей нашей инфраструкруры, железа, деплоя и UX, всё это ставит перед нами ряд таких задач как обслуживание, мониторинг, обновление,, а также тюнинг.
В k8s есть ряд специфичных вещей, например: etcd достаточная копризная и требовательная, а API Server не спасти масштабированием — нужны тонкая настройка и обходные пути.

Если вы DevOps/SRE с растущими кластерами, этот доклад для вас. Расскажем, как наблюдать такой кластер, когда обычные методы бессильны, и как безопасно обновлять тысячи узлов. Если вам интересно как мы решили эту задачу, или вы понимаете, что это ваше будущее приходить послушать: как масштабировать мониторинг, обновлять тысячи узлов без простоев и обходить особенности etcd и API Server.

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

TBD

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

Проблема доставки provider софта в кубер всегда была местом для творчества команд, предоставляющих Kubernetes as a Service. Мы поделимся опытом MWS Cloud и расскажем что взяли за основу механики доставки, как нативно запускаем процесс установки опираясь на жизненный цикл кластера, как применяем GitOps подход и каким образом дали управление обновлением managed кластера пользователю в пару кликов.

Что такое ИИ-агент c точки зрения Kubernetes - регулярное контейнерное приложение или абсолютно новый вид рабочих нагрузки для кластера с особым трафиком?
Как рулить инференсом моделей для агентов? Протоколы MCP, A2A - это обычный HTTP или что-то большее? И что там с сетевой безопасностью?
Приходите на доклад - все обсудим.

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

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

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

- Выбор между none и static — это компромисс, а не yes|no
- Kernel noise — invisible cost который убивает performance
- CPU Management = observability + testing + подход к выбору решения

Хочется крутить AI как в облаке, но у себя в контуре? А как там? Арендуешь виртуальные машины у облачного провайдера, выполняешь пару команд — и вот уже на выходе показались первые токены. При этом значительная часть современных AI-нагрузок развернута в Kubernetes.

Но что при этом происходит под капотом, и как добиться такого же пользовательского опыта в контуре компании? В докладе расскажем, как мы решаем эту задачу в Yandex Cloud Stackland.

Вместе мы последовательно переберем «слои», из которых состоит типовой GPU-кластер (оборудование и драйверы, интеграция с Kubernetes, observability, интерконнект) и в каждом случае дадим ответы на четыре вопроса:
• Как устроено взаимодействие этого слоя с предыдущим и последующим, иными словами, каков контракт?
• Какие есть опции для реализации этого контракта?
• Чем они отличаются и как выбрать из них наиболее подходящую, исходя из задачи?
• На что обратить внимание при эксплуатации

Наш продукт — корпоративная почтовая система, разработанная на микросервисной архитектуре и разворачиваемая у заказчиков (или на наших мощностях) через тяжелые Ansible-плейбуки. Установка занимала 3–4 часа, изменение любого параметра требовало полного прогона, а локальной среды разработки не существовало.
Kubernetes выглядел очевидным способом решить все проблемы, но переписать весь деплой под k8s мы не могли: конфигурации были огромными, обросшими логикой Jinja2 и глубоко завязанными на Ansible.
Мы нашли гибридный подход: сохранили Ansible как единую точку правды, научились генерировать конфигурации через Ansible в local-режиме и подхватывать их в helmfile, передавая все параметры из одного места как в j2-шаблоны, так и в Helm. В итоге мы сократили развёртывание до 5 минут, получили изолированное тестирование, полноценную локальную разработку и CI/CD на Kubernetes — не переписывая продукт с нуля.
Расскажем, где мы наступили на грабли, что пришлось чинить и почему этот путь оказался дешевле и надёжнее полного переписывания.

- Что из себя представляет PV и PVC, и почему ни отделены
- Какие есть типы
- Плюсы и минусы использования
- Проблемы миграций
- DRP план, на случай катастрофы

Мы расскажем о том, есть ли жизнь (спойлер - есть!) после того, как вы развернули первые несколько сотен кластеров, на что она похожа и некоторые секреты, как до неё такой дойти и не сойти с ума в процессе.

Поселилось разрабатываемое приложение как-то в ванильном в K8s, состоящее из 10 сервисов, как бизнесовых, так и системных. Разрабатывалось оно не один день, проходила различные этапы тестирования, и, наконец, дошло до продакшена. И было счастье и радость всем добрым молодцам пока не случилась беда. А беда пришла не одна, ибо мониторилась лишь часть performance кластера, но не состояние приложения. Начали решать проблему добро молодцы, да не сразу вышло: не было ни логов, ни трейсов, была сплошная беда. И возник пред ними вопрос закономерный - как что и что стоит мониторить в приложении том. Именно об этом и пойдёт сказ.

ITSM и ITIL должны быть источником вдохновения, но не панацеей. Почему во времена разработанных десятилетиями практик, библиотек и стандартов (ITIL, ITSM, ISO 20000 и т.д.) нужно уметь закрывать на них глаза. Пойдем от противного, расскажу как слепое следование "best practices" мешало результатам и какими способами это обходили сохраняя баланс между "порядок vs быстрые изменения"
Поговорим об
- Практика Incident Management. Взаимодействие "пользователь-L1-L2-L3"
- Практика Service Level Management. OLA - добро или зло?
- Практика Monitoring and Event Managmenet. Мониторинг может быть бесполезным или даже вредным.
- Кейс. Просто изменив очевидный\знакомый всем порядок действий, увеличили эффективность в 2 раза. Повод всем внедрить?

- Мы расскажем о том, как в Купере создавали процессы управления инцидентами: реакция и обработка алертов, коммуникация со смежными командами, эскалация инцидентов.
- Расскажем про формирование "Команды по спасению мира" и её привлечение в случае критичного инцидента.
- Покажем, как у нас происходит ведение инцидента и информирование по нему: регистрация, приоритизация, оповещение. Как нам во всём этом помогают наши собственные разработки (Jarvis bot, Status Page).
- Метрики успеха для инженеров мониторинга: скорость и качество.
- Покажем интеграцию, которая сильно облегчает постмортем инцидентов.

Инцидент зарождается в тот момент, когда мы задумываем изменение. Плохо продумали его, не учли чего-то — получили простой бизнеса на пару часов и миллионные убытки.
Хотелось бы избежать этого, но как?
У всех нас со временем накопились какие-то приёмы, подходы, как организационно можно заранее подстелить соломку, что сделать, по каким чек-листам провериться, чтобы потом с меньшей вероятностью словить инцидент из-за изменений.
На встрече я предлагаю устроить сессию обмена знаниями и вместе родить шпаргалку с реальными, основанными на нашей практике, подходами.

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

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

В Экосистеме МТС мы сталкиваемся с типичной для крупных компаний проблемой: инциденты в IT-инфраструктуре повторяются, а командам недостает объективного, свободного от конфликта интересов "второго пилота", способного убрать эмоции и субъективный подход в процессе работы над PostMortem, при этом обогащая процесс принятия решений опытом анализа прошлых инцидентов. Наш продукт AI PostMortem генерирует гипотезы и рекомендации на основе контекста инцидентов и прошлого опыта команд, что делает процесс анализа быстрее и эффективнее для всех, кто управляет сложными экосистемами. Но создать совершенное решение – сложнее, чем подключиться к LLM и сгенерировать промпт, и проблемы не сводятся к интеграции систем. В докладе мы расскажем, как оценивали добавленную стоимость, создаваемую теми или иными подходами и составляющими экосистемы данных, как реализовали быстрый (миллисекунды) поиск похожих инцидентов в исторической базе, какие уроки извлекли, и куда двинемся дальше.

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

Почему просто “чинить инциденты” мало — и как метрики негативного влияния могут поменять подход бизнеса и ИТ к проблемам, root cause и оптимизации процессов.

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

Как “понятные всем” метрики становятся простыми и сильными коммуникационными инструментами: теперь бизнес понимает, почему не все инциденты одинаково важны, а ИТ может аргументировать свои решения.

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

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

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

Нас учили, что будущее — за облаками. Однако реальность преподнесла сюрприз: это будущее оказалось не только технологичным, но и чрезвычайно дорогим. Мы в RUTUBE пошли против тренда, спустили IT с небес обратно в серверную и на этом пути извлекли ценные уроки.

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

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

Как защитить себя от утечки данных из частных (корпоративных) LLM-моделей. Для ускорение бизнес процессов применение ИИ уже показало свою эффективность. Но как сделать чтоб все данные не были доступны всем пользователям?
Расскажу как LLM Firewall работает, защищает, настраивается и на что способен.

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

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

1. Что не так с популярными Docker образами
2. Российские продукты какие есть преимущества
3. Какая экономия ожидается и какой эффект
4. Решение вопросов безопасности
5. Пример и успешные кейсы внедрения

1 Вступление (2–3 минуты)
1. Приветствие и короткое представление себя.
2. Задача: Автоматизировать установку Linux и запустить всё, что использовалось, на Windows.
3. Решение: АтомПорт — графическая оболочка, которая хранит инвентаризацию, автоматизации и логи, а также К2Тех в помощь.

2 Вклад команды К2Тех (10-15 минут):
Архитектура АтомПорт:
- группы, фильтры и права управления;
- каскадная синхронизация синдиков;
- оптимизация запросов API к БД АтомПорт.
Объем общий:
- миграция 15000 АРМ;
- 5 версий ЗО;
- offline ЗО;
- online ЗО.
Автоматизировано:
- преднастройка АРМ;
- обновление ОС до состояния ЗО;
- обновление ПО до состояния ЗО;
- перенацеливание клиентов.
Интегрировано:
- ПО КриптоПРО, Касперский, SAP и т.д.;
- оборудование (Принтера, Сканеры);
- отечественный домен.
Протестировано:
- ПО проприетарное Заказчика - DWS клиент, АСУ РЭО и т.д.
Созданы условия работы для проприетарного ПО и ПО без поддержки Linux:
- терминальные фермы;
- комплектация ОС ПО - Wine.

3 Формирование подкоманд и их задач
- описываю деления на подкоманды и их задачи;
- озвучиваю особенности работы каждой подкоманды.
4 Что такое АтомПорт (5–7 минут)
Основная часть.
1. АтомПорт — это веб-интерфейс для SaltStack.
2. Поддерживает:
- визуальное управление состояниями;
- распределенные задания и их статусы в реальном времени;
- централизованные логи;
- настройку синдикации и каскадных развертываний;
- визуализацию топологии (Москва → область →регион);
- отчеты.
3. Показываю:
- скрин интерфейса;
- пример запуска задачи через GUI;
- как отрисовываются сложные графы;
- сравнение “было в консоли / стало в АтомПорт”.
- пример Flow для salt

5 Что такое SaltStack (3–4 минуты)
1. Мастер–миньон архитектура.
2. Почему он хорош, но не всегда удобен:
- не популярно;
- конфигурации распределены по файлам;
- мониторинг и логи не всегда наглядны.
3. Рекомендации кол-ва клиентов.

6 Как это устроено внутри (3–5 минут)
1. АтомПорт не заменяет SaltStack — он работает поверх него.
2. Использует API.
3. Основные технологии:
- backend (Python, Django);
- frontend (Angular);
- шаблонизатор (jinja2);
- база данных (PostgreSQL).
4. Пример приземленной на инфраструктуру схемы Salt.
5. Пример стандартной схемы Salt

7 Рассказываю из чего состоят автоматизации в общем (3-5 минут):
- pillars, grains, graphs, states, modules, reactor, beacon, returner

8 Не наступать на грабли (5 минут):
- внимание к преднастройке;
- использовать логирование;
- дубли клиентов;
- версии агентов;
- апробация автоматизаций;
- backup всего: БД, автоматизаций и т.д;
- документирование;
- правила как расписание задач;
- snapshot центрального сервера;
- разнообразие парка оборудования

Расскажем почему pulumi лучше чем terraform и зачем вообще он нужен если есть terraform

PCI DSS требует использовать современные алгоритмы хэширования, но что делать, когда у вас 10 личных кабинетов на гибридной системе (от Spring до Wildfly), общая БД, и ни одного сервиса аутентификации?
Мы прошли путь от обнаружения уязвимости (SHA-1) до внедрения PBKDF2 с 600к итерациями - в полном соответствии с NIST SP 800-63B и OWASP.
В докладе разберем: как разделить миграцию на два этапа (чтение, запись), как обойти ограничения старых версий Spring, и как сократить время смены пароля с 26 до 2 секунд через комбинацию бизнес-решений (ограничение истории паролей) и технических оптимизаций. Вы получите историю об инкрементальном обновлении критичных компонентов под давлением аудиторов.

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

«Пап, давай оставим!» / Почему приносят одни, а чиним и поддерживаем мы?
«А выгуливать кто будет?» / Что имеет право требовать тот, у кого нет права отказаться?
«Он большим не вырастет!» / Как все подготовить и что ответить на вопрос «Ну когда уже?»
Вредные советы / Как гарантированно все испортить

Мы поддерживаем сервисы, работающие в гибридной инфраструктуре — одновременно в GKE и on-prem. В докладе расскажу, как мы организовали доставку сервисов: от настройки доменов и работы с Cloudflare до публикации приложений через разные способы маршрутизации и балансировки — Ingress, Cilium Gateway API, Google LB и HAProxy. Поделюсь решениями, которые позволили нам избежать разрастания конфигураций и сделать деплой предсказуемым во всех средах.

Наша компания занимается разработкой и эксплуатацией беспилотного транспорта.
Есть система управления флотом, построенная на микросервисной архитектуре в Kubernetes.
Автопилот работает на автомобилях, написан на C++, его сборка крайне ресурсоёмкая и требует сотни CPU во время релизов.

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

Что было до перехода на кластерный GitLab

Использовался однодовый GitLab с большими ресурсами (60 CPU, 150 ГБ памяти), но узким местом оставался диск.
Обновления сопровождались простоем.
Под большой нагрузкой возникали фризы и задержки, особенно в Sidekiq.
Применялась классическая конфигурация статических раннеров: они всегда избыток в обычное время и острая нехватка во время релизов.
Бэкап был реализован через снепшоты ВМ без проверки восстановления и работоспособности.

Применённые решения и результаты

Перешли на кластерный GitLab с обширной ролей развертывания и полной автоматизацией.
Обновления проходят без простоя в 11 из 12 релизов в году (ежегодный мажорный релиз всё ещё требует перерыва).
Работа без фризов и задержек при высокой нагрузке.
Внедрён автоскейлинг раннеров, которые автоматически добавляются и убираются в зависимости от нагрузки.
Ежедневно снимается и разворачивается бэкап на резервном кластере, который также служит площадкой для экспериментов.
Подробно проработаны healthcheck-ы различных компонентов GitLab, миграции базы данных.
Мы включили в доклад опыт авторов драйвера для интеграции автоскейл-раннеров.

Доклад посвящен применению ИИ в инструментах защиты. Речь пойдёт об ИИ-ассистенте для анализа данных и помощи сотруднику ИБ.

Архитектура чат-бота поддержки банка
Автоматизация простых интентов через RAG с reasoning - архитектура, оптимизации, ошибки
Архитектура сложных интентов на примере AI-агента кешбека.
Выбор и оптимизация LLM под кейсы
Советы и планы

Доклад раскроет подход СберТеха к защите AI-систем с использованием продуктов AI Security Gateway, AI Guardrails и AI RedTeaming. Расскажем, как эти инструменты обеспечивают безопасность данных и моделей на всех этапах жизненного цикла AI, включая мониторинг, предотвращение атак и тестирование уязвимостей. Практические кейсы покажут их эффективность в инфраструктуре СберТеха.

Я расскажу, как мы у себя в проде сделали AI-детектор аномалий поверх eBPF-телеметрии Linux. eBPF дал нам очень плотный поток первичных kernel-сигналов с VM/нод (процессы, syscalls, сеть, IO, память), но в сыром виде это был адский шум: событий много, вариативность большая, руками такое триажить долго. Поэтому мы вынесли ключевую ценность в слой ИИ: модель учится нормальному поведению хостов и сама находит отклонения, новые паттерны, всплески редких событий и нетипичные корреляции между разными классами сигналов.

Пайплайн получился такой: eBPF > Elastic > LLM-обработка. Интеллектуальная часть строит эмбеддинги событий, кластеризует их в "смыслы", ловит аномальные кластеры и формирует краткие RCA-инсайты. В результате мы перестали смотреть на тысячи строк в Kibana и начали получать несколько конкретных "что сломалось/где/почему важно". Плюс мы сделали LLM-ассистента, с которым дежурный может прямо по этим данным общаться: задавать вопросы "что было странного за последние 10 минут?", "похоже ли это на прошлый инцидент?", "что проверить дальше?" и получать ответы со ссылками на сырые события.

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

При массовом внедрении GenAI в ИТ-ландшафт, Крупные организации (СБЕР точно) сталкивается с новыми вызовами:
- GenAI-системы недетерминированы по своей природе. Классические метрики (uptime, latency) не отражают их реальное качество и надежность.
- Появляются новые классы инцидентов: «галлюцинации», дрейф качества, промпт-инжекты — требуют новых подходов к мониторингу и реагированию.
Что требует перестроения работы команды SRE/OPS.
В докладе мы поговорим о том, как меняются функции сопровождения, что такое EvalOPS. Рассмотрим конкретные примеры как управлять инфраструктурой, в которой большую часть бизнес-процессов обсаливают ИИ-агенты, какие компетенции нужно растить уже сейчас

Что если у вашей команды появится «junior SRE», который:
- понимает Kubernetes, код и мониторинг лучше большинства новичков,
- сам собирает фактуру по инциденту за минуты,
- знает архитектуру сервисов без устаревшей документации,
- и при этом работает строго в read-only режиме, не имея возможности что-либо сломать?

В докладе я покажу, как построить SRE-Copilot — AI-агента, который объединяет данные из k8s, Git, мониторинга и логирования, использует RAG и MCP, выполняет автоматический триаж, помогает с RCA и подсвечивает проблемы в конфигурациях, секретах, DNS и сервисных зависимостях.

Разберём архитектуру, реальные сценарии автоматизации и то, как AI-агенты позволяют SRE-командам работать быстрее, увереннее и качественнее — без дорогих проприетарных решений и без риска для продакшена.

В докладе поделимся практическим опытом переезда высоконагруженных AI-сценариев с вендорских моделей как услуги (MaaS) на локальные (on-premise) LLM, STT и эмбеддинги. Расскажем про реальные инженерные проблемы такого перехода: от ограничений контекстного окна и ресурсоемкости его обработки до деградации скорости инференса на фреймворках вроде vLLM и сложностей балансировки разноплановой нагрузки. Развенчаем популярные мифы о хостинге моделей и дадим конкретные инсайты, основанные на эксплуатации ансамбля моделей, обрабатывающего миллионы запросов в месяц.