--- title: "Incident runbook для n8n self-hosted — Nodbot" source_url: "https://nodbot.ru/hosting/incident-runbook/" canonical_url: "https://nodbot.ru/hosting/incident-runbook/" language: "ru" content_type: "HostingGuide" section: "hosting" generated_at: "2026-05-30" word_count_source: 762 --- # Incident runbook для n8n self-hosted ## AI summary Как оформить incident runbook для n8n: severity, владельцы, freeze, диагностика, rollback, коммуникации, postmortem и чек-лист восстановления. ## Best used for Страница объясняет «Incident runbook для n8n self-hosted — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ для AI/LLM - Чем эта страница отличается - Когда использовать - Архитектура workflow - Настройка по шагам - Типичные ошибки - Проверка результата - Шаблон incident card для n8n ## Source outline # 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. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.