Дежурство на связи - это управленческая задача, а не IT-проблема
Неструктурированные дежурства сжигают инженеров и оставляют инциденты без чёткой ответственности. Решение - не инструмент, а набор решений, которые может принять только управление.
Большинство разговоров про дежурство начинаются с инструмента оповещения: PagerDuty, OpsGenie или чего-то ещё. Команда регистрируется, настраиваются ротации, и предполагается, что проблема дежурств решена. На практике инструмент - наименее важная часть уравнения.
Когда я смотрю на культуру дежурств в компании, чаще всего вижу: неясный охват того, что один человек обязан решить в одиночку в два часа ночи; нет соглашения о том, что является событием, достойным оповещения, а что шумом; нет управленческого решения о компенсации - денежной, отгулами или иной.
Это не настройки инструмента. Это управленческие решения, которые так и не были приняты.
Что дежурство требует от организации
Быть дежурным - значит быть готовым реагировать на производственные проблемы вне рабочего времени. Чтобы это было устойчивым, несколько условий должны выполняться одновременно.
Дежурный должен иметь доступы, права и инструкции по решению распространённых проблем. Если ему нужно будить кого-то ещё, чтобы получить ключ или найти нужную документацию, ротация - это фикция.
Охват должен быть определён. «Всё» - это не охват. Если дежурный инженер отвечает только за сервисы своей команды, это управляемо. Если ему ещё нужно диагностировать сбои сторонних интеграций в полночь - это другая работа.
Цепочка эскалации должна быть согласована заранее и включать менеджера. Когда инженер не может решить что-то в одиночку - кому звонить? Эту цепочку нельзя импровизировать во время инцидента.
Вопрос компенсации
Дежурство - это дополнительная работа. В некоторых странах оно регулируется законом. Везде это реальные усилия, которые сказываются на отдыхе и личной жизни людей.
Я видел команды, где инженеры молча принимают ночи и выходные как часть работы, без какого-либо признания или компенсации. Это работает до тех пор, пока не перестаёт - а когда перестаёт, результатом становятся увольнения, которые удивляют руководство, «не ожидавшее такого».
Решение о том, как компенсировать часы дежурства - доплатой, отгулами, уменьшением ротации чтобы каждый дежурил реже - это управленческое решение. Инструмент его принять не может.
Как выглядит минимально работающая система дежурств
Из того, что я видел работающим на практике:
- Письменное определение зоны ответственности дежурного инженера и того, что явно вне её.
- Инструкция для каждого часто срабатывающего оповещения - не документация о том, как работает система, а пошаговый план «что проверить и сделать в два ночи».
- Список эскалации с именами и телефонами, а не должностями.
- Практика разбора инцидентов: после каждого оповещения, разбудившего человека, - краткое описание произошедшего и оценка, было ли оповещение действительно необходимым.
- Регулярный анализ объёма оповещений. Если дежурного поднимают более двух-трёх раз за ночную смену, система нездорова.
С чего начать
Культура дежурств начинается с разговора между инженерным менеджером и командой - не с внедрения инструмента. Вопрос: на какой уровень доступности мы готовы подписаться, что мы даём взамен и каковы явные ограничения?
Если этого разговора никогда не было, никакая конфигурация маршрутизации оповещений его не заменит.