Incident response n8n: runbook разбора аварий ¶

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

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

Incident response для n8n — это не «кто быстрее откроет executions». В первые минуты нужно определить масштаб сбоя, остановить повторный ущерб, назначить владельца инцидента, сохранить execution ID и payload, проверить критичные зависимости и дать бизнесу понятный статус. Хороший runbook разделяет диагностику, containment, восстановление и postmortem, чтобы команда не спорила во время аварии.

Когда запускать этот runbook ¶

Запускайте incident response, если automation влияет на деньги, клиентов, платежи, CRM, поддержку, отчёты или внутренние SLA. Для маленького тестового workflow достаточно обычной диагностики. Для production-инцидента нужна дисциплина: один человек координирует, один чинит, один сообщает статус владельцам процесса.

Типичные поводы:

• webhooks перестали приходить или возвращают ошибку провайдеру;
• workflow создаёт дубли лидов, заказов, платежей или тикетов;
• workers стоят, executions зависли, очередь растёт;
• внешний API недоступен или начал отдавать 401/429/500;
• AI Agent начал давать опасные или дорогие ответы;
• после обновления n8n сломались credentials, expressions или Code node;
• база данных, Redis или reverse proxy дают нестабильность.

1. Первые 10 минут ¶

Главная цель первых минут — не починить всё, а остановить расширение ущерба и собрать факты. Если workflow пишет в CRM или платёжную систему, иногда правильнее временно выключить один workflow, чем оставить его создавать дубли.

Пример сообщения: «С 11:42 заявки из формы могут задерживаться. Продажи не потеряны: входящие payload сохраняем в журнал, автоматическую запись в CRM временно остановили. Следующее обновление статуса через 30 минут или раньше при восстановлении».

2. Классификация severity ¶

Не все ошибки одинаковые. Ошибка в тестовом workflow и повторное списание оплаты — разные уровни реакции.

Если есть сомнение между S1 и S2, выбирайте S1 на первые 15 минут. Понизить severity легче, чем объяснять, почему команда час ждала при массовом дублеже.

3. Быстрая карта причин ¶

n8n-инцидент редко живёт только в одном месте. Workflow может падать из-за внешнего API, истёкшего OAuth, reverse proxy, Redis, Postgres, неверного WEBHOOK_URL, rate limit или изменения payload у провайдера.

4. Containment: как остановить ущерб ¶

Containment — это временная мера, которая снижает ущерб до полноценного исправления. Не путайте её с permanent fix.

Возможные действия:

• выключить конкретный workflow, а не весь инстанс;
• добавить IF-фильтр, который пропускает только безопасные события;
• отключить запись во внешнюю систему, но оставить журнал payload;
• временно перевести AI-ответы в режим черновика;
• уменьшить batch size или concurrency;
• поставить провайдеру быстрый 200 OK, а обработку делать асинхронно;
• включить ручную обработку заявок из backup-журнала.

Каждую временную меру нужно подписывать: кто включил, когда, зачем и как её снять. Иначе через неделю production будет работать на «аварийном костыле», о котором забыли.

5. Диагностика по слоям ¶

Идите от внешнего события к внутреннему выполнению. Не начинайте с переписывания workflow, пока не понятно, пришло ли событие и какой payload реально получил n8n.

# Проверка доступности публичного endpoint
curl -i https://automation.example.com/webhook/order-created

# Проверка контейнеров
sudo docker compose ps
sudo docker compose logs --tail=200 n8n

# Если есть workers/Redis
sudo docker compose logs --tail=200 n8n-worker
redis-cli -h redis ping

Проверяйте не только успешный запуск, но и время между событием и финальным действием. Для webhooks это критично: провайдер может повторно доставлять событие, если не получил ожидаемый ответ.

6. Восстановление сервиса ¶

Восстановление считается завершённым не тогда, когда «ошибка исчезла», а когда выполнены smoke tests и бизнес-процесс снова работает.

Минимальный smoke test:

1. Отправить тестовый payload с уникальным ID.
2. Проверить, что workflow создал ровно одну запись.
3. Убедиться, что execution завершился успешно.
4. Проверить внешний результат: CRM, таблицу, тикет, платёж, уведомление.
5. Проверить, что retry того же payload не создаёт дубль.
6. Вернуть временно отключённые ветки или зафиксировать, почему они остаются выключенными.

7. Коммуникация ¶

Техническая команда часто сообщает слишком много деталей и слишком мало смысла. Бизнесу нужно знать: что сломалось, кто затронут, есть ли потеря данных, какой обходной путь и когда будет следующий статус.

Шаблон обновления:

Статус: частично восстановлено. Причина предварительно связана с OAuth credential для Google Sheets. Новые заявки сохраняются в журнал, запись в таблицу временно отключена. Потери данных не видим. Следующий шаг — reauth service credential и smoke test на 5 реальных заявках.

Не обещайте точное время восстановления, если его нет. Лучше давать следующий момент обновления статуса.

8. Postmortem ¶

Postmortem нужен не для поиска виноватого, а чтобы следующий инцидент был короче. Хороший документ отвечает на пять вопросов:

Контрольный чеклист ¶

• Есть incident owner и время начала.
• Severity выбран и при необходимости обновлён.
• Execution ID, payload и внешний event ID сохранены.
• Ущерб остановлен: нет новых дублей, списаний или опасных AI-действий.
• Есть понятный статус для владельца процесса.
• Smoke test прошёл на реальном сценарии.
• Временные обходы либо сняты, либо имеют owner и срок.
• Postmortem содержит конкретные guardrails.

FAQ ¶

Нужно ли выключать весь n8n при инциденте?
Обычно нет. Лучше отключить конкретный workflow, опасную ветку или запись во внешнюю систему. Полная остановка оправдана, если инстанс массово портит данные или есть риск утечки.

Что важнее: logs или executions?
Нужны оба источника. Executions показывают путь workflow и данные node, а logs помогают увидеть инфраструктуру: proxy, workers, Redis, database, permission errors.

Как избежать дублей после восстановления?
Используйте внешний event ID, order ID, payment ID или другой уникальный ключ. Перед повторной обработкой проверьте, что событие не было уже записано.

Когда нужен postmortem?
Всегда, если инцидент затронул production-процесс, клиента, деньги, персональные данные или потребовал ручного обхода.

Можно ли автоматизировать incident response в n8n?
Да, но аккуратно: алерты, сбор контекста, создание incident note, health checks. Решения вроде удаления данных, массового retry или отключения security-фильтров должны оставаться ручными.

{
  "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": "..."}
}