June 2026 DevOps Meetup

Разговор 1
**Название: Платформа — это люди: соглашения об уровне обслуживания, DORA и доверие при миллиардах запросов в месяц**
Автор: Гарри Бурас
Должность / LinkedIn: руководитель отдела искусственного интеллекта и облачных технологий, ранее возглавлявший подразделение API в ведущей, чрезвычайно глобальной и мультикультурной корпорации. LinkedIn: https://www.linkedin.com/in/harry-bouras/

Аннотация:
Большинство разговоров о «платформах» посвящены инструментам. Этот нет. Возглавляя API-подразделение ведущей, чрезвычайно глобальной и мультикультурной корпорации, объединяющей десятилетия устаревших систем, обслуживая миллиарды запросов в месяц и масштабируясь как в Azure, так и в Google Cloud, я преподал мне противоположный урок на собственном горьком опыте: при таком объеме платформы не подводят технологии, а счета за облако не растут из-за плохого Terraform. Они терпят неудачу или добиваются успеха в том, как устроена организация, чтобы владеть, доставлять и развивать продукт. Организационная структура — это настоящая архитектура.

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

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

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

Разговор 2
**Посмертная культура: превращение неудач в обучение, а не в обвинение**
Автор: Дэни Елович
Большинство инженерных команд рассматривают инциденты как конфуз, который нужно похоронить: быстрое решение, расплывчатое сообщение Slack, и все двигаются дальше. В этом докладе предлагается другой подход: относиться к каждой неудаче как к подарку.
Основная идея — безупречное вскрытие — практика, впервые примененная в Google и Netflix, цель которой не найти козла отпущения, а понять, как система (люди, инструменты, процессы) вообще допустила сбой. Если человек допустил ошибку, реальный вопрос заключается в следующем: почему система позволила легко совершить эту ошибку?
В докладе будут обсуждаться:
Как выглядит хорошее вскрытие (и основные причины, по которым оно идет не так)
Как провести безупречную проверку, не превратив ее в заседание комитета по обвинению
Превращение действий в реальные изменения, а не в кладбищенский документ, который никто не читает
Обеспечение психологической безопасности, чтобы инженеры сообщали о проблемах заранее, а не скрывали их.
Ключевой вывод: команды, которые учатся на неудачах быстрее, чем их конкуренты, выпускают лучшее программное обеспечение с меньшим количеством катастрофических инцидентов — не потому, что у них лучшие инженеры, а потому, что они создали лучшие петли обратной связи.

**Разговор 3:**
Название: От сервисной организации к самообслуживанию: разработка платформ в действии
Павел Буреш из Sky

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

Во второй половине мы сосредоточимся на PEaaS (Persistence Engineering as a Service), нашей конкретной реализации этих принципов для рабочих нагрузок с отслеживанием состояния. Мы рассмотрим архитектуру — функции композиции Crossplane 2.0 в EKS, ориентированные на приложения утверждения Kubernetes (XR) и модель подключения арендаторов, которая автоматизирует IAM, конечные точки VPC, подготовку OIDC и S3 — и то, как она абстрагирует разнородные серверные части (Keyspaces, Aurora DSQL, Redis Cloud и Kafka в EKS) за одним согласованным интерфейсом.

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