On-Call Rotation

«On-call входит в зарплату» — эту фразу я регулярно слышу от компаний, где явной компенсации за дежурство нет. Она же стоит за уходом старших инженеров чаще, чем принято признавать. Дежурство — работа в нерабочее время, и когда её никак не оплачивают, команда сначала теряет самых опытных, а оставшиеся либо выгорают, либо начинают реагировать вполсилы. On-Call Rotation — это дисциплина баланса: дежурный есть всегда, нагрузка распределена ровно, никто не выгорает, и тот, кого разбудили, способен реагировать. Без здоровой ротации даже идеально выстроенное реагирование разваливается под выгоранием одного-двух человек.

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

Главный навык на уровне L5 — держать здоровье дежурства как метрику, а не «заметим, когда рванёт». Сколько ночей поднимали людей, сколько за это заплатили, ровно ли легла нагрузка — объективные сигналы, и видны они задолго до заявления об уходе. Сюда же относится правило «никаких героев»: каждый вызов подтверждается явно, а не «я и без алерта всё починил». Иначе один инженер незаметно становится узким местом, и команда узнаёт об этом в день, когда он уходит.

Понимает структуру ротации: длина смены, основной и резервный дежурный, пути эскалации; знает свои ближайшие смены; принимает вызов и делает первичную сортировку.
Перед сменой делает короткий обзор: недавние выкатки, изменённые runbook’и, незакрытые инциденты, известные хрупкие подсистемы.

Настраивает своё расписание в системе оповещения; понимает политику эскалации и её таймауты (подтвердил → передали дальше → следующий по списку); знает, как ввести в курс замену, если внезапно выпал.
Проводит структурированную передачу смены: что было, что осталось открытым, что требует внимания; обновляет runbook по следам нетривиальных вызовов.

Проектирует ротацию: длина смены (неделя — норма), follow-the-sun или один часовой пояс, основной и резервный дежурный, праздники и отпуска, отгулы за дежурство.
Ведёт гигиену алертов: еженедельный или ежемесячный разбор вызовов, удаление ложных срабатываний, рост доли полезного сигнала. Шумная смена, где вызовы ни разу не привели к действию, — это инцидент с постмортемом.
Следит за здоровьем дежурства: сколько ночей поднимали людей, ровно ли легла нагрузка, есть ли явный день на восстановление после ночных вызовов; защищает правило «никаких героев».

L6+

Внедряет политику дежурств на уровне организации: кто платит за дежурство, обязательный отдых после ночи с несколькими вызовами, метрики выносливости, правила переброски нагрузки между командами.
Решает вопросы масштаба: новый сервис — это новая ротация или расширение существующей? Защищает команду от бесконечного расширения зоны ответственности без роста числа людей.

Материалы

Книги

Andrea Spadaccini — Site Reliability Engineering (O’Reilly, 2016), глава 11 «Being On-Call». Канонический подход Google SRE. Рекомендую держать главу под рукой хотя бы ради норматива, который я цитирую дословно: не меньше половины времени SRE уходит на инженерию, а из оставшегося на дежурства — не больше 25%.
Ollie Cook, Sara Smollett, Andrea Spadaccini и др. — The Site Reliability Workbook (O’Reilly, 2018), глава 8 «On-Call». Рекомендую читать вместе с главой выше: та про принципы, эта — про антипаттерны, документацию дежурства, справедливость распределения и обучение новичков.

Статьи и руководства

PagerDuty — Incident Response Documentation. Открытое руководство с разделами Before / During / After; там же практики дежурства — передача смены, эскалация, обоснование компенсации. Лицензия Apache 2.0. Советую как ознакомительное чтение: полезно посмотреть, как дежурство устроено у них, но это описание практики одной компании, а не отраслевой стандарт.
Liz Fong-Jones — публикации и доклады про дежурство, которое можно выдержать долго (SREcon, honeycomb.io). Не читал и не смотрел, поэтому строка здесь — указатель, а не рекомендация: сквозная мысль этих выступлений в том, что общее дежурство SRE и разработчиков поднимает качество кода.

Инструменты

PagerDuty — система оповещения с ротацией, политиками эскалации, подменами и выгрузкой расписания; по-прежнему дефолт индустрии. Из тех, что были рядом с ним в этом ряду ещё недавно, Opsgenie закрывается (Atlassian прекратила продажи в 2025, полное отключение — апрель 2027, миграция в Jira Service Management), а Grafana OnCall свёрнут в общий Grafana IRM, OSS-репозиторий уходит в архив. Ротация дежурств — это то, что команда настраивает один раз и живёт с этим годами, поэтому смерть инструмента здесь дороже, чем в большинстве других категорий.
iCalendar / Google Calendar import, корпоративный CalDAV, самописные интеграции — дубль для наглядности: ротация в общем календаре команды, каким бы этот календарь ни был. Её отсутствие — частая причина «не знал, что дежурю».
Дашборды по гигиене алертов — свои (Grafana, Prometheus) или встроенные в систему оповещения: метрики pages per shift, time-to-ack, % actionable, MTTR. Из всего этого ряда рекомендую заводить их первыми: без них гигиена алертов остаётся вопросом ощущений.
Учёт нагрузки на команду — простая таблица или специальные инструменты (например, Team Health 1:1 с короткими регулярными опросами). Сон я сюда записал зря: продукты этого ряда сделаны не про него, а про нагрузку в долгую, и смотрит на неё руководитель команды, а не сам дежурный.

