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

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

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

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

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

Разговор о ротациях и компенсациях имеет смысл только после разговора об алертах. Ротации и компенсации лечат симптомы. Alert fatigue — причина.

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

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

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

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

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

Отдельная роль — 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 инженер, не являющийся автором сервиса, тратит полчаса просто чтобы сообразить, куда смотреть. С runbook — пять минут на диагностику и действие.

Дашборды для 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.