Major Incident Management: процесс работы с критическими сбоями

Что считать Major Incident

Критерии должны быть формализованы и согласованы с бизнесом до того, как произойдёт первый инцидент. Типовые признаки (любой → Major):

• Сервис недоступен для всех пользователей — продакшен лежит, нельзя работать.
• Финансовые потери начинают накапливаться (e-commerce не принимает заказы, банковские операции остановлены).
• Регуляторный риск — нарушение SLA по контракту с клиентом, под угрозой штраф.
• Утечка / нарушение безопасности — потенциально или фактически.
• Внимание медиа / соцсетей — про инцидент пишут в публичном поле.

Не критерии: «руководитель кричит», «сложная техническая задача», «не понятно, как чинить». Это всё может быть, но это не делает инцидент Major. Цель формализации — чтобы при объявлении Major все понимали, какой level эскалации включается, и не путали со сложным P2.

Роли в Major Incident

Три критичные роли, которые должны быть назначены сразу:

1. Incident Manager (IM) — координатор. НЕ чинит. Его задача: знать что происходит, кто что делает, время следующего обновления. Дежурный IM назначается на смены 24/7.
2. Technical Lead — главный технический специалист. Принимает решения по диагностике и фиксу. Может меняться по ходу инцидента (сначала сетевик, потом разработчик).
3. Communication Lead — общение с пользователями, бизнесом, медиа. Готовит и публикует обновления каждые 15-30 минут на status page и в внутренние каналы.

В малых компаниях все три роли может совмещать один человек, но это плохо: коммуникация выпадает первой. На зрелых процессах роли разделены даже на командах из 5-7 человек.

War room и формат коммуникации

War room — это выделенный канал (физический или виртуальный), где работают все вовлечённые в инцидент. На современном стеке это:

• Отдельный Slack/Mattermost-канал, создаваемый автоматически: #incident-2026-05-12-payments
• Видеоконф с открытым микрофоном (Zoom/Telegram) — для синхронной координации
• Live-документ (Google Docs / Notion) с timeline: что произошло, когда, что предпринято

Важное правило: «no chatter in war room». Только статусы и решения. Обсуждения деталей — в DM или отдельных нитях. War room — это место для координации, не для технической работы.

Формат сообщений каждые N минут:

[14:35] IM: Status update
Impact: Payment service полностью недоступен, ~5000 транзакций/мин затронуто
Action: команда DBA откатывает миграцию schema_migrations
ETA: следующее обновление через 15 минут

Типовой timeline Major Incident

Постмортем без поиска виноватых

Постмортем (post-incident review) — это разбор инцидента. Цель: понять, почему произошло, и предотвратить повторение. Не — найти виноватого.

Принцип blameless: писать в формате «процесс не справился», а не «Иван не справился». Если Иван нажал не ту кнопку — почему процесс позволил ему её нажать без подтверждения? Это вопрос к процессу, не к Ивану.

Структура постмортема:

1. Резюме — что произошло, длительность, impact (1–2 абзаца).
2. Timeline — хронология событий с временными метками. Берётся из live-документа war room.
3. Root cause analysis — методом «5 почему» или Ishikawa. Корневая причина обычно не техническая («поломался диск»), а процессная («нет мониторинга предотказного состояния дисков»).
4. Что сработало хорошо — обязательный раздел. Команды забывают фиксировать удачные решения.
5. Что сработало плохо — без личных нападок.
6. Action items — конкретные задачи с владельцами и сроками. Без action items постмортем — это литература.

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