Инженерная практика
On-call и реакция на инциденты: каждый пейдж должен быть actionable
3:47 ночи. Пейджер выстреливает: DiskUsage > 80% on cache-node-7. Респондер, на шестом пейдже за тихую-но-беспощадную ночь, смахивает его полусонным — алерт диска кричал «волки» сорок раз в этом месяце и саморазрешался каждый раз. Кроме как сегодня — нет. Нода заполнилась, кеш жёстко вытеснил, база приняла полную нагрузку чтения и упала в 4:10. Пейдж, что был важен, был неотличим от сорока, что не были. Это не пробел мониторинга. Это усталость от алертов, и это режим отказа, что определяет on-call.
Ротация: on-call — нагрузка, что ты бюджетируешь, не геройская смена
Ротация — расписание того, кто несёт пейджер. Наивная версия — «кто свободен» или один героический владелец — рушится: герой выгорает, уходит и забирает единственное знание с собой. Устойчивая ротация распределяет нагрузку на достаточно инженеров, чтобы любая одна смена была переживаема, и трактует время респондера как конечный, дорогой ресурс.
Google SRE кодифицирует это жёсткими числами. SRE тратят максимум 50% времени на операционную («ops») работу — on-call, тикеты, ручной toil — так что другая половина идёт на инженерию, что делает следующий квартал тише. Из этой ops-половины не больше 25% на on-call. А на смену цель — максимум два инцидента, потому что обработка одного инцидента от и до — триаж, митигация, корневая причина, постмортем, последующие фиксы — выходит примерно в шесть часов реальной работы. Два инцидента уже заполняют рабочий день; третий значит, что углы срезаются, а постмортем так и не пишется.
Follow-the-sun — структурный фикс худшей части: никого не должны пейджить в 3 ночи рутинно. Ты передаёшь пейджер через часовые пояса — команда в EMEA покрывает свой светлый день, передаёт Америкам, что передают APAC — так что каждый респондер бодр и внимателен, когда его держит. Цена — накладные на координацию и чистые передачи; выигрыш — что «on-call» перестаёт значить «уничтоженный сон».
Философия алертинга: пейджи по симптомам, не причинам
Это единственное решение наибольшего рычага в on-call, и большинство шумных ротаций делают его наоборот. Два способа решить, что выстреливает пейдж:
- По причинам:
CPU > 80%,disk > 80%,connection pool 90% full, растущий лаг реплики. Они описывают внутреннюю механику. Проблема: высокий CPU часто нормален, часто самокорректируется и редко значит, что пользователю причинён вред. Алерты по причинам выстреливают постоянно, и большинство — не-события. - По симптомам / по SLO:
p99 latency > 500ms за 5 минут, частота ошибок, жгущая месячный бюджет на6×. Они описывают, что пользователь реально испытывает и что обещал твой SLO. Они выстреливают, только когда что-то реальное ломается.
Правило Google прямое: трать усилие на ловлю симптомов и алерти на причины, только если они определённы и неминуемы. Четыре золотых сигнала — latency, traffic, errors, saturation — вместе ловят почти каждый значимый отказ как симптом. Механизм, что превращает SLO в пейдж, — burn rate: как быстро ты потребляешь бюджет ошибок относительно SLO. Multi-window, multi-burn-rate алерт пейджит на быстром прогорании (скажем, 6× за короткое окно, подтверждённое против более длинного) и молчит на медленной капели — так что срочность совпадает с реальной угрозой твоему обещанию надёжности, не сырому порогу.
| Алерт | Тип | Пейджить человека? |
|---|---|---|
CPU > 80% | Причина | Нет — часто нормально, самокорректируется; дашборд, не пейджер |
disk > 80% | Причина | Нет (сам по себе) — тикет, или пейдж только если тренд бьёт в полное за < 1ч |
p99 latency > 500ms / 5м | Симптом | Да — пользователи чувствуют сейчас; SLO под риском |
Бюджет ошибок жжёт 6× | Симптом (SLO) | Да — бюджет уйдёт за дни при этой скорости |
Центральный режим отказа: усталость от алертов
Вот ловушка, с числами. Индустриальные частоты ложных срабатываний идут 60–80% — большинству пейджей не нужен человек. Медианный on-call инженер впитывает около 42 пейджей в неделю; как только отношение ложных срабатываний переваливает ~60%, респондеры начинают паттерн-матчить («снова алерт диска, игнор»), что добавляет 2–5 минут MTTA на пейдж, даже когда они всё же вовлекаются. Человеческая цена жестока: 62% сообщают о еженедельном нарушении сна, и 41% on-call инженеров рассматривали уход из-за нагрузки алертов. Выгорание от пейджера — драйвер оттока, а отток уносит операционное знание за дверь с собой.
Механизм прост и летален: слишком много низкоценных пейджей → респондеры десенсибилизируются → рефлекторно отмахиваются → единственный реальный инцидент прибывает в том же костюме, что и шум, и тоже отмахивается. Это не починить лучшим респондером или большей дисциплиной. Это чинится удалением алертов. Жёсткое правило, что сеньор принуждает: если пейдж не actionable — если реакция «следи за ним» или «саморазрешится» — это не алерт, это уведомление, и оно не идёт на пейджер. Понизь его до тикета или дашборда. Цель не больше покрытия; цель — пейджер, которому ты всё ещё можешь доверять в 4 ночи.
Почему это работает
«Просто заснузь шумные» ощущается дешёвым фиксом, и так покрытие тихо умирает. Правильные инструменты сжимают шум без потери сигнала: group_by в Alertmanager схлопывает шторм связанных алертов в одно уведомление, inhibit_rules мьютит warning, когда совпадающий critical уже выстреливает, а group_wait в 30s даёт флапу саморазрешиться, прежде чем он вообще пейджит. Но конфиг маршрутизации лишь дедуплицирует — он не сделает фундаментально не-actionable алерт стоящим пробуждения. Это решение происходит выше по течению, когда ты решаешь, заслуживает ли алерт пейджера вообще.
Runbooks, эскалация и метрики, что держат тебя честным
Каждый пейдж, что доходит до человека, должен линковать runbook: диагностический чеклист и известные митигации для этого алерта. Runbook превращает холодный старт в 3 ночи («что вообще такое cache-node-7?») в процедуру, что и есть то, что реально снижает MTTR для медианного респондера, что не писал сервис. Если у алерта нет runbook, это сигнал, что он не готов пейджить.
Когда первичный респондер не может разрешить это, путь эскалации маршрутизирует дальше — первичный → вторичный → владелец сервиса / incident commander — по таймеру, так что застрявший пейдж не сидит молча. И ты держишь всю систему честной метриками:
- MTTA (среднее время до подтверждения) — индустриальная медиана 8–15 мин; растущий MTTA — ранняя подпись усталости или плохой маршрутизации.
- MTTR (среднее время до разрешения) — элита DORA 2024 под 1 час; низкие исполнители превышают неделю.
- Объём пейджей на смену — тренд вверх значит, что ротация деградирует; это то, за чем следит цель ≤2 инцидентов.
- % actionable — путеводная звезда. Каждый пейдж, что не был actionable, — кандидат на удаление. Толкай это к 100%, и MTTA, MTTR и удержание следуют.
Твой сервис: 5% пользователей видят время загрузки 2с+ с перебоями, но ни один SLO ещё не нарушен, и ты не можешь надёжно воспроизвести. Как вплести это в on-call?
Алерт disk-usage > 80% пейджит on-call 40 раз в месяц и саморазрешается почти каждый раз. Каков ход сеньора?
Какая метрика наиболее прямо говорит, что ротация деградирует к выгоранию?
Расставь жизненный цикл хорошо управляемого пейджа, от определения до закрытия:
- 1 Реши, что алерт actionable и по симптому/SLO, прежде чем он вообще дойдёт до пейджера
- 2 Пейдж выстреливает; Alertmanager группирует + ингибирует, так что респондер получает один сигнал, не шторм
- 3 Респондер подтверждает (MTTA) и открывает прилинкованный runbook
- 4 Митигирует, чтобы восстановить сервис (MTTR); эскалирует по таймеру, если застрял
- 5 Пишет постмортем и удаляет или тюнит любой алерт, что выстрелил, не будучи actionable
- 01Объясни коллеге, почему шумный алерт «disk > 80%» опаснее, чем отсутствие алерта вообще.
- 02Почему Google SRE лимитирует on-call двумя инцидентами на смену и операционную работу 50% времени SRE, и что ломается, если игнорить эти лимиты?
On-call преуспевает или проваливается на одном правиле: каждый алерт, что будит человека, должен быть actionable, или должен быть удалён. Пейджи на симптомы и burn rate SLO — то, что пользователь реально чувствует и что покрывает твоё обещание надёжности — не на причины вроде CPU или диска, что выстреливают на не-событиях и в основном саморазрешаются. Режим отказа, что определяет дисциплину, — усталость от алертов: при 60–80% ложных срабатываний и медианных 42 пейджах в неделю респондеры десенсибилизируются и отмахиваются от единственного реального инцидента вместе с шумом, пока 41% рассматривают уход из-за нагрузки. Защищайся от этого структурно — удаляй не-actionable алерты, используй группировку и ингибицию для схлопывания штормов, лимитируй нагрузку примерно двумя инцидентами на смену и 50% ops-времени и используй follow-the-sun, чтобы никого не пейджили рутинно в 3 ночи. Каждый пейдж линкует runbook, чтобы медианный респондер мог действовать, эскалация маршрутизирует дальше по таймеру, а ты держишь систему честной через MTTA, MTTR, объём пейджей на смену и путеводную метрику, % actionable. Толкай её к 100%, и надёжный пейджер, более здоровые респондеры и более быстрое восстановление все следуют.