Партнерство з 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. Це розмова про системні рішення, відповідальність, навчання, підготовку до інцидентів і про те, як складні технічні системи формують поведінку людей усередині них. Доповідь сфокусована не на інструментах, а на висновках, які з’являються лише тоді, коли проєкт проживається цілком - від задуму до реальності продакшну.

Оновлення кор-залежностей часто відкладається роками через страх “зламати все”, і ризик зростає експоненційно. Андрій покаже workflow для стрибка через кілька версій: AI аналізує breaking changes та генерує правила трансформації, AST-інструменти виконують рутину, а технічний борг перетворюється на керований процес.

Low Latency в High-Load: шлях від Redis Pub/Sub до In-Memory Runtime — іграшка, яка зайшла надто далеко У доповіді розглянемо практичний досвід побудови low-latency системи для міжбіржових операцій, де географія не менш важлива, ніж алгоритми. Поговоримо про те, чому message brokers і класичні мікросервіси не є вдалим рішенням для HFT (High-Frequency Trading)-подібних сценаріїв, як in-memory state у поєднанні з регіональними runtime-вузлами забезпечує прогнозовану затримку, і де проходить межа між швидкістю та consistency.