Best practices

Компенсация за дежурство обязательна, и форма тут вторична. Деньги, отгул, дополнительный выходной — механизм команда выбирает под себя. Важно, что он есть и назван вслух. Иначе среди старших инженеров копится глухое раздражение, которое наружу выходит уже заявлением об уходе, и разговаривать поздно.

Второе условие такое же жёсткое: на каждый pager есть runbook. Алерт без runbook — это «разбуди человека в три ночи и пусть сам соображает», и заканчивается это предсказуемо: через полгода такой алерт либо молча игнорируют, либо удаляют, причём никто уже не помнит, что именно перестали мониторить и почему когда-то решили, что это важно.

Неделя — нормальная длина смены для большинства команд. Две недели подряд не работают: к концу второй дежурный просто выключен. Ежедневная ротация ломается с другой стороны — человек не успевает ничему научиться, а накладные расходы на передачу съедают весь выигрыш.

Обзор перед сменой стоит потраченного времени. Холодный старт на ночном вызове — это первые пятнадцать минут на то, чтобы понять, где ты вообще находишься, вместо реакции. Пятнадцать-тридцать минут перед сменой закрывают вопрос: что выкатили за неделю, какие инциденты активны, какие изменения ожидаются, какие runbook’и поменялись. Я регулярно вижу команды без такого ритуала, и у них MTTR в начале смены заметно выше, чем в середине.

Разбор после смены — короткий, но обязательный. «Прошло, забыли» — и системные проблемы копятся: повторяющиеся алерты, отсутствующие runbook, деплои в пятницу вечером. Минимум — короткое сообщение о передаче смены: что произошло, что осталось открытым, что насторожило. Раз в месяц имеет смысл собирать командную ретроспективу по качеству дежурств. Без этого усталость от алертов растёт незаметно, пока кто-нибудь не сломается.

Гигиена алертов — еженедельный ритуал, а не «когда-нибудь». Ложные срабатывания копятся под соусом «ну подождём, может само перестанет». Не перестанет. Раз в неделю — разбор вызовов: по каким было что делать, по каким нет, где менять порог, что удалять, что переносить в тикеты. Шумная смена — это тоже инцидент, и разбирать её надо как инцидент.

Никаких героев: каждый вызов подтверждается явно. «Я заметил проблему раньше алерта и разобрался сам» звучит как героизм, а работает как потеря видимости: в журнале ничего нет, команда не знает, что происходило, и через полгода один инженер становится узким местом. Это политическая позиция. Защищает её тимлид, больше некому. Без неё здоровье команды деградирует незаметно для всех, кроме самого героя.

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

Incident Response — соседний лист про то, что делают в моменте; этот — про то, кто реагирует и в каком состоянии.
SLI-based Alerting — качество алертинга определяет, выдержит ли команда дежурство вдолгую. Алертинг по SLO и ротация работают только в паре.
Alert Fatigue Management — как измерить и снизить шум. Вторая половина пары для здорового дежурства.
Runbooks — runbook на каждый pager — обязательное условие здоровой ротации.
Postmortem Culture — шумные / тяжёлые on-call смены — кандидаты на постмортем.
SRE Onboarding — дежурство под присмотром как мост от программы обучения к самостоятельной ротации.
One-on-Ones — разговор о том, как идут дежурства, на 1:1 — встроенная проверка на выносливость.
ChatOps — /oncall, /escalate, /page через chat — стандартный набор команд ChatOps под дежурство.
Game Day / Chaos Drills — game day с участием новых дежурных — основная подготовка перед первой сменой; снижает и MTTR, и тревожность.

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

On-Call Comp Models (TBD) — конкретные модели: оплата за каждый вызов, фиксированная ставка за смену, отгулы, гибрид.
Follow-the-Sun Logistics (TBD) — передача смены между регионами и языковой барьер; схему имеет смысл заводить, когда в команде набирается хотя бы шесть человек из разных часовых поясов.

Severity Classification и политика эскалации из этого листа уже уехали в отдельный. Здесь — про то, кто дежурит и в каком состоянии, а не про то, как размечать инциденты по тяжести.