Доклады

Кто-то рассматривает Ceph как «магическую черную коробку» для хранения данных, кто-то его панически боится. На Highload++ 2024 я рассказывал, какие практики и инструменты мы разработали для эксплуатации Ceph’а. А в этом году хочу рассказать про наши приключения спустя год.

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

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

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

Рынок Kubernetes в России сегодня — это зона турбулентности.

Одни строят платформы своими силами, другие полагаются на вендоров, третьи только начинают путь. Как сделать осознанный выбор с позиции CTO, Head of DevOps или инженера? Какие факторы реально влияют на решения в отрасли? И что вас ждет в крупной компании, если вы заходите как специалист?

Ответы больше не строятся на догадках. Мы провели первое фокусное исследование российского Enterprise-сегмента, опросив 252 компании с оборотом от 10 млрд ₽, чтобы рассеять «туман войны» и показать реальную картину Enterprise Kubernetes в России.

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

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

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

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

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

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

В докладе мы рассмотрим способы управления процессами безопасной разработки ПО. И нет! Это не про «пыщь-пыщь в CI/CD, а все сработки SAST пуш-пуш в Jira»...

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

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

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

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

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

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

Важно! Необходима регистрация по ссылке: https://docs.google.com/forms/d/1kdu_Ze-Tkz1bw99qUbYue9OXuwjWVJLjizwmTsxIqHs/edit

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

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

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

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

Мы адаптировали 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 реализуют резервное копирование и восстановление, поделимся своим опытом и причинами, по которым решились написать свое open source-решение для бэкапов 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.
• Как выстроить стабильный релизный процесс в условиях полной изоляции.
• Компромисс между best practice и реальными ограничениями заказчика.
• Результаты: что сработало, какие ошибки повторять не стоит.

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

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

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

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

• Что такое форсайт? Форсайт (от англ. foresight — «предвидение») — это метод группового прогнозирования, где участники анализируют тренды, разрабатывают сценарии будущего и создают стратегии.

Пожалуйста, обратите внимание: видеотрансляция и запись форсайта вестись не будут.

Собираем метрики с сотни Kubernetes-кластеров, сотен железных хостов и тысяч виртуальных хостов в 5 дата-центрах, используя Open Source, а именно OpenTelemetry и Elasticsearch.

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

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

Вы увидите, как: * «GPU и Network Operator» берут на себя всю сложность настройки драйверов, SR-IOV VF и сетевых партиций (pkey); * «Автоматизация на основе квот» предоставляет разработчикам изолированные неймспейсы с гарантированной долей GPU и высокой производительностью сети.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Как вы для себя понимаете Cloud Native Application?
• Какие практики и инструменты разработки Cloud Native Application вы хотите внедрить? Расскажите, почему и что мешает?
• Какие актуальные проблемы внедрения агентской разработки перед вами стоят? Какие решения вы видите?
• Какие практики и инструменты DevSecOps по вашему мнению must have? Эффективность применения каких практик вызывает сомнения и почему?

*Брейншторм пройдет в формате групповой работы с участниками.

Пожалуйста, обратите внимание: видеотрансляция и запись брейншторма вестись не будут.

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

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

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

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

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

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

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

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

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

У разных сервисов есть разного качества документация, но в ее актуальности нет уверенности, поэтому критичность и надежность вам предстоит узнавать на практике. Ваша конечная цель — повысить доступность метода POST /order.

Игра в стиле «Capture the Flag», но не для безопасников, а для специалистов по эксплуатации.

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

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

Важно! Для участия в данном формате с собой необходимо иметь ноутбук.

Техлиды, разработчики и тимлиды часто проваливают внутрикорпоративные переговоры не из‑за техники, а из‑за коммуникации: соглашаются на нереальные сроки, берут лишний scope, говорят на «техническом», не фиксируют договоренности и в итоге выгорают сами и сжигают команду. В мастер‑классе разберем, как специалистам из разработки выстроить убеждающую позицию перед продажами, маркетингом, финансами и топ‑менеджментом так, чтобы защищать и продукт, и людей. ​ Я покажу рабочий набор инструментов переговорщика из разработки: приоритизация по ценности и рискам, формулировка MVP/MVP+, техника «если — то», «магия И вместо яда “нет”», фиксация договоренностей как броня команды. Разберем BATNA и ZOPA на понятных DevConf‑кейсах: срез бюджетов, перенос дедлайнов, рефакторинг, Black Friday, прод‑инциденты, срочная хотелка от ключевого клиента. ​ Больше половины времени займет практика в мини‑группах по реальным сценариям: жесткие сроки, урезание ресурсов, переключение людей на «стратегический» проект, смена приоритетов в середине спринта. Участники отыграют роли стейкхолдера, техлида/разработчика и наблюдателя, получат структурный фидбэк и заберут с собой шпаргалку фраз для сложных разговоров с бизнесом, менеджментом и заказчиками.

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

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

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

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

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

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

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

