Доклады

Всем давно известно, что pod в Kubernetes может включать в себя несколько контейнеров. Например, один для приложения, второй для Service Mesh, третий — журналирование, а еще четвертый, пятый и т.д. В итоге много контейнеров, много вопросов:
* Зачем нужны дополнительные контейнеры, какие задачи они должны решать, а какие нет?
* Как изолировать платформенные контейнеры от пользовательских приложений?
* Как организовать автоматизацию процесса и не сломать кластер Kubernetes?

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

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

Возможно ли угодить всем и сразу?

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

Уверен, что вы слышали про platform engineering. Это процесс создания и предоставления удобных сервисов самообслуживания командам и инженерам с целью ускорения потока создания ценностей, снижения объема нецелевых активностей команд, а также повышения качества, надежности и безопасности создаваемых решений. Звучит круто! Но как начать работать в таком процессе, как набрать нужные компетенции или систематизировать практики? Именно эти вопросы являются одними из причин создания мной открытого фреймворка Platen (www.platen.dev), который раскладывает все по полочкам.

Весь доклад будет построен исключительно на реальных кейсах, раскрывающих следующие вопросы:
1. отличия между различными ролями: "DevOps-инженер" и платформенный инженер;
2. зачем нужно становиться платформенным инженером;
3. почему нельзя "купить" платформу или найти "готовую";
4. дорожная карта становления платформенным инженером;
5. основные роли в платформенной команде: владелец платформы, платформенный инженер, архитектор платформы. Карьерный трек инженера;
6. что такое фреймворк Platen, и зачем он нужен;
7. основные части фреймворка: введение, артефакты, оценка и стратегирование, реализация;
8. про Platen metrics radar (PMR) и почему отслеживание "4 ключевых метрик" вам не помогут;
9. как составить модель предоставления платформенных сервисов (as-is и to-be);
10. инструменты изменения мышления/культуры всей компании и инженеров, в сторону платформизации;
11. что такое самодостаточные/потокоцентричные команды, и причем здесь ответственность в конвейере производства. Как командам доставлять изменения до клиентов самостоятельно в платформенной модели.

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

Расскажу:
* про то, как стандартизировать подходы, упростить DevOps и не выстрелить себе в ногу;
* про жизнь в новых реалиях — как создать импортозамещенную Kubernetes-платформу;
* про технологии, которые убеждают команды разработки «жить дружно».
А также обсудим перспективы развития движения.

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

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

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

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

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

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

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

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

А что, если пойти другим путём? Не искать идеальных кандидатов, подходящих именно для вашей компании и проекта, а вырастить их самим?

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

Сравнение различных подходов для автоматизированного создания окружений для R&D-команд.
Три подхода:
* Terragrunt multiple environments;
* Kubernetes Namespaces as Environments;
* Crossplane.
Для всех трех подходов используется Git as Source of Truth.

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

В докладе будут рассмотрены распространенные варианты реализации с помощью Ansible, Cluster API, OpenShift Machine Config с разбором плюсов и минусов и предложен собственный оператор с описанием основных решений:
1. Элементы конфигурации — чем управляем.
2. Логика контроллеров (как не уронить весь кластер одним движением).
3. Drift prevention & self healing.
4. Как масштабировать решение на сотни узлов.

В своем докладе расскажу:
* как устроен CI/CD в Ozon (архитектура и чуть детальнее рассмотрим каждый компонент);
* какие основные крон-джобы для автоматизации рутинных задач мы используем;
* на примере покажу, как происходит взаимодействие компонентов автоматизации работы джоб в пайплайне (баш-скрипт, который курлом подкачивается в джобах, который подкачивает консольную утилиту + хелм-чарт);
* отдельно уделим внимание консольной утилите, реализующей автоматизацию пайплайнов;
* покажу, как мы реализуем джобы с помощью консольной утилиты с подробным разбором;
* про код-фриз, как он у нас реализован;
* о подсчете времени работы джоб/секций скриптом внутри джобы и как мы эту информацию отправляем в елк/пром и что с этим делаем (вводная про ТТМ);
* о ТТМ, что это для нас, как считаем, какой процесс по снижению ТТМ и т.д.

