Доклады

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

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

В моем докладе вы узнаете:
* технологические составляющие платформы;
* экономические составляющие платформы;
* как выбрать базовую стратегию обоснования необходимости PE для своей компании;
* модели развития платформы в зависимости от инвестиций;
* проблемы при масштабировании платформы и пути их решения;
* внутренняя платформенная команда: части, состав, проблемы в работе;
* платформа, обязательная к использованию или по желанию команд: как лучше?
* как сравнить жизнь с платформой и без нее;
* как сделать внутренних клиентов вашей опорой перед руководством;
* кейсы из опыта MOEX Group: как мы строим единую отказоустойчивую платформу для всех компаний Группы.

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

В современных реалиях, когда кубер стал практически стандартом, одной из типовых задач становится непосредственно развёртывание и дальнейшее сопровождение K8s-кластеров. И если их немного, то это не представляет особой сложности, проблемы начинаются, когда их нужны десятки, сотни, и они нужны on-premise, вчера, ну или через 5 минут.

В этом докладе я расскажу о нашем опыте решения как раз такой задачи.

* Как наверняка понять, что платформа вам нужна?
* Как (не) выстрелить себе в ногу, внедряя платформу?
* Что придется сломать в процессах, системах и головах людей?
* Где придется признать, что ломать дороже (даже в долгой перспективе), чем оставить все как было?
* Какую ценность должна нести платформа, чтобы "продать" ее разработчикам?

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

В докладе расскажу про TelcoCloud в части контейнеров, а именно: как мы тестировали производительность сети на одном из наших проектов для телеком-заказчика. Расскажу, кому и зачем это нужно. Покажу методику и результаты тестирования, где сравню пропускную способность оверлейной сети OVN-Kubernetes и SRIOV+DPDK.

А на сладенькое — расскажу немного боли про переход с OpenShift на OKD.

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

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

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

В своем докладе я расскажу про:
* опыт эксплуатации большого кластера K8s;
* что такое requests/limits и как они работают на низком уровне;
* как мы помогали разработчикам правильно рассчитывать эти значения, а затем начали выставлять их автоматически;
* зачем нужен descheduler;
* а также покажу демо, чтобы развеять несколько мифов.

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

Новый режим Ambient Mesh в Istio стремится решить основные проблемы Service Mesh и обещает нам мир, где больше нет sidecar-контейнеров с сетевыми прокси, а значит нет никаких дополнительных затрат ресурсов, проблем с L4-трафиком или повышенных привилегий для редиректа сетевого потока. При этом Ambient-режим обещает отсутствие каких-либо компромиссов в функциональности или безопасности.

Давайте все это проверим?

В докладе я предлагаю глубоко погрузиться в архитектуру Ambient Mesh, сравнить ее с прошлой реализацией, оценить на практике все преимущества и недостатки и, конечно, главное — ответить на вопрос, пора ли использовать Istio Ambient в своем продакшне?

Kubernetes уже давно стал стандартом де-факто в построении платформ для удобной разработки. Но что делать, если ваша платформенная команда располагает только «голым» железом, а вашу платформу в любой момент может потребоваться развернуть под ключ в закрытом контуре за короткое время? Мы собрали нашу «коробку» на основе легковесных Open Source-инструментов, поставив во главу угла подход Infrastructure as a Code, и хотим поделиться своим опытом в этом деле.

В ходе доклада затронем следующие темы:
* Как мы пришли к архитектуре нашего решения, и откуда родилась идея с mgmt-кластером.
* Как реализовать декларативную «наливку» железных хостов?
* Как спрятать секреты от любопытных глаз и дать рукоятку деплоя разработчикам?
* Как раздеплоить сам куб, причем тут вообще terraform, и как выглядит инфраструктурный релиз?

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

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

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

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

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

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

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

Начиная с 2021 года билайн поменял свой курс на максимальное развитие внутренней разработки. 3000+ новых разработчиков за 3 года с большим числом legacy-продуктов и большое желание стать высокоинженерной компанией.

В данном докладе расскажу о том, как мы дошли до Kubernetes, Kafka, PostgeSQL as a Service.

Перед тем, как начать разработку нового сервиса, нужно сделать много мелких шагов:
* создать репозиторий,
* настроить репозиторий,
* добавить шаблон сервиса,
* добавить шаблон CI/CD pipeline,
* добавить шаблон helm app-chart для деплоя в различные окружения,
* добавить секреты в Vault,
* etc.

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

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

