Инженерная практика
On-call: alert-правила и математика budget
Суть Читай реальные alert-правила Prometheus, multi-burn-rate SLO-правило, расчёт error budget и Alertmanager-route, затем выбери senior-фикс или верно прочитай математику.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеAlert-правила и математика error budget — это место, где философия on-call становится конфигом. Прочитай каждый сниппет, предскажи, что он сделает с пейджером, и выбери фикс, который senior делает первым.
Цель
Потренируй цикл, превращающий принцип в доверяемый пейджер: прочитай alert-правило, оцени, алертит ли оно на симптом или причину, посчитай burn-rate и budget и заметь шаг runbook, который реально снижает MTTR.
Сниппет 1 — cause-based alert-правило
groups:
- name: node
rules:
- alert: HighCPU
expr: instance:node_cpu_utilisation:rate5m > 0.80
for: 1m
labels:
severity: page
annotations:
summary: "CPU above 80% on {{ $labels.instance }}" Викторина
Completed
Это правило будит с severity: page. Что в нём не так и каков фикс с наибольшим рычагом?
Heads-up Более длинное окно лишь откладывает тот же non-actionable cause-пейдж. Устойчиво высокий CPU всё равно может никому не вредить; дефект в том, что оно вообще алертит на причину, а не в длительности.
Heads-up Более быстрое обнаружение не-симптома не цель — оно будило бы раньше на том, что не отображается во вред пользователю. Проблема в том, на что оно алертит, а не как быстро.
Heads-up Saturation — один из золотых сигналов как симптом видимой пользователю деградации, но сырой порог CPU без привязки к latency/errors или SLO — классический cause-alert. Алертить надо на симптом, а не на датчик.
Сниппет 2 — multi-burn-rate SLO-правило
# SLO: 99.9% availability over 30 days. Budget = 0.1% of requests may fail.
- alert: ErrorBudgetFastBurn
expr: |
(
job:slo_errors_per_request:ratio_rate1h{job="api"} > (14.4 * 0.001)
and
job:slo_errors_per_request:ratio_rate5m{job="api"} > (14.4 * 0.001)
)
for: 2m
labels:
severity: page Викторина
Completed
Почему это правило требует превышения 14.4× budget И в окне 1ч, И в окне 5м, и что означает множитель 14.4×?
Heads-up Они не избыточны. Окно 1ч одно будит медленно и может продолжать срабатывать после конца burn; 5м одно срабатывает на транзиентных всплесках. Требование обоих и даёт быстрое обнаружение с низким false-positive.
Heads-up 14.4 — это множитель скорости burn budget, а не процент ошибок. Порог — 14.4 × 0.001 = 1.44% падающих запросов, скорость, которая осушила бы 30-дневный budget примерно за 2 дня.
Heads-up for: 2m лишь требует, чтобы комбинированное условие держалось 2 минуты; оно не даёт подтверждения длинным окном. Удаление окон возвращает ложные пейджи от флапов.
Сниппет 3 — арифметика error budget
SLO = 99.95% successful requests over 30 days
Traffic = 2,000 requests/second, steady
Budget = (1 - 0.9995) = 0.05% of requests may fail
Incident = a deploy bug returns 5xx on 2% of requests for 30 minutes
Question = how much of the 30-day error budget did this one incident burn? Викторина
Completed
Примерно какую долю месячного error budget съел этот 30-минутный инцидент с 2% ошибок?
Heads-up Это путает мгновенный множитель burn с долей budget. Правильный расчёт — падающие запросы к допустимым отказам: 72 000 / ~2.59М ≈ 2.8%, а не 56%. Множитель 40× лишь говорит, что burn был бы тревожным, если бы держался весь месяц — а он шёл далеко не столько.
Heads-up Burn budget зависит от падающих запросов против допустимых отказов, а не от настенного времени как процента. 30 минут лишь задают, сколько запросов затронуто; сделай расчёт по запросам.
Heads-up Ещё как может — 72 000 отказов против ~2.59М допустимых — это ≈2.8% budget всего месяца от одного короткого инцидента. Несколько таких инцидентов исчерпывают SLO.
Сниппет 4 — шаг runbook
## Runbook: api ErrorBudgetFastBurn
1. Ack the page; open the SLO dashboard (latency, errors, traffic, saturation).
2. Check Deploys panel: did a release land in the last 30 min? If yes, ROLL BACK first.
3. (If no recent deploy) check upstream-dependency error panel and DB saturation.
4. Mitigate to stop the burn; only then root-cause.
5. If error rate not falling within 15 min, escalate to secondary. Викторина
Completed
Шаг 2 велит откатить недавний deploy до root-cause. Почему этот порядок верен для on-call responder в разгар инцидента?
Heads-up Откат — это mitigation, не диагноз — deploy может быть, а может и не быть истинной root cause. Суть в том, чтобы сначала остановить вред пользователю; root-cause-анализ идёт после восстановления сервиса, на шаге 4 и в postmortem.
Heads-up Это не абсолютное правило. Runbook задаёт порядок mitigate-before-diagnose для этого конкретного, высоковероятного сценария (недавний deploy + burn budget). Таймер escalation на шаге 5 существует ровно на случай, когда очевидная mitigation не сработала.
Heads-up Во время активного burn SLO root-cause сначала продлевает вред пользователю и тратит больше budget. Остановить кровь известной mitigation, потом диагностировать — стандартный порядок incident response и то, что снижает MTTR.
Итог
On-call читается в конфиге и арифметике: сырой порог CPU с тегом severity: page — это cause-alert, плодящий fatigue; multi-window, multi-burn-rate-правило срабатывает на реальном быстром burn и игнорирует флапы; математика error budget превращает короткий инцидент в конкретный процент месячного допуска, так что ты соразмеряешь срочность реальному вреду; а хороший runbook кодирует mitigate-before-diagnose с escalation по таймеру, чтобы медианный responder восстанавливал быстро. Суди alert по actionability, делай математику budget и дай runbook нести мозг в 3 утра.