Kubernetes — это YAML-манифесты. Так было для нашей DevOps-команды долгие годы: Helm, GitOps, Senior YAML Developers. Когда конфигурация приближается к десяткам и сотням наборов YAML-манифестов, появляются большие сложности с их поддержкой. Лишний отступ, булевое значение вместо строки или число в кавычках легко превращаются в часы отладки. Можно ли сделать лучше? Можно!

В своем выступлении я расскажу, как опять начать радоваться жизни при написании манифестов, получить возможность наследования, композиции и валидации структур и полей. А бонусом я покажу, как жить без Helm в контексте работы GitOps.

За более чем 10 лет DevOps было сформировано много практик, которые помогают ускорять разработку. Обычно говорят про CI/CD и контейнеры, но это всего лишь одна сторона вопроса. Другая важная составляющая — изменение модульности и интеграционных паттернов в самих приложениях. Третья составляющая — описание инфраструктурных компонентов в виде кода.

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

Поговорим об этом на докладе.

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

Работая с terraform на многих проектах, хотелось найти такой подход к архитектуре кода, чтобы он хорошо подходил сразу по многим требованиям:
* и для проекта в начальной стадии — общих ресурсов по максимуму;
* и для проекта в релизной стадии, когда нужна изоляция dev и prod;
* обеспечивалась достаточная безопасность в pipeline и разграничение доступа к управляемым IaC-ресурсам;
* скорость и минимизация времени выполнения pipeline;
* DRY — как можно меньше повторяющегося кода;
* гибкость в использовании такого кода;
* минимальный TTM и TCO;
* максимальная возможная автоматизация;
* простой git flow.

Спешу поделиться тем, что в итоге получилось.

В докладе я раскрою тему создания и использования операторов Kubernetes.

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

FluxCD v2 — это яркий и преданный представитель GitOps-принципов. За несколько лет был проделан путь от просто полезного инструмента до зрелой масштабируемой GitOps-платформы. Материалов о том, как организовать структуру GitOps-репозиториев, не хватает, и на старте сложно предсказать, с какими ограничениями и сложностями можно столкнуться на крупных масштабах.

В своем докладе я попробую показать FluxCD непредвзято, со всеми плюсами и минусами, расскажу, о чем стоит подумать при добавлении инструмента в свою инфраструктуру. Продемонстрирую возможности модульного подхода к управлению множеством кластеров, используя принцип DRY и сохраняя структурность и читаемость кода инфраструктуры. Рассмотрю применимость к средам, создаваемым по требованию на этапе PR. Также поговорю про автоматическую проверку и тестирование изменений в код инфраструктуры. Идем со мной в GitOps?
https://www.globaldots.com

История о том, как мы получили минималистичный инструмент управления конфигурацией хостов в виде host-group-operator, используя Kubernetes в качестве универсального control-plane.

Затронем следующие темы:
* Как перестать думать о поддержке системы управления конфигурацией.
* Как управлять конфигурацией хостов так же просто и единообразно, как мы управляем стандартными объектами Kubernetes.
* Как упростить управление релизами логики, отвечающей за изменение конфигурации хостов.
* Как мы разработали host-group-operator, какие шишки при этом набили и сколько ушло времени на разработку.
* Когда стоит задуматься о разработке собственного оператора для управления произвольными объектами инфраструктуры.

* Как получить full stack-распределенную трассировку — от клика пользователя в SPA или мобильном приложении через все сервисы до SQL-запросов в БД.
* Автоматическая и ручная инструментация приложений.
* Как найти узкие места в работе приложений путем анализа трейсов, логов и метрик.
* Блеск и нищета OpenTelemetry, настоящее и будущее стандарта.

* Работа с дев-инфраструктурой как с продуктом.
* Dora-metrics.
* История развития дев-инфраструктуры, проблемы и вызовы.
* Observability деплоя в дев.

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

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

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

Сложно представить современный проект без системы мониторинга. Prometheus стал здесь стандартом де-факто.

Начнем с паттернов, лежащих в основе любой современной TSDB. Вспомним, что было до Prometheus и почему именно Prometheus (с TSDB под капотом) стал стандартом.

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

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

В этом докладе я покажу вам, как работает KubeVirt изнутри.

Будут затронуты следующие темы:
* как запускать мутабельные виртуальные машины в иммутабельных подах K8s;
* чем отличается KubeVirt от традиционных облачных платформ;
* что не так с сетью в KubeVirt;
* как выполняется живая миграция ВМ;
* общение с сообществом и участие в процессе разработки.

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

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

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

