Symptom vs Cause Alerting

«DB CPU > 80% → page» — типичный cause-based алерт. При DB outage он генерирует 50 пейджеров под одним инцидентом и парализует on-call; а при slow query на decoupled-сервисе пейджит при работающем продукте. Symptom-based алерт ловит то, что реально чувствует пользователь — latency, error rate, availability — и пейджит один раз за инцидент, ровно когда нужно. Rob Ewaschuk в 2014 году написал внутренний Google-документ «My Philosophy on Alerting», который стал каноном; SRE Book главы 6 и 4 закрепили это в индустрии. Лист — про дисциплину различения и про то, как реструктурировать alert portfolio после миграции на SLO-driven подход.

Граница: SLI-based Alerting — как алерт устроен (SLI как сигнал, burn rate как порог); этот лист — на что именно алертить (симптом, не причина). Alert Fatigue Management — что делать, когда система уже зашумлена; этот — как с самого начала не зашумлять.

Что должен уметь

Главный навык на уровне L4 — формулировать golden signals (latency / errors / traffic / saturation) для своего сервиса так, чтобы symptom-side покрывал «что пользователь почувствует», а cause-side покрывал «куда смотреть в дебаге». Я регулярно вижу команды, которые знают слова «golden signals» наизусть — но в их alert config 80% правил cause-based (CPU / memory / disk / connections), и при downstream outage on-call просто тонет в шуме. Различение видно не в формулировке принципа, а в том, какие правила реально active при page priority.

Отличает symptom-based от cause-based алерта на примере конкретного правила; объясняет, почему error rate > 1% — symptom, а connection pool > 80% — cause.
Понимает alert amplification: при downstream outage cause-based алерты на dependencies + cascading effects дают N-кратный шум на тот же incident.

Проектирует golden signals для своего сервиса: latency (per percentile), errors (rate + share), traffic (qps / req/min), saturation (utilization vs capacity). Все 4 — symptom-side; cause-side — отдельный набор.
Использует cause-based данные как secondary в runbook’е, а не primary в alert. Cause-метрики в dashboard, симптомы — в пейджере.

Применяет multi-burn-rate alerting для symptom-side SLI: быстрая burn (fast burn 1h / 5min) и медленная (slow burn 6h / 30min) — один алерт, два window’а.
Регулярно (раз в квартал) пересматривает alert portfolio: какие cause-based выкинуть как noise / понизить до dashboard / оставить как secondary; какие symptom-side добавить, если incident прошёл без алерта.

L6+

Внедряет alert-as-code дисциплину: каждое alert rule имеет owner, runbook link, SLI / threshold rationale, severity, ожидание частоты (alert per quarter), review cycle.
Связывает alerting policy с SLO program: paging-level алерты только на SLO burn; ticket-level — на внутренние saturation indicators; dashboard-only — на cause-side и diagnostic signals.

Материалы

Книги

Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 6 «Monitoring Distributed Systems». Канонический разбор: 4 golden signals, symptoms vs causes, white-box vs black-box monitoring. Если выбирать одну главу — эту.
Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 4 «Service Level Objectives». Связка SLO ↔ alert: paging only on SLO violations.
Mike Julian — Practical Monitoring (O’Reilly, 2017). Глава «Designing Meaningful Alerts». Альтернативный взгляд той же идеи: разделение alerts (page) / warnings (ticket) / informationals (log).
Cindy Sridharan — Distributed Systems Observability (O’Reilly, 2018). Контекст: почему observability ≠ monitoring; почему cause-debugging уходит в трейсы / логи, а alerting остаётся на симптомах.

Статьи и доклады

Rob Ewaschuk — My Philosophy on Alerting (Google internal, 2014). Первоисточник принципа «page on symptoms, not causes». Короткий документ — лучшая первая статья по теме. Главный публичный кейс — см. ниже.
Betsy Beyer, Niall Murphy, Liz Fong-Jones, David Rensin — The Site Reliability Workbook (O’Reilly, 2018), глава 5 «Alerting on SLOs». Многоуровневые burn rate alerts — практика, развивающая Ewaschuk: 2 percent / 5 percent / 10 percent budget burn windows, multi-window multi-burn-rate.
Charity Majors — Why We Built Honeycomb. Контекст высокой кардинальности и observability как противопоставления classical monitoring. Полезно как фон, а не как канон по alerting.

Инструменты

Prometheus + Alertmanager — де-факто стандарт. Multi-window multi-burn-rate реализуется через for + recording rules. Sloth / Pyrra / OpenSLO — генераторы SLO-aware alert rules поверх Prometheus.
Grafana / Datadog / New Relic — alerting на векторах observability platforms; pattern одинаков, синтаксис разный.
Sloth / Pyrra / OpenSLO — SLO-as-code; alert-rules генерируются из SLO spec автоматически. По моим наблюдениям, чаще выбирают Sloth — proven и интегрирован с Prometheus.
Анти-инструмент: «алёрт-rule на каждую метрику dashboard» — антипаттерн, доводящий до alert fatigue за месяц. Pattern «алерт — это пейджер; всё остальное — dashboard» — самый сильный фильтр.

