Инженерная практика
On-call: перестрой шумную rotation
Прочитать, что «каждый пейдж должен быть actionable», — не то же, что сделать реальную rotation доверяемой. Возьми шумный набор alert, проведи аудит, замени cause-alert на SLO burn-rate-пейджи, подключи runbook и escalation и докажи, что пейджер стал тише — числами, а не на ощущениях.
Преврати одно правило юнита в операционную систему для rotation: классифицируй каждый alert по actionability, алертить только на симптомы и burn rate, демотируй остальное, дай каждому оставшемуся пейджу runbook и escalation path по таймеру и измерь изменение объёма пейджей, % actionable и MTTA/MTTR.
Возьми сервис с шумным набором alert (свой или построй небольшой HTTP-сервис плюс стек Prometheus/Alertmanager с намеренно cause-based alert) и перестрой его on-call так, чтобы каждый пейдж был actionable, доказав числами до/после, что rotation стала тише и быстрее.
- Таблица до/после: объём пейджей за смену, % actionable, false-positive rate, MTTA и MTTR — измеренные или из drill, а не оценённые.
- Каждый alert, оставшийся на пейджере, symptom/SLO-based и линкует runbook; письменное обоснование перечисляет каждый демотированный или удалённый alert и почему он был non-actionable.
- Burn-rate-правило явно пейджит на реальный быстрый burn во время drill и молчит на краткий флап, не угрожающий budget.
- Escalation path срабатывает по таймеру, когда primary не подтверждает, и MTTR в drill укладывается под цель rotation (целься под 1 час, DORA-elite).
- Добавь toil-лог за одну rotation: записывай каждую ручную повторяющуюся mitigation, затем автоматизируй верхнюю (авто-rollback на burn, авто-scale на saturation) и покажи, что пейдж, прежде требовавший человека, теперь самовосстанавливается или демотирован.
- Подключи follow-the-sun-передачу между двумя часовыми поясами с письменным handoff-чек-листом, чтобы ни один рутинный пейдж не падал в 3 утра по локальному времени ни для кого.
- Построй CI-гейт качества alert: каждое новое alert-правило должно объявлять ссылку на runbook и symptom/SLO-обоснование, а сборка падает, если правило с тегом severity: page без них.
- Заинструментируй еженедельный on-call-ревью, который автоматически выводит alert с наименьшим % actionable из лога пейджей и предлагает следующего кандидата на удаление, замыкая петлю обратной связи postmortem-to-deletion.
Это цикл, который ты будешь запускать на каждой реальной rotation: определи SLO и budget, проведи аудит каждого alert на actionability, алертить только на симптомы и burn rate, демотируй или удали остальное, дай каждому выжившему пейджу runbook и escalation по таймеру, затем докажи числами до/после, что объём пейджей упал, % actionable вырос, а MTTA/MTTR удержались под целью. Снижай toil, автоматизируя повторяющиеся mitigation. Сделай это раз на реальном или игрушечном стеке — и production-версия станет мышечной памятью: пейджер, которому люди всё ещё доверяют в 4 утра.