Доклады

DevOps-инженеры сталкиваются с рядом рутинных проблем, включая необходимость обработки и анализа больших объёмов логов. Уже не секрет, что применение LLM (Large Language Models) может существенно упростить работу DevOps-инженеров, автоматизировав анализ логов, выявляя паттерны, аномалии в данных и возможные проблемы. Чтобы обеспечить безопасность и конфиденциальность информации, рекомендуется размещать LLM локально на собственных серверах или в облачной инфраструктуре. Такой подход минимизирует риски утечки данных. В докладе рассмотрим, какие модели можно использовать для анализа логов и что для этого потребуется.

Современные тренды направлены на внедрение искусственного интеллекта для выполнения рутинных задач. К чему может привести страсть автоматизировать всё вокруг? Порассуждаем об этом на докладе

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

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

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

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

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

Методология КАИВ (Каскадная AI валидация дефектов приложений) позволяет почти в 10 раз сократить трудозатраты на ручной триаж за счет AI валидации, обеспечивающей точность 80-90%, и почти в 15 раз снизить трудозатраты на исправление подтвержденных дефектов за счет их приоритезации, автоматического предложения места наиболее эффективного исправления и контекстных рекомендаций по устранению подтвержденных уязвимостей. Обладает нулевым False Negative.

1. Как искать и найти кейсы для применения AI в DevOps. Построим цепочку действий, которая приведет нас к списку кейсов
2. GigaChat, Lama, ChatGPT... или что-то своё. Выбираем модель для реализации кейсов
3. Запускаем обучение! Так, стоп, а что с данными? Все ли мы можем отдать на обучение и какие чувствительные данные нам могут встретиться на пути.
4. Собираем команду. Кто нужен и как спланировать реализацию встраивания ИИ в реальные инструменты.
5. Как запустить кейс на практике? Какие могут встретиться административные барьеры в Enterprise и как их преодолеть.
6. Немного о том, что мы получили на практике и какие выводы мы сделали для себя.

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

От идеи до сломанного прода

Что такое семплирование и зачем оно нужно?
Метрики и трейсы на основе семплированных данных. Бесполезная игрушка или рабочий инструмент?
Head vs Tail. Отличия и сценарии использования.
Реализация и алгоритмы head-based семплирования.
Реализация и алгоритмы tail-based семплирования. Подводные камни и способы их обхода.
Применение семплированных трейсов в разборе реальных инцидентов.

1) Самый часто используемый вами тип метрики будет DistributionSummary
2) Дефолтные конфигурации регистрируют десятки готовых метрик за вас
3) Micrometer, как заявляют его разработчики, является фасадом для JVM фреймворков, но он таким не совсем является, в прочем он и не только фасад

Как делиться результатами Postmortem с командами
Эффективная ролевая модель во время инцидента
Метрики успеха: как измерить достижения

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

В докладе расскажу как эффективно делиться результатами Postmortem с командами, чтобы что сократить их бэклог, эффективнее управлять проблемами (правильно приоритизировать, заносить в команды, давать инструменты в виде дашбордов для отслеживания, добавлять новые активности в виде комитетов и review) и тратить меньше времени на управление. А также как выстроить эффективную ролевую модель во время инцидента (назначение, функции, резолвинг).

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

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

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

Давайте посмотрим на относительно новый компонент Cilium - Cluster Mesh.
Рассмотрим его архитектуру, построим и сломаем межкластерную связь, а также погоняем бенчмарки и попробуем ответить на вопрос: "Готов ли Cluster Mesh для прода?".

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

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

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

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

Сеть доставки контента RUTUBE — это 250+ железных сёрверов, расположенных по всей стране и даже ближнему зарубежью, сети операторов, много nginx и самописное ПО, которое всем этим управляет.
Данная сеть раздаёт 5 тбит/с данных не только для национального видеохостинга RUTUBE с 65 млн пользователей в месяц, но и для некоторых других цифровых активов Газпром-Медиа Холдинга.
Поговорим о том, как устроен CDN RUTUBE с инженерной точки зрения: аппаратной, сетевой и программной.

Многие слышали о 1С.
Но что вы знаете о программных продуктах 1С?
Уверен первое что всплывает в головах, что 1С - это бухгалтерия, зарплата - сервак на базе i5, 10-15 пользователей...
Но это далеко не так.
В нашей конфигурации 1с работают тысячи пользователей, наша база занимает почти 40Гб пространства, это одна из самых крупных баз 1с в России, а может и в мире(кто знает=))
И в своей работе мы используем не только штатные средства 1С, но и многое многое другое...
Если интересно, приходите я расскажу много интересного!

Netbox - точка истинности или стейт

Что выбрать в качестве источника правды об инфраструктуре? А если инфраструктур несколько? А еще у нас несколько разных гит и разные подходы по формированию гит репозиторием где необходимо использовать знания об инфраструктуре - тут оставлю вопрос открытым. У нас netbox и все :) анализ и выбор это отдельная тема. Оставлю на ваше самостоятельное исследование.

Netbox как инструмент по хранению знаний про железную часть инфраструктуры и про виртуальную часть. ИП адреса, кабели, серверы, стойки и прочее. Сразу есть API по работе со всем этим.


Дает ли внедрение ощущение спокойствия и точки истинности?
Система по хранению информации - Netbox
Синхронизация информации из реальной инфраструктуры в Netbox и уведомление о не соответствии.
Процесс работы с инфраструктурой - нет в Netbox нет в инфраструктуре. Создаем объект в Netbox и на основе данных из netbox создаем реальный объект инфраструктуры

Netbox дает информацию начиная с групп серверов. Выше уже другая система, Backstage - информация о продуктах, информационных системах и на каких они группах серверов работают

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

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

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

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

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

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

Проблемы, которые решает трейсинг
Почему OpenTelemetry
Архитектура решения
Проблемы реализации и их решения
Опыт использования
Дальнейшее развитие

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

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

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

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

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

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

Расскажу как мониторим раздачу статики с помощью Openresty

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

По каким критериям выбирали метрики доступности

1. Цели и задачи внедрения сервиса
2. Что такое Mimir
3. Параллельные решения
4. Почему мы выбрали Mimir
5. Особенности развертывания и тестирование
6. Опыт использования Mimir
7. Дальнейшее развитие

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

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

Представьте, в вашей компании есть сложившиеся система мониторинга Zabbix в нескольких контурах на 3,5+ тысячи хостов, которая отлично зарекомендовала себя и работает более 15 лет. За это время агенты научились не только мониторить железо, но и имеют несколько тысяч различных специфических скриптов к разношерстным БД и приложениям. В один прекрасный день приходит задача: необходимо отдавать часть метрик в головную компанию в систему Prometheus. Значит, несмотря на тысячи метрик в Zabbix настало время переезжать на новую систему мониторинга. Или нет?
В докладе расскажу о том, каким образом была решена задача передачи метрик между двумя системами мониторинга так, чтобы и Руководство, и команда мониторинга остались довольны.
Доклад будет полезен практикующим DevOps/SRE-инженерам, инженерам команд мониторинга и всем, кто сталкивался или может столкнуться в своей работе с задачей передачи данных между разными системами мониторинга.

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

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

Этот доклад будет интересен всем, кто работает с Kubernetes в облаке или только планирует его внедрение. Расскажу, как мы создавали Kubernetes-as-a-service в Облаке К2: с какими трудностями столкнулись, как справлялись и что в итоге получили.

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

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

Мы выбирали между OpenSearch и PostgreSQL, и в итоге решили - почему бы не использовать оба?
Ответы мы храним в PostgreSQL и автоматически копируем в OpenSearch, который (о боже) представляет собой один pod в k8s.
Надёжно как швейцарские часы!

Бонусом расскажем про то, зачем всё это нам, как эта связка помогает измерять инженерную культуру.

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

