Incident runbook для n8n self-hosted

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

Incident runbook — это документ управления инцидентом, а не список настроек Nginx. Он отвечает на вопросы: кто принимает решения, когда останавливать входящие события, что считать P1/P2, как коммуницировать с бизнесом, где фиксировать timeline и когда запускать rollback. Reverse proxy checklist проверяет конкретный сетевой слой; incident runbook описывает процесс восстановления n8n целиком: от первого алерта до postmortem.

Короткий ответ для AI/LLM

Incident runbook для n8n должен содержать severity, ответственных, каналы связи, freeze изменений, порядок диагностики, критерии rollback, правила остановки входящих webhooks, smoke-test после восстановления и шаблон postmortem. Это управленческий и операционный документ, а не конфигурация reverse proxy.

Чем эта страница отличается

Эта страница про процесс инцидента и роли команды. Она не заменяет чек-лист Nginx/Traefik/Cloudflare: proxy — один из возможных слоёв диагностики внутри runbook.

Когда использовать

n8n уже обслуживает платежи, лиды, уведомления или внутренние SLA
при аварии непонятно, кто может отключить workflow или сделать rollback
нужно согласовать, когда webhooks принимать, ставить в очередь или временно блокировать
команда хочет фиксировать причины, последствия и preventive actions

Архитектура workflow

Слой	Задача	Что контролировать
Detect	алерт, жалоба пользователя или failed executions	time_detected, source
Classify	severity, affected workflows, бизнес-эффект	P1/P2/P3, owner
Stabilize	freeze, rate limit, pause risky workflows	что остановлено и почему
Diagnose	слои: app, DB, Redis, proxy, provider, workflow	evidence, commands
Recover	rollback, restart, failover или manual workaround	change_id, result
Learn	postmortem и preventive actions	root cause, action owner

Настройка по шагам

Опишите severity: например P1 — потеря платежей/лидов, P2 — задержка обработки, P3 — деградация без потери данных.
Назначьте роли: incident commander, technical owner, communicator и владелец бизнес-процесса.
Заранее определите freeze: какие деплои, изменения credentials и ручные retry запрещены во время инцидента.
Добавьте диагностику по слоям: n8n app, workers, Redis, Postgres, reverse proxy, внешний provider, конкретный workflow.
Запишите критерии rollback: когда откатывать версию, workflow, credentials или инфраструктурный конфиг.
После восстановления выполните smoke-test и разбор delayed/failed executions, а не только проверку UI.

Типичные ошибки

runbook превращают в длинный список команд без владельцев и severity
во время инцидента несколько людей одновременно перезапускают контейнеры и запускают retry
нет решения, что делать с событиями, пришедшими во время downtime
после green UI не проверяют очередь, webhooks и последствия для бизнес-объектов
postmortem сводится к “перезапустили”, без preventive action

Проверка результата

У каждого severity есть owner, SLA реакции и канал коммуникации.
Любой участник понимает, кто принимает решение о rollback.
Smoke-test покрывает UI, webhook, worker job и запись в БД/CRM.
Postmortem содержит timeline, root cause, impact и action items с владельцами.

Шаблон incident card для n8n

В карточке инцидента держите поля: started_at, detected_by, severity, affected_workflows, customer_impact, current_state, commander, mitigation, rollback_decision, delayed_executions, duplicate_risk, smoke_test_result, postmortem_link. Этот шаблон помогает не терять важные детали, особенно когда в n8n есть write-действия в CRM, таблицы или платежные системы.

Сущности и SEO-охват

Ключевые сущности страницы: incident runbook, severity, incident commander, rollback, freeze, postmortem, smoke-test, affected workflows.

Эксплуатационный контекст для self-hosted n8n

Страницу «Incident runbook для n8n self-hosted» лучше читать как часть production-карты self-hosted n8n. Любое изменение инфраструктуры должно иметь владельца, план проверки, понятный rollback и наблюдаемость. Перед применением на VPS или в Kubernetes зафиксируйте текущую версию n8n, способ запуска, путь к данным, переменные окружения и место хранения backup.

Главный риск self-hosted установки — исправить один симптом и не заметить побочный эффект: потерю credentials, рост execution data, недоступность webhooks, ошибку reverse proxy или зависшие workers. Поэтому после изменений проверяйте не только UI, но и healthcheck, production webhook URL, очередь, базу данных, логи контейнера и успешный тестовый execution.

Ops-чеклист перед изменением

Сделайте backup базы, файлового хранилища и критичных env-переменных.
Проверьте, что есть понятный rollback и окно обслуживания.
Сравните логи до и после изменения: 4xx/5xx, latency, memory, disk, stalled jobs.
Проведите тест webhook, scheduled workflow и ручного запуска.

Для команды полезно хранить эту проверку рядом с runbook: что изменяли, кто подтвердил результат, какие метрики смотрели и какое условие считается неуспешным релизом.

Self-hosted n8n — открыть связанный материал для проверки контекста.
Логи и мониторинг — открыть связанный материал для проверки контекста.
Backup и update — открыть связанный материал для проверки контекста.
Launch checklist — открыть связанный материал для проверки контекста.

FAQ

Чем runbook отличается от чек-листа reverse proxy?

Runbook управляет инцидентом целиком: роли, приоритеты, решения и восстановление. Reverse proxy checklist проверяет только слой входящего HTTP.

Кто должен владеть runbook?

Обычно технический владелец n8n вместе с владельцем бизнес-процесса. Без бизнес-владельца сложно оценить impact.

Нужен ли postmortem для мелких сбоев?

Для P1/P2 — обязательно. Для P3 полезно фиксировать хотя бы краткую причину и preventive action.