June 2026 DevOps Meetup

Розмова 1
**Назва: Платформа — це люди: SLA, DORA та довіра з мільярдами запитів на місяць**
Автор: Гаррі Бурас
Посада / LinkedIn: керівник AI & Cloud Engineering, раніше очолював організацію API провідної, надзвичайно глобальної та мультикультурної корпорації. LinkedIn: https://www.linkedin.com/in/harry-bouras/

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

Я пройдуся по важелях, які фактично рухали стрілку, кожен з яких закріплений у реальних моментах цієї шкали. Як SLA, оформлені як ясність, а не покарання, змінюють поведінку інженера більше, ніж будь-яка панель інструментів. Чому поширювати довіру та час на команду на передньому плані - найнезручніше, що може зробити лідер, це саме те, що підвищує якість збірки та скорочує переробку, яку ви не можете собі дозволити за мільярди запитів. Що насправді змінилося, коли ми перетягнули організацію у формі водоспаду до ітеративної доставки на основі Scrum, і чому це стосувалося скорочення циклів зворотного зв’язку, а не додавання церемоній. І як показники DORA стали нашою об’єктивною відповіддю на питання, про яке сперечається кожна команда: що насправді робить успішним Senior Software Engineer і що DevOps інженер?

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

Нарешті, подивіться на те, що ми всі разом збираємося зробити не так: AI змушує 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.
Чесні уроки зі стандартизації, адаптації орендарів та впровадження платформи.