Best practices

Главный публичный кейс — Rob Ewaschuk, «My Philosophy on Alerting» (Google internal, ~2014). Документ короткий (10 страниц), и каждая его рекомендация выдержала ~10 лет: «page on symptoms, not causes», «every page must be actionable», «if you don’t know what to do, it shouldn’t be a page», «alert quality matters more than alert quantity». Я регулярно вижу команды, которые читали SRE Book, но не сам этот документ — и теряют главный nuance: Ewaschuk пишет про операционную работу человека ночью, не про «правильный мониторинг». Это смещает рамку: alert design — это UX-задача для on-call инженера в 3 часа ночи. Один час чтения и пять лет дисциплины.

Короткие правила:

Page только на симптомы. Cause-based данные — в dashboard и runbook; пейджит только то, что реально означает «пользователь страдает прямо сейчас или скоро».
Каждый алерт — actionable. Если on-call не знает, что делать с сигналом, это не алерт, это лог. «Alert investigation cookbook» из 30 шагов «может быть X, может быть Y» — признак того, что условие алерта слишком широкое.
One incident → one page. Cause-based алерты на dependencies дают N-кратный шум на тот же downstream outage. Symptom-side даёт один пейджер. Это лакмус: если incident сгенерировал > 3 пейджеров — alert portfolio сломан.

Подробнее:

Cause-based алерты не отменяются — они переезжают. Распространённый страх: «если уберём CPU alert, кто-то пропустит CPU exhaustion». Cause-side метрики остаются — но в dashboard и runbook, не в pager. Когда symptom alerts (latency / errors) поднимаются, on-call открывает dashboard и сразу видит cause-side как контекст. Это разделение primary signal (что чувствует пользователь) и diagnostic signal (где смотреть в дебаге).

Multi-burn-rate alerting — практический шаг от symptom-аксиомы к работающей формуле. Чистый «error rate > 1%» — слишком reactive (срабатывает только в очевидном инциденте); чистый «budget burn 2%» — слишком reactive по-другому (срабатывает после факта). Multi-window: fast burn (1h window @ 14.4x burn) пейджит быстрый incident; slow burn (6h window @ 6x burn) пейджит медленный degradation. SRE Workbook глава 5 — формулы и параметры. По моим наблюдениям, разница между командами с whitelined alerts и зашумлёнными — наличие multi-burn-rate почти всегда; всё остальное вторично.

Quarterly alert review — обязательная гигиена. Команды, у которых alert portfolio «накапливается» без review — через год имеют сотни правил, из которых треть не срабатывала, треть срабатывала шумом, и треть актуальна. Раз в квартал — review каждого правила: срабатывал ли за период? было ли actionable? стоит ли понизить / повысить / убрать? Без review alert design деградирует к baseline alert fatigue даже при хорошем initial design.

Black-box ≠ замена white-box. Symptom monitoring часто ассоциируется с black-box (синтетические probes, external uptime checks). Это полезно, но не достаточно: black-box ловит «сервис недоступен», но не «сервис отвечает, но 20% запросов с ошибкой». White-box symptom (error rate / latency из самого сервиса) и black-box (synthetic user journey) — комплементарны. Я регулярно вижу команды, у которых либо только black-box (миссит частичные деградации), либо только white-box (миссит network / DNS / TLS issues между пользователем и сервисом).

Связанные листья

SLI-based Alerting — как устроен алерт (SLI / threshold / burn rate); этот лист — на что алертить. Читать вместе.
Alert Fatigue Management — что делать, когда alert portfolio уже шумит; этот — как с самого начала не разводить шум.
SLO Engineering — symptom-side алерты привязаны к SLO; budget burn rate — каноническая формула.
Runbooks — каждый алерт ссылается на runbook, где cause-side metrics — diagnostic step, не trigger.
Incident Response — actionable алерт = первый шаг IR; non-actionable алерт ломает IR с самого начала.
Resilience Patterns — circuit breaker / retry / shed metrics — это secondary indicators (показывают, что patterns активны), не primary alerts.

Открытые вопросы

Alert SLO (TBD) — meta-SLI для самого alerting’а: alert precision (true positive rate), recall, time-to-page-after-incident. Отдельный лист про измерение качества alert program.
Synthetic Monitoring как practice (TBD) — black-box probes, end-user monitoring (RUM), synthetic user journeys. Соседняя ветка observability.
Anomaly Detection как замена threshold-based (TBD) — Holt-Winters / Prophet / ML-based; границы применимости.
Я не уверен, как корректно ловить partial degradation на feature flag уровне (часть пользователей в плохом cohort). Если у вас есть опыт — расскажите через PR.