On-call rotation & burnout: как не сжечь команду pager-ом

Зачем это нужно

On-call ротация — это операционный контракт между бизнесом и инженерами: кто-то 24/7 держит pager и реагирует на инциденты в production. Без неё MTTR растёт до часов (пока кто-то случайно заметит alert в почте), SLO рушится, платящие клиенты уходят.

Но плохо устроенная ротация убивает команду быстрее, чем отсутствие ротации вообще. Симптомы знакомы: senior-инженеры уходят «потому что заколебал ночной pager», junior-ы боятся брать pager («я не разберусь, что делать в 3 ночи»), оставшиеся 2-3 человека дежурят каждую вторую неделю, выгорают, увольняются, цикл повторяется.

CAP описывает distributed systems. On-call — это distributed system из людей. Те же законы: partition (человек спит / в самолёте / болен) неизбежна; ты выбираешь между paging response time (always page многих → noise → fatigue) и paging quality (page одного, escalation chain → задержка). Без сознательного дизайна получишь worst-of-both.

Эта концепт-страница про архитектуру on-call как системы: follow-the-sun, primary+secondary, escalation chains, alert tuning, burnout signals, blameless postmortems, оплата дежурств.

Mental model

«On-call — это work, не goodwill. Без compensation, без bounded hours, без noise budget, без escalation, без cross-training — это не ротация, это organized hazing. Хорошая on-call — это когда pager звонит редко (tuned alerts), но когда звонит — actionable; когда звонит — есть runbook; когда runbook не помог — есть кому escalate; и за всё это платят отдельно от base salary.»

Три «партиции», которые ты обязан спроектировать:

1. Time partition — никто не дежурит 24/7. Либо follow-the-sun (3 региона × 8 часов), либо weekly rotation (1 неделя on, N недель off).
2. Knowledge partition — никто не должен быть unique-keeper-сервиса. Если 70% pages знает только один человек — knowledge silo, и ты уже проиграл.
3. Noise partition — alert ≠ page. Page = «человек обязан проснуться в 3 ночи». Если page не приводит к действию — это noise, и его надо удалить, не игнорировать.

Что на диаграмме

Четыре группы:

• Production systems — что мониторим: App tier, Database (источники метрик и инцидентов).
• Alerting pipeline — Prometheus → Alertmanager → PagerDuty: метрика превращается в page. Каждый этап — точка, где можно срезать noise раньше, чем разбудить человека.
• On-call rotation — US Primary, US Secondary, EU Primary, APAC Primary, Manager. Это «список людей» — реальная rotation живёт в PagerDuty schedule, а ноды — снимок «кто сейчас on-call».
• Comms & runbooks — Slack #incident (declare), Runbook wiki (что делать), Statuspage (что показать пользователям).

Связи показывают три потока:

• Alerting flow (метрики → page);
• Escalation chain (primary → secondary → manager при no-ack);
• Hand-off chain (US → EU → APAC → US в follow-the-sun модели).

В ноде PagerDuty прикреплён ADR-001 про модель оплаты on-call (base stipend + per-page premium vs flat salary uplift) — это самое load-bearing decision во всей системе, потому что оно создаёт economic feedback loop: каждый ложный page = реальные деньги в финотчёте, что мотивирует компанию tune-ить alerts.

Сценарии

1. Weekly handoff (понедельник 10

)

