On-Call ротации: лучшие практики SRE для борьбы с выгоранием (2026)
Лучший SRE ушла в прошлом квартале. На exit-интервью она не сказала «выгорание», но последние три месяца в её календаре — 14 ночных пагеров, 2 выходных на инцидентах и звонок в 3 утра в день рождения. Опрос Catchpoint / DevOps Institute 2021 года среди 500+ on-call инженеров показал: 67% сообщают о симптомах выгорания, напрямую связанных с нагрузкой от пейджера. SRE-книга Google ставит потолок — 2 инцидента на смену; дальше ротация считается нездоровой. У большинства команд, которые мы измеряем, этот потолок пробивается в первую неделю.
On-call лечится. Это задача расписания и социотехники, а не слабости тех, кто «не справляется». Ниже — playbook из 9 правил, который держит SLA и ваших сильных инженеров в команде дольше второй ротации.
{/* truncate */}
Проблема
В любой команде со сломанной ротацией встречаются три режима отказа:
Слишком мало участников. Ротация из 4 человек — каждый дежурит раз в 4 недели. За год это 13 недель с битым сном, отменёнными планами и испорченным фокусом. Google SRE целятся минимум в 6 человек — ниже шести времени на восстановление просто нет.
Нет ритуала передачи. Входящий on-call узнаёт о флаппающем алерте от PagerDuty в 2 часа ночи. У уходящего был контекст, но он никуда его не записал. Каждая ротация обнуляет знания — один и тот же инцидент «открывается заново» ежемесячно.
Компенсация делает вид, что пейджера не существует. Инженеры на окладе, пейджер срабатывает в 3 утра, ожидания к следующему рабочему дню никто не корректирует. Отчёт Blameless / DevOps Institute 2023 года показал: в командах без явной on-call компенсации и recovery time текучка среди senior инженеров в 2,4 раза выше, чем в командах с такими политиками.
Правила ниже бьют по всем трём разом.
Здоровый цикл ротации: primary → secondary → эскалация → review → handoff. Каждая стрелка — точка принятия решения, которую команды пропускают.
9 правил
Правило 1 — минимум 6 инженеров в ротации
Меньше шести — нет запаса. Один в отпуске или на больничном, и нагрузка прыгает на 5 человек, а и без того тяжёлая смена становится жестью. От шести и выше математика работает: primary примерно раз в 6 недель, есть окно на восстановление. Если шести нет — не запускайте 24/7 ротацию. Используйте follow-the-sun с партнёрской командой или triage-only в рабочие часы с отложенной реакцией.
Правило 2 — primary + secondary, всегда
Не роутить пейджер в одного человека. Secondary подхватывает, если primary не подтверждает за 5 минут. Одно это правило сокращает неподтверждённые пейджеры примерно вдвое в командах, которые его адаптировали — potому что primary спит, в митинге или без связи чаще, чем организация ожидает.
| Роль | Окно подтверждения | Триггер эскалации |
|---|---|---|
| Primary | 5 мин | Нет ack → пейджер на secondary |
| Secondary | 10 мин | Нет ack → пейджер на EM |
| EM | 15 мин | Нет ack → VP Eng |
Secondary — не «запасной», а активная роль с ожидаемой доступностью на смене.
Правило 3 — жёсткий потолок: 2 paging-инцидента на 12-часовую смену
Это потолок из публичной SRE-книги Google и самое полезное число в дизайне ротации. Если смена превышает 2 инцидента — что-то сломано выше по потоку: шумный alerting, хрупкая система или и то, и то. Трекать ежемесячно. Если месяц за месяцем выше 2 — ротация признана нездоровой, и план remediation принадлежит инженерному руководству, а не дежурному.
Правило 4 — структурированная передача смены при каждом swap
15 минут, синхронно если возможно, короткая запись в противном случае. Покрывает:
- Активные инциденты (открыты, mitigated-not-resolved, в расследовании)
- Текущие проблемы (deploy freezes, известные флаппающие алерты, проблемы с зависимостями)
- Change log недели (что задеплоилось, о чём следующему on-call стоит знать)
- Обновления runbook'ов (что новое, что не покрыто)
Пропуск передачи — самый частый налог. Видели команды, которые открывают один и тот же флейкий alert три ротации подряд, потому что никто не записал.
Правило 5 — компенсация отражает стоимость
Три рабочих модели, выбрать одну и зафиксировать:
- Отгул (time-in-lieu) — каждый paged час после 22:00 и в выходные превращается в оплачиваемое recovery time в ближайшие две недели.
- Фиксированный стипенд — $300-800 за неделю ротации, независимо от числа инцидентов, чётко коммуницируется.
- Гибрид — небольшой базовый стипенд + бонус за paged-инцидент.
Худшая модель — «ты на окладе, разбирайся сам». Она экстернализирует стоимость на здоровье инженера и, в конечном счёте, на ваш бюджет найма. Данные Blameless 2023 связывают прозрачность on-call компенсации с retention сильнее, чем любую другую переменную.
Правило 6 — обязательное восстановление после инцидента
Если человека пейджили между 22:00 и 6:00 — он не начинает в 9 утра. Политика, не переговоры. Команды, которые публикуют это и соблюдают, видят на 30-40% меньше самоотчётных симптомов выгорания за 12 месяцев (DevOps Institute 2023). Команды, которые полагаются на «приходи попозже, если надо» — инженеры всё равно приходят вовремя и тихо копят обиду.
Правило 7 — ротируйте типы, а не только имена
Три вида on-call работы ротируются отдельно:
- Pager-ротация (сам пейджер)
- Incident commander (ведёт ответ, когда всё поехало)
- Review-ротация (владеет постмортемом за 48 часов)
Слияние в одну роль перегружает одного и того же человека. Разделение — на любой неделе три разных инженера несут уменьшенную нагрузку, а не один несёт всё.
Правило 8 — никакого on-call за 30 дней до ухода или смены роли
Объявленное увольнение, внутренний transfer, PIP — все поводы снять с ротации. Внимание в другом месте, мотивации быть героем нет, а ставить на пейджер — провоцировать пропущенный alert. Оставшаяся ротация закроет дыру, это же сигнал хайрить до того, как станет срочно.
Правило 9 — ежемесячный review здоровья ротации — на данных, не на ощущениях
30-минутная ежемесячная встреча. Три графика:
- Paging инциденты на смену (меньше 2?)
- After-hours пейджеры на инженера (распределены ровно?)
- Recovery-time реально взятый (политика соблюдается?)
Если что-то красное — это повестка следующего месяца. Наш CTO Dashboard паттерн подходит сюда: руководство видит сигнал еженедельно, а разговор про on-call — ежемесячный, чтобы не вытеснять delivery.
Типичные ошибки
| Ошибка | Почему бьёт | Что делать |
|---|---|---|
| Недельные смены | Слишком длинно — долг сна копится к 4-му дню | Разбить на две полунедели с разными primary |
| «Добровольный» on-call | Те же 2-3 человека тащат 80% смен, пока не уйдут | Обязательная ротация с задокументированными исключениями |
| Пейджер на каждую ошибку | Alert fatigue убивает качество ответа | Жёсткая тиаризация — пейджить только SLO-impact |
| Нет runbook'ов | Каждый инцидент пересобирается с нуля | Runbook-per-alert как merge-gate |
| Считать только инциденты | Теряются low-sev прерывания, которые ломают фокус | Трекать paged minutes, не только events |
Чеклист
- Минимум 6 инженеров в ротации
- Primary + secondary на каждой смене
- Paging инциденты на смену трекаются, среднее меньше 2
- Ритуал передачи задокументирован и выполняется
- Модель компенсации опубликована
- Политика recovery-time опубликована и соблюдается
- Incident commander и review ротируются отдельно
- Уходящие / меняющие роль снимаются с ротации
- Ежемесячный rotation-health review в календаре
Как измерить, что это работает
Четыре сигнала говорят, что ротация здорова:
- Paged инциденты на смену — тренд держится ниже 2 на 3-месячном окне
- After-hours coding time — мы трекаем это как сигнал выгорания в PanDev Metrics через IDE heartbeat; устойчивая ночная активность после инцидента — признак, что recovery политика пропускается
- On-call → exit gap — время между ротацией и добровольным уходом; если стабильно меньше 6 месяцев, ротация вносит вклад в attrition
- MTTR тренд — здоровая ротация коррелирует с плоским или улучшающимся MTTR; деградирующая — сначала проявляется именно там
Наш датасет по 100+ B2B инженерным командам показывает устойчивый паттерн: команды, публикующие явные on-call компенсацию и recovery-политики, имеют на 30% меньший всплеск after-hours IDE активности на неделе после инцидента по сравнению с командами, где нормы неявные. Сигнал ограничен тем, что видно в редакторе — Slack-триаж и работа только с пейджером нам невидимы, так что относитесь к этому как к направлению, а не полной картине.
Когда этот framework не подходит
Если команда меньше шести — стоп. Устойчивую 24/7 ротацию на меньше чем шести телах собрать нельзя, никакие правила поверх не помогут. Варианты: follow-the-sun с другой командой, triage-only в рабочие часы, платный внешний SRE-партнёр на ночь — пока нанимаете.
Пропустите и если paging-объём структурно низкий (скажем, меньше 4 пейджеров в квартал). Формальная ротация станет оверхедом; неформальное покрытие с чёткой цепочкой эскалации работает лучше.
Неочевидное правило
Большинство playbook'ов начинают с «почините алерты». Мы не согласны. Шум алертов — симптом; корневая причина — никто не владеет алертами как продуктом. Правило 3 (потолок 2 инцидента на смену) создаёт forcing function: когда потолок пробит, владение alerting становится задачей инженерного руководства, а не выходным проектом линейного инженера. Сначала здоровье ротации, гигиена алертов следом.