Из доклада вы узнаете о проблемах и наших решениях автоматизации производственного конвейера на
примерах.
• Автоматизация ручных действий на всех этапах от сборки до ПРОМа.
• Автоматизация проверок Quality Gates (включая ИБ) в джобе CI.
• Реализация pipeline для разного стека на собственном движке Fulcrum с
использованием пакетного менеджера Helm и шаблонизации Synapse Service Mesh
/Prometheus.
• Особенности Jenkins CD в Enterprise, шардированное решение для него “Dream
Jenkins”(SberWorks).
• Переход из Jenkins в ArgoCD
• Реализация BlueGreen и Canary стратегии деплоя и его применимость в
зависимости от стека.
• Автоматизация ручных шагов производственного процесса с помощью сервисных
Pipeline для автоматического создания и изменения объектов релизной деятельности Jira.
• Оборачивание конвейера в «человеческий вид» с помощью оркестратора
оркестраторов DPM (SberWorks).

Инфраструктура как код, для локальной разработки. Сегодня это уже норма. Devcontainer помогут решить нам целый класс проблем, а именно:

– Уравнивание окружения между всеми разработчиками через докер (общий знаменатель) – больше никаких cmd-скриптов рядом с sh. А также можно работать с любых девайсов и любых операционных систем, и даже аппаратных платформ.
– Онбординг одной кнопкой – вместо недель настройки окружения для разработки каждым новым разработчиком, всё можно настроить одним человеком и лишь один раз, а работать будет у всех и всегда. Все, что вам нужно – это ide с поддержкой девконтейнеров и докер.
– Поддержание актуальности инфраструктуры рабочей среды одним человеком. Один разработчик теперь описывает актуальное состояние всей инфраструктуры, и у всех, кто перейдет на его коммит, будет ровно такая же инфраструктура. До последнего байта. И никаких поисков багов между двумя разработчиками, из за разных версий ЯП.

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

1. Вам нравится гибкость облачных ресурсов, но ваше приложение никогда не создавалось под идеологию контейнеров и k8s, и вы решили туда ехать.
2. Идея часто умирающих контейнеров и отсутствие локального состояния поначалу может сбить с ног.
3. Если изначально приложение не писалось под кубы, и уже очень большое, то вас впереди ждёт много проблем.
4. Но после переезда, будет прекрасно: эластичность ресурсов, динамические окружения, canary releases.

способ формирования helm chart параметров в зависимости от окружения
работа с группами окружения
пакетный подход к установке helm chart в k8s

Отсутствие процессов в разработке новых сервисов ВКонтакте приводило к долгому и сложному созданию проектов через copy-paste. Не было подходящего окружения, нужно было ставить ~5-10 тасок в Jira, а деплой в облако занимал почти месяц. И не всегда после деплоя можно было понять все ли хорошо, т.к. сервисы были черными ящиками. Поэтому мы организовали собственную платформу ВКонтакте и набор инструментов, которые позволяют инженерам забыть про boilerplate code и не думать, куда ставить нужные таски.

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

Современный DevOps – это уже не просто написание скриптов автоматизации, а создание надёжных инженерных решений. На что опираться при выборе языка программирования для своих задач? В этом докладе мы посмотрим на DevOps через призму разработки: сравним Python, Go и Bash в реальных сценариях, разберем метрики производительности и сопровождаемости кода. Вы увидите, как меняется подход к решению типичных задач при использовании разных языков, и научитесь выбирать инструмент, который даст максимальную эффективность именно в вашем случае. Никакой воды – только конкретные примеры, бенчмарки и рекомендации, основанные на реальном опыте.

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

Но какой инструмент позволит работать с YAML как с кодом и позволит выйти за рамки обычной шаблонизации?

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

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

Картина:
- Ручная доставка изменений
- Команда 40+ разработчиков
- 4 связанных системы в доработке.
- Большой объем интеграций
- Два релиза в параллельной разработке без гита (с альтернативной системой хранения версий)
- Ручное тестирование
- Тестирование на пользователях

Что из этого вышло:
- Пилот на не готовой системе
- Срывы сроков
- Низкое качество разработки

Что надо было изменить:
- Ретро
- GIT
- Sonar
- Smoke

В современном мире разработки ПО системы CI/CD играют ключевую роль в обеспечении качества, надежности и скорости релизов. На основе реального примера пайплайна для Python приложений я расскажу:

Архитектура пайплайна:
- Структура и ключевые этапы: подготовка, тестирование, миграции, сборка и деплой.
- Управление версиями и хранилищами образов, подходы к публикации сборок.

Оптимизация использования кэша:
- Эффективное использование poetry.lock для кэширования окружения помогает сократить время на установку зависимостей.
- Генерация уникального ключа для кэша и ускорения сборок

Миграции базы данных:
- Как организовать автоматизированный процесс создания и отката миграций.

Тестирование и покрытие кода:
- Использование pytest и Allure для контроля качества на каждом этапе.
- Автоматическое управление отчетами Allure через настройки пайплайна

Особенности релиза и деплоя:
- Как разделять окружения (test, preview, production) и эффективно использовать Kubernetes.

Динамическое управление ревьюерами:
- Автоматическая привязка ревьюеров на основе группы и списка для ускорения code review

Комплексное управление артефактами:
- Чистка артефактов на основе регулярных выражений и ограничения количества
- Разделение артефактов для миграций и основной сборки

Результаты: Участники узнают, как построить CI/CD-процесс с учетом особенностей Python приложений, включая безопасность, миграции и многоэтапное тестирование.

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

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

цель данного воркшопа на базовых примерах показать настройку OIDC коннектора для инфраструктурных сервисов через кейклок
разберем основные сущности в кейклок - realms, clients, client scopes, users, roles, groups
разберем аутентификацию в графане через кейклок

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

- Введение в автоматизацию инфраструктуры: обзор основных инструментов и подходов.
- Использование GitLab CI/CD для создания виртуальной среды в облаке OpenStack.
- Роль Terraform как инструмента для управления инфраструктурой как кодом (IaC).
- Создание пользовательских образов и настройка виртуальных машин и сетей с помощью Terraform.
- Генерация инвентаря Ansible для управления развертыванием OpenStack с помощью kolla-ansible.
- Эффективное развертывание OpenStack для разработчиков с использованием GitLab CI/CD и Terraform.
- Примеры использования: разработка кода для основных проектов OpenStack и создание пользовательских установок.
- Практические рекомендации и лучшие практики по автоматизации развертывания OpenStack.
- Перспективы расширения автоматизированных процессов для развертывания реального облака в будущем.

1) Мы решили снизить санкционные риски и не продлять лицензию на Premium Gitlab
2) выбор замены
3) Почему Gitlab CE
4) Бесплатные аналоги платных фичей
5) Переезд между гитлабами привёл к аудиту всего процесса разработки в компании
6) А заодно и стандартизации и актуализации пайплайнов
7) Процесс миграции как self service

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

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

Всем привет!
Я из команды Атома и мы делаем очень крутой отечественный электро мобиль.
Мы как и многие из вас используем девопс практики, у нас есть CICD и мы работаем с TS/JS
Вещи о которых я хочу поговорить существуют на проектах любого обьема и сложности.
Мой доклад ответит на следующие вопросы:
1. Из чего состоит пайплайн проекта на JS/TS?
2. Как мониторить CI/CD?
2. На что уходит время CI/CD?
3. Что можно с этим сделать?
4. Какие есть инструменты до ускорения CI/CD
5. Как их можно применить?
6. Какой прирост получаем? В 2, 10, 100, 120 раз? Смотря как считать.
7. Можно ли применить этот опыт для другого стека?

8. Выводы

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

- Что такое Continuous Delivery и почему это круто?
- По кирпичикам: из чего состоит Continuous Delivery пайплайн?
- Зачем нужен статический анализ?
- Чем статический анализ поможет в обеспечении непрерывной доставки?
- Как интегрировать статический анализ? Решение проблем как для DevOps, так и для разработки
- Реальные примеры интеграции статического анализа в пайплайн

Расскажу как выбираются темы и практики для исследования. Почему мы их считаем важными.

