Инциденты, on-call и postmortem
Разработка не заканчивается на деплое
Инцидент — это событие, приводящее к нарушению согласованного уровня предоставления услуг, требующее немедленного вмешательства инженерной команды для восстановления штатного функционирования системы и минимизации ущерба бизнес-процессам.
On-call — это режим готовности специалиста к реагированию на критические события в нерабочее время, предполагающий постоянную доступность, использование специализированных систем оповещения и чёткий регламент ротации для обеспечения непрерывного мониторинга производственных сред.
Postmortem — это структурированный аналитический процесс, проводимый после завершения инцидента, направленный на восстановление хронологии событий, выявление системных причин сбоя, формулирование корректирующих действий и документирование извлечённых уроков для повышения устойчивости инфраструктуры.
После выкладки в production система живёт годами. Пользователи, интеграции, нагрузка и среда меняются. Рано или поздно что-то пойдёт не так: упадёт сервис, замедлится оплата, сломается отчёт для регулятора. Зрелая команда отличает дефект от инцидента, знает severity, держит on-call и runbook, измеряет MTTR и проводит blameless postmortem — разбор без поиска виноватых.
Продакшен — это рабочая среда развертывания программного обеспечения, предназначенная для обслуживания реальных пользователей и обработки коммерческих транзакций, характеризующаяся строгими требованиями к доступности, безопасности и производительности.
MTTR — это метрика, отражающая среднее время, необходимое для полного восстановления работоспособности системы после возникновения инцидента, включающая этапы обнаружения, диагностики, применения исправления и верификации стабильности сервиса.
Blameless postmortem — полумифическая (на практике я такое не встречал) аналитическая практика, фокусирующаяся на изучении системных недостатков, архитектурных упущений и пробелов в процедурах реагирования для создания культуры непрерывного улучшения и доверия внутри команды.
Эта глава — вводный регламент для новичка. Смежные темы: ITSM, Kanban и Expedite, DevOps, управление изменениями.
- Восстановить сервис (mitigation, rollback, hotfix). 2) Сообщить стейкхолдерам по severity. 3) Собрать факты. 4) Postmortem и action items — когда стало тише.
Play ITЗагрузка интерактивного демо…
Стейкхолдер — это участник процесса или заинтересованная сторона, чьи бизнес-цели, финансовые интересы или операционные процессы напрямую зависят от доступности и корректности функционирования рассматриваемой информационной системы.
Инцидент и дефект — разные сущности
Дефект (баг) — несоответствие ожидаемому поведению. Находят на тестах или в эксплуатации, заводят тикет, планируют исправление в спринте или потоке Kanban. Срочность обычно плановая, если баг не роняет prod.
Инцидент (incident) — событие, которое сейчас ухудшает или останавливает сервис для пользователей. Требует немедленного реагирования по регламенту on-call, часто через класс Expedite на доске (Kanban / инциденты).
Немедленное реагирование на инцидент — это оперативный процесс активации процедур диагностики и восстановления в первые минуты после обнаружения аномалии, включающий автоматическое оповещение, изоляцию затронутых компонентов и запуск предопределённых сценариев стабилизации.
| Дефект | Инцидент | |
|---|---|---|
| Срочность | Плановая (если не prod-down) | Немедленная |
| Цель | Исправить качественно | Восстановить сервис, затем найти причину |
| Процесс | Обычный backlog | On-call, эскалация, war room, postmortem |
| Метрики | Количество багов, escape rate | MTTR, частота P1/P2 |
| Кто владеет | PO приоритизирует в backlog | Incident commander / on-call |
Один и тот же корневой баг может начаться как инцидент (prod лежит), а закончиться тикетом на долгосрочный фикс в backlog.
Эскалация — это процедура передачи ответственности за устранение инцидента специалистам более высокого уровня квалификации или руководству, инициируемая при превышении нормативных сроков восстановления или обнаружении технических ограничений текущего исполнителя.
War room — это выделенный коммуникационный канал или физическое пространство, создаваемое на время критического инцидента для консолидации ключевых экспертов, обеспечения синхронного обмена данными и принятия скоординированных технических решений в условиях высокой временной нагрузки.
Escape rate — это метрика, фиксирующая долю дефектов или уязвимостей, обнаруженных пользователями в производственной среде после успешного прохождения всех этапов тестирования и верификации, отражающая эффективность процессов контроля качества.
Incident commander — это назначенный руководитель процесса реагирования на инцидент, обладающий полномочиями по координации действий команды, принятию стратегических решений, управлению коммуникацией со стейкхолдерами и обеспечению соблюдения регламента восстановления.
P1/P2 — это уровни критичности инцидентов в корпоративной классификации, где первый уровень обозначает полную недоступность ключевого сервиса с прямым финансовым или репутационным ущербом, а второй уровень указывает на существенную деградацию функциональности системы с продолжением обработки ограниченного объёма запросов.
Severity — уровни серьёзности
Severity — это параметр классификации инцидента, определяющий степень воздействия сбоя на бизнес-процессы, доступность сервиса и пользовательский опыт, который служит основанием для приоритизации инженерных ресурсов и выбора сценария реагирования.
Severity (критичность) — договорённая шкала, насколько плохо для бизнеса и пользователей. Названия различаются (P1–P4, SEV1–SEV4, Critical–Low), важна одна таблица на всю организацию.
| Уровень | Пример | Действия |
|---|---|---|
| P1 (Critical) | Prod недоступен, утечка ПДн, невозможна оплата | Все on-call, статус-страница, war room, эскалация руководству |
| P2 (Major) | Сильная деградация, есть обходной путь | On-call в рамках SLA, частые апдейты |
| P3 (Minor) | Ограниченное влияние, мало пользователей | Обычный приоритет в backlog, мониторинг |
| P4 (Trivial) | Косметика, нет влияния на бизнес | Плановый релиз |
SLA — это юридически обязывающее соглашение между поставщиком услуг и потребителем, фиксирующее измеримые показатели доступности, производительности и времени восстановления, а также финансовые обязательства при отклонении от установленных нормативов.
Статус-страница — это публичный информационный ресурс, предоставляющий пользователям и партнёрам текущие данные о работоспособности сервисов, ходе устранения инцидентов и истории доступности, формирующий прозрачную коммуникационную среду и обеспечивающий самостоятельное информирование пользователей.
Шкала согласуется с ITSM и договором SLA. В аутсорсе в договоре часто прописаны время реакции на P1 и штрафы — знайте определения до первого звонка.
Severity — влияние на бизнес сейчас. Priority в backlog — когда починим в плане. P3 инцидент может стать P1, если совпал с днём отчётности для ЦБ.
Примеры по контекстам
| Контекст | P1 | P2 |
|---|---|---|
| Продуктовый маркетплейс | Нельзя оформить заказ | Поиск не работает, каталог открывается |
| Аутсорс для банка | Нарушен SLA по платежам | Деградация мобильного API |
| Госпортал | Недоступна подача заявления | Ошибка в статусе заявления, повторная подача возможна |
MTTR и другие метрики
MTTR (Mean Time To Repair / Recovery) — среднее время восстановления сервиса после сбоя. Считают от момента обнаружения (алерт или первый тикет) до момента, когда сервис снова выполняет свою функцию для пользователей.
Что снижает MTTR:
- актуальные runbook;
- rollback в один клик или по чек-листу;
- observability — логи, метрики, трейсы с correlation id;
- feature flags для отключения сломанной части;
- регулярные учения (game day).
Rollback — это процедура возврата системы к предыдущей стабильной версии программного обеспечения или конфигурации, инициируемая при обнаружении критических дефектов в недавно развернутом обновлении для обеспечения непрерывности бизнес-процессов.
Observability — это архитектурное свойство системы, обеспечивающее полную видимость внутреннего состояния компонентов через сбор и корреляцию метрик, логов и распределённых трассировок, что позволяет инженерам диагностировать неизвестные проблемы путём анализа текущего состояния системы.
Feature Flags — это механизм управления функциональностью на уровне конфигурации, позволяющий активировать или деактивировать отдельные возможности приложения путём изменения параметров окружения, что обеспечивает безопасное тестирование в продакшене и оперативное переключение проблемных компонентов.
Correlation id — это уникальный идентификатор, генерируемый при входе запроса в систему и передаваемый через все уровни распределённой архитектуры, обеспечивающий возможность сквозной трассировки взаимодействия микросервисов и упрощающий локализацию точек возникновения ошибок.
Трейсы — это детализированные журналы выполнения запросов, фиксирующие последовательность вызовов между компонентами распределённой системы, временные задержки на каждом этапе и контекст обработки данных для целей глубокой диагностики производительности.
Связанные метрики:
- MTTD — время до обнаружения (хорошие алерты);
- MTBF — время между отказами;
- частота инцидентов по severity за квартал.
MTTR без postmortem оптимизирует тушение, но не причину — пожары повторяются.
Поток реагирования на инцидент
On-call — дежурство по инцидентам
On-call — ротация инженеров, которые первыми реагируют на алерты вне рабочего времени (и часто в рабочее, если нет отдельной L1).
Что должно быть в wiki:
- календарь дежурств и цепочка эскалации (5 мин → тимлид → директор);
- runbook — пошаговые действия по типовым алертам;
- контакты вендоров (облако, СУБД, платёжный шлюз);
- политика отдыха после ночного P1 (не ставить дежурного в обязательный созвон в 9:00);
- как завести инцидент и кто incident commander.
L1 (первая линия) часто в техподдержке: перезапуск по runbook, сбор скриншотов. Разработчик обычно L2/L3 — глубокая диагностика, патч, анализ кода.
Пример ротации в продуктовой команде
Две недели on-call у backend-разработчика, параллельно — DevOps. Алерт из Prometheus → PagerDuty → дежурный. Если за 15 минут нет прогресса — эскалация на тимлида. P1 — созвон в Slack/Teams, канал #incident-YYYYMMDD.
Аутсорс
В договоре — время реакции на P1, доступ к prod, кто утверждает hotfix. Дежурный исполнителя координируется с on-call заказчика; без единого канала MTTR растёт из-за согласований.
Runbook — пошаговая инструкция
Runbook — это набор формализованных инструкций и сценариев реагирования, описывающий последовательность действий для диагностики и устранения типовых сбоев, предназначенный для стандартизации процесса восстановления сервисов и сохранения инженерных знаний в централизованных репозиториях.
Runbook — документ "что делать, когда сработал алерт X". Не заменяет понимание системы, но убирает панику в 3 ночи.
Минимальная структура runbook:
- Симптом — какой алерт, что видит пользователь.
- Проверки — дашборды, логи, health-check.
- Действия — restart, rollback, отключить флаг, масштабировать.
- Эскалация — когда звать L3, вендора, PO для коммуникации.
- После стабилизации — ссылки на postmortem-шаблон.
Runbook ревьюят раз в 3–6 месяцев или после каждого P1, где шаги устарели.
Hotfix, rollback и mitigation
Hotfix, rollback и mitigation — это комплекс экстренных мер восстановления, включающий оперативное внедрение узконаправленного исправления кода, откат к последней стабильной версии системы и применение временных технических ограничений для минимизации ущерба пользователям.
Mitigation — это набор временных или частичных технических мер, применяемых для снижения влияния инцидента на работоспособность системы, позволяющий восстановить критически важные функции до момента полного устранения корневой причины сбоя.
| Стратегия | Когда применяют | Риски |
|---|---|---|
| Mitigation (обход) | Нужно быстро снять боль | Временное решение; не забыть снять |
| Rollback (откат версии) | Быстрый откат безопаснее патча | Несовместимость с миграцией БД |
| Hotfix (срочный патч) | Откат невозможен | Меньше тестов; нужен stage или canary |
Примеры mitigation:
- включить fallback на старую версию расчёта;
- отключить фичу feature flag;
- перенаправить трафик на резервный ЦОД;
- поднять rate limit на partner API.
В банке и госсекторе hotfix в prod часто требует CAB или согласования по управлению изменениями — знайте tier срочного изменения заранее.
Tier — это уровневая структура технической поддержки или инженерных команд, определяющая границы компетенций, нормативы времени реагирования и маршруты эскалации инцидентов в зависимости от сложности диагностики и требуемой глубины доступа к инфраструктуре.
После стабилизации — postmortem и action items в backlog.
Action items — это перечень конкретных технических и организационных задач, сформированных на основе анализа инцидента, предназначенных для устранения выявленных уязвимостей, автоматизации рутинных процедур и обеспечения долгосрочной стабильности системы.
Blameless postmortem
Postmortem (разбор после инцидента) в зрелых командах без поиска виноватых (blameless): цель — улучшить систему и процессы, а не наказать дежурного.
Структура документа:
- Резюме — что случилось, severity, длительность, MTTR.
- Timeline — хронология по минутам (алерт, действия, восстановление).
- Root cause — системная причина (процесс, мониторинг, архитектура, ADR), а не "ошибся человек".
- Что сработало / не сработало в реагировании.
- Action items — тикеты с владельцами и сроками (runbook, алерт, тест, рефакторинг).
- Публикация в wiki для обучения команды.
Метод "пять почему" ищет системную цепочку: деплой без canary → нет политики → нет CI gate → не было ADR о стратегии релиза. Вопрос не "кто нажал deploy", а "почему процесс позволил".
Культура ошибок как данных — в уважении к инженерному труду. Postmortem по P1 обычно в течение 5 рабочих дней после стабилизации. Культура ошибок — это организационная модель, рассматривающая технические сбои как источник ценных данных для совершенствования архитектуры, регламентов и инженерных практик, обеспечивающая открытое обсуждение инцидентов и формирование доверия внутри команды.
Timeline — это хронологический журнал событий инцидента, фиксирующий точное время обнаружения аномалии, этапы эскалации, принятые технические решения и моменты восстановления сервисов, формирующий объективную основу для последующего аналитического разбора.
Root cause — это фундаментальная техническая или процессная причина, инициировавшая цепочку событий, приведших к инциденту, выявление которой требует глубокого анализа системных зависимостей и устранения первичного дефекта для гарантии долгосрочной стабильности.
Observability — наблюдаемость
Observability — способность понять состояние системы по логам, метрикам и трейсам (distributed tracing). Без них postmortem превращается в угадывание, MTTR растёт.
Минимум на production:
- централизованные логи с correlation / trace id;
- алерты по SLO, не по "диск 80%" без контекста;
- дашборды для on-call (RPS, error rate, latency p95);
- трассировка между сервисами для цепочек вызовов.
Подробнее — DevOps и CI/CD, системное администрирование.
Инциденты в Agile-потоке
- В Scrum инцидент P1 прерывает спринт — цель пересматривают с PO.
- В Kanban — класс Expedite с правилом WIP (Kanban).
- Action items из postmortem — обычный backlog, приоритет с PO.
- Повторяющиеся P1 по одной причине — сигнал для ADR или архитектурного рефакторинга.
Коммуникация при инциденте
| Аудитория | Что сообщать |
|---|---|
| Пользователи | Статус-страница, ETA если известно |
| Поддержка | Обходной путь, шаблон ответа |
| Бизнес / PO | Влияние на метрики, деньги, регулятор |
| Заказчик (аутсорс) | По SLA, протокол звонка |
| Регулятор (гос) | По регламенту информирования |
Один incident commander координирует технику и коммуникацию — не все чинят и пишут клиентам одновременно.
Роль разработчика при первом P1
- Не паниковать — открыть runbook и канал инцидента.
- Собирать факты (логи, время, версия релиза), не теории.
- Предлагать безопасное восстановление (rollback часто лучше "быстрого фикса").
- Документировать действия в тикете — для timeline postmortem.
- После сбоя — участие в postmortem без стыда; система ломается, задача — учиться.
Incident commander и роли в war room
| Роль | Задача |
|---|---|
| Incident commander | Координация, timeline, приоритет действий |
| Tech lead / on-call | Диагностика, rollback, hotfix |
| Communications | Статус пользователям и поддержке |
| Scribe | Запись времени и действий для postmortem |
| PO / PM | Бизнес-решения (отключить фичу, компенсации) |
Один человек не должен одновременно чинить prod и писать пресс-релиз.
Шаблон timeline для postmortem
| Время (UTC) | Событие |
|---|---|
| 14:02 | Алерт: error rate > 5% |
| 14:05 | On-call подтвердил, severity P1 |
| 14:12 | Rollback API v2.4.1 → v2.4.0 |
| 14:18 | Error rate нормализовался |
| 14:30 | Статус-страница: resolved |
Точное время важнее красивых формулировок. Источник — тикет инцидента и логи.
Пример postmortem (фрагмент)
Инцидент: недоступна оплата 47 минут, P1. MTTR: 47 мин. Root cause: миграция БД заблокировала таблицу payments; деплой без проверки lock timeout. Что сработало: быстрый rollback. Что нет: нет алерта на длительные блокировки. Action items: (1) алерт на lock > 30 с — владелец SRE, 2 недели; (2) миграции только с lock_timeout — владелец тимлид, 1 спринт; (3) game day на rollback — квартал.
Game day и учения
Учения (game day) — это плановые симуляции критических сбоев в контролируемых условиях, предназначенные для проверки эффективности регламентов реагирования, отработки навыков координации команды и верификации работоспособности резервных механизмов до наступления реального инцидента.
Game day — запланированное учение: симуляция падения Redis, отказа AZ, отката релиза. Цели:
- проверить runbook на практике;
- измерить MTTR в безопасных условиях;
- обучить новичков без ночного P1.
В банке и госе учения иногда обязательны по регламенту ИБ.
Статус-страница и ожидания пользователей
Ожидания пользователей — это установленные нормативы доступности, скорости отклика и корректности функциональности, закреплённые в соглашениях об уровне обслуживания и определяющие пороговые значения для классификации событий как инцидентов, требующих инженерного вмешательства.
Для продуктов с публичным SLA — status.company.ru или встроенный баннер. Шаблоны:
- Investigating — разбираемся;
- Identified — причина известна, чиним;
- Monitoring — починили, наблюдаем;
- Resolved — всё стабильно.
Молчание при P1 усиливает репутационный ущерб сильнее самого сбоя.
MTTR в аутсорсе и SLA
В договоре часто:
- время реакции (первый ответ);
- время восстановления (workaround или fix);
- штрафы или кредиты при нарушении.
Дежурный исполнителя должен логировать время обнаружения и восстановления в тикете — иначе спор об MTTR. Заказчик предоставляет доступ к логам и decision maker для emergency CAB.
Decision Maker — авторизованное лицо, обладающее правом принятия стратегических решений в ходе критического инцидента, включающее выбор сценариев восстановления, утверждение откатов изменений и координацию коммуникаций с внешними регуляторами или ключевыми клиентами.
Emergency — режим эксплуатации, объявляемый при возникновении угрозы полной потери данных, масштабной недоступности ключевых сервисов или критической уязвимости безопасности, предполагающий приоритетное выделение всех доступных инженерных ресурсов для стабилизации системы.
Инциденты и ПДн (госсектор)
При подозрении на утечку персональных данных:
- severity P1 по умолчанию;
- юристы и ИБ по регламенту;
- уведомление регулятора в установленный срок;
- postmortem с отдельным классифицированным приложением.
Runbook "утечка ПДн" готовят до инцидента, не во время.
Дежурная смена — передача
В конце недели on-call передаёт:
- открытые инциденты и тикеты;
- известные риски (завтра релиз, окно CAB);
- что сломалось в прошлый раз и что не доделали из action items.
Запись в wiki или короткий созвон 15 минут — меньше сюрпризов.
Алерты и усталость от шума
Правила здорового алертинга:
- каждый алерт — действие из runbook;
- пороги привязаны к SLO;
- дедуп и группировка (не 500 тикетов за один падение Redis);
- регулярная чистка "алерт никто не смотрит".
Дедуп — это процесс автоматической фильтрации и консолидации повторяющихся алертов и уведомлений о едином инциденте, обеспечивающий фокусировку инженерных команд на устранении первопричины сбоя и оптимизацию обработки информационных потоков.
SLO — это внутренний измеримый целевой показатель доступности или производительности сервиса, устанавливаемый командой разработки на основе бизнес-требований и служащий индикатором для балансировки скорости выпуска новых функций и операционной надежности.
Усталый on-call пропускает настоящий P1.
Связь severity и change request
Emergency fix в prod — это изменение. Даже ночью:
- минимум запись в тикет / emergency CAB;
- кто утвердил hotfix;
- план отката если патч не помог.
Emergency fix — экстренное изменение конфигурации или кодовой базы, развертываемое с приоритетом над стандартными циклами тестирования для немедленного устранения критического сбоя, сопровождающееся обязательным последующим аудитом и ретроспективным прохождением процедур верификации.
Иначе postmortem и аудит (особенно в госе) — провал.
Дерево решений severity (упрощённо)
Дерево решений severity — это алгоритмическая схема классификации инцидентов, использующая набор объективных критериев, таких как количество затронутых пользователей, степень потери данных и влияние на финансовые операции, для автоматического назначения приоритета и маршрутизации задачи.
Таблица в wiki должна совпадать с деревом — иначе каждый классифицирует по-своему.
Эскалация к вендору облака и SaaS
При P1 с подозрением на инфраструктуру:
- открыть тикет у провайдера с severity по их шкале;
- сохранить incident id вендора в своём тикете;
- параллельно mitigation у себя (другой регион, кэш).
Договор с облаком — SLA и окно поддержки. On-call знает логин и телефон до аварии.
Вендор облака — это поставщик инфраструктуры как услуги, обеспечивающий физическое размещение вычислительных мощностей, сетевое взаимодействие и базовые платформы виртуализации, несущий ответственность за отказоустойчивость аппаратного уровня согласно модели разделения ответственности.
Toil и автоматизация после postmortem
Toil — это рутинная операционная деятельность ручного характера, требующая постоянного привлечения специалистов для выполнения повторяющихся задач, характеризующаяся детерминированностью и поддающаяся полной автоматизации для освобождения инженерных ресурсов под развитие архитектуры.
Toil — повторяющаяся ручная работа при инцидентах (ручной рестарт, чистка очереди). Action items должны отличать:
- устранить причину (баг, конфиг);
- автоматизировать реакцию (runbook → скрипт → auto-remediation).
Иначе on-call выгорает, MTTR не падает.
Инцидент без production
Иногда staging или интеграционный контур падает накануне релиза — для команды это P1 по процессу, даже если пользователи не затронуты. Severity внутренняя; действия те же: восстановить, postmortem, не релизить в prod на сломанном stage.
Интеграционный контур — это совокупность связанных микросервисов, очередей сообщений и внешних API, образующая единый технологический цикл обработки бизнес-запросов, отказоустойчивость которого требует сквозного мониторинга, согласованных стратегий повторных попыток и централизованного управления конфигурациями.
Юридические и репутационные последствия
PO и юристы подключаются при:
- утечке данных;
- невозможности исполнить договор (SLA);
- простое при приёме госэкспертизы.
Технический postmortem дополняется, не заменяется, управленческим отчётом.
Словарь эксплуатации
| Термин | Определение |
|---|---|
| Инцидент | Нарушение или деградация сервиса для пользователей |
| Severity | Уровень критичности (P1–P4) |
| MTTR | Среднее время восстановления |
| MTTD | Среднее время до обнаружения |
| On-call | Дежурный инженер по алертам |
| Runbook | Пошаговая инструкция по типовому сбою |
| Postmortem | Разбор инцидента после стабилизации |
| Blameless | Без поиска виноватых, фокус на системе |
| Mitigation | Временное снижение влияния |
| Rollback | Откат к предыдущей версии |
| Hotfix | Срочный патч в production |
| Incident commander | Координатор реагирования |
| War room | Канал/созвон для P1 |
| Toil | Повторяющаяся ручная операционная работа |
Итоги и чек-лист
Итоги раздела · Чек-лист самопроверки