Расскажу о том, как используется Salt (saltproject.io) в Managed Databases в Yandex Cloud.

* Зачем нам, вообще, Salt, какой частью функциональности мы пользуемся.
* Что делать, когда хостов десятки тысяч, один salt-master не справляется, а выкатить нужно на конкретную машину.
* Как мы отлаживаем упавшие запуски стейтов/модулей.
* Про интеграцию Salt'а в систему распределенной трассировки.
* Как тестируем свои модули/стейты и всю конструкцию в целом.

Подробный разбор основных инструментов для управления трафиком, которые даёт нам Istio:
* DestinationRule.
* PeerAuthentication.
* AuthorizationPolicy.
* VirtualService.

В рамках доклада мы разберём в деталях, как устроены эти инструменты на уровне сайдкара, что умеют и, самое главное, чего не умеют. Также мы изучим неочевидные нюансы при реализации паттернов управления сетевым трафиком:
* Mutual TLS.
* Outlier Detection.
* Authorization.
* HTTP Routing (Canary Deployment).

Дополнительно мы рассмотрим возможности Istio по организации отказоустойчивых геораспределённых кластеров, и я поделюсь опытом компании Флант по внедрению разных подходов:
* Multicluster.
* Federation.

1. В чем суть zero trust. Как делать развертывание приложений безопасно.
2. Варианты имплементации zero trust в рамках кластера K8s (Service-mesh, CNI).
3. Как сделать безопасно и быстро. Баланс между уровнем безопасности и временем, потраченным на его настройку.
4. Использование Calico. Разберем кейсы, посмотрим код.

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

Проблемы:
* CFS и троттлинг CPU;
* Slow connect (TCP Retransmit) via Node Port;
* рандомные рестарты POD с PHP.

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

Помочь могут архпринципы, но есть еще две проблемы:
1. команда не понимает, что это;
2. после написания их никто не применяет.

Как собрать и автоматизировать архпринципы, в которые команда поверит.

Описание проблем при настройке Istio
* Ожидание vs реальность.

Абстракции Istio и Envoy
* Не все так однозначно.

Маппинг абстракций Istio к абстракциям Envoy
* Костыли и веревочки.

Подходы к трабл-шутингу
* Инструменты и практики.

Так уж сложилось, что тема SRE получила наибольшее распространение именно в серверных средах — бэкенды, апишки, базы. Однако с ростом количества мобильных телефонов и увеличением их роли в жизни людей вопросы доступности, наблюдаемости и надёжности мобильных приложений стали вставать всё острее.

В этом докладе я расскажу про особенности SRE в мобильных приложениях и сосредоточусь на их observability. На основе опыта мобильного банка — основного приложения Тинькофф — расскажу, как и за какими метриками мы следим.

Паттерн рейт-лимитера кажется одним из самых очевидных паттернов. Так ли он прост на самом деле?

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

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

"Ваш сервис работает медленно и с ошибками!" Как часто приходилось такое слышать? А что такое медленно и какое количество ошибок считать допустимым? А главное, как узнавать о проблемах раньше, чем пользователи? В таких случаях вспоминают про SLA и фиксируют для других и самих себя требования к работе сервиса.

У нас было несколько команд разработки, большой объем критичных для компании задач, сжатые сроки для их реализации, много новых микросервисов и старого легаси, команда SRE, которой нужно всё это поддерживать, и платформенная команда, которая попыталась реализовать решение для мониторинга SLA микросервисов с минимальными отвлечениями на это всех остальных команд. На выходе получили оповещения о нарушениях SLA "из коробки" и много пунктов для дальнейших улучшений.

Из доклада вы узнаете, как построить процесс управления инцидентами с нуля, снизить риски и улучшить свой RTO. Компания YCLIENTS поделится своим опытом улучшения уровня качества обслуживания за счет инцидент-менеджмента, а также раскроет подводные камни и сложности выстраивания процесса.

Избыточные алерты убивают людей. Буквально.

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

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

В докладе я расскажу, как умение погружаться в код и отладку сторонних продуктов помогает нам повышать стабильность и находить исходную причину отказов на примере исправления реальных сбоев Sage, высоконагруженной платформы мониторинга с входящим потоком 2,5 Гбайт/сек, использующего Elasticsearch и VictoriaMetrics под капотом.

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

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

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

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

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

