Чернетка postmortem зі Slack + телеметрії

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

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

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

1. Slack-тред інциденту — повідомлення команди, рішення, скріншоти, посилання на дашборди, реакції учасників.
2. Observability-система — метрики, алерти, trace-події, логи у вікні інциденту.
3. Issue tracker — пов'язані тікети, pull requests, deploy-записи.

Що агент формує в draft

Агент генерує постмортем у стандартній blameless-структурі:

• summary інциденту (2-3 речення),
• timeline з таймстемпами подій,
• impact (залучені користувачі, downtime, business-ефект),
• root cause-гіпотеза (preliminary, потребує перевірки),
• contributing factors,
• що спрацювало добре в response,
• lessons learned,
• action items з draft-owners.

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

Draft — це стартова точка. Інженер править фактуру, поглиблює root cause-аналіз, уточнює owners і дати action items. Агент бере на себе механічну роботу: збір артефактів, хронологію, первинний опис подій.

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

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

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

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

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

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

Enterprise 30+ інженерів. Мультиагентна схема: один агент збирає timeline, другий робить root cause preliminary-аналіз, третій формує action items з owners із team-directory. Інтеграція з внутрішнім SSO, audit-логами, compliance-системами. Draft проходить review chain: SRE-lead → Engineering Manager → Incident Commander. Історія всіх postmortem індексується для пошуку схожих інцидентів. Налаштування довше базового — з урахуванням security-review і multi-agent-архітектури. Підходить компаніям із формальним incident response-процесом.

Як це працює

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

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

1. Trigger. Інженер закриває інцидент у системі управління інцидентами або вручну позначає Slack-тред спеціальною командою. Тригер налаштовується під процес команди — автоматичний при закритті, напівавтоматичний із підтвердженням або суто ручний запуск.
2. Збір контексту. Агент читає Slack-тред повністю: повідомлення, таймстемпи, реакції, посилання, переслані повідомлення. З observability-системи підтягує метрики та алерти за вікно інциденту — від першого сигналу до завершення incident response. З issue tracker — пов'язані тікети, pull requests, deploy-записи та раніше обговорювані проблеми.
3. Нормалізація. Агент будує timeline з різних джерел: алерт спрацював о 14:23, команда відповіла о 14:27, deploy відкотили о 14:35. Події вишиковуються в єдину хронологію із зазначенням джерела кожного факту — щоб інженер при review розумів, звідки прийшли дані.
4. Застосування prompt-шаблону. Blameless-правила та структура postmortem зашиті в системний prompt. Агент генерує draft за цією структурою, підставляючи фактуру із зібраного контексту. Prompt включає правила про те, чого НЕ писати — імена в обвинувачувальних формулюваннях, недоведені причини, емоційні описи.
5. Збереження draft. Результат потрапляє в систему документації команди. Посилання публікується в Slack-канал для сповіщення тих, хто має зробити review.
6. Review та редагування. Інженер відкриває draft, править root cause, уточнює action items, додає owners і дати. Фіналізує документ і публікує в канал команди або зовнішнім стейкхолдерам.

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

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

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

Issue tracker — напівструктурований. Агент пов'язує тікети за timestamp і згаданими сервісами. Якщо в період інциденту був deploy через конкретний pull request — агент додає його в timeline з посиланням на тікет і commits. Пов'язані баги та раніше обговорювані issues потрапляють у розділ contributing factors.

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

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

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

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

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

Безпека та compliance

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

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

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

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

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

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

Бажано

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

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

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

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

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