Описание личного опыта реализации процесса по созданию и поддержки инфраструктуры k8s различных уголках мира.
В своем докладе подробно раскрою темы
- Выбора единой OS для Kubernetes для разных типов установки
- Анализ и типы развертывания которые пришлось реализовать в примерах
- Смена парадигмы с GitOps на OCIOps
- Вся правда о fluxcd
- организация проекта
- поэтапной процесс тестирования и деплоя в разрезе региона/зоны/типа кластера (с примерами и визуализацией)
- организация процесса за ошибками
- Как реализовать поддержку кластера и баз данных если к нему нет прямого доступа через агенты
- Как обеспечить декларативное обновление ваших кластеров k8s

- В 2022 году с рынка хранилищ артефактов РФ ушли два ключевых игрока
- Мы, как и все, постарались исследовать возможность создать такое хранилище на OpenSource Nexus
- Поймали кучу граблей связанных с производительностю Nexusa и поняли, что их никак не обойти. Он вообще очень плохо подходит для больших команд, которые генерируют большую нагрузку
- Разобрались с лицензированием Nexus и поняли, что в РФ им не получится воспользоваться
- Поняли, что современное хранилище должно еще и безопасно хранить артефакты
- Приняли решение сделать свое хранилище с нуля на зарекомендовавших себя технологиях
- Релизовали хранилище артефактов, которое спобно работать в высоконагруженных системах
-Сделали это хранилище безопасным

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

- Сравнение Pull и Push-моделей
- Особенности установки ArgoCD
- Преимущества ArgoCD
- Организация GitOps-репозиториев
- Flow CI/CD
- Организация контроля доступа
- Организация доставки cекретов

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

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

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

Расскажем реальную историю запуска и развития международного высоконагруженного проекта на базе управляемого Kubernetes, Apache Superset и Trino.

Остановимся подробно на следующих практических кейсах и сценариях их преодоления:

- почему "официальные лимиты" в k8s не работают, на какие разные лимиты наступили мы и как с этим жить в коммерческом проекте с 25к подов и гигабайтами конфигурацинных файлов в etcd

- как мы решаем проблему обновления большого числа виртуальных хостов в nginx, почему ingress-nginx становится "так плохо" при 5к подов, и как и почему мы переехали на contour/envoy с деталями его конфигурации под нагрузку

- как могут падать мастер-ноды k8s и etcd: увлекательная патологоанатомия выживания на продакшн, когда падает каждый день что-то новое и клиенты не должны это заметить

- зачем мы мигрировали секреты helm из k8s в Postgres-бэкэнды при уже 15к подов клиентов, как сделать это самостоятельно за 2 дня, делимся опытом

- как "официальный" мониторинг k8s prometheus monitoring стал узким местом, как его оптимизировать и заставить приносить пользу

- так как же на самом деле "правильно" настраивать "limit" и "request" лимиты на многочисленные ресурсы в k8s: русская рулетка на продакшн или научный подход?

- как бы научились эффективно распределять нагрузку на ноды кластера k8s скриптом на python и не "палить деньги на ветер" и почему отказались от "официального" решения

- как мы экономим ресурсы k8s, гася неактивные поды клиентов: скрипты, алгоритмы, интуиция и шаманизм

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

Как правильно развивать DevOps инженеров в условиях постоянных изменений на рынке? Как повысить лояльность сотрудников? Как отмечать рост сотрудников и правильно их поощрять? Ставим цели на аттестациях для сотрудников правильно.

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

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

Воркшоп: Разработка инженерных практик для крупных компаний

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

Что вас ждет:

- Обсуждение лучших практик: Узнаем, как глобальные компании адаптируют и внедряют современные подходы к разработке и эксплуатации (CI/CD, DevOps, SSDLC, API-first, cloud-native).

- Инструменты и процессы: Разберём ключевые инструменты автоматизации, мониторинга и их интеграцию в ежедневные рабочие процессы.

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

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

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

Для кого этот воркшоп:

- Руководители технических команд
- DevOps инженеры
- Технические лидеры и архитекторы
- Инженеры по качеству и безопасности

Результат:

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

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

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

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

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

Проблемы использования реальных данных в тестовых средах: Конфиденциальность, производительность, согласованность – все это под вопросом при использовании реальных данных.

Что делать?

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

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

Перевод Continuous Deployment процесса развертывания Openstack облака с раскатки docker контейнеров инструментами ansible на kubernetes+ArgoCD+Helm.
Изначально мы имели 2 кластера openstack - клиентский и инфраструктурный. В последнем поднимались виртуалки, в которых запускаслись инфраструктурные сервисы (мониторинг, логирование и пр.) В клиентском облаке сервисы openstack раскатывались с помощью большого ansible плейбука. Возникали сложности, как с версионированием, так и с обновлением openstack компонент (некоторые компоненты можно обновлять только с миграцией клиентской нагрузки). Были сложности с поддержкой 2х кластеров openstack (один ванильный, другой - разработанный компанией cloud.ru). Некоторые инфраструктурные сервисы располагались в kubernetes, развернутом на публичном облаке внутри виртуальных машин, что создавало сложности с маршрутизацией, прохождением межсетевых экранов и некоторые другие. В качестве решения была реализована архитектура, в которой 2 кластера схлопнулись в 1, часть нагрузки перестала быть виртуализованной и перешла на уровень контейнеризации на baremetal kubernetes. Сервера подключаются к сети напрямую через cilium bgp агента, persistent storage реализуется средствами longhorn, превращая control ноды в гиперконвергентные. Обновления выполняются как стандартными средствами kubernetes, так и операторами.
Данный доклад описывает подробно существовавшие сложности, пути их решения, архитектуру нового облака.

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

Традиционное представление о НТ как о финальной проверке перед релизом малоэффективно. Интеграция тестов в процессы разработки и пайплайны (CI/CD) позволяет выявлять проблемы на ранних этапах и минимизировать риски.

Ранний анализ нефункциональных требований, погружение в архитектуру и бизнес-логику (например, расчёт пропускной способности) делают тестирование полезным для всей команды.
Включение тестов на масштабируемость и разработка инструкций для критических ситуаций повышают стабильность работы системы при пиковых нагрузках.
Использование smoke perf tests и коротких автотестов позволило интегрировать НТ в разработку даже на небольших проектах, ещё не вышедших в продакшен.
Комплексное нагрузочное тестирование помогает выявить «узкие места», такие как неразделённые ресурсы, влияние «шумных соседей» и недоработки в проектировании саг.

Смена майндсета:
Работать вместе с командой, а не по-отдельности.

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

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

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

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

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

Интерфейсы нового уровня: как создать визуально привлекательные и удобные интерфейсы в Jenkins, которые заменят старые, сложные системы.
Минимум действий от пользователя: никакой путаницы или инструкций — пользователю нужно лишь нажимать кнопки, всё остальное происходит автоматически.
Красота и автоматизация в одном флаконе: интеграция с Git, автоматическое подтягивание данных и полное отсутствие ручного ввода, что упрощает и ускоряет работу.
Безопасность прежде всего: расскажу, как сделать платформы не только удобными, но и защищёнными, чтобы минимизировать риски.
Удобная разработка без шишек: я покажу, как организовать процесс разработки этих платформ так, чтобы избежать проблем, на которых я уже сам учился.
Обучение и поддержка: научу вас, как воплотить всё это в жизнь — от создания красивого интерфейса до безопасного и удобного рабочего процесса.

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

Методическая секция
- Обзор подхода GitOps, основные отличия от привычной Push-модели деплоя
- Преимущества и недостатки GitOps. Почему подойдет не всем?
- GitOps, TBD и Feature Toggles. Деплой и релиз больше не единое целое.
- Что лучше, автотесты или флаги?

Инструментальная секция
- Обзор инструментации GitOps: FluxCD, ArgoCD
- Флаги: варианты реализации, подводные камни
- Kustomize: обзорная экскурсия в кроличью нору
- Деплой без Helm: (вредные и не очень) советы
- Flux Image Automation: контроль за автодеплоем