Стандартная передача pager между primary on-call. Outgoing пишет written summary прошлой недели (3 pages: 2 disk-full, 1 deploy rollback), указывает watch list (ticket #4421 — DB CPU), 30-минутный standup, PagerDuty schedule swap. Outgoing уходит в honest weekend off — pager не звонит. Правило: no solo on-call, всегда есть backup.

2. Alert fatigue tuning (3 AM disk_usage=81% page)

Page в 3 ночи: disk 81% при threshold 80%, runbook говорит «wait or scale утром» — no action. Это false page #7 за неделю. Делаем weekly page review, считаем delete ratio (% pages, по которым ничего не сделали). Tune: threshold 80% → 90% + auto-scale при 85%; symptom-based вместо cause-based; disk-warning → email, disk-critical (PVC fail) → page. Outcome: 7 pages/week → 1.4 pages/week.

3. Follow-the-sun handoff (US → EU → APAC)

US team в 17

PT пишет handoff doc, делает 30-min overlap standup с EU (02 CET), PagerDuty схема авто-переключает pager. US ложится спать — pager не звонит. EU держит 9:00-17 CET, передаёт APAC, цикл замыкается через 24 часа на US. Outcome: zero ночных pages во всех 3 регионах. Trade-off: hand-off overhead, knowledge fragmentation, требует одинаковую expertise во всех регионах.

4. Escalation chain (primary не отвечает)

HighErrorRate → page primary. No-ack 5 min (телефон сел / DND включён) → page secondary. No-ack ещё 5 min (secondary на самолёте) → page manager. Manager ack-ает, declare incident, war room, runbook, statuspage. Постмортем: blameless — почему escalation сработал? Action items: phone-die check (battery low → SMS), secondary BYOD policy, weekend 2 backups вместо 1.

5. Burnout prevention loop

Трекаем pages per person per week. Signal: Engineer A — 50 pages/week (30 ночных) vs team avg 12. 1

показывает cynicism, sleep issues, ownership decreases — burnout signs. Root cause: 70% pages — knowledge silo (только A знает legacy biller). Actions: (1) tune noisy alerts, (2) rebalance — A на shadow-week, (3) cross-train 2 других на biller — kill silo, (4) automation для top-3 biller-pages, (5) hire +1 SRE (4-person rotation). Outcome: pages distributed, A retention preserved, knowledge spread.

Trade-offs (ADR-001: модель оплаты on-call)

Самое load-bearing decision во всей системе. Три модели:

(1) Flat salary uplift («on-call включён в зарплату senior-grade»). Легко считать, но фиксирован вне зависимости от нагрузки, демотивирует уменьшать pages (нет связи pain↔pay), скрывает understaffing. Anti-pattern. Через год senior-ы уходят, junior-ы не учатся.

(2) Hourly on-call rate (10-30% от обычной ставки за каждый час pager-duty). Справедливо, дорого считать, не отражает интенсивность (спокойная неделя оплачивается так же, как ад).

(3) Base stipend + per-page premium — принимаем.

• Stipend ($200-1000/week) за наличие pager — гарантирует, что человек получает за inconvenience даже в спокойную неделю.
• $50-200 за day-page, $200-500 за night-page (после 22
  ) — ночь дороже бизнесу, чем день; это правильный signal.
• 2-3× weekend/holiday multiplier.
• Comp time (1 day off за weekend on-call) — деньги не лечат недосып.
• Per-page premium делает экономически выгодным для компании tune-ить шумные алерты и инвестировать в automation — каждый ложный page = реальные деньги в финотчёте.

PagerDuty / Stripe / Heroku публикуют похожие схемы.

Anti-pattern: senior-only «как часть зарплаты» — junior-ы не учатся, senior-ы выгорают, knowledge silo растёт. Anti-pattern: flat 10% salary без per-page — нет economic feedback loop на noise.

Реальные системы

• Google SRE — каноничная книга («Site Reliability Engineering», гл. 11 «Being On-Call»). Правила: maximum 25% времени на toil (если больше — нанимать или automation), 2-person on-call (primary
  • secondary), post-incident review для каждого user-impacting инцидента.
• PagerDuty — продукт + публичный playbook (response.pagerduty.com)
  • on-call compensation model они публикуют сами.
• Stripe — публичные posts про «no-pager-on-vacation», «manager pays for on-call pager bill».
• Heroku — early adopter follow-the-sun с EU/US командами, публиковали retrospectives.
• GitLab — публичный handbook про on-call (handbook.gitlab.com) с компенсацией, escalation chains, postmortem templates.
• Netflix — «You build it, you run it» — developers сами on-call на свои сервисы (no separate Ops team), но платят сильно выше рынка.

Anti-patterns

• Solo on-call. Один человек = single point of failure. Болен, в самолёте, телефон сел — incident не разобран.
• «Heroes» culture. Один Engineer A знает всё, всегда отвечает быстрее всех, на самом деле создаёт knowledge silo и burnout bomb. Хорошая команда работает, когда A в отпуске.
• No noise budget. Page = anything, alert deletion ratio 30%+. Через 3 месяца команда game-fies pager (DND, mute, ignore), и настоящий critical incident пропускают.
• Page on cause, not symptom. «CPU > 80%» — это cause. Не значит, что есть user impact. Page на symptom: «error_rate > SLO», «p99_latency > SLO», «orders_per_min dropped 50%».
• Runbook does not exist / outdated. Page в 3 ночи без runbook = panic + downtime. Rule: alert не deploy-ится в prod без runbook link.
• Blameful postmortem. «Human error» как root cause — bad система пропустила ошибку. Если 1 человек может уронить prod — это failure системы, не failure человека.
• No vacation backfill. «Я уезжаю в отпуск — pager никто не возьмёт» = либо весь team тащит, либо отпуск откладывается. Должна быть формальная swap policy.
• No compensation. «On-call — это часть работы senior». Через год вы платите recruiter-у 30% зарплаты за замену.
• Manager не on-call. Если manager не дежурит хоть раз в квартал, он теряет контекст — какие alerts шумят, какие runbooks устарели, где knowledge silo.

Когда НЕ использовать

On-call ротация — overkill, если:

• Нет production traffic. Stage-проект, hackathon, internal-tool для 5 пользователей. Достаточно «best-effort реакция в рабочее время».
• Нет SLO. Если ты не обещал uptime — нет смысла будить людей ночью. Сначала договорись с бизнесом про SLO, потом стройте on-call под него.
• Команда < 4 человек. Math: 4 человека = каждый дежурит 1 неделю в месяц (приемлемо). 2 человека = каждый дежурит каждую вторую неделю → burnout за 2-3 месяца. Лучше outsource on-call (managed service / 3rd-party SRE) или business-hours only
  • готовность к downtime ночью.
• Сервис по-настоящему не критичен. Если пользователи переживут 8 часов downtime до утра — не строй 24/7 ротацию. Auto-scaling + good monitoring + morning triage достаточно.
• Stateless + idempotent + auto-recovery. Если k8s auto-restart лечит 95% инцидентов — оставшиеся 5% можно обработать утром.

Дальше читать

• Concept: availability-numbers — three nines vs four nines: что значит для on-call (43 min downtime/month vs 4.3 min/month).
• Concept: error-budgets-slo-sli — как считать error budget, и как он управляет: deploy freeze, on-call intensity, priorities.
• Concept: incident-management-process — что происходит после того, как pager зазвонил: roles (IC, comms, scribe), war room, postmortem.
• Concept: monitoring-alerting — как строить symptom-based alerts (RED, USE), что page-ить vs email-ить.
• Concept: chaos-engineering — GameDay-и тренируют on-call: planned incidents в рабочее время, чтобы junior-ы научились без real-prod pressure.
• Book: Google SRE Book, ch. 11 «Being On-Call» (бесплатно онлайн, sre.google/sre-book/being-on-call).
• Book: «Seeking SRE» (Blank-Edelman, ed.) — глава про on-call от PagerDuty + от Etsy.
• Playbook: response.pagerduty.com — публичный incident response playbook.
• Handbook: handbook.gitlab.com/handbook/engineering/infrastructure/ on-call/ — детальный пример с compensation, escalation, swap policy.