Поговорим о том, как сервисы взаимодействуют между собой, что такое общий helm app-chart и общий CI/CD pipeline, DORA-метрики и их имплементация.

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

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

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

В принципе, он у нас есть, но мы хотим рассказать, как при наличии в команде 40+ сервисов и 4-6 стендов, мы сократили себе работу в плане автоматизации, менеджмента секретов и набега разработчиков.

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

И случайно заDevSecOps'или.

У всех нас есть какой-то опыт, и мы всегда стараемся переносить его с собой повсюду. Так, например, велик соблазн перенести свой опыт обеспечения безопасности Linuх/Docker-инфраструктур (не говоря уже о Windows) на Kubernetes-кластера. При этом, к сожалению, до конца не понимая самой природы Kubernetes. И это может быть ваш личный опыт или опыт кого-то из коллег, которые писали корпоративный стандарт с «лучшими практиками» по безопасности в Kubernetes, а вам ему уже необходимо следовать... К сожалению, то, что работало раньше и где-то, очень полезно, на практике неэффективно, бесполезно или вообще может привести к авариям как кластера, так и приложений в нем.

Рассмотрим, что в теории звучит очень полезно, а на практике приводит к авариям, падениям приложений и Kubernetes-кластеров.

Пайплайн — это блюдо, которое подается в холодном виде. Привнося в свою систему такой CI/CD-сервер, как Jenkins, мы не только добавляем гибкий и удобный Open Source-продукт с большим сообществом и безграничными возможностями по его настройке, но также размещаем большое количество «черных дыр» в нашей системе, позволяющих злоумышленникам проводить через них атаки на инфраструктуру. А ряд популярных плагинов лишь увеличивает уязвимость системы перед лицом врага. Настало время это исправить! Цель этого доклада — показать приемы усиления безопасности и выстраивания безопасной разработки с использованием Jenkins.

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

При нехватке AppSec-специалистов на рынке DevSecOps-инструменты внедряются тяжело и справиться с огромным потоком результатов очень сложно. Всё это не очень позитивно влияет на time-to-market. Но если взрастить своих Security Champions в командах разработки, то можно улучшить многие метрики.

В докладе я расскажу об опыте Cloud.ru, а также развею миф о неэффективности практики Security Champions.

В мире разработки, где скорость выпуска продуктов на рынок становится приоритетом, процесс проверок безопасности не должен становиться узким местом. Оркестрация SAST-, SCA-, SecretScanning-инструментов в контейнерной среде обеспечивает единообразное и эффективное управление ими. Использование механизмов управления микросервисами, предоставляемых Kubernetes, позволяет создать более высокоуровневые интерфейсы для проведения сканирований безопасности, упрощая процесс и реализуя «shift-left»-подход.

В этом контексте рассмотрим:
* существующие решения и подходы для автоматизации внедрения проверок безопасности в CI/CD;
* оркестрацию инструментов: управление выбором, конфигурацией и запуском набора AppSec-инструментов при различных условиях;
* когда Kubernetes — это больше, чем манифесты, или наш UP от yaml-разработки к написанию операторов;
* концепцию создания AppSecJob и её преимущества для AppSec-инженеров, DevOps’ов и команд разработки.

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

В данном докладе мы с точки зрения злоумышленника под микроскопом посмотрим на Gitlab и предложим разнообразные решения для его защиты.

Kyverno – потрясающий инструмент, обладающий весьма обширным функционалом по анализу манифестов Kubernetes и образов контейнеров. На практике часто встречаюсь с тем, что «про него слышали, но явно не использовали» или «использовали, но только для определенного типа политик на ограниченном объеме».

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

Приходите, будет весело!

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

Расскажем, как мы реализовали работу протокола Kerberos в средах K8s/Istio Service Mesh, почему это было так сложно и какие преимущества мы получили. В процессе доклада рассмотрим несколько конкретных примеров организации работы сервисов с протоколом Kerberos в средах K8s/Istio Service Mesh под высокой нагрузкой.

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

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

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

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

