Партнерство з AWS майже завжди стартує з опору: “це бюрократія”, “немає часу”, “не дає цінності продукту”. У доповіді покажемо, як ми перетворили AWS програми (FTR, Ready, Delivery, Competencies) на керовану систему роботи з портфелем проєктів. Розберемо, як отримували підтримку бізнесу та команд, як домовлялись про пріоритети, і як переводили очікування в чіткі артефакти: evidence packs, шаблони, KPI-формати, business outcomes, enablement. Пояснимо, як працюють ролі та ownership, ритми, quality gates і правила відбору кейсів, а також як ми реагуємо на фідбек Amazon на кшталт “be more specific”, щоб наступна подача була сильнішою та швидшою.

Коли система партнерських подач уже працює, головний виклик - стабільно конвертувати findings у зміни в проді та доводити ефект метриками. У доповіді покажу наш практичний цикл: finding => виправлення => перевірка ефекту => тиражування патерну на багато команд. Ми зробили фокус - на метриках, які перетворюють SRE на керовану систему: ми вимірюємо швидкість, стабільність і вартість змін так, щоб рішення приймались не інтуїтивно, а на даних з врахуванням безпеки яка стала частиною цього патерну. Розберемо, як уникати “локальних” фіксів, як робити зміни відтворюваними, і як підтримувати прогрес не разово, а постійно.

Це історія про реальний біль і дорослішання системи логування. Ми подивимось, як відсутність стандартів ламають observability. Я покажу, чому Kubernetes став точкою неповернення і змусив нас переглянути підхід до логів. Розберемо вимоги та архітектурні рішення, які дозволили повернути контроль. Поділюсь практичним досвідом побудови керованих лог-пайплайнів без магії і “чарівних інструментів”. Це чесна історія з продакшну.

Ця доповідь демонструє практичні підходи до unified observability, де метрики, логи, траси та профілі інтегровані для швидкої діагностики проблем у розподілених системах. Розглянемо техніки кореляції даних через traceId та лейбли для миттєвого переходу від помилок до конкретних span'ів, налаштування continuous profiling для preview-середовищ, використання flame charts для аналізу продуктивності, dependency maps і service graphs для візуалізації архітектури. Окрема увага приділена AI-специфічним аспектам: застосування AI-асистентів для автоматизації root cause analysis та впровадження AI Evals для систематичного оцінювання якості, коректності та надійності AI-систем.

У межах ініціативи Security Hardening ми впровадили підхід Access as Code для керування доступами в AWS. Для кожного репозиторію створюється окрема IAM-роль з permissions відповідно до принципу Least Privilege. Управління ролями винесене в централізований репозиторій, де кожен сервіс описується одним YAML-файлом. Усі зміни проходять через Pull Requests та approvals, а за допомогою Terraform і Atlantis ролі автоматично створюються або оновлюються. У результаті ми отримали масштабоване, аудитоване та безпечне керування доступами без прямого доступу команд до AWS.

Ця сесія досліджує еволюцію від простих ланцюжків LLM до надійних когнітивних архітектур, зосереджуючись на розгортанні агентів зі станом у межах власної інфраструктури (On-Premise). Ми порівняємо сучасні фреймворки оркестрації, протиставляючи Google ADK (Agent Development Kit) для структурованого, незалежного від моделі проєктування агентів, LangGraph для детального контролю стану та CrewAI для багатoагентної взаємодії за ролями. Ключовим фокусом стане Model Context Protocol (MCP) — новий стандарт підключення агентів до внутрішніх даних і інструментів без прив’язки до конкретного постачальника. Ми продемонструємо, як побудувати гнучке середовище виконання за допомогою Vercel AI SDK Core (розгорнутого в Docker) для обслуговування таких агентів, забезпечуючи повну незалежність від хмарних провайдерів. На завершення ми розглянемо стек AgentOps, детально пояснивши, як реалізувати self-hosted спостережуваність (через Langfuse) та політики доступу для безпечного керування автономними системами у виробничому середовищі.

Ця доповідь - про реальний DevOps-проєкт, досвід якого виявився дуже схожим на сюжет книги «Проєкт Фенікс». Я розповім про повний шлях: побудову платформи, міграцію, роботу з командами розробки, комунікацію з бізнесом, життя системи під навантаженням і ті помилки, які стають видимими лише з часом. Це не переказ книги і не success story. Це розмова про системні рішення, відповідальність, навчання, підготовку до інцидентів і про те, як складні технічні системи формують поведінку людей усередині них. Доповідь сфокусована не на інструментах, а на висновках, які з’являються лише тоді, коли проєкт проживається цілком - від задуму до реальності продакшну.

У кожного інженера — своя дорога в IT. Моя почалася не з красивих презентацій і чітких планів, а з того, що мене на крані піднімали ремонтувати екран на стадіоні «Металіст». Потім були телеком-проєкти, автотести, Red Hat, OpenStack, OpenShift — і постійний пошук, куди рухатися далі. З часом прості кострубаті скрипти, які я писав лише щоб зекономити собі кілька годин, почали тримати прод. «Пожежі» стали приводами для нових рішень, а експерименти — досвідом, який справді працює. І десь у цьому всьому були моменти, коли я хотів піти з IT. Але натомість з’явилися DevOps01, ком’юніті, а згодом — AWS та HashiCorp-амбасадорство. У цьому виступі я розповім, як постійний пошук себе у професії та професії в собі став тим самим двигуном, що змінив не лише кар’єру, а й життя. Як маленькі ініціативи виростають у великі системи, а спільнота відкриває нові двері.

Ця доповідь присвячена практичному досвіду переходу з класичної Istio-архітектури з sidecar-контейнерами на нову модель — Istio Ambient Mesh. Ми розповімо, як масштабування мікросервісної інфраструктури на Kubernetes призвело до зростання витрат на ресурси, ускладнення CI/CD та затримок у запуску сервісів. Пошук рішень привів нас до впровадження Ambient Mesh — архітектури без sidecar-контейнерів, яка значно спрощує mesh-інтеграцію і знижує інфраструктурні витрати. У доповіді буде детально розглянуто технічні аспекти міграції: як ми готувалися до переходу, які виклики виникали у процесі впровадження та як вдалося їх подолати у співпраці зі спільнотою Istio. Поділимось результатами, аналітикою, реальними метриками до/після та дамо практичні поради командам, які планують впровадження Ambient Mesh у production.