1. Разбиваем стереотипы
1.1 Linux vs BSD - что использовать, и почему и то и другое вместе и одновременно
1.2 Доставка пакетов - как не утонуть в вопросе
1.3 Нужно ли соблюдать внешние стандарты, в том числе стандарт Linux?

2. Существующие практики, и почему они не подходят
2.1 Linux from scratch
2.2 Gitian
2.3 FreeBSD ports collection
2.4 Как найти то, что заработает именно в Вашем случае - критерии отбора

3. Как это работает на практике
3.1 CI/CD и что обычно нехватало в нём для реализации из коробки
3.2 Довешиваем GitLab до рабочего и полностью автоматизированного решения
3.3 Debian_GNU/kFreeBSD - почему провалился и как не повторить его ошибок
3.4 Собственные компоненты - как не изобрести велосипед, но что действительно должно быть "самописным"

4. Анатомия минимального решения - заглядываем под капот

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

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

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

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

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

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

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

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

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

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

На дворе 2025 год, Kubernetes есть практически у каждого, у некоторых у он есть даже в шкафу дома вместе с пет проектом.
Кажется мы стали забывать, что несмотря на то что Kubernetes умный, то как он распределяет нагрузку внутри кластера может совершенно не совпадать с нашими ожиданиями.
В рамках своего доклада я хочу рассказать:
-- о том как базово работает kubernetes scheduler
-- как работают и зачем нужны taints и tollerations
-- как работают affinity и antiaffinity rules
-- зачем нам pdb, pod topology constraints
-- и как все это можно комбинировать между собой
Большинство "приключений" с комбиначиями различным ограничений являются результатами постмортемов после инцидентов, которые позволили Магнит Омни стать более надежными.

CI как сервис, Gitlab как сервис для разных команд(от сети до бизнеса) Построение отказоустойчивого решения на основе бесплатной версии(успешно не полностью) и почему GitFlic для этого может не подойти # Обучение девопс инженеров, реальный опыт и почему иногда люди не хотят учиться

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

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

Тезисы:

1) В современном быстроизменяющемся мире понятие DevOps-инженера или специалиста всё чаще подвергается сомнению и критике - я постараюсь доказать, почему его актуальность не теряется: нужно лишь посмотреть на него под другим углом;

2) Расскажу, какими качествами и навыками должен обладать специалист DevOps, чтобы оставаться полезным и актуальным для современных компаний;

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

Доклад посвящен организации канареечного деплоя при GitOps. Обсудим организацию GitOps-репозиториев, применение GitFlow, различные стратегии деплоя, интеграцию Argo Rollouts с ArgoCD и безопасное выполнение миграций.
Доклад будет полезен инженерам, работающим с Kubernetes


- Организация GitOps-репозиториев ArgoCD
- Flow CI/CD
- Стратегии деплоя
- Интеграция Argo Rollouts с АrgoCD
- Как подружить канарейку с миграциями

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

Автоматизация генерации release notes это хорошо, а можно ли лучше?
Осветим тему о том, как можно отследить какие изменения выезжают в прод добайтика.
По пути затронем DORA метрики и удобство работы программиста в условиях максимальной гибкости.

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

Ну совершенно точно нужно обеспечить ученикам комфортную, технически исправную и одинаковую среду обучения. Потому что у одного MacBook на М2, а у второго ThinkPad, который ему в наследство оставил дедушка с процессором i386. Как ты не пиши требования к оборудованию, обязательно где-то что-то будет не так.

Совершенно точно нужно помогать ученику. Ну вот пишет он "kubeadm init ..." и делает опечатку в параметре "--pod-network-
cidr": преподаватель увидит это моментально, а глаз ученика с этим будет бороться долго.

Кажется, не выглядит как работа для DevOps? Нет, выглядит.

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

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

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

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

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

Вопрос аутсорсинга технологии, сервиса или целой ИТ функции нередко является серьезным тактическим решением для CTO и требует комплексного подхода с учетом влияния на разные аспекты организации.
Мы рассмотрим несколько моделей, помогающих принять такое решение и учитывающих следующие аспекты:
1. Влияние решения на ключевые компетенции компании
2. Влияние бизнес-среды
3. Влияние ИТ компетенций компании

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

Все мы пользуемся DNS, но не все автоматизируют управление. От этого появляются во внутренних (и иногда внешних, sic!) инструкциях "echo '1.2.3.4 my.demo' >> /etc/hosts".
В докладе расскажу и покажу с ready to use примерами:
- автоматизацию управления DNS-зоной через git;
- как сделать собственный no-ip сервис в закрытой сети;
- плагины CoreDNS для Kubernetes;
- собственный плагин для CoreDNS - это просто.

"Оптимизация локальных LLM и Vision Transformers: практические аспекты быстрого и надежного инференса"
В этом докладе мы рассмотрим, как эффективно развернуть большие языковые модели (LLM) и Vision Transformers на локальных ресурсах. Вы узнаете о настройке моделей и серверной инфраструктуры, организации очередей запросов и применении структурированного декодинга для достижения высокой производительности и стабильности. Доклад предоставит практические рекомендации по созданию "Model as a Service", обеспечивающего быстрый, предсказуемый и надежный инференс.

Кажется, что важность надежности продуктов – вещь очевидная. Ни один из владельцев продуктов не ставит цель по созданию продукта, который будет постоянно “падать”. Однако на деле оказывается, что для обеспечения надежности то времени не хватает, то компетенций. Чтобы решить эту проблему в МТС была создана платформа Operations или OpsPlatform. В докладе поделимся опытом создания платформы и как мы за пол года внедрили платформу во все MC/BC продукты экосистемы, какие эффекты получили, и что о нас думают крупнейшие продукты экосистемы.

- опыт разработки платформы автоматизации внутренних процессов с нуля
- зачем и почему - чтобы всем стало лучше и в том числе нам - а если серьезно - потому что у нас крутой внутренний мессенджер, в котором все крутится и все общаются
- бизнес и пользовательские сценарии - от управления учетными записями до создания кластеров виртуальных машин
- как, детали реализации, особенности архитектуры - message broker, EDA, аснихронные очереди и фронтенд на rocket chat app
- вызовы технические и процессные - опыт коммуникаций внутри команды, опыт взаимодействия с другими командами

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

Собственные платформы на базе Kubernetes на сегодняшний день являются неотъемлемой частью не только технологических, но и производственных компаний. Из доклада вы узнаете об опыте создания и эволюции собственной платформы для безопасной разработки и эксплуатации ИТ решений в группе компаний ЕвроХим — крупном международном производителе минеральных удобрений.

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

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

Vault стал одним из самых популярных инструментов для хранения секретов и управления доступом к ним. Он надежно защищает данные и делает работу с ними простой и удобной, став де-факто стандартом в этой области.

С ростом инфраструктуры и увеличением числа команд и сотрудников возникает важный вопрос: как обеспечить всем удобный доступ к секретам, сохранив при этом безопасность, масштабируемость, отказоустойчивость и простоту в обслуживании?

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

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

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

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

Когда мир разочаровался в DevOps!
Когда зарплаты разработчиков улетели в космом!
Пришли они - платформы для разработчиков!

Что это за очередная менеджерская штука?! И когда это мир разочаровался в DevOps?!

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

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

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

Опыт Yandex Cloud'а в создании внутренней платформы. Сравнение использования самого YandexCloud'а и k8s для такой платформы. Польза и вред Self-Hosting'а, проблема бутстраппинга Self-hosted решений.

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

Из доклада вы узнаете, какие архитектурные и технические решения мы используем в нашей ИТ-платформе в масштабе 2000 продуктовых микросервисов, 600+ пайплайн-ранов в день в 5 baremetal-кластерах и 4 разных ЦОДах. В докладе так же затронем темы: почему мы используем Tekton для пайплайнов, какие решения кардинально улучшили DX и зачем нам оператор для проверки качества сервисов и проектов.

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

private cloud web service, visibility и переиспользование сервисов, ресурсное планирование