В частности:
* посмотрим, почему не стоит хранить секреты в открытом виде в Git;
* уберем секреты в переменные CI/CD-инструментов (Gitlab, Github, Jenkins и т.д.);
* захотим все-таки хранить секреты в Git, но зашифруем (SOPS, Sealed Secrets);
- вспомним о проблеме хранения ключей шифрования (Yandex Lockbox, CI/CD, AWS KMS и другие).
* подрастем до Hashicorp Vault;
* рассмотрим интеграцию с CI/CD tools и GitOps Tools;
* использование Vault Injector;
* External Secrets Operator;
* наши разработчики придут до интеграции приложений напрямую с Vault.

Компания движется путем реализации направлений DevOps/ARCH/Sec как код. Мы реализуем:
* архитектуру как код,
* инфраструктуру и CMDB как код,
* угрозы как код.

Расскажем о том, как мы к этому пришли, как это объединило команды IT/ARCH/Sус и каким мы увидели наш технологический ландшафт благодаря реверс-подходу. И как модель угроз легла на реальный технологический ландшафт.

Поделимся планами развития.

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

Статический анализ (или SAST-решение) является одним из помощников в тестировании приложений. Главное преимущество статического анализа состоит в возможности существенного снижения стоимости устранения дефектов в программе и гарантированном полном покрытии кода.

В докладе мы поговорим о том:
* как понять, получают ли команды пользу от SAST-решения, и окупается ли оно на конкретном проекте (и это будет интересно менеджерам проектов);
* как SAST-решение, в конце концов, внедрить в пайплайн, и на какую его стадию (и это будет интересно для DevOps-инженеров).

Как мы поняли на практике, что должен уметь инструмент для развертывания. Почему в итоге отказались от Helm в качестве подсистемы развертывания для werf и начали разработку Nelm — обратно совместимой альтернативы Helm.

Расскажем о наиболее значимых улучшениях по сравнению с Helm:
* отображение плана изменений — какие изменения действительно произойдут с ресурсами при развертывании;
* выкат ресурсов последовательно группами или параллельно на основе дерева зависимостей;
* продвинутое отслеживание готовности ресурсов, в том числе автоматическое отслеживание даже неизвестных Custom Resources;
* отображение статуса ресурсов, логов и эвентов во время развертывания;
* решение всех проблем Helm, приводящих к некорректным обновлениям ресурсов;
* полноценная поддержка CRD и множество других исправлений и улучшений.

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

* Расскажу, как изменился DevOps в кластере телеком после начала экосистемной трансформации МТС.
* Покажу, как новая оргструктура поддерживает этот переход, и чем обоснованы перемены в CI/CD-стеке.
* На примере телекома объясню, какие DevOps-практики помогли нам улучшить свои процессы и сократить TTM.
* Расскажу, как работа с внутренним комьюнити помогает актуализировать компетенции инженеров и собирать обратную связь при внедрении изменений.

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

Для решения данных ограничений мы используем kubernetes operator, который работает с нашими окружениями в процессе CD и во время эксплуатации. Наш оператор называется Базовозик и может создавать новые базы managed postgresql и managed redis в облаках, ориентируясь на аннотации деплойментов Kubernetes.

* В чём плюсы такого подхода, и почему мы не используем для этого sidecar-контейнеры, которые деплоятся вместе с приложением?
* Как мы интегрировали между собой git, доску задач и окружение?
* Масштабирование, включение и выключение компонентов отдельных окружений, как это реализовано и как этим можно управлять?

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

Расскажу, как упростить работу с K8s-манифестами с помощью инструмента CUE, о его основных преимуществах, его реализации в больших проектах и сравню с уже активно используемым Helm.

В докладе рассмотрим организацию доставки изменений в информационных системах на 1С в соответствии с современными требования IT-аудита. Как ОneScript может помочь командам, разрабатывающим приложения 1С на обычных и управляемых формах, быстро внедрить CI у себя.

Расскажу, какие инструменты существуют для построения сборочной линии и какие выбрали мы: Gitlab, Allure Testops, SonarCube, Gitsync, Vanessa, Vault, Grafana и Prometheus. Наш СI (подготовка, сборка, тестирование и деплой). Обсудим наш флоу разработки — без функциональных веток, с хранилищем 1С — и как это все можно мониторить.

