Июль 2024: CrowdStrike выпускает обновление, которое кладёт 8.5 миллионов Windows-машин по всему миру. Аэропорты, больницы, банки — всё стоит. Общий ущерб оценивают в $5.4 миллиарда. Команды, у которых был отлаженный incident management process, восстановились за часы. Те, у кого не было — за дни.
Разница — не в технологиях и не в размере команды. Разница — в том, есть ли процесс, который автоматически запускается при сбое: кто отвечает, что делает, как коммуницирует, как учится на ошибках.
Incident management — это не про тушение пожаров. Это про систему, которая делает пожары редкими, а те, что случаются, — короткими и контролируемыми.
Lifecycle инцидента
Каждый инцидент проходит через пять фаз. Пропуск любой из них увеличивает либо длительность текущего инцидента, либо вероятность следующего.
Фаза 1: Detection — обнаружение
Чем быстрее вы узнаёте о проблеме, тем быстрее начинаете чинить. Три источника обнаружения, ранжированные по скорости:
Автоматический мониторинг (секунды): Uptime monitoring обнаруживает падение за 30-60 секунд. Synthetic checks из нескольких регионов подтверждают проблему, исключая ложные срабатывания. Алерт уходит дежурному инженеру.
Внутреннее обнаружение (минуты): инженер замечает аномалию в логах, необычную метрику в Grafana, ошибку в деплое. Медленнее автоматики, но покрывает сценарии, которые мониторинг не отслеживает.
Обращения пользователей (минуты-часы): тикет в поддержку, жалоба в Twitter, сообщение в Slack. Самый медленный источник. Если вы узнаёте о проблемах преимущественно от пользователей — мониторинг недостаточен.
Цель: минимизировать MTTD (Mean Time to Detect). При правильно настроенном мониторинге — 30-90 секунд для критических сервисов. Ключевые проверки: HTTP endpoints, SSL-сертификаты, DNS, TCP-порты баз данных, heartbeat cron jobs.
Фаза 2: Triage — определение серьёзности
Не все инциденты одинаковы. Triage — это быстрая оценка: насколько серьёзна проблема, кого она затрагивает, и какой уровень реагирования нужен.
P1 — Critical: core functionality недоступна для всех или большинства пользователей. API полностью лежит. Платежи не проходят. Данные теряются. Реакция: немедленно, все на палубу.
P2 — High: значительная деградация или подмножество пользователей затронуто. API работает, но с 20% ошибок. Поиск не работает, остальное — да. Реакция: в течение 15 минут, дежурный + backup.
P3 — Medium: некритичная функция ухудшена, есть workaround. Экспорт отчётов медленный, но работает. Уведомления задерживаются на 5 минут. Реакция: в рабочие часы, владелец сервиса.
P4 — Low: косметическая проблема, минимальное влияние. Кнопка отрисовывается неправильно. Опечатка в email. Реакция: в backlog, при следующем планировании.
Критерий severity — влияние на пользователя, а не техническая сложность. Баг, требующий одну строку fix'а, может быть P1, если он блокирует все платежи. Сложный рефакторинг может быть P4, если пользователи ничего не замечают.
Фаза 3: Response — реагирование
Здесь происходит диагностика и fix. Три параллельных потока:
Техническая работа: диагностика → определение root cause → реализация fix → деплой → верификация. Инженер работает над проблемой.
Коммуникация: status page обновляется каждые 15-20 минут. Инцидент проходит стадии: Investigating → Identified → Monitoring → Resolved. Пользователи информированы.
Координация: для P1/P2 — incident commander управляет процессом. Не чинит сам, а координирует: кто что делает, нужны ли дополнительные ресурсы, правильно ли приоритизированы задачи.
Фаза 4: Recovery — восстановление
Fix задеплоен — инцидент не закрыт. Recovery — это наблюдение за стабильностью после fix'а. Сколько наблюдать — зависит от серьёзности:
P1: минимум 1-2 часа мониторинга после fix'а. Убедитесь, что метрики вернулись к baseline, error rate на нуле, response time в норме.
P2: 30-60 минут активного наблюдения.
P3/P4: стандартная проверка после деплоя.
Частая ошибка: закрыть инцидент сразу после деплоя fix'а. А через 20 минут проблема возвращается, потому что fix был неполным или вызвал side effect. Recovery phase — страховка от этого.
Фаза 5: Learning — обучение
Post-mortem. Разбор инцидента после его закрытия. Не для поиска виноватых — для улучшения системы. Подробнее ниже.
Alerting: как правильно уведомлять
Мониторинг обнаруживает проблему. Alerting доносит её до нужного человека. Между "сработал check" и "инженер начал работать" — пропасть, которую заполняет alerting pipeline.
Каналы по серьёзности
Не все алерты одинаково срочны. Канал уведомления должен соответствовать серьёзности:
P1: Phone call / SMS + Push notification + Slack escalation. Будит инженера в 3 ночи. Ждать не может.
P2: Push notification + Slack/Telegram. Требует внимания в течение 15 минут, но не звонок в 3 ночи (если нет SLA-обязательств).
P3: Slack / Email. Рабочие часы, без эскалации.
P4: Jira ticket / Email digest. Не требует немедленной реакции.
Alert fatigue: когда алертов слишком много
Если дежурный инженер получает 50 алертов в день, он начинает их игнорировать. Через неделю — он пропускает реальный P1, потому что привык к шуму. Alert fatigue — главный враг incident management.
Меры:
Группировка: 10 проверок одного сервиса упали одновременно → один алерт, не десять.
Мультирегиональное подтверждение: алерт только когда 2+ из 3 регионов подтверждают проблему. Один неудачный check — не алерт.
Правильные пороги: не слишком чувствительные, чтобы не срабатывать на каждый spike, но достаточно точные для реальных проблем.
Регулярная ревизия: раз в месяц смотрите: какие алерты были actionable? Какие — шум? Шум — удалить или перенастроить.
Эскалация
Алерт ушёл дежурному. Дежурный не ответил за 5 минут. Что дальше? Без эскалации — ничего. С эскалацией:
0 мин: алерт → primary on-call (Slack + push notification)
5 мин: нет ответа → secondary on-call (Slack + push + SMS)
10 мин: нет ответа → engineering lead (phone call)
15 мин: нет ответа → VP Engineering (phone call + "всё плохо")
Эскалация должна быть автоматической. Если она зависит от того, что кто-то вручную позвонит следующему — она не сработает в 3 часа ночи.
On-call: как организовать дежурства
Если ваш сервис должен работать 24/7 (а SLA 99.9% подразумевает именно это), вам нужна on-call ротация.
Принципы здоровой on-call ротации
Ротация: еженедельная, между всеми инженерами команды. Один человек на дежурстве постоянно = burnout через месяц.
Компенсация: дежурство — это работа. Оплачивайте его или давайте отгулы. Неоплачиваемое дежурство демотивирует и создаёт текучку.
Минимум 2 человека: primary + secondary. Primary недоступен → secondary подхватывает автоматически.
Runbooks: дежурный инженер не обязан знать каждый микросервис наизусть. Runbook для каждого алерта: что проверить, какие команды запустить, когда эскалировать.
Реалистичные SLA: если на дежурстве 1 человек и вы обещаете MTTA \< 5 минут — учтите, что человек спит, принимает душ, ведёт машину. Закладывайте 10-15 минут для ночных инцидентов.
On-call как feedback loop
On-call — не просто "сидеть у телефона". Это feedback loop для качества сервиса. Команды, которые сами дежурят на своём коде, пишут более надёжный код. Принцип "you build it, you run it" (Werner Vogels, Amazon) работает именно поэтому: если ты знаешь, что тебя разбудят из-за бага — ты тщательнее тестируешь.
Метрика: если дежурный инженер получает больше 2 pager-алертов за ночь — это проблема надёжности сервиса, не проблема мониторинга. Чините сервис, а не тюните пороги.
Incident communication
Техническая работа — половина incident management. Вторая половина — коммуникация. С пользователями, с руководством, между командами.
Внешняя коммуникация: status page
Status page — основной канал коммуникации с пользователями во время инцидента. Обновления каждые 15-20 минут. Конкретика вместо общих фраз. Стадии: Investigating → Identified → Monitoring → Resolved.
Дополнительные каналы: email подписчикам status page, сообщение в Twitter/X для массовых инцидентов, баннер в приложении. Подробный гайд по incident communication — в отдельной статье.
Внутренняя коммуникация
Для P1/P2 создаётся dedicated incident channel в Slack (или аналоге): #inc-2026-03-25-api-outage. Вся коммуникация по инциденту — только там. Преимущества: полный audit trail, новые участники быстро получают контекст, не засоряются основные каналы.
Шаблон для первого сообщения в incident channel:
Severity: P1
Impact: API returning 503 for 100% of requests in EU region
Detection: Automated monitoring alert at 14:23 UTC
IC (Incident Commander): @alice
Responders: @bob (backend), @carol (infra)
Status page: https://status.yourcompany.com (incident created)
Роль Incident Commander
Для P1-инцидентов один человек управляет процессом — Incident Commander (IC). IC не чинит проблему. IC координирует:
Распределение задач: "Bob, проверь database connections. Carol, посмотри логи nginx."
Принятие решений: "Откатываем деплой" или "Ждём fix, не откатываем".
Коммуникация вверх: обновляет руководство. "P1, 30 минут, fix в деплое, ETA 10 минут."
Обновление status page: или делегирует это communications lead.
Без IC инженеры одновременно чинят, координируют, отвечают на вопросы руководства и пишут обновления. Результат: каждая задача делается хуже. IC разгружает инженеров — они фокусируются на fix'е.
Post-mortem: как учиться на инцидентах
Инцидент закрыт, сервис работает. Что дальше? Post-mortem — структурированный разбор. Проводится для всех P1 и P2, опционально для повторяющихся P3.
Blameless культура
Blameless post-mortem — не значит "никто не виноват". Это значит: фокус на системных причинах, а не на персональных ошибках. Вопрос не "кто сломал?" а "что в системе позволило этому случиться и как это предотвратить?".
Пример: инженер задеплоил миграцию, которая заблокировала таблицу на 30 минут. Blame: "Инженер не проверил миграцию". Blameless: "В CI/CD pipeline нет этапа проверки миграций на блокирующие операции. Action item: добавить lint для миграций, который ловит ALTER TABLE с LOCK."
Зачем это важно: если пост-мортемы заканчиваются обвинениями, инженеры начинают скрывать ошибки. Скрытые ошибки не фиксятся. Не фиксятся → повторяются.
Структура post-mortem
1. Summary: что произошло, длительность, severity, кого затронуло. Одним абзацем.
2. Timeline: хронология с точностью до минуты. 14:23 — alert triggered. 14:25 — engineer acknowledged. 14:31 — root cause identified. 14:45 — fix deployed. 15:00 — metrics normalized.
3. Root Cause: техническая причина. Не "сервер упал", а "connection pool exhaustion due to unclosed connections in retry logic introduced in commit abc123".
4. Impact: конкретные цифры. Количество затронутых пользователей, процент ошибочных запросов, длительность. Финансовый impact, если применимо.
5. What Went Well: что сработало. Быстрое обнаружение? Эффективная коммуникация? Хороший runbook? Фиксировать удачи так же важно, как ошибки — чтобы не потерять то, что работает.
6. What Went Wrong: что не сработало. Медленная эскалация? Отсутствие runbook? Не тот алерт? Без blame — только факты и системные причины.
7. Action Items: конкретные задачи с ответственными и дедлайнами. "Add connection pool monitoring — @bob — by March 30". Не абстрактные "improve monitoring".
Action items: самая важная часть
Post-mortem без action items — литература. Формулировка: конкретная задача + ответственный + дедлайн.
Плохо: "Improve database monitoring"
Хорошо: "Add connection pool usage alert at 80% threshold — @bob — by 2026-04-01"
Плохо: "Better testing"
Хорошо: "Add migration lint step to CI that rejects ALTER TABLE without CONCURRENTLY on tables > 1M rows — @carol — by 2026-04-05"
И самое главное: action items должны выполняться. Трекайте их в Jira/Linear/Asana. Проверяйте на еженедельном standup. Post-mortem с 5 невыполненными action items — хуже, чем без post-mortem, потому что создаёт иллюзию улучшений.
Метрики incident management
Чтобы улучшать incident management, нужно его измерять. Четыре ключевые метрики:
MTTD — Mean Time to Detect
Время от начала проблемы до её обнаружения. Зависит от качества мониторинга. Целевые значения: \< 1 минуты для P1 (автоматический мониторинг), \< 5 минут для P2. Если MTTD > 10 минут для критических сервисов — расширяйте coverage мониторинга.
MTTA — Mean Time to Acknowledge
Время от алерта до начала работы инженером. Зависит от on-call процесса. Целевые значения: \< 5 минут днём, \< 15 минут ночью. Если MTTA высокий — проблема в routing алертов, эскалации или on-call coverage.
MTTR — Mean Time to Resolve
Время от обнаружения до полного восстановления. Общая метрика эффективности incident management. MTTR = MTTD + MTTA + time to fix + recovery time. Для P1: target \< 1 часа. Для P2: \< 4 часов. Высокий MTTR при нормальных MTTD и MTTA → проблема в диагностике или сложности fix'а → нужны runbooks и tooling.
Incident frequency
Количество инцидентов по severity за период. Тренд важнее абсолютного числа: 3 P1 в месяц → 2 → 1 — хорошо, процесс работает. 1 → 2 → 3 — плохо, надёжность деградирует. Коррелируйте с деплоями, ростом нагрузки, изменениями в команде.
Runbooks: документация для инцидентов
Runbook — пошаговая инструкция для конкретного типа проблемы. В 3 ночи, когда дежурный инженер полусонный, runbook заменяет опыт и память.
Что включает runbook
Trigger: какой алерт/ситуация запускает этот runbook
Диагностика: команды для проверки (curl, SQL queries, log grep). Что смотреть и что считать аномалией.
Решение: пошаговые действия для каждого сценария (restart service, scale up, rollback, failover)
Верификация: как убедиться, что fix сработал. Какие метрики проверить.
Эскалация: когда и кому эскалировать, если runbook не помог.
Runbooks — живые документы. Обновляйте после каждого инцидента, где runbook оказался неполным или неточным. Это один из самых ценных action items в post-mortem: "Update API runbook with database failover steps — @alice — by Friday".
Автоматизация incident management
Каждый ручной шаг в incident process — потенциальная задержка. Автоматизируйте всё, что можно автоматизировать, сохраняя человеческий контроль для решений.
Автоматизировать:
— Обнаружение проблемы (мониторинг, synthetic checks)
— Routing алерта нужному инженеру (on-call schedule)
— Эскалация при отсутствии ответа
— Создание инцидента на status page
— Создание incident channel в Slack
— Сбор метрик и логов в единый view
Оставить человеку:
— Определение severity (автоматика может предложить, человек подтверждает)
— Написание human-readable обновлений для status page
— Выбор стратегии fix'а (rollback vs. hotfix vs. scale)
— Проведение post-mortem
Зрелость incident management: 4 уровня
Честно оцените, где вы сейчас, и определите следующий шаг.
Уровень 1: Reactive
Инциденты обнаруживают пользователи. Нет формального процесса — кто увидел, тот и чинит. Нет post-mortem. Одни и те же проблемы повторяются.
Следующий шаг: настроить базовый мониторинг для критических сервисов. Добавить алерты в Slack/Telegram/Email.
Уровень 2: Defined
Есть мониторинг, алерты приходят. Есть on-call — хотя бы неформальный. Есть severity levels. Post-mortem проводится для крупных инцидентов, но action items не всегда выполняются.
Следующий шаг: формализовать on-call ротацию. Создать runbooks для топ-5 алертов. Трекать action items в системе задач.
Уровень 3: Proactive
Мониторинг покрывает все критические пути. On-call ротация формализована. Runbooks актуальны. Post-mortem — стандарт для P1/P2. Action items трекаются и выполняются. MTTD \< 2 минут.
Следующий шаг: автоматизация (auto-incident creation, auto-escalation). Chaos engineering. SLO-based alerting вместо threshold-based.
Уровень 4: Predictive
Проблемы предотвращаются до того, как становятся инцидентами. SSL expiry alerts за 30 дней. Capacity planning на основе трендов. Canary deploys ловят баги до production. Incident frequency стабильно снижается квартал к кварталу.
Чеклист: оцените свой incident management
Мониторинг: критические сервисы проверяются автоматически из нескольких регионов
Alerting: алерты маршрутизируются по severity. P1 будит дежурного. P4 идёт в backlog
On-call: ротация минимум из 2 человек, с компенсацией и runbooks
Эскалация: автоматическая, по таймеру, с увеличением severity
Коммуникация: status page обновляется автоматически при инциденте, обновления каждые 15-20 минут
IC роль: для P1 есть Incident Commander, который координирует, а не чинит
Post-mortem: проводится для каждого P1/P2, blameless, с action items
Action items: трекаются в системе задач, выполняются в срок
Метрики: MTTD, MTTA, MTTR измеряются и тренд улучшается
Runbooks: актуальны, покрывают топ-10 алертов, обновляются после инцидентов
Связанные материалы
Complete Guide to Uptime Monitoring — мониторинг, который обнаруживает инциденты
Complete Guide to Status Pages — как коммуницировать с пользователями во время инцидентов
Status Page Best Practices — формула обновлений и incident communication
How to Reduce False Alarms — чтобы инциденты открывались только на реальные проблемы
SLA vs SLO vs SLI — метрики, по которым оценивается reliability
Cost of Downtime — зачем всё это: бизнес-стоимость каждой минуты инцидента
Website Downtime: Causes and Prevention — 10 причин инцидентов и как их предотвратить
FAQ
What is incident management?
Incident management is the process of detecting, responding to, and resolving service disruptions. It covers the full lifecycle: monitoring detects a problem, alerting notifies the right people, a structured response process kicks in (triage, diagnosis, fix, verification), and a post-mortem prevents recurrence. The goal is to minimize both the duration and impact of incidents.
What's the difference between incident management and incident response?
Incident response is the immediate reaction: detect, triage, fix. Incident management is broader — it includes response plus everything around it: defining severity levels, maintaining on-call schedules, writing runbooks, conducting post-mortems, and continuously improving the process. Response is a phase; management is the system.
How do I prioritize incidents?
Use severity levels tied to user impact, not technical complexity. P1/Critical: core functionality down for all users. P2/High: significant feature degraded or subset of users affected. P3/Medium: non-critical feature impaired, workaround available. P4/Low: cosmetic or minor issue. Severity determines response time, escalation path, and communication level.
Do I need an on-call rotation?
If your service needs to be available outside business hours — yes. Without on-call, a 2am outage waits until 9am for response. That's 7 hours of downtime. On-call doesn't mean 24/7 monitoring by one person. Rotate weekly across the team, compensate fairly, and automate as much as possible so on-call engineers only wake up for real incidents.
What is MTTA and MTTR?
MTTA (Mean Time to Acknowledge) measures how long between an alert firing and an engineer starting work on it. MTTR (Mean Time to Resolve) measures total time from incident detection to full resolution. Both are key operational metrics. MTTA tells you if your alerting and on-call process is fast enough. MTTR tells you if your overall incident response is effective.
Should post-mortems be blameless?
Yes. Blameless doesn't mean accountability-free — it means focusing on systemic causes rather than individual mistakes. 'Dave deployed bad code' isn't actionable. 'The deployment pipeline lacked a canary stage, so the faulty release reached 100% of traffic instantly' is actionable. Blame discourages reporting; systemic analysis prevents recurrence.
How often should I review my incident process?
After every P1/P2 incident (post-mortem), and quarterly for the overall process. Quarterly reviews cover: are severities calibrated correctly? Is MTTA improving? Are action items from post-mortems getting completed? Are there patterns across incidents? This is how the process evolves from 'we have a runbook' to 'we rarely have serious incidents.'
What tools do I need for incident management?
At minimum: monitoring (to detect), alerting (to notify), a status page (to communicate), and a post-mortem template (to learn). As you scale: on-call scheduling (PagerDuty, OpsGenie), incident tracking, automated runbooks, and integration between all of these. The tools matter less than the process — a team with good habits and basic tools outperforms a team with expensive tools and no process.