И всё это в зависимости от размера компании, поскольку он имеет значение.

В докладе рассматриваются вопросы, с которыми сталкиваются компании при первом подходе к внедрению управления секретами через Vault:
* Сколько ресурсов ему нужно?
* Как быстро он работает?
* Какое хранилище выбрать и почему?
* Как подключать приложения?
* Как запустить в него команды?
* Как скрыть секреты в пайплайне?

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

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

В ходе доклада мы разберемся, как контролировать сторонние зависимости в вашем продукте, как бороться с malware/protestware в библиотеках/пакетах, какие меры помогут обезопасить ваш продукт.

1. Не надо стесняться! Или история о том, когда глаза боятся, а руки делают.
2. Цифровая трансформация и проблемы безопасности Энтерпрайза.
3. Цифровая трансформация — совместный вызов ИБ и IТ.
4. Изменение фокуса команд разработки и подсвечивание задач ИБ.
5. Автоматизация — двигатель прогресса! История создания платформ безопасности.

Существует большое количество различных инструментов безопасности (SCA, SAST, CA, etc.) которые встраиваются в CI. Open Source-решения для этих задач ведут себя по-разному, имеют различные форматы отчетов и механизмы исключений.

В этом докладе я расскажу о нашем опыте работы с Open Source-инструментами безопасности и про внутренний инструмент Quality Gate, который позволил привести различные контроли безопасности к единой схеме работы в CI.

Supply chain security или безопасность цепочки поставок приложений — это отдельный мир со своими угрозами и практиками по защите. На базе основных шагов превращения исходного кода в готовый продукт/сервис, предоставляемый конечному пользователю, в этом докладе будут рассмотрены:
* основные угрозы, применимые к CI/CD, и примеры их реализации;
* методы и способы их защиты, не всегда требующие сложных технических перемен.

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

Теория:
* Расскажем о сценариях использования Kafka.
* Узнаем, что такое консумер, продюсер и брокер.
* Разберём, как связаны топики, партиции и сегменты.
* Поговорим о формате сообщений в Kafka.
* Расскажем о лидере партиций, репликации данных и партицировании.
* Поговорим о гарантиях доставки сообщений и идемпотентности.
* Выясним, что такое консумер-группа и ребалансировка консумеров в ней.

Практика:
* Склонируем репозиторий с конфигурацией Docker Compose.
* Подберём конфигурации топиков и создадим их.
* Настроим и запустим продюсер.
* Настроим и запустим консумер.
* Изменим оффсет для консумер-группы.
* Посмотрим на основные показатели в Grafana.

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

Однако среди существующих лидеров случаются и нестандартные кейсы. Одним из них является опыт «Газпром-Медиа Холдинга», который запустил свою OTT-платформу кинотеатр Premier.

В своем докладе мы поделимся опытом выстраивания процессов с учетом уникальных и неординарных продуктов компании:
• Специфика отрасли. Особенности разработки и эксплуатации медиа- и видеосервисов;
• Capability создания динамических окружений для разработки и тестирования. Нюансы технологических решений (Управление множеством Kubernetes кластеров, Multitenant с GitOps);
• SDLC-метрики. Что было до внедрения платформы и после. Мониторинг эффективности разработки и поставки ПО с использованием ключевых DevOps-метрик;
• Вызовы и сложности, возникавшие при внедрении SDLC-метрик и платформы;
• Оценка эффекта от изменений и перспективы развития.

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

Уже сейчас можно выделить три крупных блока практик:
* SRE-практики (вобрали в себя инженерию работы с распределенными системами, практики совместной работы со сложными системами),
* Platform Engineering (инженерия инфраструктурных решений, работа с платформой),
* Value Stream Manegement (командные топологии и взаимодействие команд).

В докладе хочу разделить эти практики, рассказать их суть и показать, что это и есть DevOps.

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

Доклад научит DevOps'ов лучше понимать бизнес, а бизнес лучше понимать, что нужно от DevOps'ов.

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

История о том, как мы превратили классический "отдел DevOps" в продуктовую команду с сильным техническим центром.