1. Кому нужен этот ваш CI/CD — критерии и ценность.
2. Инструменты (накручиваем шаг за шагом).
3. Боль и страдания:
3.1 Боль заказчика.
3.2 Боль разработчика.

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

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

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

В своем выступлении я расскажу, как в Райфе с помощью DevOps-сообщества мы пришли к тому, что нужно проводить внутренние исследования инженерной культуры.

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

Аббревиатура CI/CD стала банальностью за последние несколько лет. Тема, казалось бы, настолько изъезжена и тривиальна, что недостойна внимания. Но дьявол кроется в деталях.

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

* Сравнение: как кубер, который вроде бы так же жонглирует контейнерами, работает значительно стабильнее.
* Подводные камни, с которыми столкнулись, — проблемы с DNS и прочие.
* Кишки решения — ansible-скрипты, пайплайны и прочее.
* Как и почему мы пришли к такой жизни.
* Плюсы и минусы.

Мой доклад — это наша история внедрения практик GitOps: от внутренних инфраструктурных задач до применения в промышленной эксплуатации на основных системах компании.

Для практической реализации GitOps мы выбрали ArgoCD. При этом во время внедрения наступили на множество «граблей», изобрели свои собственные «велосипеды» и в полной мере познали тёмную сторону GitOps: реальная жизнь оказалась не такой сказочной, как в многочисленных обзорных статьях, которые мы прочитали до того.

Чтобы решить поставленные задачи, нам пришлось научиться работать с большим количеством сервисов — с сотнями как с единым целым. Вокруг этого выстроили свои собственные решения и в итоге получили проработанные внутренние процессы и сервисы. Они основаны на кирпичиках Open Source и склеены внутрикорпоративными требованиями и особенностями.

Используемый технический стек: ArgoCD, GitLabCI, Kubernetes, Jenkins

Основные вопросы моего доклада:
* подход к релизному циклу для сотен сервисов — от dev до prod;
* Argo CD Config Management Plugins и интеграция с Hashicorp Vault;
* переиспользование Helm Template и Values через Config Management Plugins;
* автоматизированное тестирование и развертывание приложений ArgoCD;
* основные проблемы внедрения практик GitOps и поиск оптимального решения.

Обо всём этом постараюсь успеть рассказать в докладе :)

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

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

В своём докладе я расскажу о том, какие есть возможности для распространения ролей, что необходимо для подключения автоматической сборки документации, какие Self-Hosted-сервисы позволяют хранить Ansible-контент, каким образом можно настроить тестирование Molecule и не уничтожить сервер и как мы в YADRO перешли от кучи приватных репозиториев к единому открытому проекту для Ansible-решений.

Каждый день мы общаемся с коллегами. Иногда бывает так, что по чей-то ошибке происходит авария. Один забыл указать правильный конфиг, другой решил перезагрузить сервер,третий решил «сейчас тут быстро поправлю и будет хорошо». Что делать? Стоит ли сказать коллеге, что он плохо работает и вообще не понимает, что делает? Конечно, нет — каждый имеет право на ошибку. Этим и руководствуется такой культурный паттерн, как «no blame culture».

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

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

Я хочу обсудить, почему практика «no blame culture» не всегда хороша:
* как мы пересекаем ту черту, когда она перестает работать и скрывает плохие конфликты. Обсудим, когда конфликты хорошо, а когда — плохо, и что можно вынести из хороших конфликтов;
* как практика влияет на культуру команды, а культура — на ее эффективность. Посмотрим в цифрах влияние культуры на производительность;
* немного поговорим о «no blame culture» и бирюзовых компаниях, а еще почему бирюза не такая классная, как думается.

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

Во всех компаниях от мала до велика рано или поздно поднимается важный вопрос — где хранить секреты для продакшна и как их подгружать в развернутое приложение?

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

В этом докладе я расскажу про далеко не самый популярный способ хранения секретов: 1password.

Из доклада вы узнаете:
* как настроить хранение секретов в 1password с помощью helm secrets (дам пошаговую инструкцию);
* как все это упаковать в Argo CD;
* какие плюсы и минусы есть у данного решения.

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

Но что делать, если текущие инструменты не справляются с ростом масштабов и нужно автоматизируемое cloud-native-решение? На помощь может прийти Envoy Proxy.

В докладе обсудим:
* основные термины и топологию Envoy,
* статическую и динамическую конфигурацию Envoy,
* фильтры Envoy,
* Envoy control plane,
* типовые кейсы перехода на Envoy.

