Krafton скоротив кількість інцидентів на 77% без AI-магії — лише платформна робота

Кожен черговий інженер, який спостерігав, як дашборд загорається червоним о третій ночі, знає правду, яку ніхто на вендорному кейноуті не хоче вимовляти вголос: різниця між п'ятихвилинним збоєм і аварією, що потрапляє в новини, майже ніколи не залежить від інструментів. Krafton, сеульська студія за PUBG: Battlegrounds, щойно надала цьому докази. Кількість інцидентів впала зі 107 у 2024 році до 24 станом на 2026 рік, а середній час відновлення скоротився з 53,5 хвилин до 10,3. Це головний результат, і AI-агенти майже не мали до нього жодного стосунку.

Цифри

Зупинімося на Krafton, бо цифри тут незвичайні. Як повідомляло TechTarget з брейкаут-сесій Datadog DASH 10 червня, команда Junghun Kim також скоротила час виявлення з 8,8 хвилин до 1,6 хвилини. Покращення у 5,5 рази за виявленням, у 5,2 рази за відновленням і скорочення загальної кількості інцидентів у 4,5 рази. Для гри з мільйонами одночасних користувачів кожна з цих хвилин означає виручку, повернення коштів і репутаційні втрати в соцмережах.

Для контексту: SRE-команди, з якими я працював на європейських iGaming-платформах, розглядали б MTTD менше двох хвилин на складній розподіленій системі як практичну межу. Виявляти швидше можна, але лише ціною потоку хибних спрацьовувань. Досягнення Krafton у 1,6 хвилини при одночасному скороченні загальної кількості інцидентів — складніший результат. Це означає, що якість сигналу зросла одночасно зі швидкістю реагування.

Показник MTTR заслуговує на детальніший розгляд. Скорочення з 53,5 до 10,3 хвилин — це крива, яку зазвичай спостерігають лише тоді, коли команда замінює ненадійний процес розгортання. За словами Kim, дев'ять років вдосконалення, останнім кроком якого стала консолідація п'яти інструментів спостережуваності в один — Datadog. Консолідація п'яти інструментів в один виглядає чисто на слайді. На практиці в інцидентах, які я спостерігав, це зазвичай займає від дванадцяти до вісімнадцяти місяців і по дорозі ламає кілька дашбордів. Дев'ять років накопиченого контексту — ось що зробило це можливим.

Є ще Getswish — оператор шведського платіжного застосунку Swish. Збій 2021 року потрапив до національної преси ще до того, як аутсорсинговий IT-провайдер взагалі дізнався про нього. Наприкінці 2024 року порівнянний інцидент був виявлений і усунутий власними силами за п'ять годин. П'ять годин — не привід для хвастощів за мірками iGaming, але для платіжної інфраструктури, що працювала за контрактом аутсорсингової підтримки трьома роками раніше, це структурна зміна в питанні того, хто контролює масштаби збитку. Команда Jonas Cronholm-Lundin досягла цього, перебудувавши доставку коду на GitOps і відновивши практику реагування на інциденти за книгою SRE від Google. Жодних агентів. Жодної магії.

Що справді нового

Datadog представив понад 100 оновлень на DASH. Два, release notes яких технічні керівники повинні справді прочитати, — це Runtime Prioritization Engine з автоматичним тегуванням вразливостей безпеки та функція Auto-Processing у Observability Pipelines. Обидва є AI-класифікаторами, що працюють із даними, які у вас вже є. Krafton також використовує MCP server від Datadog і нещодавно випущений Pup CLI, щоб надати кодовим агентам доступ до контексту інцидентів через Datadog, Kubernetes, Jira і Slack.

Остання деталь — це справді нове. MCP разом із CLI означає, що агенти можуть зчитувати стан інцидентів із чотирьох канонічних джерел без власного інтеграційного шару. Для команд, які останні два роки скотчем прив'язували Slack-боти до PagerDuty вебхуків, це суттєвий примітив. Але він досі суто допоміжний. Kim був чіткий: крос-джерельна діагностика, складання постмортемів, генерація ранбуків, документація для передачі чергування. Жодне з них не торкається production.

Цитату Kim про автономність варто повісити на стіну. «Сьогодні AI все ще може помилятися під час інцидентів, і якщо він вживає критичних дій, які важко відкатити, ризик для надійності production занадто великий». Це слова старшого інженера ігрової компанії, який у 2026 році пояснює, чому його команда не передала кермо агенту. Це майже слово в слово збігається з тим, що технічні керівники фінтех-компаній, з якими я працював, казали приватно протягом останніх вісімнадцяти місяців.

