On-call практики: дежурство без выгорания¶

Из всех тем SRE эта — самая человеческая. Не про серверы, метрики или код. Про людей, которые просыпаются в 3 часа ночи. Про справедливость, усталость и культуру.

On-call (дежурство) — это когда инженер назначается ответственным за реагирование на инциденты в определённый период времени. Звучит просто. На практике это самая частая причина выгорания SRE, по себе знаю, когда у меня 120 часов переработок заканчивались за три месяца.

Почему дежурство выжигает¶

Дежурный не просто ждёт алерта. Он в состоянии постоянной готовности: не может пойти в кино, выпить с друзьями или просто выключить телефон. Непрерывное ожидание, даже если инцидентов нет, — это когнитивная нагрузка. А если они есть — это стресс плюс прерванный сон или вообще его отсутствие сутками.

Исследования показывают: после трёх ночных пробуждений за неделю продуктивность падает на уровень человека с похмелья. А если так длится месяцами — это прямой путь к выгоранию.

Сколько должен дежурить один человек¶

Google SRE в своей классической книге рекомендует: SRE должен тратить не более 50% времени на операционную работу (включая on-call). Остальные 50% — на инженерные проекты.

Для on-call это означает: - Не чаще одной недели в месяц. Если человек дежурит две недели из четырёх — он не успевает восстанавливаться. - Не более 8–12 часов в день для primary дежурного В идеале — 12-часовые смены с переключением на secondary, чтобы дежурный мог выспаться. - Не более 2–3 ночных инцидентов за дежурство. Если система валится каждую ночь несколько раз, то эту проблему нужно решать системно, а не усиливать дежурную команду.

Модели дежурства¶

Primary / Secondary (эскалация)¶

Два инженера на смене. Primary — первый на линии. Если не справляется или проблема выходит за рамки его компетенции — подключается Secondary.

Схема:
[Алерт] → Primary (10 мин) → если не решил → Secondary (30 мин)
                                      → если не решил → L3 / разработчики

Плюсы: Primary не чувствует себя брошенным, Secondary подстраховывает. Минусы: нужно вдвое больше людей в ротации.

Follow-the-sun¶

Команды распределены по часовым поясам. Дневная смена передаётся коллегам в другом регионе, а не переходит в ночную.

Плюсы: инженеры не работают ночью. Минусы: нужны распределённые команды, накладные расходы на handover.

На мой взгляд - это лучшее решение. Но это возможно организовать далеко не всегда (вернее, почти никогда).

Round-robin (простая ротация)¶

Дежурные меняются по расписанию, каждый дежурит неделю. Самая распространённая модель.

Плюсы: предсказуемо, легко планировать. Минусы: ночные дежурства неизбежны, если команда в одном часовом поясе.

Компенсация за дежурство¶

Есть два подхода:

Компенсация временем. Отработал ночной инцидент — на следующий день начинаешь не с 9, а с 13. Или получаешь дополнительный выходной.

Компенсация деньгами. Доплата за дежурную неделю — фиксированная сумма плюс почасовка за реальные инциденты.

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

Как сделать дежурство выносимым¶

1. Хорошие алерты — залог спокойной ночи¶

Главный враг дежурного — шум. Алерты, которые не требуют действий, но будят каждые 15 минут. Почитайте главу про качественный алертинг: каждый алерт должен вести к действию. Если алерт можно проигнорировать — его не должно быть.

2. Runbook для типовых ситуаций¶

Когда дежурный видит алерт, он должен открыть runbook и выполнить шаги. Не вспоминать, не искать, не гадать. Runbook — это страховка от паники в 3 часа ночи. А понимание того, как разворачивается инцидент от алерта до постмортема — в главе про жизненный цикл инцидента.

Метрика качества runbook: может ли новый инженер, который впервые дежурит, выполнить его без помощи коллег? Может - отличный ранбук! Не может - переделывай!

3. Чёткая эскалация¶

Дежурный должен знать, кому звонить, если он не справляется. Не «найди кого-нибудь в маттермосте, а «если проблема не решена за 15 минут — звони Ивану +7...».

4. Культура психологической безопасности¶

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

5. Анализ после дежурства¶

После дежурной недели команда собирается на 30 минут:

Сколько было инцидентов?
Сколько из них требовали реального вмешательства?
Какие алерты были ложными?
Что можно автоматизировать, чтобы снизить нагрузку?

Ретроспектива дежурства — это не «кто виноват». Это «что мы можем сделать, чтобы следующая неделя была легче».

Когда дежурство не нужно¶

В некоторых ситуациях on-call в традиционном понимании избыточен:

Некритичные сервисы (например, внутренние инструменты, которые могут постоять до утра). Здесь достаточно дежурства в рабочее время.
Система не меняется месяцами и стабильна как скала. Можно дежурить по желанию или уменьшить частоту ротации.
Автоматизация закрыла 100% сценариев. Теоретически такое возможно, но практически — фантастика.

Итог¶

On-call — это неотъемлемая часть SRE, но она не должна разрушать жизнь инженеров. Хорошее дежурство — предсказуемое, с качественными алертами, защищённое runbook'ами и с понятными границами ответственности. И главное: оно должно быть справедливым: каждый член команды дежурит по очереди, а нагрузка компенсируется временем или деньгами.

Плохой on-call — когда систему штормит, алерты летят без умолку, а дежурный не спит по три дня. Если ваша команда в таком состоянии — это не on-call проблема. Это проблема системы, которую нужно решать до того, как выгорят люди.