Создание "Платформы R&D", а для PT (Positive Technologies) это создание эффективной среды разработки, привело к потребности в инструментах – нужны инструменты управления доступами, ресурсами в инфраструктуре, сервисами и артефактами разработки. Начав наводить порядок, в процессах разработки большой компании, стало понятно в каких инструментах и стандартах существует самая высокая потребность и как их можно объединить в централизованное решение.
Этот доклад является продолжением предыдущей главы "Платформа R&D. Глава 1: Наводим порядок (https://devoops.ru/talks/85d87020eb2e4042a5e3c52c6977569f/)" и посвящен реализации единого интерфейса взаимодействия R&D с системами проектного менеджмента, хранения и сборки исходного кода, управления зависимостями, артефактами и инфраструктурой разработки.

В нашем облаке мы решили двигаться к Zero-Trust, что предполагает использование Service Mesh, где только авторизованные сервисы могут взаимодействовать друг с другом.

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

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

Когда у тебя большая распределенная инфраструктура выдавать доступы разработчикам, лидам, аналитикам ставоится все интереснее. Конечно же у нас есть OpenVPN, Wireguard и прочие всем знакомые инструменты, но они подходят не всегда.
В рамках своего доклада я расскажу как мы Магнит Омни:
-- решили вопрос предоставления доступа для разработчиков/лидов/etc. для разных окружений
-- как мы научились выдавать консистентный доступ в разные окружения
-- как нам удалось сократить время выдачи доступов с нескольких дней до 15 минут
-- как мы автоматизировали настройку Netbird VPN и превратили его в платформенный
-- и про "факапы" я тоже расскажу

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

· Как мы прошли путь к текущей реализации dev-окружения сквозь обычные виртуалки, kubernetes + собственный cli, коммунальный kubernetes + helm.
· Анализируем dev платформу: Kubernetes + ArgoCD, vCluster, Kyverno, etc. Проблемы и решения при поддержки множества автогенерируемых vCluster'ов.
· Основные типы тиражируемых сред и поддержка актуальности.
· Как решить проблему огромного helm chart. Какие подходы можно использовать при организации проектов разработки и как тиражировать варианты сборок окружений.

О чем хочется рассказать:
ВК большая компания с множеством разных БЮ, в каждом БЮ разные системы мониторинга и алертинга. В рамках доклада пройдемся от того как было, что с алертом случалось когда он зарождался и как доходил до человека, который мог починить проблемы, и как стало сейчас с внедрением автоматизации во все БЮ. Используем Grafana oncall + сильно допиливаем ее саму + вокруг выстраиваются разные вспомогательные сервисы. Какие кейсы эскалации алертов, как мы избегаем шума алертов. А также что можно еще сделать с алертом, например алерт может вырасти в полноценный инцидент, с jira таской и чатом инцидента со всеми заинтересованными лицами. Как чатом можно управлять используя бота, и какой у нас флоу инцидента в рамках автоматизации.

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

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

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

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

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

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

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

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

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

Уже давно не секрет, что в Т-Банк есть своя observability-платформа Sage.
Внутри банка, мы предоставляем сервис мониторинга, у которого ежедневно более 5000 активных пользователей(DAU).

И как это принято, у нас есть SLA с нашими пользователями,
но "как понять предоставляем ли мы сейчас услугу или нет?" - именно с этого вопроса начинатся мой рассказ о построении SLOs/SLIs для нашей платформы Sage. Метрики для метрик.

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

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

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

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

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

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

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

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

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

Для тех кто уже понял “Что такое SLI/SLO?” теперь станет понятно как это реализовать на практике.

Представь, ты инициативный разработчик или инженер. Ты уже узнал какая классная штука SLO и как оно помогает поддерживать работу сервисов и не замедлять разработку. Ты уже продал это руководству и команде - все жаждут увидеть это в дейтсвии. Ты полон энтузиазма и уверенности, что все быстро сделаешь, ведь, кажется, это делали много раз в разных комапниях, следуя заветам книг Google. Ты начинаешь искать готовый вариант, чтобы сделать первый MVP как можно быстрее. И понимаешь, что готового рецепта нет. Ты начинаешь поиск источников о практиках других компаний, инструментов для реализации и находишь частичные данные, но ты не знаешь насколько этот айсберг велик. А хочется по горячему, пока интерес не остыл, показать хоть что-то команде и принести пользу.

Поделюсь нашим опытом и наработкам. Я бы хотел все это знать и иметь в самом начала работы с SLO.

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

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

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

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

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

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

Hashicorp Vault является стандартом де-факто хранения чувствительных данных. Интегрируется он примерно с чем угодно и, естественно, с другим фактическим стандартом размещения нагрузки - Kubernetes.
Инструментов для интеграции Hashicorp Vault с Kubernetes существует немало и каждый обладает своими примуществами и недостатками, поэтому в докладе рассмотрим и сравним популярные инструментов доставки секретов из Hashicorp Vault:
- External Secrets Operator
- Hashicorp Vault Secrets Operator
- Hashicorp Vault Agent Injector
- Hashicorp Vault CSI Provider
- (Banzai Cloud) Bank Vaults-Vault Secrets Webhook
Для каждого из интрументов приведу пример настройки, рассмотрю как именно доставляется секрет до приложения и принцип работы инструмента. Сравню инструменты с точки зрения механизмов ротации секретов, а также удобства использования. Подсвечу ограничения инструментов.

Новая жизнь бросает нам новые вызовы - и вот уже CNI и Service Mesh-и с EBPF под капотом это не что-то из области фантастики или экспериментов, это уже повсеместно внедряется на production инфраструктуру. Однако не так много инженеров понимают, что происходит под капотом этой системы. И еще меньше инженеров знает, как системы на базе eBPF могут быть скомпроментированы и как защититься от угроз если не полностью, то хотя бы минимизировав риски. И сегодня я расскажу вам об этом.

В докладе мы затронем следующие темы:
- Что такое bpf как технология
- eBPF и как это работает
- Атаки на удаление ключей из ebpf maps
- Kernel exploits by eBPF
- Вызов незапланированных syscalls
- Falco bypass
И другие виды атак

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

В докладе - расскажем о том, как работал процесс раскатывания больших инициатив ИБ в Яндексе еще совсем недавно и что поменялось в нем после появления менеджеров. А также ответим на вопросы - зачем нам метрики? Как сделать так, что об инициативе узнали все? А также расскажем о фейлах ))

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

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

Процесс безопасной разработки в финтехе, обзор регуляторики - "когда, зачем, кому", особенности технической реализации требований - как.
Реальные кейсы применения инструментов для выполнения шагов pipeline'а. Интеграция в pipe.
Баланс требований и суровая техническая реализация.
Практическая реализация Security Gates

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

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

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

Продолжение доклада по исследованию "Сколько стоит голова девопса"
В ситуации, когда ИБ перегружено своими безумными идеями, появляется вопрос: "Как построить безопасность без ИБ"
Данный доклад ставит целью раскрыть простой cookbook для инженеров автоматизации, который поможет им правильно сформулировать информацию для себя и для того "Васи из ИБ" и понять, как же работают их системы и что защищать. По факту - сделать shift right для начала, чтобы потом сделать shift left и хвастаться своим DevSecOps'ом. Как выстраивать линии обороны в своих инфраструктурах при малых затратах и совмещать это с гибкостью автоматизации и вообще ответить на вопрос: "А если моя инфраструктура уничтожена, за сколько я разверну ее снова?"

Автоматизация проверок безопасности
Архитектура сервисов AppSec
Схожесть AppSec с другими популярными сервисами

В докладе рассмотрим архитектуру и управление различными реестрами Docker-контейнеров с акцентом на инфраструктуру, узкие места, защиту доступа к реестру, устройство Docker-образов и выявление уязвимостей до запуска в production. В сессии подробно рассмотрим механизмы аутентификации и авторизации для Docker-трафика, уделим внимание продвинутым аспектам управления образами Docker, включая создание мультиплатформенных образов, получение SBOM отчетов, а также перечня уязвимостей при помощи инструментов сканирования. Обсудим возможные сложности при эксплуатации реестров, а также при реализации сканирования на уязвимости.