В докладе расскажу:
* как нам помогла Spotify-модель и почему DevOps-трансформация лучше ложится на продуктовый подход;
* какие топологии команд попробовали прежде, чем перешли на текущий формат, и с какими болями столкнулись в процессе перехода;
* как трансформация повлияла на ТТМ и отказоустойчивость сервисов;
* с какими задачами сталкиваемся сейчас. Как сделать единую систему грейдов для инженеров, находящихся в совершенно разных командах? Как настроить дублирование и дежурства, учитывая часовые пояса?
* что у нас пока что не получилось, и какие планы на будущее.

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

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

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

В рамках доклада эксперты Платформы Сфера впервые представят результаты исследования российского рынка инструментов DevOps за 2022 год.

О чем можно будет узнать из отчета:
* в каком объеме применяются инструменты DevOps в российских компаниях;
* что, с точки зрения IТ-менеджеров и DevOps-разработчиков, является основными преимуществами в использовании подходов DevOps;
* сдерживающие факторы для использования DevOps и планы компаний по расширения использования этих инструментов;
* степень автоматизации процессов конвейера разработки с применением инструментов, поддерживающих DevOps, в российских компаниях;
* планы по замене инструментов разработки в связи с уходом ряда компаний с российского рынка (что на что планируется менять);
* степень использования облачных сервисов и ПО с открытым кодом.

Исследование проводилось с декабря 2022 по конец февраля 2023. Все участники сессии смогут бесплатно получить электронную версию отчета.

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

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

Коллаборативные практики проникают в IT на всех уровнях разработки: парное программирование, архитектурные комитеты, профессиональные комьюнити. Ex nihilo nihil fit — говорили римляне.

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

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

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

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

Что может быть прекраснее четко функционирующего конвейера? Только четко функционирующий конвейер, начинка которого сделана из качественных деталей и легко обслуживается. А ведь с кодом примерно та же история: о чистом коде все говорят, его редко видят, но еще реже — пишут. И зачастую непродуманная архитектура кода пайплайнов приводит к плохо переиспользуемым библиотекам, неявной структуре программы, его сложной дальнейшей модификации и адаптации под разные продуктовые команды. Особенную боль это доставляет тогда, когда им пользуетесь не только вы, но и ваши коллеги из соседних продуктовых команд. Настало время это исправить! Ведь пайплайн — это тоже сервис, и к нему должны предъявляться такие же требования, как и к внутреннему продукту компании.

В этом докладе мы:
* попробуем применить подход «12-факторного приложения» к пайплайну;
* посмотрим, как основные парадигмы ООП можно использовать при разработке пайплайна;
* научимся проводить декомпозицию кода пайплайна на интерфейсы;
* разберемся, как реализовывать платформно-зависимые участки кода так, чтобы ваш пайп мог работать и в Jenkins, и в Gitlab CI, и в любой другой среде;
* поймем, почему иногда полезно делать автотесты для кода пайплайнов.

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

Мы расскажем про полностью локальную инфраструктуру для разработки Kubernetes-native ПО на примере разработки Luntry. Как, купив 2 сервера в самом начале, можно пережить трехкратный рост количества микросервисов и трехкратный рост команды. Как при этом минимизировать ручную работу, сделать разработчиков довольными и не платить за облака.

DevOps был призван сломать стену между Dev и Ops, но, оказалось, ломать её согласны только «девопс-инженеры» и то только для того, чтобы построить себе уютный колодец из её обломков.

В докладе спускаемся на дно колодца и обсуждаем проблему токсичности в DevOps-сообществе.

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

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

За последние два года я провел более ста собеседований и помогал развиваться многим людям, которые вырастали из Trainee в Junior, из Middle — в Senior и т.д. Всё это дало мне некоторое понимание и видение, которое культивировалось в Open Source-проект, посвященный развитию инженеров и тех, кому интересно DevOps-направление.

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

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

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

В своём докладе я расскажу, как построено техническое интервью в нашей команде.

1. Что такое CI/CD.
2. Что должна уметь CI/CD-система.
3. Какие CI/CD-системы есть на рынке, сравнение, выбор.
4. Каким должен быть идеальный CI/CD-пайплайн.
5. Какие CI/CD-системы есть в Газпромбанке, почему именно они.

Контейнерная инфраструктура — это не новшество или тренд, а уже проверенный и надежный подход к развитию IT-платформ. Мы в Мир Plat.Form пришли к технологиям контейнеризации в уже далеком 2017 году. И Антон расскажет, "как было" и "как стало".

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

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

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