Что делать, если деплой инфраструктуры в ручном режиме занимает десятки часов, а хочется, чтобы все работало по кнопке автоматически? В докладе расскажу, как мы ускорили деплой ML-инфраструктуры в 20 раз, используя terraform.

Что вас ждет:
1) рассмотрим плюсы и минусы terraform как единого инструмента деплоя;
Поговорим про хранение стейта инфраструктуры, идемпотентность, динамически создаваемые переменные и секреты и т.д.;
2) обсудим способы, как управлять зависимостями (helm-чарты, инфраструктура) при деплое большого окружения;
3) увидим, как убрать узкие горлышки и минимизировать ручную работу.

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

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

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

Чаще всего выбор осуществляется «по знакомству» или «по рекомендации»: что-то видели раньше, что-то посоветовали, что-то будет просто быстрее развернуть и настроить.

В ходе выступления я расскажу про основные преимущества систем и сравню уже существующие решения с теми, которые инженер может собрать сам, «на коленке». Поговорим про запуск Ansible из web ui и исполнение плейбуков и ролей по расписанию.
Если уж автоматизировать Ansible, так до конца:
* сверим функционал: что умеют, а что не умеют web-панели для работы с Ansible;
* атака Титанов: монструозный AWX;
* проезд разрешен: прелести использования Semaphore;
* старикам у нас везде дорога: неочевидная связка Foreman и Ansible;
* Last but not least: Rundeck, PoleMarch и прочие инструменты.

Внедрение процесса непрерывной поставки и практик IAC в условиях, когда продакшн-сервера ездят по дорогам и теряют связь с сетью. CI/CD в экстремальных условиях.

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

В докладе я расскажу, что будет после DevOps, будет ли вторая волна, появились ли новые лидеры, сообщества и организации. Обсудим тренды и нерешенные проблемы в разработке и эксплуатации, новые подходы и инструменты. Разберем исследования, публикации и отчеты, книги и конференции, компании и экспертов. Рассмотрим такие направления, как Platform Engineering, Developer Experience, Internal Developer Platforms, Productivity Engineering, DevTools 2.0, ClickOps, AIOps, Cloud Native, Reliability Engineering, Resilience Engineering, Team Topologies.

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

В частности, посмотрим на DevOps в цифрах, как происходило внедрение Project DevOps, разберем практики DevSecOps и Quality Gates, принципы DORA CALMS, запуск и развитие DevOps Community, переход к DevOps as a platform way и многое другое.

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

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

Представьте, что вам отдают в один день всю тестовую инфраструктуру, которую делали порядка 5-7 лет, и говорят, что она работает плохо, а надо, чтобы работала хорошо. Через боль и страдания, спустя один год мы сделали хорошо. Что же мы сделали?

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

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

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

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

* Автоматический деплой feature-ветки через ApplicationSet с SCM Provider Generator в ArgoCD.
* Конфигурация приложений через Consul и Vault.
* Организация репозиториев и CI при GitOps-подходе.
* Жизненный цикл feature-ветки и ресурсов, относящихся к этой ветке.

DevOps-инженеры легко становятся заложниками одной из двух моделей восприятия:
1) Задача DevOps — автоматизировать процессы, чтобы быстрее поставлять ценность конечному потребителю (при сохранении или росте качества), а значит DevOps’ы должны отвечать и за то, какую ценность несет поставка. То есть думать о бизнесе, стратегии и поддержке процессов разработки!
2) Задача DevOps — закрыть на уровне инфраструктуры все проблемы, которые можно снять с плеч разработки и бизнеса, чтобы те сосредоточились на «действительно важном». То есть решать проблемы, не задавать вопросы, подставлять «инфраструктурные костыли».

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

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

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

Поделюсь опытом включения DevOps-инженеров в практики архитектурных решений (включая участие в формировании артефактов ADR и ADL — продемонстрирую шаблоны), инцидент-менеджмента (включая контроль PIR — поделюсь шаблоном), формирования корпоративной библиотеки инструментов.