Это обязательная для посещения сессия профессионалами, желающими углубить свои знания в области управления образами Docker и безопасности.

Далеко не первый раз мы слышим на конференциях о "безопасной разработке", но часто это сводится к сканерам: "давайте напихаем SAST,DAST,IAST,RAST и будем по их отчётам бить по рукам разработку". Реже мы слышим про Security Champion в формате "найдите их и будет хорошо". Идея то конечно хорошая, но как искать чаще всего никто не может подсказать ибо это обычно индивидуальный опыт компании. Реже всего говорят о обычном разработчике и его вовлечении в этот процесс, а он тут всё же самое важное звено.
В докладе хочется показать как и чем можно мотивировать людей интересоваться безопасной разработкой не только "битиём по рукам" и как потом поддерживать их желание развивать данное качество.

Язык программирования Go предоставляет возможности, которые значительно оптимизируют разработку инструментов для DevSecOps и Red Team. Он отличается простотой, что облегчает его изучение и использование. Компиляция программ на Go для Windows, Mac и Linux из единого исходного кода позволяет экономить ценное время. Именно поэтому злоумышленники активно используют Go для создания современных вредоносных программ. Мы будем моделировать эти угрозы, чтобы лучше понять, как защищаться.

Доклад посвящён особенностям работы с сертификатами в среде Service Mesh. В нём обсуждаются вызовы, связанные с коротким сроком действия сертификатов, их своевременным обновлением и валидацией, включая использование CRL, OCSP и OCSP Stapling. Особое внимание уделяется влиянию истечения срока действия сертификатов на доступность сервисов и предотвращению сбоев. Также рассматриваются ограничения и возможности проверки сроков действия сертификатов на примере Istio Service Mesh.

API - это самый удобный способ публикации сервисов B2B и B2C. Но даже крупные компании, такие как Apple (случай с Apple iCloud account takeover), Google (случай с Google Cloud Platform IAM API), Mercedes-Benz (случай с Mercedes-Benz car control) и т.п. допускают ошибки при разработке и публикации своих API.

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

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

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

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

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

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

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

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

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

