Доклады
Показать только принятые докладыПрименение ИИ в Devops (7)
LLM в работе DevOps-инженера: как сделать анализ логов проще и безопаснее
DevOps-инженеры сталкиваются с рядом рутинных проблем, включая необходимость обработки и анализа больших объёмов логов. Уже не секрет, что применение LLM (Large Language Models) может существенно упростить работу DevOps-инженеров, автоматизировав анализ логов, выявляя паттерны, аномалии в данных и возможные проблемы. Чтобы обеспечить безопасность и конфиденциальность информации, рекомендуется размещать LLM локально на собственных серверах или в облачной инфраструктуре. Такой подход минимизирует риски утечки данных. В докладе рассмотрим, какие модели можно использовать для анализа логов и что для этого потребуется.
Программный комитет ещё не принял решения по этому докладу
Младший инженер или Искусственный интеллект?
Современные тренды направлены на внедрение искусственного интеллекта для выполнения рутинных задач. К чему может привести страсть автоматизировать всё вокруг? Порассуждаем об этом на докладе
Программный комитет ещё не принял решения по этому докладу
"200 тысяч единиц уже готовы, еще миллион на подходе" или как мы решали проблему подготовки множества управляемых кластеров за 5 минут
При росте объемов данных и требований к ускорению времени вывода на рынок (TTM) невозможно обойтись без современных инструментов, в том числе и ИИ. Автоматизация развертывания сложных окружений всегда сопряжена с трудностями, особенно когда важна скорость. В этом докладе мы рассмотрим подходы и технологии, которые обеспечивают типизацию и быстрый деплой окружения с учетом специфики вашей инфраструктуры — сети, балансировки, отказоустойчивости и распределенности.
Программный комитет ещё не принял решения по этому докладу
Код и совесть: этические риски применения LLM в DevOps, как их избежать и на что обращать внимание
С увеличением уровня внедрения LLM в процессы DevOps возникает ряд этических вопросов, касающихся их использования. Мы должны осознавать, что автоматизация процессов и генерация кода с помощью LLM могут привести к нежелательным последствиям, если не учитывать аспекты инженерной этики.
В докладе я поделюсь опытом по выявлению и минимизации этических рисков, связанных с использованием LLM в DevOps. Обсудим безопасность языковых моделей, важность прозрачности алгоритмов и необходимость создания этических норм для разработки и внедрения таких технологий. Вместе определим, какие вопросы необходимо задать себе и коллегам прежде, чем внедрять нейросетевые решения в инфраструктуру.
Мы рассмотрим ключевые идеи, такие как обеспечение безопасности конфиденциальных данных, предотвращение предвзятости в моделях и необходимость постоянного мониторинга и оценки результатов работы LLM. Также уделим внимание тому, как открытая дискуссия может помочь создать более этичные и ответственные решения в области DevOps.
Программный комитет ещё не принял решения по этому докладу
vGPU в K8s - как перестать считать видеокарты для контейнеров
- Анализ проблем утилизации GPU в контексте подходов single-model и multi-model inference.
- Сравнительная оценка аппаратных и программных решений для оптимизации использования GPU.
- Глубокое понимание реализации концепции vGPU в Kubernetes и её архитектурных особенностей.
- Практические подходы к устранению дефицита CPU, возникающего при перераспределении ресурсов GPU.
- Рекомендации по эффективному управлению ресурсами GPU в контейнеризированных окружениях.
Доклад принят в программу конференции
Это же полный КАИВ! Методология Каскадной AI валидации дефектов приложений
Методология КАИВ (Каскадная AI валидация дефектов приложений) позволяет почти в 10 раз сократить трудозатраты на ручной триаж за счет AI валидации, обеспечивающей точность 80-90%, и почти в 15 раз снизить трудозатраты на исправление подтвержденных дефектов за счет их приоритезации, автоматического предложения места наиболее эффективного исправления и контекстных рекомендаций по устранению подтвержденных уязвимостей. Обладает нулевым False Negative.
Программный комитет ещё не принял решения по этому докладу
Как искать подходы к применению ИИ в DevOps и что из этого может получиться
1. Как искать и найти кейсы для применения AI в DevOps. Построим цепочку действий, которая приведет нас к списку кейсов
2. GigaChat, Lama, ChatGPT... или что-то своё. Выбираем модель для реализации кейсов
3. Запускаем обучение! Так, стоп, а что с данными? Все ли мы можем отдать на обучение и какие чувствительные данные нам могут встретиться на пути.
4. Собираем команду. Кто нужен и как спланировать реализацию встраивания ИИ в реальные инструменты.
5. Как запустить кейс на практике? Какие могут встретиться административные барьеры в Enterprise и как их преодолеть.
6. Немного о том, что мы получили на практике и какие выводы мы сделали для себя.
Программный комитет ещё не принял решения по этому докладу
Chaos engineering (7)
Лучшие работающие SRE практики. Как реализовать эксплуатируемый маппинг и ускорить решение инц.
Поговорим о том как внедрить лучшие SRE практики.
Как избавиться от избыточного мониторинга, и контролировать продукт с одного экрана.
Реализация работающего маппинга в высоконагруженном приложении.
Доклад принят в программу конференции
История хаоса в Такси
От идеи до сломанного прода
Программный комитет ещё не принял решения по этому докладу
Семплирование трейсов изнутри. Что скрывается под вершиной айсберга?
Что такое семплирование и зачем оно нужно?
Метрики и трейсы на основе семплированных данных. Бесполезная игрушка или рабочий инструмент?
Head vs Tail. Отличия и сценарии использования.
Реализация и алгоритмы head-based семплирования.
Реализация и алгоритмы tail-based семплирования. Подводные камни и способы их обхода.
Применение семплированных трейсов в разборе реальных инцидентов.
Доклад принят в программу конференции
Метрики с Micrometer
1) Самый часто используемый вами тип метрики будет DistributionSummary
2) Дефолтные конфигурации регистрируют десятки готовых метрик за вас
3) Micrometer, как заявляют его разработчики, является фасадом для JVM фреймворков, но он таким не совсем является, в прочем он и не только фасад
Программный комитет ещё не принял решения по этому докладу
Лучшие практики управления инцидентами и проблемами
Как делиться результатами Postmortem с командами
Эффективная ролевая модель во время инцидента
Метрики успеха: как измерить достижения
В управлении инцидентами уже собрано много практик, в докладе расскажу про две, на мой взгляд, самые важные задачи на старте процесса — ролевую модель при инциденте и Postmortem с командами.
В докладе расскажу как эффективно делиться результатами Postmortem с командами, чтобы что сократить их бэклог, эффективнее управлять проблемами (правильно приоритизировать, заносить в команды, давать инструменты в виде дашбордов для отслеживания, добавлять новые активности в виде комитетов и review) и тратить меньше времени на управление. А также как выстроить эффективную ролевую модель во время инцидента (назначение, функции, резолвинг).
Измерим результаты использования эффективной ролевой модели: время на митигирование, резолвинг, количество повторений и время реакций.
Программный комитет ещё не принял решения по этому докладу
Декларативное партиционирование PostgreSQL
Наш опыт перехода на использование декларативного партиционирования для хранения данных, преимущества и ограничения использования.
Программный комитет ещё не принял решения по этому докладу
В погоне за девятками, как достичь и не споткнуться
Для корпоративных систем телекома и не только требуется высокая доступность с неизменным качеством.
В докладе говорится о том, как в сервисах МТС применяются практики SRE, проводится параллель с практиками в Google, основываясь на Google SRE book.
Автор является CTO одной из высоконагруженных телекомовских платформ с повышенными требованиями к скорости и надежности, где четко определен SLO и существуют обязательства перед потребителями. На примере данной системы в докладе развивается мысль чем и как обосновывается достижимость SLO по доступности в 3,5 девятки. Приводится пример того, какие потребуются мероприятия и какими станут трудозатраты, если потребуется повысить доступность до 4 девяток и если более. Как это повлияет на архитектуру, инфраструктуру и команду эксплуатации. И почему подавляющему большинству сервисов в реальности не потребуется более высокого процента доступности чем 99.95.
Программный комитет ещё не принял решения по этому докладу
Системное и сетевое администрирование (7)
Cilium Cluster Mesh уже можно?
Давайте посмотрим на относительно новый компонент Cilium - Cluster Mesh.
Рассмотрим его архитектуру, построим и сломаем межкластерную связь, а также погоняем бенчмарки и попробуем ответить на вопрос: "Готов ли Cluster Mesh для прода?".
Программный комитет ещё не принял решения по этому докладу
Много пользователей и ansible inventory: Управление 15 000+ инстансами баз данных
Бизнес растет, с ним растет число проектов, и вот мы получаем ситуацию, когда нужно организовать эффективное управление 15 000+ инстансами баз данных для более 100 инженеров проектов. Столкнувшись с такой необходимостью, наша инфраструктурная команда реализовала многопользовательский подход к ansible inventory, и настройка и обслуживание кластеров баз данных значительно упростились.
В докладе поговорим о структуре multi tenant ansible inventory, инструментах автоматизации (генерация переменных, применение изменений), интеграции с GitLab CI. Также рассмотрим подходы к уменьшению когнитивной нагрузки на инженеров, работающих с кластерами баз данных.
Программный комитет ещё не принял решения по этому докладу
Puppet Bolt: оркестрация в экосистеме Puppet (и не только)
В этом докладе (похоже, что впервые на русском языке) мы поговорим о Puppet Bolt - системе оркестрации из экосистемы Puppet, но достаточно универсальной, чтобы использоваться и вне её. В первой части доклада будет дано краткое введение в Puppet Bolt. Во второй части будет представлено несколько примеров использования — как обычных, так и весьма нестандартных.
Доклад принят в программу конференции
Как обслуживать тысячи похожих проектов nginx динамически
У вас есть продакшн в едином экземпляре, все работает, но в dev среде есть разработчики, которым нужно каждому подготовить свою среду. Расскажу как устроен upstream в nginx и как готовить динамически готовить шаблоанные конфигурации.
Программный комитет ещё не принял решения по этому докладу
Как устроен CDN RUTUBE: железо, сеть, ПО
Сеть доставки контента RUTUBE — это 250+ железных сёрверов, расположенных по всей стране и даже ближнему зарубежью, сети операторов, много nginx и самописное ПО, которое всем этим управляет.
Данная сеть раздаёт 5 тбит/с данных не только для национального видеохостинга RUTUBE с 65 млн пользователей в месяц, но и для некоторых других цифровых активов Газпром-Медиа Холдинга.
Поговорим о том, как устроен CDN RUTUBE с инженерной точки зрения: аппаратной, сетевой и программной.
Программный комитет ещё не принял решения по этому докладу
1С это не только бухгалтерия и зарплата... Как мы ухаживаем за базой размеров 40ТБ...
Многие слышали о 1С.
Но что вы знаете о программных продуктах 1С?
Уверен первое что всплывает в головах, что 1С - это бухгалтерия, зарплата - сервак на базе i5, 10-15 пользователей...
Но это далеко не так.
В нашей конфигурации 1с работают тысячи пользователей, наша база занимает почти 40Гб пространства, это одна из самых крупных баз 1с в России, а может и в мире(кто знает=))
И в своей работе мы используем не только штатные средства 1С, но и многое многое другое...
Если интересно, приходите я расскажу много интересного!
Программный комитет ещё не принял решения по этому докладу
Netbox - точка истинности или стейт
Netbox - точка истинности или стейт
Что выбрать в качестве источника правды об инфраструктуре? А если инфраструктур несколько? А еще у нас несколько разных гит и разные подходы по формированию гит репозиторием где необходимо использовать знания об инфраструктуре - тут оставлю вопрос открытым. У нас netbox и все :) анализ и выбор это отдельная тема. Оставлю на ваше самостоятельное исследование.
Netbox как инструмент по хранению знаний про железную часть инфраструктуры и про виртуальную часть. ИП адреса, кабели, серверы, стойки и прочее. Сразу есть API по работе со всем этим.
Дает ли внедрение ощущение спокойствия и точки истинности?
Система по хранению информации - Netbox
Синхронизация информации из реальной инфраструктуры в Netbox и уведомление о не соответствии.
Процесс работы с инфраструктурой - нет в Netbox нет в инфраструктуре. Создаем объект в Netbox и на основе данных из netbox создаем реальный объект инфраструктуры
Netbox дает информацию начиная с групп серверов. Выше уже другая система, Backstage - информация о продуктах, информационных системах и на каких они группах серверов работают
Какие проблемы сейчас решаем в использовании Netbox в нашей инфраструктуре
- Облако и невозможность использования ansible для создания и управления конфигурацией ВМ. Как подружить terraform и получение данных о ВМ из Netbox, да еще Netbox практически «стейт»
- Многие продукты инфраструктуры хотят в Netbox хранить свои переменные, но в Netbox нет нормальное ролевой модели
- Netbox и масштабирование нагрузки на него
Доклад принят в программу конференции
Наблюдаемость и Operational intelligence (8)
Prometheus. Что есть реальность?
Как и в фильме «Матрица», реальность не всегда такова, какой кажется. Данные систем мониторинга могут создавать миражи, которым мы доверяем без лишних сомнений. В докладе рассмотрим, что на самом деле скрывается за графиками и как не поддаться «иллюзиям», которые они могут создавать.
В первой части обсудим, почему визуализированные метрики могут дать искажённое представление о реальности. Как и в «Матрице», данные — это не объективная истина, а интерпретация, которая зависит от множества факторов. Наш анализ покажет, что проблема "ложныхметрик" — не в технической ошибке, а в особенностях их представления и восприятия.
Затем мы погрузимся глубже — в архитектурные особенности систем мониторинга на примере Prometheus. Как и Нео, который осознал, что мир «Матрицы» — это симуляция, мы разберёмся, как происходит чтение в Prometheus.
В заключении поговорим о том, как «проснуться» и начать воспринимать метрики систем мониторинга правильно. А также разберём особенности, которые надо учитывать, чтобы не попадать в ловушки ложного восприятия.
Программный комитет ещё не принял решения по этому докладу
Как собирать 1 млн логов в секунду через vector, хранить и быстро искать в clickhouse.
В каждой компании есть необходимость выстроить систему observability. В своём докладе расскажу, как эволюционировал пайплайн сбора и хранения логов. От ElasticSearch к файлам на дисках и к clickhouse.
О том, как мы перестраивали нашу архитектуру под большее количество данных. Много ли сейчас у нас данных? Имеем на входе 24к RPS, 1 миллион спанов в сек., 5к инстансов сервисов. Рассмотрим особенности таблиц с логами в clickhouse.
Также затронем долговременное хранение в hadoop
Программный комитет ещё не принял решения по этому докладу
Распределенный трейсинг Opentelemetry и Grafana Tempo
Проблемы, которые решает трейсинг
Почему OpenTelemetry
Архитектура решения
Проблемы реализации и их решения
Опыт использования
Дальнейшее развитие
Программный комитет ещё не принял решения по этому докладу
От Billing к Capacity Management в Kubernetes
Доклад посвящен переходу от Billing к Capacity Management в сложной инфраструктуре Kubernetes.
Я расскажу, как мы в условиях многокластерной архитектуры и множества команд внедрили прозрачные процессы учета ресурсов, оценки их использования и нахождения точек для оптимизации.
Доклад затронет текущие вызовы, подходы к решению сложностей подсчета ресурсов и примеры внедрения инструментов для анализа и прогнозирования потребностей.
Программный комитет ещё не принял решения по этому докладу
Мониторинг и SLA на фронтенде: где брать метрики, когда их не хватает и как не высасывать из пальца SLI
Расскажу о метриках доступности: что мы меряем на фронтенде.
Основная проблема мониторинга фронтенда: большая часть кода фронта выполняется на клиенте. Но у нас есть еще и SSR.
Расскажу о том как окутывали метркиами фронт: вначале SSR, потом статика, затем пользовательские метрики.
Расскажу как мониторим раздачу статики с помощью Openresty
Что делаем для мониторинга клиентских метрик и как учитываем их при вычислении SLO
По каким критериям выбирали метрики доступности
Программный комитет ещё не принял решения по этому докладу
Яркий мир Mimira (Централизованное хранилище метрик на базе Grafana Mimir)
1. Цели и задачи внедрения сервиса
2. Что такое Mimir
3. Параллельные решения
4. Почему мы выбрали Mimir
5. Особенности развертывания и тестирование
6. Опыт использования Mimir
7. Дальнейшее развитие
Программный комитет ещё не принял решения по этому докладу
Мониторинг конечных пользователей: RUM на примере сети CDN
Задачи мониторинга лежат в фундаменте DevOps, и хорошо налаженная система, которая решает их на своей инфраструктуре – предмет гордости для любого инженера. Но нередко бывает так, что все лампочки у своих инфраструктурных компонентов светятся зеленым, а интернет-юзеры сообщают о проблемах доступа к сервису… Сбои во внешних системах, сетевые аномалии и некорректно работающий фронтенд можно отследить только расположенными снаружи инфраструктуры глазами. А кто может дать более точную информацию, чем сами страдающие пользователи? О том, как получать, хранить и анализировать метрики “с того конца”, поговорим в этом докладе, с CDN-сетью в качестве наглядного примера.
Программный комитет ещё не принял решения по этому докладу
Sasl-авторизация на большом кластере Kafka: решение проблем перфоманса и обсервабилити
Отвечу на вопросы:
- Как мы включали авторизацию на кластере, переваривающем 17млн сообщений в секунду
- Strimzi провайдер — продакшен-решение без логов
- Как разделение авторизации и аутентификации позволило запуститься на полгода раньше
- Проблемы со стороны клиентов — как расследовать
- Как потери единичных пакетов дестабилизируют всю систему и что с этим делать
- Как организовать переход нескольких тысяч микросервисов на четырех языках на походы в кафку с авторизацией
Программный комитет ещё не принял решения по этому докладу
Cloud Native Engineering (5)
Между молотом и наковальней: как остаться в Zabbix, когда у тебя тысячи метрик, а с тебя требуют переезд в Prometheus
Представьте, в вашей компании есть сложившиеся система мониторинга Zabbix в нескольких контурах на 3,5+ тысячи хостов, которая отлично зарекомендовала себя и работает более 15 лет. За это время агенты научились не только мониторить железо, но и имеют несколько тысяч различных специфических скриптов к разношерстным БД и приложениям. В один прекрасный день приходит задача: необходимо отдавать часть метрик в головную компанию в систему Prometheus. Значит, несмотря на тысячи метрик в Zabbix настало время переезжать на новую систему мониторинга. Или нет?
В докладе расскажу о том, каким образом была решена задача передачи метрик между двумя системами мониторинга так, чтобы и Руководство, и команда мониторинга остались довольны.
Доклад будет полезен практикующим DevOps/SRE-инженерам, инженерам команд мониторинга и всем, кто сталкивался или может столкнуться в своей работе с задачей передачи данных между разными системами мониторинга.
Программный комитет ещё не принял решения по этому докладу
DIY Kubernetes, Почему вам будет недостаточно пяти бинарей
В докладе разберём, каким требованиям должны соответствовать современные приложения и средства оркестрации и каков «джентльменский набор» для удобной работы с Kubernetes. А ещё на конкретных примерах рассмотрим, какие трудности и проблемы возникают при поддержке собственного решения на базе Kubernetes.
Программный комитет ещё не принял решения по этому докладу
Canary deploy. Выбор для production.
- виды деплоев и чем канарейка лучше
- сравним инструменты для канарейки
- рассмотрим интеграцию с базами метрик и алертинг
- пример настройки
- какие могут возникнуть проблемы и как их решить
Программный комитет ещё не принял решения по этому докладу
Kubernetes as a Service: путь взросления сервиса в облаке
Этот доклад будет интересен всем, кто работает с Kubernetes в облаке или только планирует его внедрение. Расскажу, как мы создавали Kubernetes-as-a-service в Облаке К2: с какими трудностями столкнулись, как справлялись и что в итоге получили.
Также обсудим какие фичи Kubernetes действительно важны для облака, а без каких можно обойтись на первых порах. И немного поделюсь, как у нас это устроено "под капотом".
Программный комитет ещё не принял решения по этому докладу
OpenSearch {vs,+} PostgreSQL: как БД помогает в измерении инженерной культуры
Расскажем, как строили Pulsar-Analytics - систему для анализа пользовательских ответов.
Её сердце - OpenSearch, который мы используем не для хранения логов, а как базу данных с широкими возможностями для аналитики.
Мы выбирали между OpenSearch и PostgreSQL, и в итоге решили - почему бы не использовать оба?
Ответы мы храним в PostgreSQL и автоматически копируем в OpenSearch, который (о боже) представляет собой один pod в k8s.
Надёжно как швейцарские часы!
Бонусом расскажем про то, зачем всё это нам, как эта связка помогает измерять инженерную культуру.
Программный комитет ещё не принял решения по этому докладу
DevOps практики и культура (51)
Как десятикратно разогнать скорость поставки в большом Enterprise
Расскажем, как превратить общебанковский платформенный деплой за 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).
Программный комитет ещё не принял решения по этому докладу
Devcontainers 2025 - уже можно!
Инфраструктура как код, для локальной разработки. Сегодня это уже норма. Devcontainer помогут решить нам целый класс проблем, а именно:
– Уравнивание окружения между всеми разработчиками через докер (общий знаменатель) – больше никаких cmd-скриптов рядом с sh. А также можно работать с любых девайсов и любых операционных систем, и даже аппаратных платформ.
– Онбординг одной кнопкой – вместо недель настройки окружения для разработки каждым новым разработчиком, всё можно настроить одним человеком и лишь один раз, а работать будет у всех и всегда. Все, что вам нужно – это ide с поддержкой девконтейнеров и докер.
– Поддержание актуальности инфраструктуры рабочей среды одним человеком. Один разработчик теперь описывает актуальное состояние всей инфраструктуры, и у всех, кто перейдет на его коммит, будет ровно такая же инфраструктура. До последнего байта. И никаких поисков багов между двумя разработчиками, из за разных версий ЯП.
В докладе мы посмотрим, как с нуля развернуть ваш репозиторий в девконтейнер, пройдемся по деталям устройства инфраструктуры таких контейнеров, изучим работу нескольких контейнеров для организации всех необходимых в разработке инструментов (базы, очереди, кеши).
Поделимся собственными болями, на которые наткнулись, и как их решили. И обсудим работу с разными аппаратными архитектурами. Оценим производительность разработки в контейнере и без него, на примере крупного опенсорс проекта. В конце посмотрим на перспективы использования девконейтейнеров в вашей организации, для построения платформенных решений, и вопросов, связанных с безопасностью.
Программный комитет ещё не принял решения по этому докладу
Монолит в Kubernetes (GCE в GKE). Переезд огромного проекта (1млн строк, 5 лет разработки на PHP) в Google Kubernetes Engine.
1. Вам нравится гибкость облачных ресурсов, но ваше приложение никогда не создавалось под идеологию контейнеров и k8s, и вы решили туда ехать.
2. Идея часто умирающих контейнеров и отсутствие локального состояния поначалу может сбить с ног.
3. Если изначально приложение не писалось под кубы, и уже очень большое, то вас впереди ждёт много проблем.
4. Но после переезда, будет прекрасно: эластичность ресурсов, динамические окружения, canary releases.
Программный комитет ещё не принял решения по этому докладу
Управление множеством конфигураций с помощью helmfile
способ формирования helm chart параметров в зависимости от окружения
работа с группами окружения
пакетный подход к установке helm chart в k8s
Программный комитет ещё не принял решения по этому докладу
Как перейти от отсутствия процессов в разработке и деплое сервисов к их полной автоматизации. Опыт ВКонтакте
Отсутствие процессов в разработке новых сервисов ВКонтакте приводило к долгому и сложному созданию проектов через copy-paste. Не было подходящего окружения, нужно было ставить ~5-10 тасок в Jira, а деплой в облако занимал почти месяц. И не всегда после деплоя можно было понять все ли хорошо, т.к. сервисы были черными ящиками. Поэтому мы организовали собственную платформу ВКонтакте и набор инструментов, которые позволяют инженерам забыть про boilerplate code и не думать, куда ставить нужные таски.
В докладе расскажу, какие шаги мы предприняли для этого и на что стоит обратить внимание.
Программный комитет ещё не принял решения по этому докладу
Как выбрать правильный язык для DevOps задач: от скриптов к инженерным решениям
Современный DevOps – это уже не просто написание скриптов автоматизации, а создание надёжных инженерных решений. На что опираться при выборе языка программирования для своих задач? В этом докладе мы посмотрим на DevOps через призму разработки: сравним Python, Go и Bash в реальных сценариях, разберем метрики производительности и сопровождаемости кода. Вы увидите, как меняется подход к решению типичных задач при использовании разных языков, и научитесь выбирать инструмент, который даст максимальную эффективность именно в вашем случае. Никакой воды – только конкретные примеры, бенчмарки и рекомендации, основанные на реальном опыте.
Программный комитет ещё не принял решения по этому докладу
CUEрьезная генерация YAML-шаблонов: как структурировать работу с манифестами K8s
В современной динамичной и конкурентной бизнес-среде сложно представить себе архитектуру IT-компании без использования K8s-кластера. Задействовав данную технологию, разработчики ежедневно сталкиваются с форматом YAML, который всячески усложняет и замедляет процесс разработки. Количество манифестов растет и появляется необходимость автоматизировать работу с шаблонами.
Но какой инструмент позволит работать с YAML как с кодом и позволит выйти за рамки обычной шаблонизации?
Именно CUE — технология, которая позволяет выстроить процесс работы с форматом YAML максимально безболезненно для инженеров. Расскажу подробно, в каких случаях CUE — самый подходящий инструмент и как выстроить правильную структуру репозитория при работе с большим проектом.
CUE реализует простой подход работы с YAML как с кодом, а при интеграции с Golang вполне легко можно создать свой инструмент, позволяющий обеспечить не только работу с шаблонами K8s, но и автоматизировать валидацию, генерацию YAML и его дальнейшую поставку на кластер с учетом всех особенностей архитектуры и текущих версий релизов на кластере. На примере организации структуры репозитория расскажу про важность согласованности локального и удаленного хранилищ, создав которую, можно автоматизировать многие промышленные процессы с помощью CUElang.
Программный комитет ещё не принял решения по этому докладу
Хороший пример как делать не надо или как DevOps культура спасла бы большой проект
Картина:
- Ручная доставка изменений
- Команда 40+ разработчиков
- 4 связанных системы в доработке.
- Большой объем интеграций
- Два релиза в параллельной разработке без гита (с альтернативной системой хранения версий)
- Ручное тестирование
- Тестирование на пользователях
Что из этого вышло:
- Пилот на не готовой системе
- Срывы сроков
- Низкое качество разработки
Что надо было изменить:
- Ретро
- GIT
- Sonar
- Smoke
Программный комитет ещё не принял решения по этому докладу
CI/CD для Python приложений: от версионирования до миграций
В современном мире разработки ПО системы CI/CD играют ключевую роль в обеспечении качества, надежности и скорости релизов. На основе реального примера пайплайна для Python приложений я расскажу:
Архитектура пайплайна:
- Структура и ключевые этапы: подготовка, тестирование, миграции, сборка и деплой.
- Управление версиями и хранилищами образов, подходы к публикации сборок.
Оптимизация использования кэша:
- Эффективное использование poetry.lock для кэширования окружения помогает сократить время на установку зависимостей.
- Генерация уникального ключа для кэша и ускорения сборок
Миграции базы данных:
- Как организовать автоматизированный процесс создания и отката миграций.
Тестирование и покрытие кода:
- Использование pytest и Allure для контроля качества на каждом этапе.
- Автоматическое управление отчетами Allure через настройки пайплайна
Особенности релиза и деплоя:
- Как разделять окружения (test, preview, production) и эффективно использовать Kubernetes.
Динамическое управление ревьюерами:
- Автоматическая привязка ревьюеров на основе группы и списка для ускорения code review
Комплексное управление артефактами:
- Чистка артефактов на основе регулярных выражений и ограничения количества
- Разделение артефактов для миграций и основной сборки
Результаты: Участники узнают, как построить CI/CD-процесс с учетом особенностей Python приложений, включая безопасность, миграции и многоэтапное тестирование.
Программный комитет ещё не принял решения по этому докладу
Как мы пришли к развертыванию Kubernetes-кластеров собственным оператором
Ручной труд сделал из обезьяны человека, а из человека девопса.
Сказ о том, как мы от ручного развертывания кластеров пришли к полной автоматизации.
Программный комитет ещё не принял решения по этому докладу
Мастер-класс "sso через кейклок для инфраструктурных сервисов"
любая инфраструктура включает в себя множество инфраструктурных сервисов, например, графана, прометеус, гитлаб, докер режистри
каждый сервис требует аутентификации и авторизации
в идеале это стоит централизовать
одним из самых популярных сервисов является кейклок
цель данного воркшопа на базовых примерах показать настройку OIDC коннектора для инфраструктурных сервисов через кейклок
разберем основные сущности в кейклок - realms, clients, client scopes, users, roles, groups
разберем аутентификацию в графане через кейклок
Доклад принят в программу конференции
Почему Puppet?
Puppet остается одним из основных инструментов подхода IAC. Информации о нем в русскоязычном Интернете продолжает недоставать. Мой доклад призван восполнить некоторые пробелы, дать как вводную информацию, так и погрузиться на глубину. На примере Авито мы рассмотрим особенности администрирования инфраструктуры и обсудим наши собственные инструменты для оптимизации работы с Puppet. Доклад хорошо иллюстрирует, что не всегда важно какой инструмент вы выбираете, а как вы адаптируете его под свои нужды.
Доклад принят в программу конференции
Автоматизация развертывания OpenStack с помощью GitLab CI/CD и Terraform
- Введение в автоматизацию инфраструктуры: обзор основных инструментов и подходов.
- Использование 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 образ через все окружения и при этом сократить количество сборок.
Расскажем про то, как мы решали проблему целостности собираемых docker-образов для stage и prod окружений, когда они собираются и деплоятся независимо друг от друга. Ведь когда сборка происходит независимо, есть вероятность того, что для stage и prod будут собраны разные образы с разными системными зависимостями.
Разработали механизм вычисления хеша репозитория и использования его для поиска и переиспользования уже существующего артефакта, аналогично тому как это делает сам docker. Как итог получили не только защиту от ошибок на prod, но и значительно уменьшили количество сборок в случаях, когда в репозитории менялись файлы, не важные для сборки.
Программный комитет ещё не принял решения по этому докладу
Ускоряем сборку фронтенда в 100 раз
Всем привет!
Я из команды Атома и мы делаем очень крутой отечественный электро мобиль.
Мы как и многие из вас используем девопс практики, у нас есть CICD и мы работаем с TS/JS
Вещи о которых я хочу поговорить существуют на проектах любого обьема и сложности.
Мой доклад ответит на следующие вопросы:
1. Из чего состоит пайплайн проекта на JS/TS?
2. Как мониторить CI/CD?
2. На что уходит время CI/CD?
3. Что можно с этим сделать?
4. Какие есть инструменты до ускорения CI/CD
5. Как их можно применить?
6. Какой прирост получаем? В 2, 10, 100, 120 раз? Смотря как считать.
7. Можно ли применить этот опыт для другого стека?
8. Выводы
Программный комитет ещё не принял решения по этому докладу
DevOps на грани: управление сотнями сервисов и эффективное взаимодействие с разработчиками
ВКонтакте работают тысячи разработчиков, количество сервисов внутри — приближается к тысяче. Как эффективно управлять таким количеством сервисов и дружить с разработчиками при ограниченных ресурсах команды?
Расскажу, как мы внедряли CI/CD для ускорения и упрощения развёртывания, какие инструменты и практики использовали для команд.
Будет полезно тем, кто хочет ответить на вопрос, достаточно ли автоматизировать процессы DevOps для решения этой проблемы.
Программный комитет ещё не принял решения по этому докладу
Continuous Delivery + Статический анализ = Успех
- Что такое Continuous Delivery и почему это круто?
- По кирпичикам: из чего состоит Continuous Delivery пайплайн?
- Зачем нужен статический анализ?
- Чем статический анализ поможет в обеспечении непрерывной доставки?
- Как интегрировать статический анализ? Решение проблем как для DevOps, так и для разработки
- Реальные примеры интеграции статического анализа в пайплайн
Программный комитет ещё не принял решения по этому докладу
Что мы проверяем в Исследовании Состояния DevOps в России
Расскажу как выбираются темы и практики для исследования. Почему мы их считаем важными.
Программный комитет ещё не принял решения по этому докладу
Kubernetes кругосветка: история создания отчуждаемой инфраструктуры k8s и ее поддержки
Описание личного опыта реализации процесса по созданию и поддержки инфраструктуры k8s различных уголках мира.
В своем докладе подробно раскрою темы
- Выбора единой OS для Kubernetes для разных типов установки
- Анализ и типы развертывания которые пришлось реализовать в примерах
- Смена парадигмы с GitOps на OCIOps
- Вся правда о fluxcd
- организация проекта
- поэтапной процесс тестирования и деплоя в разрезе региона/зоны/типа кластера (с примерами и визуализацией)
- организация процесса за ошибками
- Как реализовать поддержку кластера и баз данных если к нему нет прямого доступа через агенты
- Как обеспечить декларативное обновление ваших кластеров k8s
Программный комитет ещё не принял решения по этому докладу
Качественно хранить артефакты - это не просто
- В 2022 году с рынка хранилищ артефактов РФ ушли два ключевых игрока
- Мы, как и все, постарались исследовать возможность создать такое хранилище на OpenSource Nexus
- Поймали кучу граблей связанных с производительностю Nexusa и поняли, что их никак не обойти. Он вообще очень плохо подходит для больших команд, которые генерируют большую нагрузку
- Разобрались с лицензированием Nexus и поняли, что в РФ им не получится воспользоваться
- Поняли, что современное хранилище должно еще и безопасно хранить артефакты
- Приняли решение сделать свое хранилище с нуля на зарекомендовавших себя технологиях
- Релизовали хранилище артефактов, которое спобно работать в высоконагруженных системах
-Сделали это хранилище безопасным
Программный комитет ещё не принял решения по этому докладу
Мастер-класс "ArgoCD: Push me, Pull me, Deploy me! - Developer’s satisfaction!"
Доклад посвящен популярному 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 под экстремальными нагрузками трещит по швам, но держится отлично - как не сломать облачного провайдера, постоянно повышая прибыльность проекта
Расскажем реальную историю запуска и развития международного высоконагруженного проекта на базе управляемого 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ов эффективно в IBS
Как правильно развивать DevOps инженеров в условиях постоянных изменений на рынке? Как повысить лояльность сотрудников? Как отмечать рост сотрудников и правильно их поощрять? Ставим цели на аттестациях для сотрудников правильно.
Программный комитет ещё не принял решения по этому докладу
Как мы автоматизировали и ускорили выкатки релизов API Почты в 20 раз
Высокий ТТМ, долгие сборки, много ручной работы, несколько параллельно живущих staging-окружений, непредсказуемость
времени выкатки – всё это влияло на частоту и скорость наших релизов.
В этом докладе я хочу рассказать про наш опыт ускорения релизов и стандартизации этого процесса в сервисах Mail.ru и
поделиться подходами и инструментами, которые практически каждый сможет внедрить в собственные проекты.
– Почему мы за это взялись
– Как правильно организовать выкатки? Какие есть подходы и что выбрали мы
– Как устроен пайплайн: сборки образов, мерж веток, джобы, механизм раскатки, виды апрувов и другое
– Как мы следим за пайплайном: графики, алерты и нотификации
– Особенности организации пайплайнов в GitLab CI
– Результаты, которых мы достигли, и ближайшие планы по развитию
– Как внедрить себе
Доклад принят в программу конференции
Workshop: Разработка инженерных практик в крупных компаниях!
Воркшоп: Разработка инженерных практик для крупных компаний
Приглашаем принять участие в воркшопе, посвящённом созданию и внедрению инженерных практик в крупных организациях.
Что вас ждет:
- Обсуждение лучших практик: Узнаем, как глобальные компании адаптируют и внедряют современные подходы к разработке и эксплуатации (CI/CD, DevOps, SSDLC, API-first, cloud-native).
- Инструменты и процессы: Разберём ключевые инструменты автоматизации, мониторинга и их интеграцию в ежедневные рабочие процессы.
- DORA метрики и RED подход: Погрузимся в метрики производительности команд разработки и эксплуатации для достижения высоких бизнес-результатов.
- Практическая часть: Совместная разработка методологии внедрения практик в масштабах компании. Создадим план действий для выстраивания инженерной культуры и повышения зрелости процессов.
- Реальные кейсы: Изучим примеры компаний, успешно реализовавших переход к продвинутым инженерным практикам, и разберём их на конкретных примерах.
Для кого этот воркшоп:
- Руководители технических команд
- DevOps инженеры
- Технические лидеры и архитекторы
- Инженеры по качеству и безопасности
Результат:
После воркшопа участники смогут применить полученные знания для выстраивания инженерных практик, улучшения процессов разработки и эксплуатации, а также повысить уровень автоматизации и гибкости своих команд.
Программный комитет ещё не принял решения по этому докладу
DRP для динамического ландшафта финтеха - опыт Т-Банка
Как свести к минимуму негативное влияние возможных аварий на работу крупного финтеха?
Как построить процесс подготовки и поддержки актуальных планов DR для динамических ландшафтов?
Расскажем наш подход:
- итеративное создание DRP - от частных планов систем к общему плану бизнес-услуги
- чеклист анализа системы и создание плана восстановления
- ключевое - восстановление основной функциональности, точка готовности системы
- общий план восстановления бизнес-услуги и работа с зависимостями
- планы требуют учений (бумажных и реальных)
- изменяем архитектуру систем / услуг
- доопределяем риски, их источники и признаки их реализации
- выравниваемся с требованиями регуляторов
- услуги и системы динамически изменяются - внедряем гигиену SRE команд по поддержке планов в актуальном состоянии
Доклад принят в программу конференции
Адаптация CI: как мы справляемся с ростом функционала KasperskyOS for Mobile
KasperskyOS for Mobile постоянно развивается и эволюционирует, стремясь к новой вехе - универсальной модульной мобильной платформе, функционал которой может быть расширен за счет доустановки компонентов из пакетов.
Такие преобразования непременно отражаются на всех процессах, особенно на процессе сборки. В докладе рассматриваются практические аспекты работы с CI когда функционал продукта растет и постоянно изменяется.
Программный комитет ещё не принял решения по этому докладу
Развертывание обезличенных баз данных
Представьте: вы разработчик, и вам нужно протестировать новую фичу. Но вместо чистого листа вы сталкиваетесь с тестовыми данными, которые похожи на настоящие, но не совсем. Проблемы с конфиденциальностью, производительностью и согласованностью данных – все это может свести на нет вашу работу.
Вот почему:
Важность тестовых сред, максимально приближенных к продакшену: Чем ближе тестовая среда к реальности, тем точнее результаты тестирования.
Проблемы использования реальных данных в тестовых средах: Конфиденциальность, производительность, согласованность – все это под вопросом при использовании реальных данных.
Что делать?
Обзор методов обезличивания данных:
Профилирование: определяем конфиденциальную информацию в базах-источниках
Маскирование: Скрываем конфиденциальную информацию, оставляя структуру данных неизменной.
Перемешивание: Меняем местами данные, чтобы нарушить связи между ними.
Синтетические данные: Создаем искусственные данные, максимально приближенные к реальным, если их нельзя подменить
Замена в тексте: Определяем и меняем данные прямо в большом тексте
Рекомендации по внедрению процесса обезличивания в DevOps-практики:
Начните с малого – выберите небольшой проект и попробуйте разные методы обезличивания.
Автоматизируйте процесс обезличивания, чтобы сэкономить время и силы
Работайте вместе с командой безопасности, чтобы обеспечить защиту данных, а мы расскажем как это делается
Программный комитет ещё не принял решения по этому докладу
Перевод CD процесса раскатки OpenStack облака с Ansible+Docker на Kubernetes+Helm+ArgoCD
Перевод 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 и коротких автотестов позволило интегрировать НТ в разработку даже на небольших проектах, ещё не вышедших в продакшен.
Комплексное нагрузочное тестирование помогает выявить «узкие места», такие как неразделённые ресурсы, влияние «шумных соседей» и недоработки в проектировании саг.
Смена майндсета:
Работать вместе с командой, а не по-отдельности.
Программный комитет ещё не принял решения по этому докладу
Infrastructure from Code. Следующий этап развития IaC.
Каждый высококлассный инженер, приходя в компанию, сталкивается с необходимостью освоить процесс поставки бизнес-ценности в продакшен. Хотя у многих он экранирован, но знание и понимание того, как управлять собственной инфраструктурой, бывают бесценны.
Методы управления инфраструктурой развиваются: от ручной конфигурации и bash-скриптов до подхода Infrastructure as Code (IaC), декларативного (Terraform) и библиотек описания инфраструктуры (AWS CDK, Pulumi, TFCDK). Однако сложность и объем инфраструктуры растут быстрее, чем появляются новые инструменты.
Относительно новая концепция Infrastructure from Code (IfC) создает инфраструктуру непосредственно из кода приложения, интегрируясь с ним или анализируя его для автоматического определения инфраструктуры.
В докладе мы пройдем сложный путь становления инструментов управления инфраструктурой. От обычных скриптов до IfC. И разберемся, что такое относительно новый IfC, его преимущества и недостатки, отличия от IaC и его дополнения.
Доклад принят в программу конференции
Скаллируем раннеры с Nomad
Что если нам нужно билдить, а раннер занят, что если ждать не выход? Нужно начать оркестрацию раннеров? А можно и сделать что-то похожее. Если у нас не хватает ресурсов на поддержание K8S кластера для автоскаллирования раннеров, то нам на помощь может прийти небольшой Nomad. Рассмотрим как же экономно скаллировать раннеры без особого вреда для ресурсов нашей инфраструктуры. В каких случаях это полезно, а в каких лучше не прибегать к такому решению. Рассмотрим то, что нужно сделать, чего стоит избежать и на чём особенно заострить внимание. В итоге, скаллируем раннеры при помощи Nomad, практически в авто режиме.
Программный комитет ещё не принял решения по этому докладу
Вы знали, что в Jenkins можно делать собственные интерфейсы? И при чём тут JavaScript и GROOVY
Интерфейсы нового уровня: как создать визуально привлекательные и удобные интерфейсы в Jenkins, которые заменят старые, сложные системы.
Минимум действий от пользователя: никакой путаницы или инструкций — пользователю нужно лишь нажимать кнопки, всё остальное происходит автоматически.
Красота и автоматизация в одном флаконе: интеграция с Git, автоматическое подтягивание данных и полное отсутствие ручного ввода, что упрощает и ускоряет работу.
Безопасность прежде всего: расскажу, как сделать платформы не только удобными, но и защищёнными, чтобы минимизировать риски.
Удобная разработка без шишек: я покажу, как организовать процесс разработки этих платформ так, чтобы избежать проблем, на которых я уже сам учился.
Обучение и поддержка: научу вас, как воплотить всё это в жизнь — от создания красивого интерфейса до безопасного и удобного рабочего процесса.
Программный комитет ещё не принял решения по этому докладу
ТОП неочевидных проблем при внедрении Kubernetes платформы в Large Enterprise
- Какие основные проблемы тормозят развитие кубов в крупных компаниях
- Какие ограничения всплывают в реализованных кубах
- Куда еще смотреть, если решили разрабатывать свое решение
Программный комитет ещё не принял решения по этому докладу
FluxCD и True GitOps: методические рекоммендации и обзор инструментов
Методическая секция
- Обзор подхода GitOps, основные отличия от привычной Push-модели деплоя
- Преимущества и недостатки GitOps. Почему подойдет не всем?
- GitOps, TBD и Feature Toggles. Деплой и релиз больше не единое целое.
- Что лучше, автотесты или флаги?
Инструментальная секция
- Обзор инструментации GitOps: FluxCD, ArgoCD
- Флаги: варианты реализации, подводные камни
- Kustomize: обзорная экскурсия в кроличью нору
- Деплой без Helm: (вредные и не очень) советы
- Flux Image Automation: контроль за автодеплоем
Программный комитет ещё не принял решения по этому докладу
Автоматизированное создание стандартных сред: от Docker до Debian + kFreeBSD
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 team в ecom.tech
однажды мы заметили, что платформенные и стримовые команды тратят довольно много времени на выяснение потребностей заказчиков, а также на исследования способов решения проблем. при этом основная работа простаивает. так и пилотные запуски технологий силами платформенных команд отвлекают от основного вектора работ. чем больше становится техническая команда, тем больше возникает сложностей в том, чтобы сориентироваться в коммуникациях и процессах. помимо снятия когнитивной нагрузки с товарищей, команда enable занимается тем, чтобы наладить процессы взаимодействия с инфраструктурой.
Доклад принят в программу конференции
Как избежать "тестового ада" и сэкономить ресурсы с помощью умных стендов
Ситуация: вы разработчик, который хочет протестировать новую фичу, но интеграционный контур занят коллегами. Вы вынуждены ждать, и это замедляет работу. Плюс, когда наконец удается провести тест, что-то ломается из-за изменений других разработчиков.
В докладе мы разберем, как решить эту проблему с помощью личных стендов:
— про наш опыт создания автоматизированных стендов "по кнопке"
— как внедрить kyverno для автоматической очистки и поддержки стендов
— Разберем сложности реализации: создание интерфейса, пайплайнов, управление ресурсами
Программный комитет ещё не принял решения по этому докладу
Как мы упорядочили хаос логов с помощью модели OpenTelemetry, Vector.dev и Clickhouse: опыт, уроки и развитие за год
Работа с логами может быть удобной не только для разработчиков, но и для эксплуатации, нужно только договориться.
Представь: ты видишь как сервисов в компании становиться больше, команд больше, логов больше. И вот уже есть инженеры, которым нужно находить и понимать логи многих сервисов. Какие у нас варианты?
Дать волю. Все будет гибко и удобно для разработчиков, логи пишут как хотят, сами читают, знают где найти. Это до тех пор, пока разработчик не перешел в другую команду, или до тех пор, пока ночью дежурному не потребовалось искать логи совершенно новых для него сервисов. Затраты времени могут быть огромны.
Договориться об общих правилах. Да будет меньше свободы художникам, но для общего дела будет гораздо лучше. Вспомним про правила дорожного движения, ведь они есть и для пешеходов, и для водителей.
С логами тоже самое. Это помогает порядку и предсказуемости при функционировании сложной системы.
Я расскажу как в прошлом году мы реализовали унифицированную работу с логами с применением "готовых правил дорожного движения" из OpenTelemetry на базе Vector.dev и Clickhouse, какой опыт мы получили и как развили это решение.
Доклад принят в программу конференции
От меня хотят статьи в базу знаний, почему они ко мне пристали и зачем мне это?
Написать документацию - сложная задача? А ещё непонятно почему документ ждут именно от Вас? Да и вообще Вы не техпис и не аналитик, а от Вас ждут какие-то статьи в базе знаний? В докладе поговорим о том, почему инженеру важно участвовать в наполнении, верификации и актуализации базы знаний.
Программный комитет ещё не принял решения по этому докладу
От DevOps-инженеров к сервисным DevOps командам
В этом докладе расскажу про DevOps сообщество Сбера, посмотрим, что поменялось по сравнению с прошлыми моими выступлениями. Какие задачи сейчас решает сообщество. Кратко расскажу про реальное применение практик Platform Engineering, Internal Developer Portal и текущие вызовы в этих условиях для Operational Enabling Teams. Как обстоятельства повлияли на органичное изменение парадигмы и переход от подхода DevOps-инженер в каждой продуктовой команде к подходу сервисные DevOps команды в Трайбе. Как Operational Enabling Teams помогли сервисным DevOps командам. И традиционно по всем затронутым темам сделаю обзор граблей на которые мы наступили, какие надежды оправдались, и какие решения привели к серьезным вызовам.
Доклад принят в программу конференции
Как найти пользователей в платформе и что с ними делать
Доклад про особенности продуктового подхода и работу с пользователями. Если вы продуктовый менеджер, управляете платформой и тонете в бэклоге с непонятными проблемами - вам будет интересно послушать. Расскажу как выстроить основные процессы, как и о чем говорить с пользователями, на какие метрики смотреть и как сделать счастливыми людей с другой стороны вашего продукта.
Программный комитет ещё не принял решения по этому докладу
Грамотное распределение нагрузки внутри Kubernetes
На дворе 2025 год, Kubernetes есть практически у каждого, у некоторых у он есть даже в шкафу дома вместе с пет проектом.
Кажется мы стали забывать, что несмотря на то что Kubernetes умный, то как он распределяет нагрузку внутри кластера может совершенно не совпадать с нашими ожиданиями.
В рамках своего доклада я хочу рассказать:
-- о том как базово работает kubernetes scheduler
-- как работают и зачем нужны taints и tollerations
-- как работают affinity и antiaffinity rules
-- зачем нам pdb, pod topology constraints
-- и как все это можно комбинировать между собой
Большинство "приключений" с комбиначиями различным ограничений являются результатами постмортемов после инцидентов, которые позволили Магнит Омни стать более надежными.
Программный комитет ещё не принял решения по этому докладу
#Несколько_тем
CI как сервис, Gitlab как сервис для разных команд(от сети до бизнеса) Построение отказоустойчивого решения на основе бесплатной версии(успешно не полностью) и почему GitFlic для этого может не подойти # Обучение девопс инженеров, реальный опыт и почему иногда люди не хотят учиться
Программный комитет ещё не принял решения по этому докладу
Между небом и землей или как сидеть на облачном и железном стуле одновременно
Островок растёт семимильными шагами как в плане бизнеса, так и с точки зрения инфраструктуры. Начиналось всё с десятка серверов в одной стойке, а сейчас это свыше 500 серверов в нескольких локациях, поддерживаемые небольшой командой.
В докладе расскажу как мы попробовали облака и отказались от них. Как пережили ковид и бурный рост. Какими инструментами мы управляем всем нашим парком серверов, а также какие планы на будущее и почему всё-таки железо с примесью клауда
Программный комитет ещё не принял решения по этому докладу
Состояние инжиниринга в 2025 году
В прошлом выступлении про NextOps я показал куда движется DevOps как профессиональное движение и как будет решаться проблема взаимодействия между разработкой и эксплуатацией. В этот раз предлагаю детальнее погрузиться в инжиниринги, дать определение, рассмотреть отдельные направления инжиниринга, разобрать публикации, поискать лидеров и обсудить состояние на начало 2025 года.
Доклад принят в программу конференции
Герой нашего времени: проблема самоопределения и изменение ценности DevOps-инженера для компании
Тезисы:
1) В современном быстроизменяющемся мире понятие DevOps-инженера или специалиста всё чаще подвергается сомнению и критике - я постараюсь доказать, почему его актуальность не теряется: нужно лишь посмотреть на него под другим углом;
2) Расскажу, какими качествами и навыками должен обладать специалист DevOps, чтобы оставаться полезным и актуальным для современных компаний;
3) Приведу примеры рабочих задач и областей, в которых DevOps-инженер сможет принести наибольшую пользу, не уходя слишком далеко от обычного набора задач, присущих этой позиции.
Программный комитет ещё не принял решения по этому докладу
Канареечный деплой с ArgoCD и Argo Rollouts
Доклад посвящен организации канареечного деплоя при GitOps. Обсудим организацию GitOps-репозиториев, применение GitFlow, различные стратегии деплоя, интеграцию Argo Rollouts с ArgoCD и безопасное выполнение миграций.
Доклад будет полезен инженерам, работающим с Kubernetes
- Организация GitOps-репозиториев ArgoCD
- Flow CI/CD
- Стратегии деплоя
- Интеграция Argo Rollouts с АrgoCD
- Как подружить канарейку с миграциями
Программный комитет ещё не принял решения по этому докладу
Паттерны отказоустойчивости k8s или как сделать вашу on-permise инфраструктуру действительно надежной
Здесь мы ответим на вопрос, как же сделать ваш прод на k8s действительно надежным и не бояться ни за один из аспектов отказа приложения внутри него. Здесь мы разберем отказоучтойчивость в кубере на примере каждого из уровня. От приложения и его выкатки, до самого кластера и датацентра, в котором он находится, используя для этого понятные всем термины и определения.
Программный комитет ещё не принял решения по этому докладу
Platform Engineering (24)
WIP: Непрервыное автоматизированное отслеживание изменений в условиях agile
Автоматизация генерации release notes это хорошо, а можно ли лучше?
Осветим тему о том, как можно отследить какие изменения выезжают в прод добайтика.
По пути затронем DORA метрики и удобство работы программиста в условиях максимальной гибкости.
Программный комитет ещё не принял решения по этому докладу
Виртуальный класс или DevOps для образования
Что нужно, если ты хочешь учить людей техническим навыкам, например, разворачивать 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 в Сбере
Создать кластер Kubernetes – не самая сложная задача, но что делать, если их требуются тысячи?
Расскажу о том, как мы в Сбере пришли к идее создания Managed-сервиса и как это позволило не сойти с ума и справиться с обслуживанием огромного количества кластеров. Также разберёмся в ключевых особенностях и плюсах нашего решения и посмотрим на его возможности.
Доклад принят в программу конференции
Build or Buy: как CTO принять решение об аутсорсинге
Вопрос аутсорсинга технологии, сервиса или целой ИТ функции нередко является серьезным тактическим решением для CTO и требует комплексного подхода с учетом влияния на разные аспекты организации.
Мы рассмотрим несколько моделей, помогающих принять такое решение и учитывающих следующие аспекты:
1. Влияние решения на ключевые компетенции компании
2. Влияние бизнес-среды
3. Влияние ИТ компетенций компании
На основе этих 3х аспектов мы соберем матрицу принятия решения об аутсорсинге, учитывающую большинство рассмотренных факторов. Такая матрица может быть легко адаптирована под конкретную компанию и использована для быстрой оценки целесообразности аутсорсинга, а также в качестве чек-листа тем и вопросов для проработки в более сложных случаях.
Программный комитет ещё не принял решения по этому докладу
Как я перестал страдать и полюбил CoreDNS
Все мы пользуемся 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: практические аспекты быстрого и надежного инференса"
В этом докладе мы рассмотрим, как эффективно развернуть большие языковые модели (LLM) и Vision Transformers на локальных ресурсах. Вы узнаете о настройке моделей и серверной инфраструктуры, организации очередей запросов и применении структурированного декодинга для достижения высокой производительности и стабильности. Доклад предоставит практические рекомендации по созданию "Model as a Service", обеспечивающего быстрый, предсказуемый и надежный инференс.
Программный комитет ещё не принял решения по этому докладу
OPS – we did it again! And again… Как мы внедряли платформу обеспечения надежности
Кажется, что важность надежности продуктов – вещь очевидная. Ни один из владельцев продуктов не ставит цель по созданию продукта, который будет постоянно “падать”. Однако на деле оказывается, что для обеспечения надежности то времени не хватает, то компетенций. Чтобы решить эту проблему в МТС была создана платформа Operations или OpsPlatform. В докладе поделимся опытом создания платформы и как мы за пол года внедрили платформу во все MC/BC продукты экосистемы, какие эффекты получили, и что о нас думают крупнейшие продукты экосистемы.
Программный комитет ещё не принял решения по этому докладу
Автоматизация ресурсов для команд разработки: Практический опыт внедрения
- опыт разработки платформы автоматизации внутренних процессов с нуля
- зачем и почему - чтобы всем стало лучше и в том числе нам - а если серьезно - потому что у нас крутой внутренний мессенджер, в котором все крутится и все общаются
- бизнес и пользовательские сценарии - от управления учетными записями до создания кластеров виртуальных машин
- как, детали реализации, особенности архитектуры - message broker, EDA, аснихронные очереди и фронтенд на rocket chat app
- вызовы технические и процессные - опыт коммуникаций внутри команды, опыт взаимодействия с другими командами
Программный комитет ещё не принял решения по этому докладу
Fullstack Observability в Java приложениях: Путешествие от кода до кластера
В докладе рассмотрим как построить современную систему наблюдаемости от уровня кода до систем кластерного уровня, что и на каких этапах необходимо реализовывать. Тех стек в докладе будет Java, но полученные знания применить и реализовать вы сможете на любой системе которая у вас под рукой принципы те же. Так же рассмотрим различные принципы сбора телеметрии для систем, откуда и какие данные мы сможем достать без модификации приложения.
Доклад принят в программу конференции
Создание собственной платформы разработки и эксплуатации приложений на базе Kubernetes для международного промышленного холдинга
Собственные платформы на базе Kubernetes на сегодняшний день являются неотъемлемой частью не только технологических, но и производственных компаний. Из доклада вы узнаете об опыте создания и эволюции собственной платформы для безопасной разработки и эксплуатации ИТ решений в группе компаний ЕвроХим — крупном международном производителе минеральных удобрений.
В докладе будут раскрыты особенности применения cloud-native технологий в условиях ограничений корпоративной безопасности, рассмотрены допущенные ошибки проектирования взаимодействия команд разработки с платформой, аспекты обоснования экономических эффектов и планы по созданию возможностей для синергии.
Программный комитет ещё не принял решения по этому докладу
Как мы распилили коммунальный Airflow: натягиваем микросервисы на MLOps
Сейчас очень многие используют Airflow как продакшен-реди решение для оркестратора обучения ML-моделей. Все, что надо сделать пользователю - это скопировать свои даги в нужную папку. Но что делать, когда команд, использующих Airflow кластер, становится не 1, а 10, а дагов - не 100, а тысяча! В докладе расскажу, какие проблемы начинают выстреливать вместе с ростом масштаба и как их решать. Попробуем применить best practices микросервисной разработки для airflow-сервисов и превратить Airflow в удобный инструмент ML-платформы.
Программный комитет ещё не принял решения по этому докладу
Больше команд — больше Vault! Мы сделали это просто
Vault стал одним из самых популярных инструментов для хранения секретов и управления доступом к ним. Он надежно защищает данные и делает работу с ними простой и удобной, став де-факто стандартом в этой области.
С ростом инфраструктуры и увеличением числа команд и сотрудников возникает важный вопрос: как обеспечить всем удобный доступ к секретам, сохранив при этом безопасность, масштабируемость, отказоустойчивость и простоту в обслуживании?
В этом докладе я расскажу, как мы решили задачу удобного доступа к Vault для сотен команд, людей и тысяч приложений, сделав для каждой команды свой отдельный Vault и полностью автоматизировав этот процесс. Поделюсь, как мы создали масштабируемую, отказоустойчивую и простую в обслуживании систему, и расскажу об опыте и проблемах, с которыми пришлось столкнуться на нашем пути.
Программный комитет ещё не принял решения по этому докладу
А это платформа?
Чем дальше, тем больше мы говорим о платформах и платформенных командах. Где-то рядом с платформенными командами, в далёком космосе летает книга Team Topologies. На жестокой земле же, среди людей нам не до того: то тут, то там горит, разработчики тупят, тестировщики хотят странного, а безопасники закручивают очередную гайку. Отдел эксплуатации сидит за стеной из регламентов и отстреливается тикетами. В этой битве нет победителей, только выгоревшие. Но что если решение проблемы ближе, чем мы думаем?
В докладе расскажу как вывернуть инфраструктурный тулинг мехом наружу, перестать страдать, и понять что первые шаги к плаформе уже сделаны.
Доклад принят в программу конференции
GitOps для AirFlow. Как мы перешли на легковесный k8s-native Argo Workflow
Множество платформ по машинному обучению строятся на основе популярного инструмента AirFlow. Но действительно ли он так хорош или все-таки есть подводные камни?
В данном докладе я поделюсь тем, как мы решили отказаться от AirFlow и подобных ему инструментов по типу Dagster, в которых DAG/пайплайны пишутся на Python, в пользу ArgoWorkflow с написанием всего в yaml формате.
Мы поговорим о проблемах, которые возникают у достаточно большого числа команд при работе с AirFlow, в особенности при построении платформ по машинному обучению на базе Kubernetes.
Программный комитет ещё не принял решения по этому докладу
Dev To Dev платформа как продукт
Когда мир разочаровался в DevOps!
Когда зарплаты разработчиков улетели в космом!
Пришли они - платформы для разработчиков!
Что это за очередная менеджерская штука?! И когда это мир разочаровался в DevOps?!
Все просто! Мы хотим снять когнитивную нагрузку с разработчиков, убрать возможности кастомизации и позволить инженерам заниматься тем, что нравится больше всего - писать красивый и функциональный код!
Программный комитет ещё не принял решения по этому докладу
CI/CD в SourceCraft. Почему он такой, и кто в этом виноват
В мире CI/CD сейчас главенствует YAML. При разработки собственной dev платформы важна преемственность, поэтому мы так же выбрали YAML.
Но несмотря на внешнюю схожесть, наш вариант описания CI/CD задач отличается от существующих.
В докладе я расскажу о том, какие подходы использовали при реализации CI/CD в новой платформе для разработчиков от Яндекса SourceCraft, почему мы не взяли существующие форматы и какие плюсы мы при этом получили. А так же покажу, как наш CI/CD справляется с типичными сценариями построения пайплайнов.
Программный комитет ещё не принял решения по этому докладу
Облако в кубере, а кубер -- в облаке. Опыт self-hosting'а в Yandex Cloud.
Опыт Yandex Cloud'а в создании внутренней платформы. Сравнение использования самого YandexCloud'а и k8s для такой платформы. Польза и вред Self-Hosting'а, проблема бутстраппинга Self-hosted решений.
Программный комитет ещё не принял решения по этому докладу
Как построить современную ИТ-платформу с нуля — опыт Туту
Больше 6 лет назад я с небольшой командой из пяти инженеров начал строить ИТ-платформу в Туту. Мы создавали ИТ-платформу с нуля: у нас был гринфилд, картбланш на любые решения и большой кредит доверия от руководства компании. Интерес разработчиков компании к платформе был огромным: до этого архитектура была монолитной, а мы начали создавать новый мир Kubernetes для микросервисов с новыми инструментами, технологиями, процессами и практиками. В итоге у нас получилась современная и хорошо автоматизированная ИТ-платформа, которая обеспечивает всем необходимым разработку в Туту.
Из доклада вы узнаете, какие архитектурные и технические решения мы используем в нашей ИТ-платформе в масштабе 2000 продуктовых микросервисов, 600+ пайплайн-ранов в день в 5 baremetal-кластерах и 4 разных ЦОДах. В докладе так же затронем темы: почему мы используем Tekton для пайплайнов, какие решения кардинально улучшили DX и зачем нам оператор для проверки качества сервисов и проектов.
Вы узнаете, как сделать платформу, которая ускорит разработку и избавит от головной боли эксплуатацию.
Доклад принят в программу конференции
Маркетплейс сервисов компании
private cloud web service, visibility и переиспользование сервисов, ресурсное планирование
Программный комитет ещё не принял решения по этому докладу
Платформа R&D. Глава 2: Стандартизация и tooling
Создание "Платформы R&D", а для PT (Positive Technologies) это создание эффективной среды разработки, привело к потребности в инструментах – нужны инструменты управления доступами, ресурсами в инфраструктуре, сервисами и артефактами разработки. Начав наводить порядок, в процессах разработки большой компании, стало понятно в каких инструментах и стандартах существует самая высокая потребность и как их можно объединить в централизованное решение.
Этот доклад является продолжением предыдущей главы "Платформа R&D. Глава 1: Наводим порядок (https://devoops.ru/talks/85d87020eb2e4042a5e3c52c6977569f/)" и посвящен реализации единого интерфейса взаимодействия R&D с системами проектного менеджмента, хранения и сборки исходного кода, управления зависимостями, артефактами и инфраструктурой разработки.
Программный комитет ещё не принял решения по этому докладу
Как перейти на свой Service Mesh и сделать жизнь разработчиков хуже без потери производительности
В нашем облаке мы решили двигаться к Zero-Trust, что предполагает использование Service Mesh, где только авторизованные сервисы могут взаимодействовать друг с другом.
После анализа существующих решений мы поняли, что ни одно из них полностью не соответствует нашим требованиям, поскольку готовые решения используют концепцию сертификатов, которые хранятся на системе. Мы же хотели отказаться от них, т.к. сертификаты могут быть использованы злоумышленниками. В результате разработали собственное решение, которое отвечает нашим требованиям и способно держать большую нагрузку.
В своем докладе расскажу о проблемах, с которыми мы столкнулись при внедрении нашего решения. Обсудим, как это можно сделать без ущерба для производительности, даже если ваш код написан на Python. Также я предоставлю полезные инструкции, которые помогут вам реализовать это у себя.
Программный комитет ещё не принял решения по этому докладу
Гибкое управление доступами для распределенной инфраструктуры
Когда у тебя большая распределенная инфраструктура выдавать доступы разработчикам, лидам, аналитикам ставоится все интереснее. Конечно же у нас есть OpenVPN, Wireguard и прочие всем знакомые инструменты, но они подходят не всегда.
В рамках своего доклада я расскажу как мы Магнит Омни:
-- решили вопрос предоставления доступа для разработчиков/лидов/etc. для разных окружений
-- как мы научились выдавать консистентный доступ в разные окружения
-- как нам удалось сократить время выдачи доступов с нескольких дней до 15 минут
-- как мы автоматизировали настройку Netbird VPN и превратили его в платформенный
-- и про "факапы" я тоже расскажу
Доклад принят в программу конференции
Почему не взлетают внутренние платформы?
Платформы - тренд последних лет. Многие компании идут в их разработку, но положительного эффекта не наблюдают. Либо вообще выкидывают через некоторое время. Хочется порассуждать, а когда и, главное, зачем такие платформы нужны (как IDP, так и внутренние бизнесовые) и обсудить, что может привести их к провалу.
Доклад принят в программу конференции
Эволюция dev-окружений: как мы прошли путь от виртуалки до vCluster.
· Как мы прошли путь к текущей реализации dev-окружения сквозь обычные виртуалки, kubernetes + собственный cli, коммунальный kubernetes + helm.
· Анализируем dev платформу: Kubernetes + ArgoCD, vCluster, Kyverno, etc. Проблемы и решения при поддержки множества автогенерируемых vCluster'ов.
· Основные типы тиражируемых сред и поддержка актуальности.
· Как решить проблему огромного helm chart. Какие подходы можно использовать при организации проектов разработки и как тиражировать варианты сборок окружений.
Программный комитет ещё не принял решения по этому докладу
Reliability Engineering (13)
Алерт. Долгое и странное путешествие
О чем хочется рассказать:
ВК большая компания с множеством разных БЮ, в каждом БЮ разные системы мониторинга и алертинга. В рамках доклада пройдемся от того как было, что с алертом случалось когда он зарождался и как доходил до человека, который мог починить проблемы, и как стало сейчас с внедрением автоматизации во все БЮ. Используем Grafana oncall + сильно допиливаем ее саму + вокруг выстраиваются разные вспомогательные сервисы. Какие кейсы эскалации алертов, как мы избегаем шума алертов. А также что можно еще сделать с алертом, например алерт может вырасти в полноценный инцидент, с jira таской и чатом инцидента со всеми заинтересованными лицами. Как чатом можно управлять используя бота, и какой у нас флоу инцидента в рамках автоматизации.
Программный комитет ещё не принял решения по этому докладу
Математика починки инцидентов
Аптайм — это функция от количества инцидентов, времени их починки и влияния на пользователей. При этом время инцидента зависит от основных действий по поиску и устранению проблемы, и вспомогательных процессов по уведомлению ответственных, сбору их в едином пространстве, быстрому добавлению новых людей, а ещё общению с поддержкой и PR. И починку можно рассматривать как алгоритм действий, который можно оптимизировать глобально или проводить локальные оптимизации в самых проблемных местах.
В докладе разложим весь процесс от возникновения триггера инцидента до полного восстановления сервиса на отдельные действия и попробуем оптимизировать каждый этап чтобы уменьшить общее время инцидентов в продукте. С процентилями, распределением вероятностей и визуализацией влияния отдельных действий на распределение времени починки ваших инцидентов.
Программный комитет ещё не принял решения по этому докладу
Повышаем гибкость проекта через фича флаги Unleash
Фича флаги позволяют изменять поведение системы без правки кода и повторного развертывания. На нашем проекте мы могли бы их имплементировать сами, но, как говорят ребята из Unleash, "друзья не позволяют друзьям создавать свою собственную систему фича флагов", поэтому мы взяли их Open Source решение. И не прогадали!
Из моего доклада вы узнаете, как фича флаги участвуют в бизнес-процессах и влияют на развитие продукта, как их правильно интегрировать в код и, наконец, про особенности эксплуатации самого Unleash.
Программный комитет ещё не принял решения по этому докладу
Как протестировать кластер Kubernetes на 5000 нод не утилизировав все ресурсы облака
Исторически было известно, что кластер Kubernetes может поддерживать до 5000 узлов при оптимальном количестве подов на каждом равном 110. Недавно Google опубликовал статью о кластерах с 65000 нод. А сколько нод может поддерживать ваш кластер?
Хороший вопрос, но для такого тестирования нужно огромное количество ресурсов. В своем докладе я расскажу как мы в Yandex Cloud тестируем наши кластера на масштабируемость, используя минимум ресурсов. Поговорим о том, какие факторы влияют на масштабируемость и что можно сделать с кластером k8s, чтобы он поддерживал столько нод, подов, секретов и других объектов, сколько вам нужно.
Программный комитет ещё не принял решения по этому докладу
File.d – быстрый сборщик логов и немного больше
В докладе будет рассказано о том как работает File.d, из каких частей состоит и как его можно использовать на примерах конфигов отдельных компонентов и пайплайнов. Также будут затронуты темы скорости работы, гарантий доставки и механизмов защиты системы логирования от внезапных увеличений объемов данных.
Программный комитет ещё не принял решения по этому докладу
Как мы научили ML группировать 50 000 событий в инциденты
L1-инженеры 50 000 раз в сутки решают что делать с событием мониторинга — добавить к открытому инциденту или создать новый, а может добавить к только что закрытому или вообще это просто шум. А может случился экосистемный сбой и нужно оповестить большую часть из 500 наших продуктов.
В докладе мы расскажем зачем мы решили автоматизировать группировку событий мониторинга, как мы внедряли изменение, что это нам дало и какими Open Source решениями нам удалось достигнуть точности выше 80%.
Программный комитет ещё не принял решения по этому докладу
Метрики для метрик: Опыт выстраивания SLOs/SLIs для платформы мониторинга
Уже давно не секрет, что в Т-Банк есть своя observability-платформа Sage.
Внутри банка, мы предоставляем сервис мониторинга, у которого ежедневно более 5000 активных пользователей(DAU).
И как это принято, у нас есть SLA с нашими пользователями,
но "как понять предоставляем ли мы сейчас услугу или нет?" - именно с этого вопроса начинатся мой рассказ о построении SLOs/SLIs для нашей платформы Sage. Метрики для метрик.
На примере домена метрик в Sage, в своем докладе я расскажу:
* как мы измеряем надежность;
* как мы строили SLOs/SLIs;
* как мы работали с нашими клиентами, чтобы выявить их ожидания от нашей надежности;
* как выглядит наша подсистема метрик на сегодня
Доклад будет интересен как экспертам, так и людям, которые только погружаются в тему построения SLOs/SLIs
Доклад принят в программу конференции
Практические проблемы становления SRE
Проблемы, с которыми можно столкнуться на разных этапах зрелости команд, организации и практик
Доклад принят в программу конференции
Как не потерять миллионы на SLA: архитектурный подход к управлению ожиданиями
В мире высоких требований к надёжности платформ часто бывает так, что SLA становятся больше головной болью, чем инструментом стабильности. Создание SLA, которые действительно работают, а не просто выглядят красиво на бумаге, требует глубокого понимания архитектуры систем и грамотного управления ожиданиями клиентов.
В своём докладе я поделюсь, как мы прошли путь от неэффективных и бессмысленных метрик, родившихся из попыток «угодить всем», к архитектурно обоснованным SLA, которые реально работают. Вы узнаете, почему классические SLI вроде Latency и доступности прокси могут быть пустой тратой ресурсов, и как инженерное видение помогло нам найти баланс между техническими возможностями и потребностями бизнеса.
Я расскажу, как анализ компонентов платформы позволил выстроить последовательность работы, связать это с метриками и алертами, и создать план внедрения адекватных SLA. Поговорим о непростых технических компромиссах, неожиданностях, и почему инженерные лидеры не должны бояться отказаться от "фальшивых" метрик. Этот доклад — для тех, кто хочет научиться строить SLA, которые защищают ваши системы и бизнес, а не становятся причиной бессонных ночей.
Доклад принят в программу конференции
Катастрофоустойчивость для ВКС. Как мы реализовывали георезервирование для “стартапа”.
Три года мы помогаем сопровождать продукт российской ВКС одному из наших заказчиков. Мы прошли тернистый путь от стартапа “прод на коленке за две недели” и каждый день “ложились в прайм тайм” до геораспределенного по трем ЦОДам конкурентного продукта.
Наш рассказ будет о боли, которая испытывалась все это время, о том, как мы “придумывали заново” каждое популярное решение и через “нетиповые” решения приходили к типовым. Как боролись с проблемами инфраструктуры за пределами нашей зоны ответственности, и как нам в этом помогали разработчики.
Из продукта, к которому не было доверия на старте, мы стали бизнес критичной системой, с подтвержденным уровнем доступности 99.99% в 2023 году.
Программный комитет ещё не принял решения по этому докладу
Как добыть SLO: источники и инструменты гномов SREдней полосы
Для тех кто уже понял “Что такое SLI/SLO?” теперь станет понятно как это реализовать на практике.
Представь, ты инициативный разработчик или инженер. Ты уже узнал какая классная штука SLO и как оно помогает поддерживать работу сервисов и не замедлять разработку. Ты уже продал это руководству и команде - все жаждут увидеть это в дейтсвии. Ты полон энтузиазма и уверенности, что все быстро сделаешь, ведь, кажется, это делали много раз в разных комапниях, следуя заветам книг Google. Ты начинаешь искать готовый вариант, чтобы сделать первый MVP как можно быстрее. И понимаешь, что готового рецепта нет. Ты начинаешь поиск источников о практиках других компаний, инструментов для реализации и находишь частичные данные, но ты не знаешь насколько этот айсберг велик. А хочется по горячему, пока интерес не остыл, показать хоть что-то команде и принести пользу.
Поделюсь нашим опытом и наработкам. Я бы хотел все это знать и иметь в самом начала работы с SLO.
Программный комитет ещё не принял решения по этому докладу
На чём стоит Performance: многоуровневые гарантии для устойчивых систем
В системах с тысячами серверов отказы неизбежны: выходят из строя диски, сервера, целые дата-центры, не говоря уже о сбоях ПО.
Эффективное решение подобных проблем требует знаний методологий, инструментов анализа и прикладного слоя.
Но для обеспечения стабильной работы одной реакции на сбои недостаточно — нужны превентивные подходы, устраняющие целые классы проблем.
На докладе обсудим, как создать систему многоуровневых гарантий — от оборудования до контейнеров с приложениями, — чтобы пользователи получали стабильный сервис, независимо от того, где произошел сбой.
Доклад принят в программу конференции
И зачем нам еще одна платформа хаос тестирования?
В начале 2024 года мы собрали команду и начали разрабатывать своё приложение для проведения хаос тестирования. Поговорим о том, почему мы решили так делать, вспомним про то, что такое хаос тестирование, чем хуже другие инструменты. Расскажем про то, как команды отреагировали на наше решение, чего мы хотим добиться. Немного про планы развития нашего продукта.
Программный комитет ещё не принял решения по этому докладу
Безопасность, DevSecOps (16)
Аудит безопасности Kubernetes кластера без Kubernetes кластера
Далеко не многие знают как ломать Kubernetes, а тем более как ломать Куб, когда его нет. В докладе я поделюсь своим опытом проведения аудита кластеров еще на стадии проектирования, когда на руках есть только Cluster API манифесты будущих Kubernetes. Подсвечу интересные моменты, что там можно найти, а чего нельзя, и конечно же расскажу как автоматизировать этот процесс.
Программный комитет ещё не принял решения по этому докладу
Vault8s: доставляем секреты из Hashicorp Vault в 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
Для каждого из интрументов приведу пример настройки, рассмотрю как именно доставляется секрет до приложения и принцип работы инструмента. Сравню инструменты с точки зрения механизмов ротации секретов, а также удобства использования. Подсвечу ограничения инструментов.
Программный комитет ещё не принял решения по этому докладу
EBPF & Security: атаки на сервисы с EBPF
Новая жизнь бросает нам новые вызовы - и вот уже CNI и Service Mesh-и с EBPF под капотом это не что-то из области фантастики или экспериментов, это уже повсеместно внедряется на production инфраструктуру. Однако не так много инженеров понимают, что происходит под капотом этой системы. И еще меньше инженеров знает, как системы на базе eBPF могут быть скомпроментированы и как защититься от угроз если не полностью, то хотя бы минимизировав риски. И сегодня я расскажу вам об этом.
В докладе мы затронем следующие темы:
- Что такое bpf как технология
- eBPF и как это работает
- Атаки на удаление ключей из ebpf maps
- Kernel exploits by eBPF
- Вызов незапланированных syscalls
- Falco bypass
И другие виды атак
Программный комитет ещё не принял решения по этому докладу
Проектный офис в ИБ: как запускать ИБ требования во всем Яндексе и <u>не ...</u> спать спокойно
Что нам стоит безопасность построить?
Зачастую, рассказывая о безопасности, все делают наибольший акцент на технологиях и их применимости в тех или иных условиях. Но правда в том, что после технической реализации стоит длительный этап перевода команд/отделов/департаментов на новое решение.
В докладе - расскажем о том, как работал процесс раскатывания больших инициатив ИБ в Яндексе еще совсем недавно и что поменялось в нем после появления менеджеров. А также ответим на вопросы - зачем нам метрики? Как сделать так, что об инициативе узнали все? А также расскажем о фейлах ))
Программный комитет ещё не принял решения по этому докладу
AppSec Platform
Тематика безопасной разработки становится все более и более актуальной год от года. Многие Компании реализовали несколько практик (таких, как SAST, SCA и т.д.) и вопрос управления срабатываниями сканеров становится все более значимым.
В своем докладе я расскажу про нюансы, с которыми можно столкнуться - от нюансов дедубликации срабатываний сканеров до подготовки отчетности и про возможное решение: AppSec Platform (ASOC, ASPM), какие задачи они решают, каким функционалом обладают и как они могут быть использованы для оптимизации процессов безопасной разработки
Программный комитет ещё не принял решения по этому докладу
FinDevSecOps - от регуляторики к реализации
Процесс безопасной разработки в финтехе, обзор регуляторики - "когда, зачем, кому", особенности технической реализации требований - как.
Реальные кейсы применения инструментов для выполнения шагов pipeline'а. Интеграция в pipe.
Баланс требований и суровая техническая реализация.
Практическая реализация Security Gates
Программный комитет ещё не принял решения по этому докладу
Как при помощи OWASP 10 для GEN AI и инструментов мы можем перекрыть риски связанные с MLOPS/LLMOPS
Использование генеративных нейросетей внутри компаний дает большие преимущества бизнесу в решении определенных задач. При этом уже известны инциденты безопасности, связанные именно с пайплайном нейросетей: инъекции вредоносного контента, искажение запросов, генерация неэтичного контента, кража обучающих данных и кража моделей.
В своем докладе мы рассмотрим примеры реальных угроз, как данные влияют на риск взлома и какие конкретные шаги можно предпринять, чтобы сделать ML-пайплайн безопаснее.
Программный комитет ещё не принял решения по этому докладу
Ладно уж храни свои секреты
Все что вам нужно знать про секреты, как их хранить и как обращаться с ними
Программный комитет ещё не принял решения по этому докладу
How much is the fish. Security cookbook
Продолжение доклада по исследованию "Сколько стоит голова девопса"
В ситуации, когда ИБ перегружено своими безумными идеями, появляется вопрос: "Как построить безопасность без ИБ"
Данный доклад ставит целью раскрыть простой cookbook для инженеров автоматизации, который поможет им правильно сформулировать информацию для себя и для того "Васи из ИБ" и понять, как же работают их системы и что защищать. По факту - сделать shift right для начала, чтобы потом сделать shift left и хвастаться своим DevSecOps'ом. Как выстраивать линии обороны в своих инфраструктурах при малых затратах и совмещать это с гибкостью автоматизации и вообще ответить на вопрос: "А если моя инфраструктура уничтожена, за сколько я разверну ее снова?"
Программный комитет ещё не принял решения по этому докладу
Как построить AppSec империю
Автоматизация проверок безопасности
Архитектура сервисов AppSec
Схожесть AppSec с другими популярными сервисами
Программный комитет ещё не принял решения по этому докладу
Постигая реестры Docker-контейнеров: от архитектуры до безопасности
В докладе рассмотрим архитектуру и управление различными реестрами Docker-контейнеров с акцентом на инфраструктуру, узкие места, защиту доступа к реестру, устройство Docker-образов и выявление уязвимостей до запуска в production. В сессии подробно рассмотрим механизмы аутентификации и авторизации для Docker-трафика, уделим внимание продвинутым аспектам управления образами Docker, включая создание мультиплатформенных образов, получение SBOM отчетов, а также перечня уязвимостей при помощи инструментов сканирования. Обсудим возможные сложности при эксплуатации реестров, а также при реализации сканирования на уязвимости.
Это обязательная для посещения сессия профессионалами, желающими углубить свои знания в области управления образами Docker и безопасности.
Программный комитет ещё не принял решения по этому докладу
Безопасная разработка, человек и мотивация.
Далеко не первый раз мы слышим на конференциях о "безопасной разработке", но часто это сводится к сканерам: "давайте напихаем SAST,DAST,IAST,RAST и будем по их отчётам бить по рукам разработку". Реже мы слышим про Security Champion в формате "найдите их и будет хорошо". Идея то конечно хорошая, но как искать чаще всего никто не может подсказать ибо это обычно индивидуальный опыт компании. Реже всего говорят о обычном разработчике и его вовлечении в этот процесс, а он тут всё же самое важное звено.
В докладе хочется показать как и чем можно мотивировать людей интересоваться безопасной разработкой не только "битиём по рукам" и как потом поддерживать их желание развивать данное качество.
Программный комитет ещё не принял решения по этому докладу
Offensive GoLang
Язык программирования Go предоставляет возможности, которые значительно оптимизируют разработку инструментов для DevSecOps и Red Team. Он отличается простотой, что облегчает его изучение и использование. Компиляция программ на Go для Windows, Mac и Linux из единого исходного кода позволяет экономить ценное время. Именно поэтому злоумышленники активно используют Go для создания современных вредоносных программ. Мы будем моделировать эти угрозы, чтобы лучше понять, как защищаться.
Программный комитет ещё не принял решения по этому докладу
Сроки действия сертификатов в Service Mesh, особенности проверки и другие странности
Доклад посвящён особенностям работы с сертификатами в среде Service Mesh. В нём обсуждаются вызовы, связанные с коротким сроком действия сертификатов, их своевременным обновлением и валидацией, включая использование CRL, OCSP и OCSP Stapling. Особое внимание уделяется влиянию истечения срока действия сертификатов на доступность сервисов и предотвращению сбоев. Также рассматриваются ограничения и возможности проверки сроков действия сертификатов на примере Istio Service Mesh.
Программный комитет ещё не принял решения по этому докладу
Как начать интегрировать принципы защиты API в процесс разработки, подружиться с AppSec-командой и не увеличить сроки релиза
API - это самый удобный способ публикации сервисов B2B и B2C. Но даже крупные компании, такие как Apple (случай с Apple iCloud account takeover), Google (случай с Google Cloud Platform IAM API), Mercedes-Benz (случай с Mercedes-Benz car control) и т.п. допускают ошибки при разработке и публикации своих API.
В первой части я расскажу об ошибках, которые допускали компании при публикации своих сервисов, как они исправляли эти ошибки и как этого можно было бы не допустить.
Во второй части доклада я расскажу про мой опыт организации процесса защиты API, который усложниля тем, что приходилось "дружить" с двумя командами сразу, объясняя почему ИБ и разработка должны договариваться а не выставлять требования.
В третей части доклада я расскажу про то, что можно начать применять уже завтра для защиты своих API.
Программный комитет ещё не принял решения по этому докладу
Настольная азбука управления уязвимостями
Через незакрытые уязвимости часто происходит взлом той или иной компании.
В докладе я расскажу, какое внимание стоит уделять процессу управления уязвимостями.
Из доклада слушатели смогут осознать себя в этом вопросе.
Также я расскажу про уровни зрелости этого процесса, которые подойдут всем от маленькой компании из пары-тройки команд разработки до большого бигтеха.
Доклад принят в программу конференции
CTO/CIO трек, Org Engineering (3)
Почему CTO должен дружить со всеми департаментами и как эта дружба влияет на архитектуру программного продукта
Работа в много-продуктовых компаниях, которые находятся под требованиями регуляторов разных стран, значительно отличается от моно-продуктовых компаний ограниченного рынка, поэтому CTO активно взаимодействует со всеми департаментами, особенно с финансовым и юридическим. Мы рассмотрим сложные кейсы, которые влияют на техническую архитектуру (сети, датацентры, средства кибер-безопасности), продуктовое развитие и которые могли бы быть упущены, если бы CTO не интересовался бы юридической частью или финансами, а финансы и юристы не взаимодействовали с CTO на постоянной основе. Также мы рассмотрим как совместно с данными департаментами принимать решения о использовании SaaS сервисов, облаков, мерах по достижению надежности, защите персональных и детских данных. Попытаемся определить error budget для юридических рисков и методы оценки их в деньгах.
Программный комитет ещё не принял решения по этому докладу
CI/CD динамических dev стендов за почти даром
Все мы знаем классическую схему окружений: prod, stage и dev. Но когда в компании много команд и разработчиков, работающих над микросервисным продуктом, начинают возникать трудности. Каждый хочет выкатить свою фичу на dev (чаще всего это комбинация микрофронта и нескольких бэкенд-микросервисов) и передать её тестировщикам. При этом важно, чтобы на стенде оставались стабильные версии всех остальных микросервисов и микрофронтов. Поднимать отдельный стенд для каждой фичи — возможный путь, но он очень ресурсозатратен.
С ростом системы линейно увеличивается количество разработчиков и фич в работе, а также возрастает число микросервисов, что приводит к квадратичному росту затрат на инфраструктуру. Мы поделимся, как этот момент можно обойти более элегантно. Наша идея: поднимать только те сервисы, которые изменяются в рамках фичи, а для остального использовать stage окружение. Этот подход уже год успешно работает у нас.
Конечно, потребуется немного поработать с роутингом и обвязкой, но усилия минимальны. Мы покажем, как это настроить в GitLab, и поделимся нашими инструментами и наработками, чтобы упростить внедрение такого подхода и в вашем проекте.
Программный комитет ещё не принял решения по этому докладу
я стал юнит-лидом, вырос до хеда, а потом объединился с холдингом
как создать оргструктуру заново, как перестроить взаимосвязи внутри департамента и как после этого объединиться с точно такой же командой, чтобы не удвоить нагрузку, а сделать все правильно
Программный комитет ещё не принял решения по этому докладу
Big Data и Data Engineering (4)
Аналитическая база данных как продукт внутренней платформы данных
Предоставить пользователям аналитическую базу данных - это не просто поднять гринплам, кликхауз или купить на них подписку. На примере внедрения в платформу данных базы нового поколения Starrocks (https://www.starrocks.io) расскажу про обеспечение необходимого минимума фунционала и автоматизации для потребителей - инженеров данных, инженеров-аналитиков или разработчиков dwh.
Постараюсь ответить на вопрос - каким требования должны удовлетворять инсталляции и сами движки баз, особенно если вы как поддержка хотите спать по ночам и не вздрагивать при слове обновление, блокирующие операции ddl или отказ мощностей.
В докладе будет k8s (куда же без него в современном мире), сервисы миграций, аутентификации и авторизации, dbt как сервис - и все это приправлено щепоткой golang и gitlab-ci.
Программный комитет ещё не принял решения по этому докладу
Быстрее пуллинг: как мы ускоряли автоскейлинг в Inference-Платформе
Я расскажу наш опыт ускорения автоскейлинга ресурсов с GPU в нашем продукте - Inference Платформа Selectel на базе Managed Kubernetes.
В докладе мы охватим следующие темы
- Узкие горлышки в различных этапах автоскейлинга в K8S
- Один из самых долгих этапов - пуллинг образа контейнера на ноду
- Основные компоненты образа в мире ML
- Почему стандартные подходы к оптимизации размера образа не срабатывают в мире ML
- Уменьшение размера образа выносом весов моделей в отдельное сетевое хранилище
- Увеличение скорости загрузки слоев образа с помощью кеширования в кластере
- Ленивой загрузка слоев образов и снепшотеры (nerdctl, SOCI, Nydus)
- Форматы сжатия образов zstd vs gzip
Мы узнаем какие из методов помогли сократить время аплоуда и ускорить автоскейлинг, какие есть плюсы и минусы подходов.
Программный комитет ещё не принял решения по этому докладу
Разработка отечественного BI-решения: опыт замещения Amplitude Analytics в проекте для крупнейшего ритейлера
В рамках доклада будет представлен опыт разработки и внедрения отечественного 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: ежедневные трансформации стали инкрементальными и менее ресурсоёмкими.
- Сокращение затрат на аренду вычислительных мощностей и операций с хранилищем данных.
- Ускорение процессов визуализации отчётов за счёт оптимизации витрин данных.
Программный комитет ещё не принял решения по этому докладу
Динамические окружения для Data-инженера
- DAGи и Data-пайплайны - что это и зачем это нужно
- Airflow - оркестратор DAGов
- Зачем нужны динамические окружения в Airflow
- Как организовать динамические окружения в Airflow
- Как подружить Airflow и ArgoCD
Программный комитет ещё не принял решения по этому докладу
Практики управления командой (15)
Менеджмент для неменеджеров. Как управлять эффективно и без занудства
Вы не любите планёрки? Вы просто не умеете их готовить.
Управление проектами, бюджетирование ресурсов, диаграммы Ганта... Может, можно без этого?
Лучше меня никто не сделает. Возможно, стоит попробовать делегировать по-другому?
Я расскажу несколько историй (своих и клиентов), как небольшие изменения в процессах управления - совещаниях, проджект-менеджменте и подходах к делегированию критическим образом сказались на продуктивности и эффективности.
Программный комитет ещё не принял решения по этому докладу
Blameless culture. Как правильно работать с инцидентами.
Два извечных вопроса: кто виноват и что делать? В своем докладе я хочу рассказать про культуру без обвинений и смещение фокуса с вопроса "кто виноват?" на "что делать?"
Чаще всего виноваты именно процессы, а не люди и внедрение культуры без обвинений может сильно поднять моральный дух и сплоченность команды
Посмотрите, со всех сторон нам рассказывают про невероятный кадровый голод. Компании бьются за людей, рекрутеры и HR-специалисты строят сильный бренд, придумывают кучи плюшек, но так ли они нужны в токсичной атмосфере? И что происходит дальше, после испытательного срока?
Я порассуждаю о любви к ближнему своему, о психологии и о том как это все связано с инцидент-менеджментом
Доклад принят в программу конференции
У нас нет выделенной команды мониторинга, и так и задумано
Несколько лет назад в Иви мы расформировали команды мониторинга и централизованной выгрузки релизов.
Причина: такая конфигурация имела несколько проблем.
Что мы сделали:
- функцию выгрузки релизов передали в продуктовые команды
- функцию мониторинга и 1-2 линии поддержки (сервисов) выполняем всеобщими дежурствами
...
Profit
Программный комитет ещё не принял решения по этому докладу
Системный подход к внедрению Kanban (STATIK) в команде SRE
Поделюсь своим личным опытом внедрения методологии Kanban в команде SRE.
Управление поставкой и Kanban регулярная тема конференций для руководителей и разработчиков. Невольно возникает вопрос применима ли методология для команд надежности?
Я расскажу о том, как системный подход к внедрению Kanban (STATIK) помог нам пересобрать процесс поставки и внедрить новые практики, а также покажу как они повлияли на показатели (время и количество выпускаемого) и удовлетворенность команды.
Программный комитет ещё не принял решения по этому докладу
Kvaps, Gaal и Cozystack: как мы с нуля строили процессы работы с b2b-клиентами в собственной компании
Как правило, мы все приходим работать по найму в компанию со сложившимися процессами: уже есть какая-то документация, традиции, система обслуживания и поддержки клиентов, есть какие-то внедренные и кастомизированные эджайл-практики, нанятые менеджеры. В общем, даже если все очень плохо, есть уже сложившаяся и более-менее предсказуемая система, в которой можно существовать.
Но все меняется, если ты уходишь из найма и начинаешь строить свою компанию. Тут же оказывается, что тебя не хватает на все процессы, что невозможно сразу сделать хорошо, что контролировать и управлять процессами невероятно сложно, а денег на наем крутых управленцев и инструментарий, конечно же, еще нет. При этом в тебя уже поверило несколько клиентов и тебе необходимо работать с ними.
Первые пару-тройку месяцев все идет более-менее гладко: клиенты на энтузиазме, ты тоже. Но со временем у них могут появляться новые требования, расти какое-то недовольство мелочами, вылезать какие-то моменты,с вязанные с непроясненными ожиданиями и сферами ответственности в с обеих сторон.
Этот доклад — как проект Linux from Scratch: я расскажу, как и где мы лажали и продолжаем лажать спустя полтора года после запуска компании, как мы лечили и предотвращали «детские болезни», какие ошибки наверняка попытаетесь совершить и вы и как, в конце концов, собрать компанию «из сорцов».
Предыстория
Год назад Андрей Квапил объявил о запуске собственной платформы Cozystack. Чуть позже к нему присоединились Георг Гаал и я, автор этого доклада. Наша текущая бизнес-модель — заработок на подписке на саппорт open source-платформы, продажа облака, а также обслуживание приложений клиентов, которые крутятся в нашей платформе. Наверное, мы наступили на все грабли, на которые только можно было наступать. Более того, мы еще далеки от идеала и суперчетких процессов, продолжаем ошибаться, учиться и набивать шишки. Но тем ценнее наш опыт для тех, кто тоже начинает строить свою ИТ-компанию, особенно в b2b.
Программный комитет ещё не принял решения по этому докладу
Как устроить работу команды и не свалиться в бюрократию - процессы для людей
Вынесем операционные процессы сервисной команды из-за закрытых дверей.
Расскажу о процессах, которые удаляют от ситуативных реакций и фокусируют на пользе:
- Доставка ценности: Как мы подошли к организации работы с собственной поставкой, целеполаганием и синхронизацией со смежниками (разработка)
- Регулярные каденции: Почему ретро полезно в SRE команде? Как мы используем его с инцидентами и привлекаем смежников?
- Управление аварийными ситуациями: Как подготовиться к "пожару" ДО принятия сервиса на поддержку и минимизировать влияние человеческого фактора на его решение;
- Нагрузочное тестирование: Типичный инструмент для продуктовой команды - когда и зачем он полезен SRE?
- Дежурства: Стратегии организации, как построить работу с дежурствами так, чтобы команда не выгорала
- Онбординг: Когда в компании много инструментов, в команде десяток сервисов и несколько десятков контактов - новички очень дороги, поделюсь лайфхаками, как нивелировать эти проблемы
- Выхлоп из деятельности команды: ранбуки, постмортемы и другие артефакты - как организовать их полезно и нужно ли их выпускать
Доклад принят в программу конференции
Проект "Феникс" Как дальше развивать Канбан метод в DevOps
Роман "Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему" стал одним из первых Бизнес романов на тему DevOps, для принятия решений использовался Канбан.
Расскажу какие практики Канбан метода применялись бы, и какие выгоды были бы получены если продолджили использовать Канбан метод в проекте
Программный комитет ещё не принял решения по этому докладу
Dogfooding as a Service - как "сломать" продукт так, чтобы команда тебе была благодарна
Как получить обратную связь о своем продукте и выявить самые коварные баги еще до официального релиза и при всем при этом поднять уровень корпоративной культуры?
В своем докладе я поделюсь как мы организовали сервис для продуктовых команд dogfooding as s service и что все это значит.
Программный комитет ещё не принял решения по этому докладу
Коммуникация, или как сделать так, чтобы менеджер от вас отстал
Я — Engineering Manager, и я из той самой касты людей, которые достают вас вопросом "Какой статус?".
Поверьте, на самом деле я не хочу его задавать. И я не хочу мешать вам работать. Давайте я расскажу вам, как сделать так, чтобы я от вас отстала.
Ответ лежит в организации работы над вашими задачами и коммуникациями о них.
В докладе поговорим про три типа таких задач:
- Рядовые;
- Критичные;
- С высоким влиянием на ландшафт и потребителей.
Вы узнаете, как при работе с такими задачами сохранить свои нервные клетки, рабочее время и хорошие отношения с коллегами других профессий.
Доклад принят в программу конференции
Как мы в DevOps-команде решили Канбан применять
Расскажу о трехлетнем опыте использования Канбан-метода в небольшой команде DevOps-инженеров. Отвечу на самый главный вопрос "Зачем?" Расскажу с чего начали, как провели воркшоп STATIK (Systems Thinking Approach to Introducing Kanban) - cистемный подход к применению Канбан-метода, какие инсайты обнаружили в ходе STATIK и чем он помог. Поделюсь возникшими трудностями на пути применения Канбан-метода в нашей команде и как их решали, чего достигли и что не получилось. Покажу какие метрики эффективности выполнения задач мы считаем и насколько помогают для этого Канбан-инструменты. Обсудим, что может помешать прозрачности работы и как работать с заказчиками, вырабатывать правила и достигать соглашений.
Доклад принят в программу конференции
Организационное проектирование DevOps
DevOps существует уже более 15 лет, но лишь немногие организации могут сказать, что успешно внедрили DevOps. Эксперты отмечают, что в компаниях процветают анти-паттерны DevOps, компании продолжают страдать от большого T2M, а взаимодействие Dev-Ops все так же создает сложности.
Доклад поможет компаниям-новичкам в DevOps не совершать ошибок, а остальным пересмотреть свой подход к построению DevOps. Рассмотрим типичные ошибки построения DevOps в организациях и как их решать, а так же теорию взаимодействия инженерных команд.
Программный комитет ещё не принял решения по этому докладу
Метрики удовлетворенности инфраструктуры. Понять и простить или отпустить?
У нас не задеплоилось с первого раза, давайте влепим кол инфраструктуре. А то, что мы криво поставили переменные пода - это не к нам, это к devops. Часто ли вы такое слышали от разработчиков, тестировщиков или поддержки? Как сделать доказательную базу того, что с инфраструктурой всё хорошо, а проблема в коде? Сегодня мы поговорим с вами о том, как можно организовать процесс снятия метрик удовлетворённости инфраструктуры для команд разработки и тестирования, рассмотрим вариант стэка технологий для этого, а так же пример реализации с видом метрик, которые могут оказаться полезными в вашей работе.
Программный комитет ещё не принял решения по этому докладу
Nginx Ingress в k8s: как манифест Ingress превращается в конфигурацию nginx … с помощью LUA
В своем выступлении «загляну под капот» одного из самых популярных Ingress контроллеров в k8s – Nginx Ingress. Материалы доклада помогут вам добиться желаемых результатов при работе с данным инструментом.
Программный комитет ещё не принял решения по этому докладу
Enabling teams или "Инженер на час"
В чем основное различие Enabling-команд и команд с "Инженерами на час". Наше видение того, какие типы команд наиболее востребованы в Enterprise. Эти типы команд взаимоисключают друг друга или можно построить что то среднее? Наш опыт построения Enabling-команды.
Доклад принят в программу конференции
Бережливое проектирование: как экономить тратя время на думы
В этом докладе поговорим, как бережливая архитектура может преобразовать наши проекты в выгодные инвестиции. Получим конкретные советы и стратегии, основанные на успешных практиках нескольких компаний. Узнаем, как минимизация затрат и оптимизация процессов могут повысить эффективность наших проектов и изменить наше представление о их стоимости. Приготовьтесь к новому взгляду на архитектуру, который приведет к экономии и инновациям.
Это доклад продолжение докладов про коллаборации, важность проектирования для DevOps(ов).
Программный комитет ещё не принял решения по этому докладу
Не мейнстрим. Когда не нужен kubernetes (4)
Docker Swarm жив!
Часто слышу миф, что Docker Swarm давно забросили и не поддельное удивление в сообществе, что Docker Swarm всё-же жив. Хочу разобрать откуда возникли данные мифы, когда стоит реально выбрать Swarm, какие плюсы и минусы данного решения, best practice и DRP-план.
Программный комитет ещё не принял решения по этому докладу
От сложного к простому. От VMWARE ESX+ Kuberenetes к Docker Swarm на baremetal.
В нашем проекте мы прошли путь от использования VMWARE кластера c Kubernetes к более простому решению на основе Docker Swarm. В докладе расскажу причины этого перехода, немного про подготовку и процесс миграции с минимальными простоями, а также несколько интересных историй из практики, связанных с разработкой и тестированием наших web приложений.
Программный комитет ещё не принял решения по этому докладу
Вам не нужен Kubernetes
Kubernetes отлично подходит для оркестрации, масштабирования и управления контейнерезированными приложениями, но всегда ли он нужен?
В докладе я расскажу о кейсах из практики, когда внедрение Kubernetes для проектов не оправдало ожиданий или пошло во вред. Отдельно остановлюсь на технических и экономических плюсах и минусах Kubernetes.
Программный комитет ещё не принял решения по этому докладу
Автоматическая генерация документации на основе настроек клиента
Автоматизация управления документацией в архитектуре микросервисов и микросервисных команд с помощью Ansible
Введение
В быстро меняющемся мире разработки программного обеспечения, поддержание актуальной и постоянно обновляемой документации является критически важным. Однако этот процесс часто требует много времени и подвержен ошибкам. В этом докладе мы обсудим новый подход к автоматизации генерации и управления документацией в архитектуре микросервисов.
О чем доклад
1. Автоматическая генерация документации на основе настроек клиента
2. Генерация универсального файла настроек для миллионов микросервисов и управление им с помощью Ansible:
3. Генерация и обновление документации на основе реальной установки без необходимости привлечения технического писателя или инженера:
Мы научились генерировать универсальный файл настроек для множества микросервисов и управлять им с помощью Ansible.
Наше решение позволяет генерировать поддерживающую документацию на основе настроек клиента на стороне клиента во время установки. Эта автоматизация сокращает время и снижает риск ошибок.
Документация генерируется на основе фактической установки и обновляется в реальном времени при любом взаимодействии с программным обеспечением, включая перенос портов, обновление версий, переустановку и т.д. Это гарантирует, что документация всегда актуальна, предоставляя полную картину текущего состояния системы.
Программный комитет ещё не принял решения по этому докладу
Управление ИТ-активами (3)
ITIL: применение в управлении уровнем и доступностью сервиса при выделении продуктовой ИТ-компании
Около 2 лет назад от СТД “Петрович” отделилась продуктовая ИТ-компания “Петрович-Тех”, созданная для закрытия потребностей СТД. Бывший ИТ-департамент стал полностью самостоятельной единицей, а также значительно вырос - и по численности сотрудников, и по уровню решаемых задач.
Уровень сервисов и их доступность стали ключевыми показателями, под которые появилась необходимость перестроить процессы молодой ИТ-компании.
Как масштабировать и перестроить процессы бывшего департамента под структуру компании и новые отношения с заказчиком? Ответ мы нашли в адаптации ITIL под наши потребности и готовы поделиться своим маршрутным листом: на примерах и с кейсами.
Программный комитет ещё не принял решения по этому докладу
Пароли, доступы и алерты: как сделать их удобными и безопасными
Парольные менеджеры часто помогают подставлять пароли в веб-формы и хранить SSH-ключи. Но что делать, если эту чувствительную информацию нужно передать группе людей? И как избежать ситуации, когда приходится менять все пароли из-за увольнения сотрудника?
В своем докладе я поделюсь, как мы решали задачу предоставления доступа к инфраструктурам (VPN, SSH, веб-формы) для команды, обеспечив при этом безопасность. Мы нашли способ, чтобы сотрудники имели доступ, но не могли скомпрометировать данные.
Кроме того, расскажу, как мы централизовали алерты от более чем сорока систем мониторинга в одном месте. Это позволило не только управлять ими с единой панели, но и снизить риски, обеспечит спокойный сон всей команды.
Программный комитет ещё не принял решения по этому докладу
Как посчитать стоимость всех вычислительных ресурсов в крупной компании и не сойти с ума
Т-Банк известен тем, что у нас нет отделений, а все наши клиентские продукты и их поддержка опираются на ИТ-решения, в основе которых лежит ИТ-инфраструктура — серверы, хранилища, сетевое оборудование и так далее. На инфраструктуре работают десятки тысяч виртуальных машин и сотни тысяч контейнеров. Инфраструктура динамически меняется каждый день, удваивается год к году, а затраты на ресурсы составляют десятки миллиардов рублей в год. Каким командам принадлежат эти тысячи ИТ-объектов? Как эти объекты нагружены? Сколько стоят ресурсы для каждого продукта и как эти затраты влияют на его юнит экономику? Достаточно ли командам ресурсов для масштабирования ИТ-систем при взрывном росте клиентской базы? Нам было важно знать точные ответы на эти вопросы, чтобы эффективно управлять нашими мощностями и расходами.
В докладе расскажу о том, как мы разработали собственную систему учета ИТ-объектов на основе графовой базы данных, как настроили процессы разметки ресурсов и их владельцев и минимизировали ручной труд при инвентаризации, как посчитали стоимость владения каждым ресурсом на базе собственной биллинговой платформы и как с помощью аналитических инструментов сделали эту информацию понятной и прозрачной для всех руководителей команд. Система позволяет руководителям продуктовых команд оценивать текущую ситуацию с распределением, утилизацией, стоимостью ресурсов и управлять развитием продукта, а лидерам ИТ банка эффективно планировать будущие закупки для масштабирования технологической базы банка.
Программный комитет ещё не принял решения по этому докладу
Жизнь в облаках и без (5)
Путешествие в облака и обратно: превратности судьбы
Что может побудить нас переехать в облако? А обратно? Достаточно ли хорошо мы понимаем, какие подводные камни обнаруживаются в любом из этих путей? В данном докладе, я бы хотел затронуть тему не самых очевидных нюансов, с которыми столкнется инженерная команда, которая выбирает ту или иную дорогу. Как водится, с каждой из сторон множество плюсов и минусов, поэтому мы с вами попытаемся понять, как выбрать вариант подходящий именно для вас, а не только потому, что так модно/молодежно, и обратим ваше внимание на скрытые факторы, с которыми мы столкнулись благодаря большому опыту миграций различных инфраструктур в обе стороны.
Рассмотрим мы следующие вопросы:
- Скрытые затраты миграции, сколько на самом деле стоит это мероприятие?
Детализация этапов миграции: анализ затрат на подготовку, миграцию, обучение комманды, перестройку процессов
Сравнение реальных расходов с ожидаемой экономией
Примеры кейсов компаний, которые столкнулись с неожиданными затратами
Метрики: как оценивать ROI миграции
- Временные проблемы или сигнал к миграции?
Анализ “тревожных звоночков”: рост требований к производительности, устаревшая инфра, трудности масштабирования
Сценарии выбора: когда временные проблемы действительно требуют миграции, а когда можно обойтись оптимизацией текущей инфры
- Инфраструктурные риски
Категории рисков: физические (отказ оборудования), программные (устаревший софт), киберугрозы
Риски при переходе в облако: зависимость (вендор-лок)
- Влияние облака/on-prem на обновление/устаревание технологий
Жизненные циклы инфры, как меняется подход к обновлениям
Стоимость обновлений в обоих сценариях
Как облако решает “устаревания”
- Скрытые (неочевидные) ограничения облаков
Технические ограничения: специфика работы с API, зависимость от скорости ответа
Ограничения на перенос данных между регионами
Кейсы, когда облачные сервисы не подходили для задач компании
- Эффективность затрат: когда “дешевле” в облаке не значит “дешевле”
Сравнение моделей: pay-as-you-go vs. капитальные вложения в on-prem
Штрафы за превышение лимитов или несоблюдение контрактов, перенос данных, лицензирование
- Юридические и контрактные ограничения, которые приходят вместе с облаком
Соблюдение законодательства (о перс. данных, etc..)
Кто несет ответственность за инциденты (учетка данных, сбои в работе)
- Управление и мониторинг: чем отличается контроль инфраструктуры в on-prem и облаке
Автоматизация: как облако упрощает мониторинг и управление
Сравнение инструментов: традиционные vs. облачные
- Архитектура отказоустойчивости: кто справляется лучше — облако или on-prem?
Параметры отказоустойчивости: что включает в себя архитектура в обоих случаях
Кейсы: примеры успешных и неуспешных решений в облаке и on-prem
Гибридные варианты
- Качество сервисов: почему SLA облака не всегда соответствует реальности
Анализ: что включает SLA и как его интерпретировать
Всегда ли оператор выполняет свои обещания
Независимый мониторинг, стресс-тесты инфры
Программный комитет ещё не принял решения по этому докладу
Распределённая инфраструктура k8s. О чём не напишут в статьях
Многие команды разработки за 15 лет существования Kubernetes внедрили этот инструмент в production как облачный сервис или bare-metal реализацию. В нашей компании bare-metal k8s стал основой внутренней платформы для разработчиков, которая должна быть отказоустойчивой, поэтому он живёт в нескольких цодах. На докладе я поделюсь:
- Экспертизой в расселении Kubernetes в разные цоды
- С какими проблемами мы столкнулись при внедрении DevOps практик на такую архитектуру
- Как мы решали вопросы межцодной коммуникации между ресурсами внутри K8s и контроля их доступности
- Каким образом можно обеспечить доступность ресурсов при сбоях в облаке или датацентре
- Какие есть варианты для безопасной коммуникации в межцоде
Программный комитет ещё не принял решения по этому докладу
Трудности запуска своего автоскейлера на on-premise 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 после восстановления основной инфраструктуры
Программный комитет ещё не принял решения по этому докладу
Технологический суверенитет (2)
Круговорот апгрейда СХД
Хочу рассказать о том, как проектируем обновление программного обеспечения, как мы планируем и преодолеваем трудности, возникающие при выполнение процедур обновления сложных программно-аппаратных комплексов
Программный комитет ещё не принял решения по этому докладу
Как выглядят DevOps-практики у производителей ПАК
Когда мы говорим про лучшие (или худшие) DevOps-практики, на ум приходят конвееры поставки на тестовые стенды, в продуктовое окружение, контейнеры и прочие технологические сущности. Между тем - DevOps это не столько методология, сколько идеология, автор в этом в очередной раз убедился, непосредственно участвуя в процессе взрываного роста производства наших ПАКов (программно-аппаратных комплексов, Машин различного назначения). Средства автоматизации неожиданно стали приносить больше проблем, чем пользы, и проблемы эти пришлось решать скорее в идеологическом разрезре, а уже потом чинить технологии.
Программный комитет ещё не принял решения по этому докладу
Рост и развитие специалиста (14)
Закулисье тайм-менеджмента. Что скрывается за «мне не хватает времени».
Сколько часов в день вам не хватает, чтобы всё успеть?
Насколько вы довольны своими навыками управления временем?
За последние 15 лет я побывал в роли предпринимателя, CTO, продакт-менеджера, программиста, консультанта. Нехватка времени - это моя большая боль. И я перепробовал десятки инструментов тайм-менеджмента.
Исследуя проблему нехватки времени, я пришёл к выводу, что нехватка времени — это не про время. Это симптом, за которым скрывается настоящая причина: нехватка энергии, прокрастинация, расфокус и несколько других.
Я поделюсь результатами своего исследования, и расскажу, какие системные причины приводят к нехватке времени.
Также, я поделюсь инструментами, подходами и лайфхаками, которые лично мне помогают управлять своим временем - просто и достаточно эффективно.
Помимо этого я расскажу, как понимание нейробиологии и физиологии поможет лучше управляться со временем.
Идеальным результатом выступления для меня будет, если ты найдёшь для себя один подходящий инструмент, и внедришь его в этот же день.
Программный комитет ещё не принял решения по этому докладу
eNPS чемпионы или как мы внедряли "честный" карьерный трек
Почему типовые карьерные треки не работают?
Опыт построения рабочего карьерного трека в компании Cloud.ru
Программный комитет ещё не принял решения по этому докладу
От HR до DevOps: инсайдерское руководство по выживанию
Уникальный взгляд на профессию DevOps от человека, который прошёл путь от поиска инженеров до превращения в одного из них. Разберём, как изменились требования к DevOps за последние годы, какие навыки действительно важны для карьерного роста, и как использовать знание процессов найма для построения успешной карьеры в IT. Практические советы, которые вы не услышите от обычного технического специалиста.
Программный комитет ещё не принял решения по этому докладу
Менторство в DevOps: стоит ли пользоваться услугами стороннего ментора?
Успешно участвую в платформе https://getmentor.dev/ как ментор.
За 1.5 года успел помочь 12 обратившимся с совершенно разным бэкграундом и исходными запросами.
Также пробовал себя в роли менти.
Готов предложить аудитории обзорный доклад с состоянием менторства в мире и на русскоязычном рынке в целом (провести небольшое исследование), рассказать чего не нужно ожидать от такого рода сотрудничества, а в чем может быть совершенно неожиданная польза для ментора в том числе.
Ответим на вопрос, чем менторство лучше и хуже внутрикорпоративного обучения.
А как бонус проведем сравнение живого ментора и ChatGPT помощника.
Программный комитет ещё не принял решения по этому докладу
Центр компетенций - улучшение DevOps практик в компании. Путь проб и ошибок.
Путь гипотез, проб, ошибок и ркзультатов
Проблематика больших распределенных по стране компаний.
Цели на этапе создания и контекст.
Метрики "измерения" ЦК и 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. Хочу поделиться опытом как я принимал решение, на что обращал внимание и жалею ли теперь. Хочу поделиться опытом тем, сейчас стоит перед таким выбором или задумывается о стартапах в целом
Программный комитет ещё не принял решения по этому докладу
Триллер "Нанимали сисадмина, прибежала стая 'Ops-ов' или как отрасль убила профессию системного администратора"
Казалось бы, тема «DevOps - кто этот зверь?» уже избита и на конференции DevOps-ов даже как-то не ком-иль-фо ее поднимать. Однако, я предлагаю подойти к ней не со стороны ‘opsa, а со стороны нанимающего к себе в команду инженера.
Что мы видим сейчас на рынке и почему это боль? Я расскажу, как мы искали SysOps-a среди DevOps-ов. Как отрасль убила профессию Системного администратора и чем теперь это чревато.
Разберу один день из будней классического DevOps-a и осознанно подниму холиварный вопрос - DevOps - это методология, содержащая в себе набор инструментов, или просто набор инструментов, которыми пользуются все остальные Ops-ы? И почему же быть просто системным администратором в наше время стало стыдно?
Программный комитет ещё не принял решения по этому докладу
Я, как стартап. Главный проект моей жизни.
А что, если классические бизнес-технологии применить к своей собственной жизни? Спринты, пирамида метрик, целеполагание, стратегия, кастдевы...
Я расскажу про свой опыт и про подходы, которые помогут посмотреть на себя, как на стартап, продукт или проект.
Программный комитет ещё не принял решения по этому докладу
FrontOps: как и зачем дружить с фронтендерами для достижения общих целей
В современном процессе разработки программного обеспечения применение FrontOps-практик к фронтенд-приложениям становится все более важным для DevOps-инженеров. Автоматизация процессов сборки и деплоя фронтенда не только ускоряет выпуск новых фич, но и повышает надежность системы в целом. Внедрение автоматических тестов различных уровней (юнит, интеграционные, e2e) в CI/CD пайплайны гарантирует сохранность существующей функциональности при добавлении новых изменений. Оптимизация пайплайнов и выбор эффективных и современных инструментов, таких как pnpm, bun и vite, значительно улучшают эффективность и скорость доставки продукта.
Использование инфраструктуры как кода (IaC) для фронтенда решает проблему несоответствия сред разработки, тестирования и продакшена, снижая риски при деплое и облегчая масштабирование. Реализация наблюдаемости и мониторинга с помощью инструментов типа Sentry является критически важной для поддержания высокого качества пользовательского опыта и быстрого решения возникающих проблем. Уделение внимания безопасности с самого начала защищает от распространенных уязвимостей посредством интеграции DevSecOps-подходов и использования инструментов вроде ESLint, SonarLint и DefectDojo.
Тесное сотрудничество с фронтенд-разработчиками способствует улучшению продукта и ускоряет процессы релиза, подчеркивая важность эффективного взаимодействия между командами и общих целей.
Программный комитет ещё не принял решения по этому докладу
Компетенции DevOps, от антипаттернов к паттернам
Кто же такой DevOps-инженер?
Какими он компетенциями он должен обладать на разных профессиональных уровнях?
Как попасть в профессию и куда в ней развиваться?
Рассмотрим самые частые ошибки молодых инженеров и подумаем, как их не совершать.
Программный комитет ещё не принял решения по этому докладу
Митапы (1)
Fail-митап
Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!
В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.
Доклад принят в программу конференции
Круглые столы (2)
Панельная дискуссия «AI для инженера»
Сo-pilot в разработке — тренд последних лет. Однако этот трек не единственный в ландшафте AI-оптимизации внутренних процессов в бигтехе.
А о чем мы поговорим?
Кажется есть парочка мыслей:
1. как в целом можно замерять эффективность производственного процесса — немного менеджерской теории, чего мы там все меряем;
2. AI есть, а о пользе слышали? Когда нас всех уволят?
3. как можно использовать AI в разных ролях: поддержки, дизайна, аналитики, солюшн-архитектуры, тестирования;
4. когда это становится масштабируемым.
5. Как внедрять AI? И почему большинство инженеров не так активно его используют?
Поищем общие и конфликтующие позиции, послушаем success-stories из первых рук.
Программный комитет ещё не принял решения по этому докладу
Ой, он нас посчитал
Можно доклад, но круче будет собрать дискуссию и похоливарить на эту тему.
1. Краткая история метрик оценки разработки: строчки кода и прочее
2. DORA, QUANT, SPACE
3. Что делает и куда смотрит сбер.
4. Почему метрики для оценки разработки - разрушают команду
5. Как одна метрика разрушила всю команду.
6. А можно ли контролировать 800+ инженеров без метрик?
7. Почему метрики - это правильно и хорошо
Программный комитет ещё не принял решения по этому докладу
Воркшопы (8)
Воркшоп "Чат-бот как панацея от канцелярских ответов DevOps"
В каждой развивающейся компании вместе с увеличением штата сотрудников появляются нормативная и техническая документации. С течением времени они разрастаются и появляется многоуровневая иерархия. Всё это приводит к чрезмерным тратам времени и снижению производительности новичков и DevOps-составителей, к которым адресуются все вопросы.
На воркшопе мы вместе разработаем умного и вежливого чат-бота на базе LLM, исчерпывающим образом отвечающего на вопросы по документации от DevOps-инженеров, и поговорим о применённых технологиях.
Также поделюсь опытом внедрения корпоративного чат-бота в нашей компании и расскажу о возможностях расширения функционала.
Программный комитет ещё не принял решения по этому докладу
Воркшоп "Кунг-фу STATIK. Как построить свою Канбан-систему"
Канбан-метод — это метод для постоянного совершенствования любых сервисов, связанных с интеллектуальным трудом, таких как разработка ИТ-продуктов. Канбан-метод состоит из более 150 инструментов и практик, одним из которых является STATIK (Systems Thinking Approach to Introducing Kanban) - cистемный подход к применению Канбан-метода. STATIK помогает начать использовать Канбан-метод и выявляет многие неочевидные факты и детали Вашего сервиса. В ходе воркшопа мы разберем основные шаги STATIK и попробуем спроектировать Канбан-систему. Все практические задания и теория, как Вы догадались из названия воркшопа, будут метафорическими, и построенными на основе известного мультфильма "Кунг-фу Панда". После воркшопа Вы сможете применить STATIK в своем сервисе и начать эволюционные улучшения. Так что - вперед, мир Кунг-фу и Канбан ждет Вас!
Доклад принят в программу конференции
Мастер-класс "От данных до готового мониторинга всего 5 минут пешком"
Мы в Т любим автоматизацию и системный подход, мониторинг не исключение! На воркшопе расскажем, как можно при помощи крутых систем добраться до готового процесса мониторинга прямо перед релизом, не теряя времени. Как можно эффективно использовать логи и трейсы для определения причин сбоев. Специально для участников воркшопа устроим сбой на проде, о котором нас в режиме реального времени оповестит свеженастроенный мониторинг. Найдем причину сбоя вместе и починим прод.
Хороший мониторинг близко.
Программный комитет ещё не принял решения по этому докладу
Деловая игра Бизнес-тренажёр 22
Бизнес-тренажёр 22 - это игра, в которой можно потренироваться и поэкспериментировать с различными стратегиями развития бизнеса. Кейсы в игре "основаны на реальных событиях", что делает сильно приближенной к реальности.
Программный комитет ещё не принял решения по этому докладу
Нетворкать: когда, с кем, зачем и как?!
Расскажу о нетворкинге (не путать со смол-током):
* ЗАЧЕМ?!
* что это за общение и как быть целеустремленным в любой коммуникации,
* с чего начать разговор,
* чем продолжить,
* как закончить,
* как обменяться контактами,
...произведя правильное впечатление.
Участники мастер-класса унесут с собой
* наброски рассказа о себе несколькими способами,
* понимание ЧТО, КОМУ, О ЧЁМ и КОГДА рассказывать,
* какие и кому задавать вопросы.
Доклад принят в программу конференции
Нескучная лекция о гормонах
Поднимите руку, если вас бесят разные "разогревы" и "айсбрейкеры" на тренингах, скрам-ритуалах и мероприятиях.
Я раньше к ним относился очень скептически. Но поменял своё к ним отношение, когда понял, что происходит с нами на уровне физиологии и гормонов в этм моменты.
На воркшопе мы на практике познакомимся с "гормонами счастья" и "гормонами стресса", и прочувствуем на себе, как простые лайфхаки и упражнения помогут нам поменять своё состояние. Тем самым повлиять на свою эффективность, продуктивность. И в том числе профилактировать выгорание.
Также я поделюсь лайфхаками, как эти знания можно использовать в жизни.
Программный комитет ещё не принял решения по этому докладу
Воркшоп "Масштабируем K8s: от классики до event-driven похода"
Автомасштабирование узлов кластера Kubernetes и горизонтальное масштабирование подов позволяют быстро расширить ресурсы при пиковых нагрузках. Но сложные приложения могут не нагружать поды или узлы максимально, но требовать дополнительных ресурсов, например, для параллельной обработки нескольких объектов в очереди. То есть триггером масштабирования кластера может быть не утилизация, а события от внешних систем — очереди сообщений Kafka, системы мониторинга Prometheus или, например, от платформы CI/CD. Мы вместе попробуем запустить такое приложение, посмотрим, как с ним работают классические подходы автомасштабирования и попробуем масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler).
Программный комитет ещё не принял решения по этому докладу
Воркшоп "Механизмы безопасности в Astra Linux"
Astra Linux содержит ряд инструментов для обеспечения информационной безопасности, которые не всегда хорошо понимаются. Например, мандатный контроль целостности (МКЦ), который совершенно не про контрольные суммы, а про то, что даже root не всегда root. Или приносит с собой мандатный контроль доступа (МКД), который крайне непросто понимать тем, кто не занимался этим вопросом никогда.
Посмотрим на практике, что означают механизмы МКЦ и МКД, своими руками потыкаем в Astra Linux и научимся понимать, где и что нам нужно из этого использовать.
Доклад принят в программу конференции
TechTalk (2)
А давайте построим систему индексации данных: с чего начать, на какие грабли наступить и к чему прийти, чтобы она заработала
В 2ГИС поисковые данные обновляются довольно часто — особо активные сегменты могут обновляться раз в 10 минут. Насколько быстро эти данные начнёт использовать поисковый движок, настолько свежие данные увидит пользователь. Поэтому основная задача — быстро доставить свежие данные до пользователя.
При этом данные могут со временем менять свой формат, поэтому мы должны уметь работать с разными версиями данных и уметь без проблем откатываться на более старые версии. Должны обновлять данные одновременно и своевременно на всех машинах, где осуществляется поиск. Мы должны видеть на каждой из машин, насколько свежие индексы на ней находятся и всё ли их множество присутствует, иметь возможность видеть аномалии.
Я расскажу, как построить систему, которая в реальном времени обновляет данные и позволяет работать с разными версиями данных.
Программный комитет ещё не принял решения по этому докладу
Сборка монорепозитория: реально ли за минуту?
ВКонтакте можно назвать колыбелью монорепозиториев. Процесс сборки кода из таких репозиториев обычно занимает много времени. А если учесть, что одновременно над проектом работают множество разработчиков с различными изменениями, ситуация становится еще сложнее. Тем не менее, оптимизация этого этапа является ключевым моментом на пути к выпуску продукта и позволяет сократить время вывода на рынок. В докладе расскажу, как ускоряем процесс сборки и какие методы используем для эффективной работы с зависимостями.
Программный комитет ещё не принял решения по этому докладу