Внесок Getswish до нового плейбуку носить структурний характер. Їхні ранбуки тепер організовані навколо OODA-петлі — системи прийняття рішень, запозиченої з військової авіації. Спостерігай, орієнтуйся, вирішуй, дій. Суть OODA в реагуванні на інциденти полягає в тому, що вона дає агенту — людині чи ні — стабільну декомпозицію поточного кроку. Якщо ви колись захочете передати частини петлі автоматизації, явне визначення петлі є обов'язковою умовою. Формулювання Cronholm-Lundin було правильним: куровані ранбуки та постмортеми — це навчальні дані для будь-якого агента, якого ви приймете наступним.

Що вже враховано для інженерних команд

Ринок вже врахував підхід «AI-асистент, а не AI-оператор». Кожен платформний вендор це повторює. Що ще не враховано — скільки фундаментальної роботи потрібно зробити до того, як будь-яка допомога почне приносити результат.

Подивіться на Krafton ще раз: дев'ять років вдосконалення процесів, консолідація інструментів, метадані власності, вбудовані в кодові шляхи, захисні бар'єри за серйозністю — і лише потім MCP разом із кодовими агентами зверху. Агенти — це останні 10% стеку. Вони генерують цінність тому, що нижні 90% чисті. Якщо ваші інциденти досі тріажуються тим, хто голосніше кричить у Slack, накладення агента зверху лише пришвидшить виробництво впевнено неправильних постмортемів.

Інший недостатньо обговорюваний аспект — економіка чистоти даних. Bryan Pierson з US Bank розповів на DASH, що не кожен лог отримує місце першого класу у бекенді Datadog. Решту вони маршрутизують до S3 через Observability Pipelines з міркувань вартості зберігання. Це нудна, але правильна відповідь, яку врешті-решт вимагатиме кожен CFO. Рахунки за спостережуваність мають властивість переходити від «керованих» до «бюджету двох інженерів» між одним кварталом і наступним, а багаторівнева маршрутизація до об'єктного сховища — стандартний вихід із ситуації. Пайплайни OpenTelemetry роблять це портативним, якщо хочете зберегти опцію між вендорами.

Моя думка: агентні функції стануть базовими вимогами через 18 місяців, і ніхто не пам'ятатиме, який вендор першим їх випустив. Що буде важливим — чи збудувала ваша платформна команда основу знизу.

Контраріанська думка

Контраріанська інтерпретація: Krafton і Getswish — це упередження вижившого. Обидві компанії мали бюджет, інженерну культуру, а у випадку Krafton — майже десятиліття часу, щоб досягти такого стану. Більшість команд, що читають підсумки DASH, не мають дев'яти років. У них є CFO, який питає, чому рахунок за спостережуваність зростає на 40% щороку, і CTO, який бачив демо агента і хоче знати, коли інциденти починатимуть вирішуватися самі.

Для таких команд чесна відповідь може полягати в тому, що AI-асистент поверх посередньої платформи все одно краще, ніж нічого. Eric Swanson, SRE в MagicSchool AI у Денвері, відверто висловив побоювання: розробники перекладають дисципліну логування на агентів, а інженери притупляють навички, відточені критичним мисленням. Він має рацію, турбуючись про це. Але контраргумент полягає в тому, що не кожна компанія побудує платформу для управління інцидентами рівня Krafton, і компетентний мінімум агентів може підняти медіанного оператора більше, ніж опустить стелю для найкращих.

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

Ключові висновки

• Спочатку платформа. Скорочення інцидентів Krafton на 77% і покращення MTTR у 5 разів стали результатом дев'яти років роботи над процесами, а не агентів, прикручених наприкінці.
• MCP плюс CLI — новий інтеграційний примітив. MCP server і Pup CLI від Datadog дозволяють агентам зчитувати контекст інцидентів через спостережуваність, Kubernetes, Jira і Slack без спеціального клею. Варто провести proof-of-concept цього кварталу.
• Тримайте агентів на допоміжній стороні межі. Постмортеми, ранбуки, документація передачі, крос-джерельна діагностика. Дії, що змінюють production, залишаються за людиною, поки відкат не стане дешевим.
• Структуруйте ранбуки для людей і агентів одночасно. Ранбуки Getswish на основі OODA-петлі слугують і навчальним матеріалом. Курируйте зараз — збирайте плоди пізніше.
• Розподіляйте дані спостережуваності за рівнями до того, як рахунок розподілить вас. US Bank маршрутизує логи нижчої цінності до S3 через Observability Pipelines. Це вже стандартна практика, а не оптимізація.