On-Call UX: как не выжигать людей

Три часа ночи, среда

Вам звонит PagerDuty. Вы просыпаетесь, открываете ноутбук, пытаетесь понять, что происходит. Alert говорит «CPU usage above 90% on prod-api-3». Вы смотрите на дашборд — CPU действительно высокий, но сервис отвечает нормально, error rate в норме. Через 20 минут CPU снижается сам, вы закрываете алерт и ложитесь спать. Утром вы разбитый, весь день работаете вполсилы. А через два дня это повторяется. И через неделю снова. Через месяц таких дежурств вы начинаете ненавидеть свою работу — причём проблема была не в продакшене, а в неправильно настроенных порогах алертов.

По данным State of SRE Report за 2024 год, 71% SRE-инженеров сообщают, что отвечают на «десятки или сотни» инцидентов в месяц, которые даже не превращаются в тикеты. 27% алертов в компаниях с 500–1500 сотрудниками игнорируются или не расследуются вообще. Это и есть alert fatigue — состояние, когда алертов так много и они так часто оказываются ложными, что дежурный перестаёт воспринимать их как сигнал реальной проблемы.

Alert fatigue — корень проблемы

Прежде чем говорить о ротациях и компенсациях, нужно разобраться с алертами, потому что ротации и компенсации — это лечение симптомов, а alert fatigue — причина.

Хороший алерт отвечает на два вопроса: что-то реально сломано для пользователей? И дежурному нужно что-то сделать прямо сейчас? Если ответ на любой из этих вопросов «нет» — это не алерт, это информационное уведомление, и оно не должно будить людей в три часа ночи. Atlassian в своём руководстве по on-call формулирует правило: каждый алерт, который разбудил человека, но не потребовал действий, — это баг в системе алертинга, и его нужно чинить с тем же приоритетом, что и баг в продакшене.

Практическое упражнение: возьмите историю алертов за последний месяц и классифицируйте каждый. Сколько из них требовали вмешательства человека? Сколько resolved сами? Сколько были дубликатами? В большинстве команд, которые проделывают это упражнение, actionable алертов оказывается 20–30%, остальное — шум.

Ротации, которые работают

PagerDuty в своём ops guide рекомендует передавать смену по понедельникам — так дежурный начинает неделю с чистого листа и не получает «подарок» в пятницу вечером. Длительность смены — неделя, это индустриальный стандарт. Двухнедельные смены приводят к накопленной усталости, однодневные — к потере контекста.

Минимальный размер ротации — 4–5 человек. При трёх инженерах каждый дежурит раз в три недели, и если кто-то в отпуске, двое оставшихся дежурят через неделю. Это прямая дорога к выгоранию. При пяти инженерах каждый дежурит раз в пять недель — нагрузка терпимая, и отпуск одного человека не ломает расписание.

Отдельная роль — secondary on-call. Вторичный дежурный подключается, если первичный не отвечает в течение 5–10 минут или если инцидент требует координации нескольких команд. Наличие secondary снижает стресс первичного дежурного: он знает, что есть страховка.

Важная деталь, которую многие упускают: handoff между сменами. При передаче смены уходящий дежурный должен передать контекст — какие проблемы были за неделю, какие алерты flaky, на что обратить внимание. Без этого новый дежурный тратит первые часы на ориентирование.

Компенсация

On-call — это ограничение личной свободы. Дежурный инженер не может уехать за город без ноутбука, не может выпить бокал вина за ужином, не может пойти в кино и выключить телефон. За это нужно платить, и «это часть работы» — плохой ответ, который приводит к тому, что лучшие инженеры уходят в компании, где on-call компенсируется.

Распространённые модели компенсации:

Фиксированная надбавка за неделю дежурства. В Европе — от 500 до 1000 USD в неделю, в зависимости от компании и региона. В Германии, Испании и Бразилии компенсация регулируется законодательно. В России рынок пока менее структурирован, но крупные компании платят от 15 до 40 тысяч рублей за неделю on-call.

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

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

Лучшая практика — комбинация: фиксированная надбавка за саму доступность плюс дополнительная компенсация за ночные инциденты плюс гарантированный поздний старт на следующий день после ночного вызова.

Инструменты для гуманного дежурства

Подробный обзор платформ для управления инцидентами — в главе про инструменты. Здесь — о принципах.

Правильно настроенная система алертинга — первый инструмент. Deduplicated alerts, suppression windows для запланированных работ, routing по сервисам — всё это снижает количество ложных пробуждений.

Runbooks — второй инструмент. Когда дежурного разбудили, он должен видеть рядом с алертом ссылку на runbook: что проверить, как продиагностировать, как починить. Без runbook дежурный инженер, который не является автором сервиса, тратит 30 минут на то, чтобы понять, куда смотреть. С runbook — 5 минут на диагностику и действие.

Dashboards для on-call — третий инструмент. PagerDuty рекомендует менеджерам отслеживать распределение нагрузки: кого будят чаще, какие сервисы генерируют больше алертов, как меняется MTTR. Если один инженер получает 80% ночных алертов, потому что он — единственный, кто знает определённый сервис, это сигнал bus factor-проблемы, которую нужно решать через knowledge sharing.

Метрики здоровья on-call

Количество алертов за смену. Если дежурный получает больше двух ночных алертов за неделю, система требует внимания.

Процент actionable алертов. Целевой показатель — выше 80%. Если каждый пятый алерт ложный, дежурные начнут игнорировать все.

MTTA (mean time to acknowledge). Сколько времени проходит от алерта до подтверждения. Рост MTTA — ранний индикатор alert fatigue.

Retention инженеров с on-call-обязанностями. Если люди уходят через полгода после включения в ротацию, у вас проблема с on-call UX, а не с рекрутингом.