Про різні етапи розвитку дизайнерської карʼєри та виклики, з якими ми стикаємося на кожному з них. Відповіді на запитання: що робить дизайнера справді крутим; яка освіта потрібна дизайнеру і чи можна без неї; навіщо дизайнеру політика та як презентувати свій дизайн; як працювати в команді; як нетоксично критикувати; як пізнати себе й віднайти своє «кунг-фу» — і багато іншого.

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

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