Дизайн on-call ротации

Действуй как Engineering Manager. Спроектируй on-call ротацию для команды из {{team_size}} инженеров, распределение: {{timezone_spread}}, текущая нагрузка: {{current_load}}. On-call — это не «бонус», это infrastructure, без которой сервис разваливается. Плохая ротация → выгорание → текучка → ещё хуже on-call.

Размер ротации

Минимум 4 человека. Меньше — single point of failure (отпуск, болезнь, увольнение → 100% покрытие падает на одного).

• 4 человека: 1 неделя on-call в месяц. Терпимо, но без буфера.
• 6 человек: 1 неделя в 6 недель. Sweet spot — есть recovery, есть резерв.
• 8+ человек: 1 неделя в 8 недель. Идеально, но требует большой команды.
• 2-3 человека: временно ок, нанимай ещё. Иначе текучка через 6 месяцев.

Не включай новичков первые 3 месяца. Сначала shadow rotation (наблюдение без ответственности), потом secondary, потом primary.

Длительность шифта

Week-long (Mon→Mon) — стандарт. Плюсы: context сохраняется, в течение недели можешь докрутить runbook'и. Минусы: 7 ночей с пейджером — тяжело.

• Handoff день: понедельник 10:00 локальное время primary. Час на передачу.

Day-long (24 часа) — для команд с очень high pager load (> 10 page/неделю). Снижает burnout per shift, но больше handoff overhead.

• Подойдёт только при автоматизированном handoff (incident state в системе, не в голове).

Split: business hours / after hours отдельными ротациями — для крупных команд (> 12 человек). Снижает «night-only inженеров».

Follow-the-sun (для {{timezone_spread}})

Если команда распределена по 2+ TZ (например, EU + US):

• Каждая зона держит свои часы. EU primary 08-20 CET, US primary 08-20 PST. Никто не пейджится ночью.
• Handoff: EU EOD → US SOD (overlap 1-2 часа), incident state передаётся в shared doc / IM.
• Преимущество: никто не теряет ночь сна. Недостаток: требует двух полноценных ротаций (≥ 4 человек в каждой зоне = 8+ total).
• Compromise (если зон 2, но команда 6): weekday follow-the-sun, weekend — одна зона по очереди.

Если все в одной TZ → follow-the-sun не подходит, нужна полная week-on rotation.

Primary / Secondary

Всегда два уровня. Primary получает page первым, secondary — backup, если primary не реагирует в 10 минут OR если primary undisturbed.

• Primary: 5 минут до ack (PagerDuty escalation после).
• Secondary: ack через 10 минут, если primary молчит. Также — co-pilot для SEV1 (primary не должен быть один в war room).
• Не двойная нагрузка: primary + secondary разные люди, не «primary плюс sometimes secondary».
• Secondary тоже компенсируется (см. ниже), хоть и меньше.

Компенсация

On-call — это работа, не «волонтёрство». Без компенсации — выгорание + текучка.

Финансовая:

• Per-shift stipend: $X/неделя primary, $Y/неделя secondary (Y ≈ 30-50% от X). Industry: $500-2000/неделя primary в зависимости от региона/нагрузки.
• Per-page bonus: $50-100 за page вне рабочих часов (особенно ночью). Compensates real disruption.

Time-based:

• Comp day: после тяжёлого on-call (≥ 3 ночных page'а) — обязательный recovery day на следующей неделе.
• No deploys on-call week: primary освобождён от шипания фич, фокус только на reliability work (runbook'и, alert tuning, post-mortem follow-ups).
• Capacity reduction: primary недоступен для new project work, secondary — 50% capacity.

Без time-based компенсации финансовая = «купили твоё здоровье». Включи и то и другое.

Burnout signals (мониторь активно)

Burnout не «случается», он накапливается. Раннее обнаружение спасает людей и команду.

Per engineer (monthly check-in):

• Pager load: > 2 page/week/engineer = red flag (alert fatigue).
• Night pages: > 1 night page/month/engineer = красный флаг (нарушение сна → snowball).
• Weekend pages: более 2 weekend page'й в месяц подряд — escalate.
• Self-reported energy: «как ты по 1-10?» в 1:1 после on-call недели. < 6 — сигнал.

Team-level:

• Attrition risk: инженер просит сменить ротацию / снизить шифты → talk немедленно.
• Sick days после on-call: рост = burnout.
• Incident participation skew: один человек тушит 50% incidents → bus factor + burnout.

Что делать при красных флагах:

1. Снизить нагрузку: дополнительный человек в ротацию, временный split.
2. Alert audit: 80% page noise → fix alerts (alerting-playbook).
3. Force time off: comp days mandatory, не «если хочешь».
4. 1:1 с manager: что мешает? чего боишься? чего хочешь?

Handoff protocol

Без handoff'а primary uходит в weekend, secondary приходит на минное поле в 9 утра понедельника. Plus context loss = duplicated work.

Mandatory handoff meeting (Monday 10:00 local, 30-60 min):

• Open incidents: что активно, что в monitoring, что ждёт post-mortem.
• Ongoing investigations: что копали, какие гипотезы, что осталось.
• Recent changes: деплои за прошлую неделю, новые services, изменения в alert config.
• Known issues: «alert X шумный, мы планируем fix в среду — пока silence до Y».
• Action items со старой недели: что не успели — попадает в handoff doc, secondary продолжает.
• Energy check: «как прошла неделя? что плохо?» — для team retro потом.

Handoff doc (shared, обновляется в течение недели):

## Handoff: {date} (from @alice to @bob)

### Open incidents
- INC-1234 (SEV2, monitoring): {service} latency, mitigation applied, watching 24h
- INC-1235 (SEV3, investigating): {service} memory leak, suspected lib X

### Ongoing investigations
- Alert {Y} fired 5 times last week, root cause unclear, see thread #...

### Recent changes
- 2026-05-13: deploy service-A v3.2 (new endpoint /foo)
- 2026-05-14: alert "high-latency" threshold tightened (1s → 500ms)

### Known noise
- Alert "high-CPU" on cron-runner is expected at 02:00 UTC daily — silence applied through 2026-06-01

### Action items continued
- [ ] Post-mortem for INC-1230 due 2026-05-20 (@alice owns)
- [ ] Runbook update for {alert-name} (@bob takes over)

### Notes
- Manager OOO 2026-05-15-17, escalate to @director

Anti-patterns

• ❌ Ротация из 2 человек — single point of failure, burnout гарантирован.
• ❌ Primary дополнительно делает feature work на on-call неделе — toxic, garantirovan мисс page'й.
• ❌ Нет компенсации — «это часть работы». Через 6 месяцев инженеры уходят.
• ❌ Junior на primary в первый месяц — alerts misinterpreted, эскалация запоздала.
• ❌ Нет handoff meeting — context loss, secondary тушит то, что primary уже почти починил.
• ❌ Все в одной TZ дежурят 24/7 — гарантированная депривация сна.
• ❌ Manager не on-call никогда — теряет touch с реальностью, не понимает burnout сигналов.
• ❌ Ротация назначается за неделю — не планируешь свою жизнь. Назначай за 8-12 недель вперёд.
• ❌ Нет swap mechanism (заболел, не могу) — люди тащат больные → ошибки.

Output format

## Rotation design
- Size: N engineers
- Shift length: week / day
- Follow-the-sun: yes/no, zones [...]
- Primary/secondary: yes
- Onboarding: 3 months shadow → 3 months secondary → primary

## Compensation
- Per-shift stipend: $X primary / $Y secondary
- Per-page bonus: $Z (off-hours only)
- Comp day after ≥ 3 night pages
- No deploys on on-call week
- 50% capacity reduction on on-call week

## Health metrics (monthly)
- Pages/week/engineer (target: ≤ 2)
- Night pages/month/engineer (target: ≤ 1)
- Sick days post-on-call (track)
- Energy self-rating 1-10 (track in 1:1)

## Handoff
- Monday 10:00 local, 30-60 min
- Shared handoff doc updated weekly
- Mandatory attendance, no skip

Принцип: on-call — это инфраструктура устойчивости. Если ротация выжигает людей — сервис тоже сгорит, просто медленнее. Инвестируй в ротацию как в production system.