Представьте, что в вашей компании работают несколько подрядчиков-аутсорсеров: одни предоставляют услуги DevOps, другие — услуги разработки. Изначально их работа вас полностью устраивает. Однако с ростом компании растут требования и количество задач для аутсорсеров. В какой-то момент баланс стоимости и профита рушится, и компания решает перенести все, что было на аутсорсе, к себе. В момент решения мне доверили направление DevOps + SRE.

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

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

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

Совместив знания и опыт itsm, dasa devops, maturity matrix, DevOps governance, westrum, kanban, картинка дальнейших шагов начинает складываться. А те решения, которые могли показаться спорными или неоптимальными, остаются в прошлом или претерпевают изменения.

Повествование пойдёт о том, как на примере компании Bimeister поэтапно осуществилось внедрение DaaS. Какие сложности ждали на этом пути, какие решения были изначально верными, а какие спорными, к чему это привело и какие мысли о будущем посещают сейчас.

Расскажу, как мы строили сервис DNS, способный выдерживать десятки миллионов запросов в секунду и не деградировать. Как не нагружать NXDOMAIN'ами бэкенды. Как потерять все бэкенды и при этом продолжить корректно отвечать на запросы. Поговорим про эволюцию DNS в компании: как мы прошли путь от нескольких серверов, торчащих непосредственно в мир, до сложной многоуровневой схемы с сотнями инстансов. Рассмотрим, как мы используем dnsdist для балансировки нагрузки, фильтрации запросов и создания гибких правил управления DNS-трафиком.

Скорее всего, вы уже знаете, что такое телеметрия и зачем она вам нужна. Если нет, то узнаете из моего доклада. А еще о том, какие инструменты могут вам помочь в деле формирования, сбора, хранения и отображения данных телеметрии. Также расскажу вам, какие инструменты не могут помочь, если у вас on-premise-инфраструктура и нет облаков. Немного поиграем в конструктор и соберем решение из разных деталей. Потом разберем и снова соберем, но уже из других. В очередной раз переработаем архитектуру решения под множество окружений — и наконец получим результат.

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

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

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

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

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

Ссылка на материалы использованные в докладе https://github.com/vseinstrumentiru/devopsconf2024/blob/main/resentation-from-efk-to-vector-and-clickhouse/references.md

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

В своем докладе я проанализирую, почему Prometheus потребляет столько ресурсов и расскажу, как можно этого избежать. Начнем анализ с изучения механизмов хранения серий данных в Time Series Database (TSDB) Prometheus. Особое внимание уделим тому, как выбор метрик, отправляемых в Prometheus, влияет на потребление ресурсов системы.

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

Эти аспекты являются ключевыми для обеспечения эффективного и экономичного мониторинга в современных проектах.

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

Вы наверняка тоже много раз слышали про надежность и устойчивость, но до сих пор не все знают, что именно они означают на практике, а главное — как их измерять. А те, кто знают, делают это по-разному. Поэтому в программе доклада:
* Надежность и устойчивость — это еще не метрики. Что же мы тогда измеряем?
* Доступность как комплексная метрика и ее производные.
* Два подхода к измерению доступности приложений.
* Что такое SLI, SLO и SLA.
* Автоматизация дашбордов Grafana с помощью Jsonnet.

Яндекс Go — это система из 800 микросервисов. Два года назад перед нами встала задача сильно вырастить аптайм всей системы.

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

Будет обзор наших практик (митигации и др), технологий (chaos engineering и др), архитектурных паттернов (DOMA и др), процессов (инцидент-менеджмент и др) и ментальных моделей (metastable failure state и др). Будет много ссылок для углубленного изучения этих аспектов.

Буду объяснять все на выдуманных примерах инцидентов, но на основе реальных событий.

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

В докладе будет:
* как и, главное, зачем связкой "Vector > ClickHouse < Grafana" собирать инфраструктуру Observability;
* как форматировать и сколько хранить телеметрию;
* как SQL’ем работать с телеметрией и выводить её в Grafana;
* как организовать централизованный доступ к данными телеметрии;
* насколько Vector готов к бою, а ClickHouse — к большим объемам телеметрии.

В докладе представлю историю инженерии устойчивости, разницу определений и методов в сравнении с надежностью, стабильностью. Расскажу о применении DORA за рамками ускорения деплоев. Узнаете о ключевых принципах, персонах и сообществе, а также о пересечении методов с другими доменами (медицина, энергетика и т. п.). Как происходило внедрение в СберМаркет — ключевые цели, этапы, успехи и провалы. С чего начать в вашей организации.

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

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