Предоставить пользователям аналитическую базу данных - это не просто поднять гринплам, кликхауз или купить на них подписку. На примере внедрения в платформу данных базы нового поколения Starrocks (https://www.starrocks.io) расскажу про обеспечение необходимого минимума фунционала и автоматизации для потребителей - инженеров данных, инженеров-аналитиков или разработчиков dwh.
Постараюсь ответить на вопрос - каким требования должны удовлетворять инсталляции и сами движки баз, особенно если вы как поддержка хотите спать по ночам и не вздрагивать при слове обновление, блокирующие операции ddl или отказ мощностей.
В докладе будет k8s (куда же без него в современном мире), сервисы миграций, аутентификации и авторизации, dbt как сервис - и все это приправлено щепоткой golang и gitlab-ci.

Я расскажу наш опыт ускорения автоскейлинга ресурсов с GPU в нашем продукте - Inference Платформа Selectel на базе Managed Kubernetes.

В докладе мы охватим следующие темы
- Узкие горлышки в различных этапах автоскейлинга в K8S
- Один из самых долгих этапов - пуллинг образа контейнера на ноду
- Основные компоненты образа в мире ML
- Почему стандартные подходы к оптимизации размера образа не срабатывают в мире ML
- Уменьшение размера образа выносом весов моделей в отдельное сетевое хранилище
- Увеличение скорости загрузки слоев образа с помощью кеширования в кластере
- Ленивой загрузка слоев образов и снепшотеры (nerdctl, SOCI, Nydus)
- Форматы сжатия образов zstd vs gzip

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

В рамках доклада будет представлен опыт разработки и внедрения отечественного BI-решения для крупнейшей российской сети супермаркетов «Перекрёсток». Проект реализовывался в условиях необходимости замещения Amplitude Analytics, что потребовало создания собственной инфраструктуры, разработки ETL-решений и расширения возможностей open-source BI-инструментов. Особое внимание будет уделено решению задач обработки больших данных, инкрементальной аналитике и созданию интерфейсов self-service для визуализации.

Основные тезисы
===
Контекст проекта:
- «Перекрёсток» — крупнейшая российская сеть супермаркетов с DAU ~20 миллионов.
- Отказ от Amplitude Analytics привёл к необходимости полного пересмотра подходов к аналитике: от трекинга до построения сложных отчётов.

Ключевые вызовы:
- Работа с большими объёмами данных в условиях ограниченных вычислительных ресурсов.
- Разработка функционала для обработки произвольных NoSQL данных (JSON) с тысячами кастомных свойств.
- Замещение алгоритмов Amplitude, включая идентификацию пользователей и построение сессий.
- Ограниченные возможности open-source инструментов (Metabase) для сложной визуализации.

Подход к решению:
- Использование отечественной инфраструктуры на базе Yandex Cloud.
- Переход с Spark на Python-библиотеку Datapipe для создания гибких инкрементальных ETL-процессов.
- Доработка интерфейса Metabase для подготовки запросов без написания SQL-кода.
- Перенос тяжелых вычислений с ClickHouse на ETL-процессы, чтобы обеспечить масштабируемость и устойчивость.

Ключевые результаты:
- Бесперебойная работа ETL: ежедневные трансформации стали инкрементальными и менее ресурсоёмкими.
- Сокращение затрат на аренду вычислительных мощностей и операций с хранилищем данных.
- Ускорение процессов визуализации отчётов за счёт оптимизации витрин данных.

- DAGи и Data-пайплайны - что это и зачем это нужно
- Airflow - оркестратор DAGов
- Зачем нужны динамические окружения в Airflow
- Как организовать динамические окружения в Airflow
- Как подружить Airflow и ArgoCD

Вы не любите планёрки? Вы просто не умеете их готовить.
Управление проектами, бюджетирование ресурсов, диаграммы Ганта... Может, можно без этого?
Лучше меня никто не сделает. Возможно, стоит попробовать делегировать по-другому?

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

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

Несколько лет назад в Иви мы расформировали команды мониторинга и централизованной выгрузки релизов.
Причина: такая конфигурация имела несколько проблем.
Что мы сделали:
- функцию выгрузки релизов передали в продуктовые команды
- функцию мониторинга и 1-2 линии поддержки (сервисов) выполняем всеобщими дежурствами
...
Profit

Поделюсь своим личным опытом внедрения методологии Kanban в команде SRE.

Управление поставкой и Kanban регулярная тема конференций для руководителей и разработчиков. Невольно возникает вопрос применима ли методология для команд надежности?

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

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

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

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

Этот доклад — как проект Linux from Scratch: я расскажу, как и где мы лажали и продолжаем лажать спустя полтора года после запуска компании, как мы лечили и предотвращали «детские болезни», какие ошибки наверняка попытаетесь совершить и вы и как, в конце концов, собрать компанию «из сорцов».

Предыстория
Год назад Андрей Квапил объявил о запуске собственной платформы Cozystack. Чуть позже к нему присоединились Георг Гаал и я, автор этого доклада. Наша текущая бизнес-модель — заработок на подписке на саппорт open source-платформы, продажа облака, а также обслуживание приложений клиентов, которые крутятся в нашей платформе. Наверное, мы наступили на все грабли, на которые только можно было наступать. Более того, мы еще далеки от идеала и суперчетких процессов, продолжаем ошибаться, учиться и набивать шишки. Но тем ценнее наш опыт для тех, кто тоже начинает строить свою ИТ-компанию, особенно в b2b.

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

Расскажу о процессах, которые удаляют от ситуативных реакций и фокусируют на пользе:
- Доставка ценности: Как мы подошли к организации работы с собственной поставкой, целеполаганием и синхронизацией со смежниками (разработка)
- Регулярные каденции: Почему ретро полезно в SRE команде? Как мы используем его с инцидентами и привлекаем смежников?
- Управление аварийными ситуациями: Как подготовиться к "пожару" ДО принятия сервиса на поддержку и минимизировать влияние человеческого фактора на его решение;
- Нагрузочное тестирование: Типичный инструмент для продуктовой команды - когда и зачем он полезен SRE?
- Дежурства: Стратегии организации, как построить работу с дежурствами так, чтобы команда не выгорала
- Онбординг: Когда в компании много инструментов, в команде десяток сервисов и несколько десятков контактов - новички очень дороги, поделюсь лайфхаками, как нивелировать эти проблемы
- Выхлоп из деятельности команды: ранбуки, постмортемы и другие артефакты - как организовать их полезно и нужно ли их выпускать

Роман "Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему" стал одним из первых Бизнес романов на тему DevOps, для принятия решений использовался Канбан.
Расскажу какие практики Канбан метода применялись бы, и какие выгоды были бы получены если продолджили использовать Канбан метод в проекте

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

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

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

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

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

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

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

В своем выступлении «загляну под капот» одного из самых популярных Ingress контроллеров в k8s – Nginx Ingress. Материалы доклада помогут вам добиться желаемых результатов при работе с данным инструментом.

В чем основное различие Enabling-команд и команд с "Инженерами на час". Наше видение того, какие типы команд наиболее востребованы в Enterprise. Эти типы команд взаимоисключают друг друга или можно построить что то среднее? Наш опыт построения Enabling-команды.

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

Это доклад продолжение докладов про коллаборации, важность проектирования для DevOps(ов).

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

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

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

Автоматизация управления документацией в архитектуре микросервисов и микросервисных команд с помощью Ansible

Введение

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

О чем доклад

1. Автоматическая генерация документации на основе настроек клиента

2. Генерация универсального файла настроек для миллионов микросервисов и управление им с помощью Ansible:

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

Около 2 лет назад от СТД “Петрович” отделилась продуктовая ИТ-компания “Петрович-Тех”, созданная для закрытия потребностей СТД. Бывший ИТ-департамент стал полностью самостоятельной единицей, а также значительно вырос - и по численности сотрудников, и по уровню решаемых задач.
Уровень сервисов и их доступность стали ключевыми показателями, под которые появилась необходимость перестроить процессы молодой ИТ-компании.
Как масштабировать и перестроить процессы бывшего департамента под структуру компании и новые отношения с заказчиком? Ответ мы нашли в адаптации ITIL под наши потребности и готовы поделиться своим маршрутным листом: на примерах и с кейсами.

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

В своем докладе я поделюсь, как мы решали задачу предоставления доступа к инфраструктурам (VPN, SSH, веб-формы) для команды, обеспечив при этом безопасность. Мы нашли способ, чтобы сотрудники имели доступ, но не могли скомпрометировать данные.

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

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

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

Что может побудить нас переехать в облако? А обратно? Достаточно ли хорошо мы понимаем, какие подводные камни обнаруживаются в любом из этих путей? В данном докладе, я бы хотел затронуть тему не самых очевидных нюансов, с которыми столкнется инженерная команда, которая выбирает ту или иную дорогу. Как водится, с каждой из сторон множество плюсов и минусов, поэтому мы с вами попытаемся понять, как выбрать вариант подходящий именно для вас, а не только потому, что так модно/молодежно, и обратим ваше внимание на скрытые факторы, с которыми мы столкнулись благодаря большому опыту миграций различных инфраструктур в обе стороны.
Рассмотрим мы следующие вопросы:
- Скрытые затраты миграции, сколько на самом деле стоит это мероприятие?
Детализация этапов миграции: анализ затрат на подготовку, миграцию, обучение комманды, перестройку процессов
Сравнение реальных расходов с ожидаемой экономией
Примеры кейсов компаний, которые столкнулись с неожиданными затратами
Метрики: как оценивать ROI миграции
- Временные проблемы или сигнал к миграции?
Анализ “тревожных звоночков”: рост требований к производительности, устаревшая инфра, трудности масштабирования
Сценарии выбора: когда временные проблемы действительно требуют миграции, а когда можно обойтись оптимизацией текущей инфры
- Инфраструктурные риски
Категории рисков: физические (отказ оборудования), программные (устаревший софт), киберугрозы
Риски при переходе в облако: зависимость (вендор-лок)
- Влияние облака/on-prem на обновление/устаревание технологий
Жизненные циклы инфры, как меняется подход к обновлениям
Стоимость обновлений в обоих сценариях
Как облако решает “устаревания”
- Скрытые (неочевидные) ограничения облаков
Технические ограничения: специфика работы с API, зависимость от скорости ответа
Ограничения на перенос данных между регионами
Кейсы, когда облачные сервисы не подходили для задач компании
- Эффективность затрат: когда “дешевле” в облаке не значит “дешевле”
Сравнение моделей: pay-as-you-go vs. капитальные вложения в on-prem
Штрафы за превышение лимитов или несоблюдение контрактов, перенос данных, лицензирование
- Юридические и контрактные ограничения, которые приходят вместе с облаком
Соблюдение законодательства (о перс. данных, etc..)
Кто несет ответственность за инциденты (учетка данных, сбои в работе)
- Управление и мониторинг: чем отличается контроль инфраструктуры в on-prem и облаке
Автоматизация: как облако упрощает мониторинг и управление
Сравнение инструментов: традиционные vs. облачные
- Архитектура отказоустойчивости: кто справляется лучше — облако или on-prem?
Параметры отказоустойчивости: что включает в себя архитектура в обоих случаях
Кейсы: примеры успешных и неуспешных решений в облаке и on-prem
Гибридные варианты
- Качество сервисов: почему SLA облака не всегда соответствует реальности
Анализ: что включает SLA и как его интерпретировать
Всегда ли оператор выполняет свои обещания
Независимый мониторинг, стресс-тесты инфры

Многие команды разработки за 15 лет существования Kubernetes внедрили этот инструмент в production как облачный сервис или bare-metal реализацию. В нашей компании bare-metal k8s стал основой внутренней платформы для разработчиков, которая должна быть отказоустойчивой, поэтому он живёт в нескольких цодах. На докладе я поделюсь:
- Экспертизой в расселении Kubernetes в разные цоды
- С какими проблемами мы столкнулись при внедрении DevOps практик на такую архитектуру
- Как мы решали вопросы межцодной коммуникации между ресурсами внутри K8s и контроля их доступности
- Каким образом можно обеспечить доступность ресурсов при сбоях в облаке или датацентре
- Какие есть варианты для безопасной коммуникации в межцоде

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

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

○ Как обеспечить отказоустойчивость контактного центра
○ Возможные варианты реализации. Вложение в инфраструктуру против финансовых потерь и репутационных рисков. Когда одно пересиливает другое.
○ ПАК под замком с минимальными затратами. ЦОД на Урале.
○ В докладе расскажу:
■ Когда стоит задумываться о надежности
■ Технологии, применяемые для отказоустойчивости отдельных компонент инфраструктуры
■ DRP или как вытащить ПАК из под замка
■ К чему стремиться. Сокращение RTO/RPO, автоматизация


Рассказ о себе и компании (5мин)
Становление надежности в контактном центра (10 мин)
RTP/RPO. Принципиальные отличия на для контактного центра простой – это не просто финансовые потери и
недополученная прибыль, но и в первую очередь, репутационные риски.
Вложение в инфраструктуру против финансовых потерь и репутационных рисков. Когда одно пересиливает другое.
Отказоусточйчивость отдельных компнент контактоного центра (5мин)
Резервирование, балансировка и избыточность
Сценарий, когда географически разнесенный ЦОД не спасет (2мин)
Реальные кейсы пратнеров с шифровальщиками
Концепт "ПАК под замком" (5 мин)
5 сценариев для бизнеса.
ЦОД в Челябинске, прееживший падение
Как прятать, когда извлекать
Техническая реализация ПАК под замком (5ми)
Backup as Service, изоляция сеть и как управлять, атоматическое развертывание и автотесты
Дальнейшее развитие "ПАК под замком" (3 мин)
Работа над сокращением времени восстановления и допустимой потери данных.
Merge после восстановления основной инфраструктуры

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

Когда мы говорим про лучшие (или худшие) DevOps-практики, на ум приходят конвееры поставки на тестовые стенды, в продуктовое окружение, контейнеры и прочие технологические сущности. Между тем - DevOps это не столько методология, сколько идеология, автор в этом в очередной раз убедился, непосредственно участвуя в процессе взрываного роста производства наших ПАКов (программно-аппаратных комплексов, Машин различного назначения). Средства автоматизации неожиданно стали приносить больше проблем, чем пользы, и проблемы эти пришлось решать скорее в идеологическом разрезре, а уже потом чинить технологии.

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

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

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

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

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

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

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

Почему типовые карьерные треки не работают?
Опыт построения рабочего карьерного трека в компании Cloud.ru

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

Успешно участвую в платформе https://getmentor.dev/ как ментор.
За 1.5 года успел помочь 12 обратившимся с совершенно разным бэкграундом и исходными запросами.
Также пробовал себя в роли менти.
Готов предложить аудитории обзорный доклад с состоянием менторства в мире и на русскоязычном рынке в целом (провести небольшое исследование), рассказать чего не нужно ожидать от такого рода сотрудничества, а в чем может быть совершенно неожиданная польза для ментора в том числе.
Ответим на вопрос, чем менторство лучше и хуже внутрикорпоративного обучения.
А как бонус проведем сравнение живого ментора и ChatGPT помощника.

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

Этап сообщества и создания пространства для общения + наставничество
> Результаты

Этап внутренних митапов + Выводы
> Организация PI Planning и EventStorming

Этап организации платформенной команды c шарингом участников
> Прекращение активности и мысли на счет Орг дизайна

Этап Оценок + стандартизации грейдов специалистов + Выводы
> Пересмотр подходов к оценке Senior+ специалистов

Этап трансформации проблемных продуктов + выбор новых инструментов
> предварительные выводы

Общие выводы и текущие функции ЦК
Про будущее - Технический арбитраж

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

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

В современном мире онбординг – это не просто введение нового сотрудника в курс дела. Это ключевой этап, от которого зависит, насколько быстро и эффективно новичок (и при этом не важно, это сотрудник новый для компании или перешедший из другого подразделения) станет полноценной частью команды. Я хочу поделиться с вами методиками, которые мы успешно внедрили в нашей компании и которые могут кардинально изменить ваш подход к онбордингу. А главное, почему НУЖНО взять ответсвенность за онбординг самой команде и почему команда может находить в этом процессе ценность для себя.

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

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

Это совместный доклад с Андреем Синицыным (TechLead+HR)
Я работаю на рынке It-рекрутинга с 2011 года и за эти годы наблюдала смену множества тенденций, но одна из них особенно меня задевает. Еще 5-7 лет назад безусловным благом считался путь джун-миддл-синьер-тимлид и многие шли по нему не задумываясь. Сегодня появляется все больше и больше лидов, которые хотят обратно в синьеров. Усталость от пипл менеджмента и давление бизнеса, выгорание и потеря инженерной квалификации, сложности с возвращением на уровень "синиор" - это, к сожалению, проблемы с которыми сегодня сталкиваются те, кто когда-то выбрал "правильный" путь идти в лиды. Выбрал сам или "так сложились обстоятельства".
В своем докладе-провокации мы расскажем о том, почему НЕ стоит быть лидом. На примере реальных историй продемонстрируем иногда неожиданные проблемы с которыми сталкивается начинающий лид
как инженер
как "пипл-менеджер"
как бизнес-единица от которой ждут результат
Обозначим зоны риска.
Дадим краткую статистику зарплат и соотношение вакансий/резюме (она демонстрирует, что конкуренция среди лидов в разы выше, чем среди синьоров а разница в зарплатах не всегда значима)
И в конце доклада для тех, кто все же решил выбрать путь управленца, поделимся списком вопросов для саморефлексии. Вопросы на которые нужно ответить самому себе перед тем, как принимать решение стать лидом.

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

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

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

2 года назад я ушел с позиции head of infra в Skyeng c ~50 сотрудников в подчинении в стартап, где стал СТО и единственным разработчиком, условно сильный downgrade. Хочу поделиться опытом как я принимал решение, на что обращал внимание и жалею ли теперь. Хочу поделиться опытом тем, сейчас стоит перед таким выбором или задумывается о стартапах в целом

Казалось бы, тема «DevOps - кто этот зверь?» уже избита и на конференции DevOps-ов даже как-то не ком-иль-фо ее поднимать. Однако, я предлагаю подойти к ней не со стороны ‘opsa, а со стороны нанимающего к себе в команду инженера.
Что мы видим сейчас на рынке и почему это боль? Я расскажу, как мы искали SysOps-a среди DevOps-ов. Как отрасль убила профессию Системного администратора и чем теперь это чревато.

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

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

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

В современном процессе разработки программного обеспечения применение FrontOps-практик к фронтенд-приложениям становится все более важным для DevOps-инженеров. Автоматизация процессов сборки и деплоя фронтенда не только ускоряет выпуск новых фич, но и повышает надежность системы в целом. Внедрение автоматических тестов различных уровней (юнит, интеграционные, e2e) в CI/CD пайплайны гарантирует сохранность существующей функциональности при добавлении новых изменений. Оптимизация пайплайнов и выбор эффективных и современных инструментов, таких как pnpm, bun и vite, значительно улучшают эффективность и скорость доставки продукта.

Использование инфраструктуры как кода (IaC) для фронтенда решает проблему несоответствия сред разработки, тестирования и продакшена, снижая риски при деплое и облегчая масштабирование. Реализация наблюдаемости и мониторинга с помощью инструментов типа Sentry является критически важной для поддержания высокого качества пользовательского опыта и быстрого решения возникающих проблем. Уделение внимания безопасности с самого начала защищает от распространенных уязвимостей посредством интеграции DevSecOps-подходов и использования инструментов вроде ESLint, SonarLint и DefectDojo.

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

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

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

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

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

Сo-pilot в разработке — тренд последних лет. Однако этот трек не единственный в ландшафте AI-оптимизации внутренних процессов в бигтехе.

А о чем мы поговорим?
Кажется есть парочка мыслей:
1. как в целом можно замерять эффективность производственного процесса — немного менеджерской теории, чего мы там все меряем;
2. AI есть, а о пользе слышали? Когда нас всех уволят?
3. как можно использовать AI в разных ролях: поддержки, дизайна, аналитики, солюшн-архитектуры, тестирования;
4. когда это становится масштабируемым.
5. Как внедрять AI? И почему большинство инженеров не так активно его используют?

Поищем общие и конфликтующие позиции, послушаем success-stories из первых рук.

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

1. Краткая история метрик оценки разработки: строчки кода и прочее
2. DORA, QUANT, SPACE
3. Что делает и куда смотрит сбер.
4. Почему метрики для оценки разработки - разрушают команду
5. Как одна метрика разрушила всю команду.
6. А можно ли контролировать 800+ инженеров без метрик?
7. Почему метрики - это правильно и хорошо

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

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

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

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

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

Бизнес-тренажёр 22 - это игра, в которой можно потренироваться и поэкспериментировать с различными стратегиями развития бизнеса. Кейсы в игре "основаны на реальных событиях", что делает сильно приближенной к реальности.

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

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

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

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

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

Также я поделюсь лайфхаками, как эти знания можно использовать в жизни.

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

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

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

В 2ГИС поисковые данные обновляются довольно часто — особо активные сегменты могут обновляться раз в 10 минут. Насколько быстро эти данные начнёт использовать поисковый движок, настолько свежие данные увидит пользователь. Поэтому основная задача — быстро доставить свежие данные до пользователя.

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

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

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