Прямой ответ
Процесс инцидентов нужен не «как у больших», а чтобы три вещи происходили предсказуемо: алерт будит того, кто может помочь (дежурство с явной ротацией и эскалацией), дежурный знает первые шаги (runbook приложен к каждому алерту — ссылка в аннотации), после инцидента система становится крепче (blameless-постмортем с конкретными действиями, а не «разобрали и забыли»). Для команды из 3–10 человек это помещается в одну страницу договора: градация severity (SEV1 — всё лежит, SEV2 — деградация, SEV3 — мелочь до рабочих часов), роли (incident commander — один, даже если команда из двух человек), канал инцидента, и правило «алерт без runbook — кандидат на удаление». Бюрократия начинается там, где процесс пишут ради процесса; здоровый процесс — это привычки, записанные ровно в том объёме, в котором их соблюдают.
Severity и роли: минимум структуры
Градация по влиянию, не по эмоции: SEV1 — продукт недоступен/данные теряются (реакция немедленно, бросив всё; пейджит дежурного и эскалирует через 10 минут молчания); SEV2 — значимая деградация (часть функций, заметная доля пользователей; реакция в течение часа, в рабочее время — сразу); SEV3 — несрочное (единичные ошибки, косметика; тикет и разбор в плановом порядке). Роли в инциденте: incident commander — координирует и принимает решения (что пробуем, что откатываем), не обязательно самый глубокий эксперт; оператор — руки (команды, деплои); коммуникатор — статус-апдейты во внешний канал каждые 15–30 минут (в маленьком инциденте все роли на одном человеке — это нормально, важно, что решения принимает кто-то один, а не консилиум). Первое действие дежурного почти всегда одно и то же: оценить откат — «что менялось за последние часы?» (деплой? миграция? конфиг?); откат последней версии — статистически самое результативное действие, и стратегия деплоя обязана делать его быстрым (стратегии).
Runbook: документ, который пишут до инцидента
Runbook — не энциклопедия системы, а первые шаги по симптому: к каждому пейдж-алерту прикладывается страница («5xx выросли», «очередь растёт», «диск заполняется», «БД недоступна») с диагностикой по шагам: какие дашборды открыть (Grafana-панели — прямые ссылки), какие команды выполнить (готовые, копируемые — journalctl -u api --since "10 min ago", docker/systemctl-наборы; обход ресурсов сервера — методика диагностики), известные причины и быстрые лечения (перезапуск зависшего воркера, очистка очереди, увеличение пула), и критерий эскалации («если за 15 минут не локализовали — зови <имя/роль>»). Runbook живёт рядом с алертами (аннотация в правиле алертинга — ссылка) и обновляется после каждого инцидента (постмортем-действие «дополнить runbook» — самое частое и самое полезное). Правило гигиены: алерт, у которого за квартал не открыли runbook ни разу и который ни на что не повлиял, — удаляется или понижается до тикета (борьба с alert fatigue).
Дежурство: честная организация
Ротация — по неделе на человека, минимум трое участников (двое — дежурство без выходных по факту), пересменка — с передачей («что шумело, что на наблюдении»). Компенсация — организационная реальность, а не мелочь: ночные пейджи оплачиваются/отгуливаются, иначе дежурство превращается в выгорание по расписанию. Эскалация обязательна и автоматична (Alertmanager: не подтвердил за 10 минут — второму, за 20 — руководителю): «дежурный проспал» не должен означать «инцидент никто не видел». Границы: дежурный решает инциденты по runbook и известным сценариям, а не проводит рефакторинг в 3 ночи — изменения вне задокументированных процедур ждут утра (ночные «быстрые фиксы» без ревью стабильно порождают второй инцидент). Качество дежурства измеряется не геройством, а метриками: время реакции, доля ложных пейджей (цель — каждый пейдж требует действий; шумные алерты чинятся), число инцидентов вне рабочих часов (растёт — продукт деградирует системно).
Постмортем: blameless и с действиями
Формат после каждого SEV1/SEV2 (в течение 1–2 дней, час времени): хронология (когда возник, когда заметили, когда локализовали, когда починили — таймстампы из алертов и чата), влияние (сколько пользователей/данных/денег, длительность), корневые причины («почему» несколько раз подряд: «упал воркер» → «утечка памяти» → «не лимитирован» → «лимит не добавили, потому что…»), и главное — действия с владельцами и сроками («алерт на рост RSS», «runbook: перезапуск воркера», «лимит памяти в юните» — каждое — тикет, проверяемый на следующей встрече). Blameless — не «никто не виноват», а «ищем дефект системы, а не стрелочника»: люди принимали решения в рамках доступной информации; наказуемы только злостные нарушения, а не ошибки. Публичность постмортемов внутри команды (и наружу для крупных сбоев — публичные status-page разборы строят доверие клиентов) превращает чужой инцидент в обучение всех.
Практический сценарий: инцидент от пейджа до тикетов
03:12 — пейдж: «error_rate > 5% (SEV1)», дежурная открывает runbook из ссылки алерта: шаг 1 — дашборд RED: ошибки на одном пути /checkout, p95 в норме (не деградация «всего»); шаг 2 — «что менялось»: деплой в 23:40 (аннотация на графике — деплой-события); шаг 3 — решение commander'а: откат версии (blue-green переключение, 40 секунд), ошибки ушли за минуту. 03:20 — статус в канал: «инцидент mitigated, наблюдаем». Утро — постмортем: причина — новая интеграция платёжного провайдера без таймаута на один из вызовов (дисциплина таймаутов); действия: таймаут+ретрай (сегодня), алерт на p99 внешнего API (неделя), интеграционный тест с искусственной задержкой провайдителя (спринт), строка в чек-лист ревью «таймауты на внешних вызовах». Через месяц метрика: похожий сбой у партнёра-логиста был локализован за 6 минут и не стал SEV1 — система отреагировала лучше, потому что прошлый инцидент вложился в процессы, а не в воспоминания.
FAQ
Нужен ли on-call команде из двух человек? Формальная ротация из двух — выгорание гарантировано; практический вариант: алерты только SEV1 (жёсткий фильтр шума), оба «дежурят» по договорённости с приоритетом у свободного, и честный разговор о компенсации. Лучше — дорасти до трёх: третий участник делает дежурство устойчивым скачком.
Incident-менеджмент инструменты (PagerDuty/Opsgenie) или своими силами? Своими — Alertmanager + Telegram/Slack-бот покрывают ротацию и эскалацию для небольшой команды бесплатно; специализированные сервисы окупаются на десятках дежурных, интеграциях и compliance-отчётности. Начинать со своего, мигрировать по боли.
Что делать с «мелкими» инцидентами — постмортем на каждый? Нет: SEV3 — тикет и разбор в плановом порядке; постмортем-ритуал — для SEV1/SEV2 и для повторяющихся мелочей (три одинаковых SEV3 за месяц — это системная проблема и повод для полного разбора).
Как измерить здоровье процесса инцидентов? Четыре метрики: MTTA (время до реакции), MTTR (до восстановления), доля ложных алертов, доля постмортемов с закрытыми действиями в срок. Растёт MTTR при растущем числе инцидентов — система деградирует быстрее, чем учится; главная метрика — последняя.
Источники: PagerDuty Response (открытая книга инцидент-процесса), Google SRE Book (postmortem culture) — ссылки в шапке.