Расскажу о нетворкинге (не путать со смол-током):

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

Участники мастер-класса унесут с собой

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

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

На этом воркшопе мы разберем основные ошибки внедрения Team Topologies и Team API, составим планы по устранению последствий и отработаем приемы, как не попасть в ловушки при работе с этими паттернами.

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

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

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

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

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

Большинство встреч 1-on-1 на уровне менеджмента — это разговоры про задачи. Но на уровне Executive и C-level задачи — уже не главная проблема. Главные вопросы другие:

• как влиять без давления формальной власти;
• как принимать решения в сложной системе с высокой неопределенностью;
• как развивать мышление сильных лидеров;
• как работать с командой как системой.

На этом практикуме мы разбираем задачи, вопросы и форматы 1-on-1 для Executive и C-level. Участники знакомятся с картой развития компетенции менторинг-коучинг:

• 6 уровней коучингового мастерства;
• 6 уровней менторского мастерства.

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

• управленческий инсайт;
• системное понимание;
• новое стратегическое решение.

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

Формат: практикум (2 часа) / 3–4 видеоразбора и групповое обсуждение.

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

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

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

После того как 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).
• Метрики успеха для инженеров мониторинга: скорость и качество.
• Покажем интеграцию, которая сильно облегчает постмортем инцидентов.

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

• Почему просто «чинить инциденты» мало — и как метрики негативного влияния могут поменять подход бизнеса и ИТ к проблемам, root cause и оптимизации процессов.
• Эволюция метрик: какой была первая версия; как они трансформировались под реальные запросы бизнеса; ошибки, которые встречались на каждом этапе, и что было важно не упустить.
• Как «понятные всем» метрики становятся простыми и сильными коммуникационными инструментами: теперь бизнес понимает, почему не все инциденты одинаково важны, а ИТ может аргументировать свои решения.
• Кейсы внедрения метрик влияния на деньги, бизнес-процессы, клиентов — анализ плюсов и минусов каждого подхода.
• Почему внедрение и поддержка культуры работы с инцидентами — главный катализатор качественных изменений, и как команда меняется, когда есть доверие к метрикам.
• На чем строить дальнейшее развитие системы приоритизации и мониторинга: планы, лайфхаки для тех, кто хочет попробовать аналогичный путь.

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

Четыре года мы помогаем нашему заказчику строить и развивать инфраструктуру российской ВКС. Мы размещаемся в трех ЦОДах и второй год подряд подтверждаем уровень доступности 99.99%.

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

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

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

• О сервисах/инструментах и почему приносят именно нам.
• Учимся отказывать правильно: здравый смысл, техрадар, фильтры.
• Отказаться нельзя считать: доступность, девятки и сроки внедрения.
• Внедрили, и что теперь? Поддержка, автоматизация, кладбище домашних животных.

Кажется, зачем покупать что-то, если можно собрать свое и бесплатно из open source-проектов?

Поговорим о том, где здесь можно обжечься, с примерами на Kubernetes. Динамическая сложность, комбинаторика тестирования, стратегия выбора open source-компонентов.

Мы расскажем о том, как строится полный цикл разработки на платформе SourcCraft и осветим важные обновления для инженеров и разработчиков.

TRON ASOC помогает обнаруживать, анализировать и устранять уязвимости на всех этапах разработки и эксплуатации, интегрируясь с вашими инструментами DevOps/DevSecOps и предоставляя единую точку входа в процесс Безопасной Разработки ПО.

На встрече обсудим основные преимущества решения, жизненный цикл уязвимостей и проблем безопасности ПО, а также место решений класса ASOC в экосистеме Безопасности вашей фирмы.

Дадим краткий обзор observability-платформы Monium и рассмотрим ее основные функциональные возможности.

Я расскажу о том, почему централизация процессов работы с ИБ-дефектами, выявляемыми различными сканерами при разработке безопасного ПО важна и почему, на мой взгляд, без нее не обойтись. И, конечно же, про то, почему Excel — это отлично, но не всегда.

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

Runtime Radar — Open Source-продукт от команды энтузиастов из компании Positive Technologies. Создан на основе технологий eBPF и Tetragon под лицензией Apache 2.0. ​​

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

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

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

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

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

На рынке хранилищ артефактов сложилась парадоксальная ситуация: решений много, но каждое несет в себе компромиссы, заложенные много лет назад. Классические хранилища артефактов — тяжелые монолиты с дорогими лицензиями за базовые enterprise-возможности. Контейнерные реджестри закрывают один формат, но не остальной стек. Платформенные решения привязывают хранилище к экосистеме, не оставляя свободы для гибких процессов. А вопрос «можешь ли ты доказать, что артефакт безопасен?» все они решают через отдельные сервисы и отдельные лицензии.

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

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

Yandex Cloud Stackland — анонс новой on-premises-платформы контейнеризации.