Доклады

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

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

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

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

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

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

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

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

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

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

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

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

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

Как выстроить DevSecOps, если процессов безопасной разработки фактически нет?
В докладе — практический Roadmap внедрения: от требований ГОСТ Р 56939-2016 (РБПО) и международных подходов (OWASP, NIST, ISO) к построению зрелого SSDLC.
Разберём, какие практики внедрять в первую очередь, как выстроить безопасность CI/CD без конфликта с Разработкой и как избежать «зоопарка» инструментов.
Отдельно рассмотрим роль ASOC'а в качестве единой точки входа в безопасность приложений и инструмента прозрачности для CISO и DevSecOps/AppSec-лидов.

В современном проде 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, которые помогут сделать даже нечеловеческие учетные записи безопасными по умолчанию и наконец-то закрыть самый большой незакрытый вектор атак в современной инфраструктуре.

Доклад об актуальным проблемах обеспечения безопасности API в условиях 2026 года, когда рост количества интеграций и влияние искусственного интеллекта создают новые вызовы для защиты API. Поговорим о ключевые проблемах влияющие на безопасность (неполная инвентаризация API, сложность внедрения мер безопасности в CI/CD-процессы без замедления доставки продукта) и поделимся подходами, которые позволят автоматизировать безопаность ваших приложения.

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

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

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

Полтора года назад наше legacy жило на виртуалках, деплоилось «башсиблом» и «голыми» манифестами. В этом докладе я расскажу, как мы совершили прыжок к современной DevOps-архитектуре и внедрили GitOps на базе ArgoCD.

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

Time to Market — это не просто показатель скорости доставки изменений, а инструмент, который помогает увидеть, где именно инженерная система теряет время и какие практики с этим связаны.

В докладе разберём:
- как смотреть на TTM как на систему, а не как на одно число: через Backlog, Delay, Process, Cycle и Lead;
- почему важно разделять узкие места ожидания и узкие места исполнения, и как это помогает точнее выбирать направления улучшений;
- как по данным связать зрелость инженерных практик с отдельными компонентами TTM;
- какие практики чаще связаны с ожиданиями и согласованиями в потоке, а какие — с прохождением изменений через разработку, интеграцию и релиз;
- как читать корреляционные карты и профили практик без ложных выводов о причинности, но с практической пользой для принятия решений;
- как использовать TTM и зрелость практик для поиска bottleneck’ов и выбора следующих инженерных инициатив.

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

Вам передали инфраструктуру. Документации нет, предыдущая команда недоступна, всё как-то работает – и трогать страшно. Знакомо?
Мы разберём на реальных кейсах, как системно подходить к "дому с привидениями": от первичного аудита тысячи серверов до обнаружения кубернетеса там, где его никто не ждал. Расскажем, как восстанавливать доступы не ломая прод, как мониторить то, о чём никто не знает, и как мигрировать инфру, которая разваливается прямо в руках.
Но инфра – это только половина истории. Отдельно разберём что делать с неизвестными сервисами глазами DevOps-инженера: как понять что вообще запущено, как это деплоится, от чего зависит и как это чинить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разрабатывая предиктивный автоскейлер для Kubernetes, мы столкнулись с проблемой: стоимость сбора метрик превысила их ценность, а тестировать политики на реальном стенде оказалось невозможно из-за постоянных изменений в проекте. Решением стало создание цифрового двойника прикладного проекта. Мы расскажем, как на основе телеметрии (K8s, Istio), моделей подов (аппроксимация полиномами) и архитектуры как код построить симулятор, который позволяет увидеть узкие места и поведение системы без прогона реального трафика. Оценим точность модели и перспективы подхода.

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

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

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

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

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

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

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

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

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

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

Но это ещё не всё! Я поделюсь с вами нашим опытом успешной локализации и тем как наши команды проходят путь импортозамещения и перехода на работу в среде отечественных операционных систем.

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

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

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

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

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

В этом докладе я поделюсь результатами нашего исследования про влияние AI на разработку софта, которое мы проводили в конце прошлого года в качестве микса опроса и мета-исследования https://ai4sdlc-research.space/. Также я расскажу а как мы внутри Т-Банка развиваем это направление и каких результатов нам удалось достигнуть. А напоследок расскажу о том, как мне видится развитие событий на горизонте 1 года и что станет с нашей профессией как инженеров по разработке софта?

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

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

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

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

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

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.

DevSecOps почти всегда начинается с конфликта между скоростью разработки и требованиями безопасности.
Через год после старта DevSecOps у большинства компаний появляется 5–10 security-инструментов и полная потеря управляемости.
DevSecOps без метрик превращается в "мы что-то сканируем".

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

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

Приглашаем на интерактивный воркшоп-приключение, в котором мы поговорим о надежности в крупных микросервисных системах.
Мы собрали v-team опытных инженеров (то есть, вас) чтобы улучшить надёжность создания заказов в одном известном приложении заказа еды (маркетплейсе, банке, выберите свой вариант).
Главное для клиента сервиса — получить нужную ему услугу. Поэтому вы зашли почитать трейсы и построили по ним карту зависимостей между сервисами при ключевом сценарии работы.
У разных сервисов есть разного качества документация, но в её актуальности нет уверенности, поэтому критичность и надёжность вам предстоит узнавать на практике. Ваша конечная цель — повысить доступность метода POST /order.

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

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

Формат — интерактивный мастер-класс, а не лекция. Участников ждёт активная работа: упражнения, разбор инженерных кейсов, обсуждение типичных ситуаций между разработкой, эксплуатацией, продуктом и бизнесом.

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

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

Игра в стиле "Capture the Flag" но не для безопасников, а для специалистов по эксплуатации.
Три уровня, на которых нужно найти определенный "флаг". Один демонстрационный уровень, где я показываю саму механику игры и потом уровни для игроков с подсказками

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

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

Важно! Для участия требуется ноутбук с предустановленными K8s (kubectl/lens) и WireGuard-клиентами.

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

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

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

Формат игры:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это будет настоящее погружение в мир инцидент‑менеджмента для тех, кто отвечает за стабильность IT‑систем.

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

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

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

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

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

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

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

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

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

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

В докладе будет рассмотрено текущее состояние регулирования разработки безопасного ПО (РБПО), ключевые требования ГОСТ Р 56939-2024 и связанных стандартов, а также практические шаги по их внедрению в процессы разработки. Мы разберём, какие процессы и артефакты ожидаются от команд разработки, как в нормативную модель вписываются SAST, DAST и SCA, и что именно нужно сделать разработчику или DevOps-команде, чтобы соответствовать требованиям на практике.

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