Специально для всех, кто хочет не запутаться и разобраться в тонкостях правильного выбора SLO, при этом не попасть в «закон Гудхарта», я подготовил доклад, в котором вместе поговорим про:
* определение SLO и его значение в контексте предоставления услуг;
* обзор типов SLO (ведь это не только про известные всем Availability, Latency) + примеры кейсов;
* почему выбирать правильные типы SLO важно: как это влияет на производительность сервиса и NPS пользователей;
* определение требований пользователей, бизнеса и команды;
* согласование типов SLO с разработчиками и командой эксплуатации;
* значимость SLO. Как не допустить превращение в «цифру, к которой все стремятся», и не забыть о том, что это действительно важный инструмент для улучшения доступности?

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

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

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

Я расскажу о программе курса по подготовке SRE, который с 2022 года читается в Школе Анализа Данных Яндекса.

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

У каждого специалиста есть так называемый «цифровой портрет», который состоит не только из резюме на job-сайте или профиля в Linkedin. Помимо стандартных площадок, его формируют GitHub, Хабр, StackOverflow, Codeforces, сайты конференций, личные страницы, VK, FB, X, YouTube и куча других ресурсов.

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

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

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

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

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

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

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

С ростом компаний растут и требования к надёжности систем. Многие сталкиваются с вопросом, как эту самую доступность обеспечивать. Чаще всего со стороны инфраструктуры используется схема 2-х ЦОДов active-passive, так было и у нас до определённого момента...

Доклад будет полезен тем, кто отвечает за доступность сервисов и ещё не сделал этого перехода. Расскажу про общие подходы, наши вызовы, ошибки и практические решения при переходе на мульти-ЦОД-архитектуру.

YTsaurus — BigData-платформа с открытым исходным кодом от Яндекса. Кластер YTsaurus представляет собой сложную stateful-систему: в зависимости от настроек он содержит от 8 до 15 компонентов различного типа. Для упрощения развёртывания и управления кластерами YTsaurus мы разработали K8s-оператор, но даже при этом составление разумного yaml-манифеста и установка базовой инсталляции — кропотливая и непростая задача.

Чтобы привлекать пользователей, нужно снижать порог входа. Что может быть проще, чем вместо yaml-программирования заполнить несколько полей в интерфейсе Yandex. Cloud и получить кластер по кнопке? YC. Marketplace позволяет сделать именно это. Но как упихнуть трёхстраничный манифест в форму из нескольких полей? Какие грабли подложил нам helm? И чем примечательна константа 93Gb? Об этом вы сможете узнать из моего доклада.

* Open Source для корпорации или корпорации для Open Source – роль крупного бизнеса в развитии открытого кода и инструменты поддержки.
* Как корпорациям работать с Open Source - может ли эту проблему решить Open Source Programs Office?
* Экономика Open Source в примерах: как развивалась, какие проблемы возникли в процессе и методики для решения проблем.
* Open Source и безопасность кода.

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

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

Из доклада вы узнаете:
* как мы научились обрабатывать большой объем сериализованных данных с беспилотных автомобилей (130-150 Tb в сутки);
* какой Open Source-стек мы для этого выбрали;
* почему отказались от Apache Airflow и остановились на Dagster;
* где и как мы запускаем вычисления на Spark, а где обходимся Apache Arrow и Polars;
* чем нас не устроил стандартный планировщик Kubernetes, и чем мы его заменили (спойлер: Volcano);
* как мы реализовали автоматическую эволюцию схем табличных данных в Spark + Hive Metastore.

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

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

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

В докладе я расскажу о способах создания удобной среды разработки на основе платформы Kubernetes, ориентированной на команды с более чем двумя сотнями Data Scientists и Data Engineers, позволяющей выпускать более 100 моделей в течение нескольких недель. Данная платформа уже реализована в Альфа-Банке.

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

Лига Цифровой Экономики первой столкнулась с необходимостью разобраться, как устроен «ГосТех» — цифровая платформа для консолидации государственных сервисов. Нашей целью было интегрировать с «ГосТехом» один из проектов Росимущества. Рассказываем, чему научил нас этот интересный опыт.

