Расписание

Говорим о расписании, сессиях и делимся информацией.

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

История внедрения DORA-метрик: от их декомпозиции и формулирования ценности до результатов внедрения и разбора ошибок.

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

Расскажу, как мы переносили Kafka с VM в Kubernetes.

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

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

В докладе я расскажу, как Middleware Service Hub превращает разрозненные данные в связанный технологический контекст, развивается от каталога компонентов к Digital Twin организации и становится основой для Architecture as Code, API governance и AI Harness.

Как устроены наши отказоустойчивые K8s-кластера в инфраструктуре, как мы автоматизировали их управление через CAPI на масштабах сотен серверов.

Реальный опыт эволюции подхода управления централизованной конфигурацией проектов Gitlab, Hashicorp Vault и других в 2ГИС: от простых bash-скриптов до связки Terraform и Terragrunt.

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

Основная идея выступления — на практике показать возможности улучшения «стандартного» Kubernetes.

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

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

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

Проиллюстрируем, как росла наша платформа трейсинга, менялись инструменты от Tempo до VictoriaTraces, какие шишки мы собирали, какие проблемы решали и как повышали гарантии услуги.

Индустрию штормит от сокращений. Команды урезают, микросервисов меньше не становится, а соблазн отдать ИИ-агенту ключи от инфраструктуры растет. В пять утра очень хочется натравить агента на алерты, чтобы он сам прочитал логи, нашел проблему и сделал спасительный kubectl fix. Но готовы ли мы пустить LLM в закрытый контур, зная про галлюцинации и непредсказуемость?

Нейросети и LLM часто воспринимаются как неприступная «магия», но на деле их периметр защищен слабее классических IT-систем.

На примерах из практики РТЛабс покажу, как находить в CI/CD ошибки, которые не ловит линтинг Helm-чартов: некорректный JSON внутри YAML, опасные изменения Kafka-топиков и недоступность зависимостей из Kubernetes-кластера. Разберем, где достаточно готовых инструментов, а где нужны собственные проверки с учетом контекста релиза и целевой среды.

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

Хотите почувствовать себя в роли DevVibeOps — тогда вам ко мне! :)

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

Fail Talks — это откровенные и полезные истории о провалах в DevOps-практиках.

Сравним возможности ArgoCD и Flux, kubectl, Helm и Nelm/werf в упорядочивании развертывания, отслеживании готовности и управлении жизненным циклом ресурсов.

К вам пришла ML-команда: «LLM'ка отвечает в контейнере, теперь отдайте ее пользователям и поддерживайте».

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

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

Хочу рассказать, как мы и зачем в Dodo Engineering внедряли OpenTelemetry и Observability-as-Service, какие грабли собрали в процессе, какие гипотезы проверяли и почему вам это все надо или не надо.

За прикладным уровнем AI-систем — MLOps, моделями и инференсом — стоит платформа, которую нужно заставить работать: Kubernetes, операционная система, драйверы NVIDIA и весьма капризное серверное железо. На примере реальных расследований из эксплуатации GPU-кластеров на базе Talos Linux покажу, как искать причины сложных проблем на стыке этих слоев — и почему реальная причина часто оказывается совсем не там, где ее ждешь.

Как обновление Cluster API чуть не уничтожило наши кластера — как митигировали, что поменяли и как работаем дальше.

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

Опишу, как мы создавали у себя DevOps Cookbook. Что это такое в нашем понимании, как мы пришли к тому, что он нам необходим.

Как мы перешли от «стены текста» к боту-помощнику. И наши планы на будущее.

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

Почему никому не нужно релизить в 70 раз чаще и нужны ли будут инженеры в 2027-м?
Каждый год нам пишут, что жить стало лучше и веселее. И вот уже: 90% индустрии пишет код с ИИ, ИБ не тормозит пайплайны, IDP есть у каждого первого, а «элитные» команды релизят не переставая. Мы смотрим на эти графики State of Cloud Native, переводим взгляд на наш пылающий легаси-монолит и думаем: на какой планете живут все эти люди?

Современные корпоративные AI-платформы — это уже не просто OpenWebUI + Ollama, это десятки возможных комбинаций различных решений: AI-gateway, RAG-системы, инференс-бэкенды, инфраструктура, агенты и прочая обвязка, закрывающая потребности бизнеса. Всё это добро должно работать согласованно, держать высокую нагрузку и обеспечивать пользователей качественным сервисом с адекватными задержками.

Расскажу, к какой архитектуре пришли мы, построив корпоративный ChatGPT-like сервис на 18К пользователей с DAU 1500+ на этапе разработки.

Расскажу, как импортозамещение NGFW в банке превратилось в пересборку сетевой модели production Kubernetes: namespace-level доступы, миграция в облако и отказ от привычной модели авторизации трафика.

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

Рассмотрим на практике популярные open-source инструменты, которые позволяют улучшить безопасность Kubernetes в Runtime.

Каждое второе входящее резюме врет (17 лет опыта в Kubernetes при том, что ему 12), а нейросеть, которая это ловит, либо разоряет на счетах, либо врет сама, либо принимает решение по найму, которое потом нельзя объяснить юристам.

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

Миграция с Managed Spark в Kubernetes — это не перенос кода, а проектирование отдельного управляемого compute-слоя, который стал частью ML-платформы: поддерживаемые base images, CI/CD, Airflow, Spark Operator, YuniKorn, секреты и observability.

В докладе покажу, как сделать запуск Spark-задач удобным для DE/ML-инженеров и сохранить управляемость в эксплуатации кластера.

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

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