Инженерная практика
On-call: тест на воспроизведение
Воспроизведение бьёт перечитывание. Для каждого промпта произнеси или запиши полный ответ по памяти, прежде чем открыть модельный — усилие припоминания и есть то, что закрепляет дисциплину on-call к моменту, когда ты реально держишь пейджер.
Восстанови ключевые механизмы юнита — почему симптомы бьют причины, что делает burn-rate-alerting, анатомию alert fatigue, лимиты нагрузки, жизненный цикл пейджа и как снижение toil держит rotation устойчивой — не подглядывая.
- 01Почему alerting по симптомам имеет больший рычаг, чем по причинам, и каково единственное исключение?
- 02Объясни burn-rate-alerting и почему multi-window, multi-burn-rate бьёт сырой порог error rate.
- 03Пройди по механизму alert fatigue и почему его нельзя починить, попросив responder быть внимательнее.
- 04Назови лимиты нагрузки on-call от Google SRE и логику, делающую каждый лимит рычагом надёжности, а не просто гуманности.
- 05Опиши жизненный цикл хорошо ведомого пейджа от определения до закрытия и где подключается каждый механизм on-call.
- 06Что такое toil, почему его снижение важно именно для on-call и как метрики MTTA, MTTR, объём пейджей и % actionable направляют это снижение?
Если ты смог восстановить каждый ответ по памяти, ты держишь спину юнита: алертить по симптомам и SLO burn rate, а не по причинам; burn-rate-alerting сопоставляет срочность реальной угрозе budget; alert fatigue — структурный сбой, лечимый удалением, а не дисциплиной; лимиты нагрузки (≈2 инцидента/смену, ≤50% ops, ≤25% on-call) защищают инженерию, что держит rotation тихой; каждый пейдж проходит определённый жизненный цикл с runbook и escalation по таймеру; а снижение toil, направляемое MTTA, MTTR, объёмом пейджей и % actionable, и есть то, что держит всё устойчивым.