Чернетка розбору інциденту зі Slack + телеметрії

AI-агент Grow2.ai створює чернетку документа розбору інциденту за готовим інцидентом. Після закриття інциденту агент збирає контекст із трьох джерел і видає структуровану чернетку, готову до редагування інженером.

Джерела, з яких агент читає

1. Slack-тред інциденту — повідомлення команди, рішення, скріншоти, посилання на дашборди, реакції учасників.
2. Система спостережуваності — метрики, алерти, trace-події, логи у часовому вікні інциденту.
3. Трекер задач — пов'язані тікети, пул-реквести, записи про розгортання.

Що агент формує в чернетці

Агент генерує розбір інциденту у стандартній blameless-структурі:

• зведення інциденту (2-3 речення),
• хронологія з таймстемпами подій,
• вплив (залучені користувачі, простій, бізнес-ефект),
• гіпотеза першопричини (попередня, потребує перевірки),
• чинники, що сприяли інциденту,
• що спрацювало добре під час реагування,
• засвоєні уроки,
• завдання з чернетковими відповідальними.

Blameless-формат закодовано у prompt: агент описує системні та процесні фактори, а не звинувачує конкретних людей. Формулювання — "алерт не спрацював через помилку в порозі спрацювання", а не "інженер не налаштував алерт".

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

Що автоматизація НЕ робить

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

Також агент не рахує фінансові наслідки інциденту і не визначає порушення SLA/SLO з точністю, достатньою для зовнішніх звітів клієнтам. Він може підсвітити факт перевищення порогу в чернетці, але валідація та атрибуція залишаються за профільною роллю.

Типові варіанти налаштування

Solo-команда / стартап 1-5 осіб. Один prompt-шаблон, підключення до Slack і одного інструменту спостережуваності команди. Чернетка пишеться у вибрану командою систему документації. Інженер править перед розсилкою. Фокус — швидкість налаштування і мінімум конфігурації. Підходить командам, де postmortem раніше не писали зовсім через брак часу. Агент запускається вручну за командою в Slack після закриття інциденту. Перші запуски — для перевірки якості чернетки на минулих інцидентах. Результат — перша звичка документувати інциденти, навіть якщо не ідеально.

SMB SaaS 6-30 осіб. Два-три шаблони: для P1/P2-інцидентів і інцидентів безпеки окремо. Інтеграція з трекером задач, історією розгортань, основним стеком моніторингу. Агент викликається автоматично при закритті інциденту. Чернетка потрапляє в систему документації і водночас у Slack-канал команди для рев'ю. Рольовий доступ: хто може запустити, хто зобов'язаний перевірити. Налаштування — близько тижня. Підходить командам із регулярними інцидентами та вимогою до postmortem-дисципліни.

Корпоративний сегмент 30+ інженерів. Мультиагентна схема: один агент збирає хронологію, другий робить попередній аналіз першопричини, третій формує завдання з відповідальними з довідника команди. Інтеграція з внутрішнім SSO, журналами аудиту, системами відповідності вимогам. Чернетка проходить ланцюжок рев'ю: SRE-lead → Engineering Manager → Incident Commander. Історія всіх postmortem індексується для пошуку схожих інцидентів. Налаштування довше базового — з урахуванням рев'ю безпеки і мультиагентної архітектури. Підходить компаніям із формальним процесом реагування на інциденти.

Як це працює

Автоматизація побудована на агентній архітектурі: один або кілька AI-агентів Grow2.ai читають джерела даних, застосовують prompt-шаблон із blameless-правилами та видають структурований markdown. Нижче — послідовність кроків від закриття інциденту до готової чернетки і те, як агент обробляє різні типи вхідних даних.

Покроковий процес

1. Тригер. Інженер закриває інцидент у системі управління інцидентами або вручну позначає Slack-тред спеціальною командою. Тригер налаштовується під процес команди — автоматичний при закритті, напівавтоматичний із підтвердженням або суто ручний запуск.
2. Збір контексту. Агент читає Slack-тред повністю: повідомлення, таймстемпи, реакції, посилання, переслані повідомлення. З системи спостережуваності підтягує метрики та алерти за часове вікно інциденту — від першого сигналу до завершення реагування на інцидент. З трекера задач — пов'язані тікети, пул-реквести, записи про розгортання та раніше обговорювані проблеми.
3. Нормалізація. Агент будує хронологію з різних джерел: алерт спрацював о 14:23, команда відповіла о 14:27, розгортання відкотили о 14:35. Події вишиковуються в єдину хронологію із зазначенням джерела кожного факту — щоб інженер при рев'ю розумів, звідки прийшли дані.
4. Застосування prompt-шаблону. Blameless-правила та структура postmortem зашиті в системний prompt. Агент генерує чернетку за цією структурою, підставляючи фактуру із зібраного контексту. Prompt включає правила про те, чого НЕ писати — імена в обвинувачувальних формулюваннях, недоведені причини, емоційні описи.
5. Збереження чернетки. Результат потрапляє в систему документації команди. Посилання публікується в Slack-канал для сповіщення тих, хто має зробити рев'ю.
6. Рев'ю та редагування. Інженер відкриває чернетку, уточнює першопричину, конкретизує завдання, додає відповідальних і дати. Фіналізує документ і публікує в канал команди або зовнішнім стейкхолдерам.

Як агент працює з різними типами даних