1) Критерии автоматизируемой архитектуры в проектах:
* Как можно определить, что в проекте присутствует архитектура, почему это важно для автоматизации и сколько архитектур нужно проекту?
* Почему необходимо устранить всякую неопределенность в архитектуре перед началом написания/генерации кода ее автоматизации?
* Что такое изолированные модули в автоматизации, зачем это нужно и как влияет на работу с ChatGPT?
2) Требования к коду для оптимальной работы с ChatGPT:
* Какие атрибуты качества кода автоматизации необходимо учитывать и можно ли сгенерировать с помощью ChatGPT хороший код?
3) Эффективная постановка задачи для ChatGPT:
* Какие ключевые атрибуты ресурсов необходимы для их развертывания, являются они константами или переменными?
* Какие стратегии следует применять в ситуациях, когда кажется необходимым использовать переменные?
* Какие ключевые элементы следует учитывать при формулировке запросов к ChatGPT для получения эффективного и точного кода?
4) Бест практис в постановке задач для ChatGPT и не только.

Все хотят отказоустойчивые приложения, многие их пишут, а многие ли осмотрелись вокруг?

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

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

Размещение stateful- и stateless-приложений рядом друг с другом позволяет унифицировать подходы к разработке и управлению инфраструктурой и упростить работу инженеров. Однако запуск stateful-приложений требует внимания к ряду деталей — например, конфигурирования Persistent Volumes. И даже работая в Kubernetes с cloud native-приложениями вроде MongoDB, Kafka инженеры сталкиваются с многочисленными неочевидными нюансами. Поэтому разработчикам K8s и облачных инструментов необходимо дорабатывать имеющиеся решения, чтобы cloud native-экосистема созрела для подобного рода приложений.

Мы накопили солидный опыт эксплуатации различных stateful-приложений: Patroni, ELK, CH, Redis, MongoDB, RabbitMQ в Kubernetes — и на докладе подсветим ключевые особенности их конфигурирования, а также поделимся практическим опытом их использования в разных сценариях. После доклада слушатели смогут сформировать полное представление о текущем состоянии и перспективах работы со stateful-приложениями в Kubernetes и внедрить новые знания на практике.

Сейчас к построению внутренних платформ в компаниях для cloud-native-приложений есть три подхода:
1) сделать самим,
2) использовать облако как основу платформы,
3) купить вендорское решение.

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

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

В этом мастер-классе я расскажу, как максимально быстро и безопасно автоматизировать часть своей работы с помощью локально развернутых LLM. Мы вместе попробуем несколько моделей для базовых DevOps-задач, научимся писать промпты (да, они немного отличаются от промптов для Chat GPT), а также поговорим про то, как можно улучшить ответ модели за N шагов.

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

На воркшопе будем:
* говорить про риски в среде обитания;
* искать только полезные с помощью метода Risk-Storming — золотой середины по времени/усилиям. На примере и самостоятельно;
* продумывать контроли и способы снижения.

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

Я вам расскажу, как можно уменьшить эту боль с помощью инструмента Data Transfer для миграции в Yandex Cloud на Managed PostgreSQL. Современная база данных — это не только данные, но еще и много различных сущностей: пользователи, права, хранимые функции, экстеншны, триггеры, индексы. В докладе мы разберем этапы подготовки и миграции, различные нюансы, которые нужно учесть при подготовке и тестовой миграции. Также уделим внимание таким аспектам, как рассинхронизация, статистика, индексы и внешние ключи, которые нужно не забыть при переключении рабочего трафика со старой базы на новую.

Ну и немного подискутируем, кто же должен этим заниматься: DBA или DevOps-инженеры?

Использование Helm-чартов для упрощения упаковки, настройки и развертывания приложений и сервисов в кластерах Kubernetes уже стало индустриальным стандартом. Чарты позволяют использовать один шаблон под разные окружения и в разы сэкономить время. Но есть ли способ еще больше упростить процесс?

На воркшопе:
* посмотрим, что такое Helm chart, как создать свой стартер и внести изменения, которые сделают его гибче и функциональнее. Есть ли смысл делать из стартера суперчарт?
* рассмотрим, что представляет собой helmfile, сравним helmfile и umbrela chart в эксплуатации, и поймем, почему первый способ удобнее для команды;
* научимся подключать чарт библиотеки для упрощения модификаций в имеющиеся чарты.

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

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

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