Инженерная практика
On-call: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту on-call — alert по симптомам vs причинам, burn-rate-пейджи, alert fatigue, лимиты нагрузки, runbook, escalation и метрики честной rotation.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Ни один не про заучивание определения — каждый отражает решение, которое senior принимает о том, что будит пейджер в 4 утра, а что — нет.
Цель
Убедись, что связываешь спину юнита: на пейджере только actionable alert по симптомам/SLO, всё остальное демотировано, нагрузка ограничена, runbook прилинкован, а rotation измеряется через % actionable.
Викторина
Completed
Alert на использование диска будит on-call 40 раз в месяц и почти всегда саморазрешается. Почему это опаснее, чем вообще не иметь alert?
Heads-up Именно избыточный alerting и заставляет пропустить реальное событие. Поток ложных срабатываний 60–80% десенсибилизирует responder; ширина покрытия — не то же самое, что доверяемый пейджер.
Heads-up Цена человеческая, а не в хранилище. Alert fatigue и вызванная им десенсибилизация — это failure mode, вокруг которого построен юнит, а не объём логов.
Heads-up Подъём порога лишь откладывает тот же non-actionable cause-alert. Вопрос в том, должен ли он вообще будить человека — алертить надо на симптом (диск будет полон в течение 1ч), а сырой порог демотировать.
Викторина
Completed
Тебе надо решить, что будит человека. Какое условие должно быть на пейджере и каков принцип?
Heads-up Высокий CPU часто нормален и самокорректируется; это причина, а не симптом. Cause-alert срабатывает на не-событиях и пропускает реальные симптомы, не двигающие этот датчик. Алертить надо на симптомы; на причины — только если они definite and imminent.
Heads-up Самое раннее — не то же, что actionable. Почти полный пул часто восстанавливается; пейджи должны соответствовать видимому пользователю вреду или риску SLO, а не внутренней механике, которая может никогда не сработать.
Heads-up Чувствительность без actionability — это начало alert fatigue: прерывистый хвост будет срабатывать постоянно и саморазрешаться, приучая responder сбрасывать его. Алертить надо на устойчивые симптомы, угрожающие budget, а не на одиночные медленные запросы.
Викторина
Completed
Google SRE ограничивает смену примерно двумя инцидентами, а операционную работу — 50% времени SRE. Что ломается, если игнорировать лимиты?
Heads-up Дисциплиной не обойти арифметику: третий инцидент означает, что углы срезаются, и срезается именно профилактика. Лимиты защищают инженерную половину, которая делает следующий квартал тише.
Heads-up Надёжность тоже деградирует. Пропущенные postmortem означают повторные инциденты, объём пейджей растёт, responder выгорают, а attrition уносит операционные знания за дверь — это doom loop, а не просто потерянный сон.
Heads-up Это механизмы надёжности. Потолок ops в 50% существует, чтобы вторая половина шла на инженерию, снижающую будущую ops-нагрузку; игнорируя его, ты вытесняешь именно эту работу.
Викторина
Completed
Какая метрика напрямую сигнализирует, что rotation деградирует к выгоранию?
Heads-up Рост MTBF означает, что отказы становятся реже — это хорошо и ничего не говорит о том, сколько non-actionable пейджей изматывают responder между отказами.
Heads-up Число дашбордов не связано с нагрузкой пейджера или actionability. У команды могут быть отличные дашборды и при этом жестокий, изматывающий пейджер.
Heads-up Runbook помогают MTTR, но не измеряют, устойчива ли нагрузка rotation; можно тонуть в пейджах, при этом написав отличные runbook.
Викторина
Completed
Пейдж сработал, но primary responder застрял и не подтвердил. Какой правильный структурный механизм и какова роль runbook здесь?
Heads-up Неподтверждённый пейдж, висящий молча, — это и есть удлинение инцидента. Escalation по таймеру — ровно защита от застрявшего primary; это не преждевременный шум.
Heads-up Перепейджинг того же застрявшего человека не добавляет ни ёмкости, ни знаний. Escalation маршрутизирует к тому, кто реально может помочь; это path, а не более громкий сигнал.
Heads-up Даже senior писал не каждый сервис. Runbook превращает холодный старт в 3 утра в процедуру и снижает MTTR для медианного responder; alert без runbook не готов быть пейджем.
Викторина
Completed
Предложено изменение для снижения шума: заснузить самые шумные alert и добавить Alertmanager group_by, inhibit_rules и group_wait 30s. Что это даёт, а что нет?
Heads-up Grouping снижает избыточные пейджи, но одиночный non-actionable alert всё равно non-actionable. Fatigue лечится удалением или демотированием неактуальных alert, а не только их дедупликацией.
Heads-up Snooze — это как тихо умирает покрытие: alert всё ещё подключён к пейджеру и удивит следующего responder. Демотируй в тикет или дашборд, либо удали.
Heads-up inhibit_rules глушат warning, когда уже горит соответствующий critical — полезная дедупликация, но она предполагает, что alert уже хорошо спроектированы. Это не замена решению о том, что actionable, на уровне выше.
Итог
Сквозная линия юнита — одно правило, применённое на каждом слое: пейдж должен быть actionable, иначе он удаляется. Алертить по симптомам и SLO burn rate, а не по причинам вроде CPU или диска; остальное демотировать в тикеты и дашборды. Ограничь нагрузку (≈2 инцидента/смену, ≤50% ops-времени), чтобы профилактика выжила. Линкуй runbook к каждому пейджу, эскалируй по таймеру, когда responder застрял, и используй grouping/inhibition для схлопывания штормов — но помни, routing только дедуплицирует. Измеряй MTTA, MTTR и объём пейджей и держи курс по северной звезде: % actionable.