Slack-повідомлення — це розмовний потік із жартами, офтопом, посиланнями. Агент витягує лише фактичні події: "deploy відкотили", "помилка в лог-агрегаторі", "алерт на latency". Офтоп ігнорується. Контекст команди — хто що зробив, у який момент — потрапляє в хронологію, побутові зауваження — ні. Реакції на повідомлення використовуються як сигнал важливості: повідомлення з десятьма "+1" з більшою ймовірністю описує ключове рішення.

Дані спостережуваності структуровані. Агент читає назви метрик, їхні значення, пороги алертів, trace-події. Формує фрази на кшталт "p99 latency зріс вище порогу о 14:15, повернувся до норми о 14:38". Графіки та дашборди не включаються в чернетку — лише висновки про поведінку метрик. Це зберігає читабельність документа і не перевантажує його технічними деталями.

Трекер задач — напівструктурований. Агент пов'язує тікети за міткою часу і згаданими сервісами. Якщо в період інциденту був deploy через конкретний пул-реквест — агент додає його в хронологію з посиланням на тікет і коміти. Пов'язані баги та раніше обговорювані проблеми потрапляють у розділ чинників, що сприяли інциденту.

Альтернативні підходи

Нижче — якісне порівняння трьох підходів до написання розбору інциденту.

Ручний підхід дає максимум якості, якщо у інженера є час і гарна пам'ять на деталі інциденту. Насправді після нічного інциденту чернетка відкладається на завтра, потім на понеділок, потім не пишеться взагалі. Знання залишаються в головах команди.

No-code-процес через Zapier або рушій робочих процесів підходить для жорстко структурованих процесів: форма заповнюється, дані маппяться в шаблон. Але розбір інциденту — не форма. Живий Slack-тред з контекстом, логами, рішеннями та емоціями не лягає в поля без втрат змісту.

AI-агент закриває проміжок між "ручним, але рідко" і "шаблонним, але поверхневим". Агент читає неструктуровані дані смислово, а не за ключами, і видає чернетку, яку інженер править за хвилини замість годин ручного збору та написання прози. Механічна частина роботи перекладається на автоматизацію, аналітична залишається за людиною.

Безпека та відповідність вимогам

Дані інциденту чутливі: посилання на внутрішні сервіси, імена клієнтів, деталі вразливостей, технічні параметри інфраструктури. Agent-фреймворк Grow2.ai підтримує on-premise-розгортання або self-hosted LLM для команд з вимогами відповідності. Для хмарного розгортання дані обробляються в ізольованому контексті, не використовуються для навчання моделей, зберігаються згідно з політикою зберігання даних команди.

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

Що потрібно до впровадження

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

Обов'язковий мінімум

1. Централізований канал інцидентів у Slack (або аналозі). Якщо інциденти обговорюються в різних особистих чатах і DM, агенту нічого читати. Потрібна практика "інцидент → виділений тред або канал".
2. Інструмент спостережуваності з API. Будь-яка система моніторингу з доступом до метрик та алертів через API. Без спостережуваності агент не збере хронологію подій.
3. Трекер задач. Система, де фіксуються баги, задачі, розгортання. Надає контекст щодо пов'язаних тікетів.
4. Місце для зберігання розборів інцидентів. Notion, внутрішній wiki або інша система документації. Куди агент писатиме чернетку.
5. Базова культура blameless-postmortem. Якщо команда історично шукає винного, автоматизація не виправить культуру. Агент підсилює існуючу практику, а не створює її з нуля.

Бажано

Формальний процес реагування на інциденти із рівнями критичності (P1/P2/P3), процедура ескалації, роль Incident Commander. Це спрощує конфігурацію агента та робить чернетку узгодженою між інцидентами.

Наявність трекінгу розгортань: агент використовує історію релізів для зв'язки "інцидент стався через X хвилин після deploy Y". Без цього зв'язка будується лише за міткою часу, що знижує точність атрибуції.

Роль "інженер-рев'юер" на ротації: людина, яка перевіряє чернетку перед фінальною публікацією. Не обов'язково виділена — може бути ротація між senior-інженерами.

Можливі підводні камені

• Розмитий Slack-тред. Якщо команда обговорює інцидент паралельно в трьох місцях — агент збере лише один потік. Рішення: домовленість "один інцидент — один тред", плюс практика крос-посилань між місцями обговорення.
• Шум у системі спостережуваності. Сотні алертів від нестабільних метрик перетворюють хронологію на кашу. Потрібна фільтрація: агент читає лише критичні сигнали та пов'язані з ураженими сервісами сигнали. Фільтри налаштовуються в prompt.
• Очікування повноцінного RCA від агента. Чернетка — це стартова фактура, а не готовий аналіз першопричини. Команди, які публікують чернетку без інженерного рев'ю, отримують поверхневі розбори інцидентів і втрачають довіру до документу.
• Неувага до prompt-tuning. Дефолтний шаблон працює, але не ідеально. Команди, які не адаптують prompt під свій контекст (свої сервіси, свій формат рівня критичності, свою аудиторію розбору інциденту), отримують загальну чернетку замість релевантної.
• Відсутність процесу рев'ю. Якщо чернетка одразу публікується без перевірки — помилки агента (некоректна атрибуція, неправильний таймстемп, вигадана деталь) потрапляють у документ. Потрібне правило: чернетка ≠ фінальний розбір інциденту до редагування інженером.