Черновик 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 до редактирования инженером.