Postmortem template для n8n: разбор инцидента ¶

Обновлено: 2026-05-29

Intent: postmortem template для n8n incident: timeline, impact, root cause, contributing factors, action items, owner и follow-up
H1: Postmortem template для n8n: как разбирать инцидент и не повторять ошибку
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 639
New word count: 1028

Короткий ответ ¶

Postmortem для n8n нужен после сбоя, который повлиял на данные, клиентов, SLA, деньги, безопасность или работу команды. Хороший postmortem не ищет виноватого, а фиксирует timeline, impact, root cause, contributing factors, что сработало, что не сработало и какие action items снизят риск повторения. Для n8n особенно важно разбирать не только “какой node упал”, но и trigger, payload, credentials, retry, queue, external API, monitoring и ручной процесс вокруг workflow.

Когда делать postmortem ¶

Postmortem нужен не после каждого красного execution. Его стоит проводить, если сбой имел последствия.

Примеры:

• лиды не попадали в CRM;
• webhook принимал события, но workflow не создавал заказы;
• payment notification обработался дважды;
• AI Agent отправил плохой ответ клиенту;
• credentials истекли без алерта;
• очередь Redis накопила jobs;
• backup не восстановился;
• внешний API вернул 429, а workflow создал лавину retry;
• secret попал в logs или execution data.

Цель postmortem — улучшить систему, а не написать красивый отчёт.

1. Краткое резюме ¶

Начинайте документ с блока, который можно прочитать за минуту.

## Summary

Дата: 2026-05-29
Сервис/Workflow: Lead intake to CRM
Severity: SEV-2
Impact: 184 заявки задержаны, 17 дублей создано
Duration: 10:12–12:46 Europe/Amsterdam
Detected by: support report, не monitoring
Root cause: повторная доставка webhook + отсутствие idempotency
Status: fixed, replay завершён
Owner: Ops / CRM automation

Хорошее резюме отвечает на вопросы: что произошло, кого затронуло, сколько длилось, как нашли, почему случилось и что сейчас со статусом.

2. Timeline ¶

Timeline пишется фактами, а не интерпретациями.

Не удаляйте “неудобные” события: позднее обнаружение, отсутствие алерта, ручной workaround. Это самые полезные части разбора.

3. Impact ¶

Impact должен быть измеримым. “Было плохо” не помогает.

Проверьте:

• количество affected executions;
• количество потерянных/задержанных/дублированных records;
• клиентов или внутренних пользователей;
• финансовые последствия;
• нарушение SLA;
• ручные часы на исправление;
• влияние на доверие или безопасность;
• какие данные могли быть раскрыты.

Пример:

Impact:
- 184 заявки обработаны с задержкой до 2 часов 34 минут.
- 17 дублей создано в CRM.
- Потери данных не подтверждены.
- Клиентские уведомления не отправлялись автоматически, support отправил 32 ответа вручную.

4. Root cause и contributing factors ¶

Root cause — это не “node упал”. Нужно докопаться до условия, которое сделало сбой возможным.

Contributing factors — условия, которые усилили инцидент:

• слабый monitoring;
• нет Error Workflow;
• ручной релиз без checklist;
• недостаточные тестовые payload;
• слишком агрессивный retry;
• неверный response mode;
• отсутствие владельца credential;
• изменения в external API.

5. Detection и response ¶

Отдельно разберите, как инцидент обнаружили.

Вопросы:

• Кто первым заметил проблему?
• Сколько времени прошло до обнаружения?
• Почему monitoring не сработал раньше?
• Был ли понятный runbook?
• Кто принял решение остановить workflow?
• Были ли права доступа у нужных людей?
• Как команда общалась во время инцидента?

Если проблему нашёл клиент или support, а не alert, это отдельный action item.

6. What went well / what went wrong ¶

Этот блок помогает не потерять хорошие практики.

## What went well
- Workflow удалось быстро отключить.
- Были сохранены executions для анализа.
- CRM export помог найти дубли.

## What went wrong
- Не было алерта на рост дублей.
- Retry создавал дополнительную нагрузку.
- Owner credential был неизвестен.

Не превращайте “what went wrong” в список обвинений. Формулируйте через систему и процесс.

7. Action items ¶

Action items — самая важная часть. Без них postmortem бесполезен.

Каждый пункт должен иметь владельца и критерий готовности. “Улучшить мониторинг” — плохой action item. “Алерт, если failed executions > 5 за 10 минут” — хороший.

8. Replay и data repair ¶

Для n8n-инцидентов часто нужно не только исправить workflow, но и привести данные в порядок.

Проверьте:

• какие events нужно переиграть;
• какие events уже обработаны;
• какие записи нужно удалить/объединить;
• какие клиенты ждут ответа;
• какие внешние системы получили неверные данные;
• что нельзя replay-ить без риска дублей;
• кто подтверждает завершение сверки.

Replay должен использовать idempotency и журнал, иначе он может создать второй инцидент.

9. Postmortem template ¶

Готовый шаблон:

# Postmortem: <workflow/service>

## Summary
- Date:
- Severity:
- Duration:
- Impact:
- Detected by:
- Current status:

## Timeline
| Time | Event |
|---|---|

## Impact
- Affected executions:
- Affected records/customers:
- Data loss:
- Manual work:

## Root cause

## Contributing factors

## Detection and response

## What went well

## What went wrong

## Action items
| Action | Owner | Due date | Verification |
|---|---|---|---|

## Replay / data repair

## Follow-up date

FAQ ¶

Нужно ли делать postmortem, если всё быстро починили?
Да, если был impact. Быстрый фикс не означает, что причина устранена.

Кто должен писать postmortem?
Лучше вместе: владелец workflow, человек из ops/dev и представитель affected процесса. Один автор часто пропускает контекст.

Как избежать поиска виноватых?
Писать факты, системные причины и action items. Не “Иван забыл”, а “не было release gate, который проверяет X”.

Сколько action items нормально?
Лучше 3–7 выполнимых пунктов, чем 25 пожеланий. Каждый пункт должен иметь owner, срок и проверку.

Когда закрывать postmortem?
Когда action items выполнены или сознательно отменены, replay завершён, а follow-up подтвердил снижение риска.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}