Офисные ритуалы #15. Дежурство по ротации — 24 августа 2026 г. в 20:20:12.134
Офисные ритуалы #15. Дежурство по ротации Представьте: три часа ночи, вы спите, а где-то в компании падает сервис. Кто должен это заметить? Кто решает, насколько все серьезно? И главное — кто вообще будет чинить систему, пока остальные спят? В IT для этого существует отдельная практика — on-call rotation, или дежурство по ротации. Команда заранее составляет график, и в каждый конкретный момент есть человек, который находится "на дежурстве". Если мониторинг замечает серьезную проблему, именно ему приходит уведомление. И да — в зависимости от компании и графика оно вполне может прийти ночью, в выходной или праздник. Дежурный должен подтвердить, что увидел сигнал, разобраться, что произошло, начать устранять проблему или подключить нужных специалистов. Когда его смена заканчивается, ответственность переходит следующему человеку — отсюда и rotation. Это не редкая внутренняя фишка одной компании. On-call — распространенная практика в SRE, DevOps и командах, которые отвечают за сервисы, работающие круглосуточно. Например, в GitLab система расписана буквально по ролям и часовым поясам. У компании есть несколько on-call-ротаций. В первой линии дежурит Engineer On Call — как правило, SRE. Если автоматический мониторинг замечает проблему с GitLab. com, первым вызывают именно его. Есть отдельный Incident Manager On Call, который подключается для координации более сложных инцидентов, а если нужны специальные знания — можно вызвать экспертов из второй линии. Причем GitLab использует принцип follow the sun: часть дежурств распределяется между APAC, EMEA и Америкой, чтобы круглосуточное покрытие по возможности приходилось на обычные часы бодрствования сотрудников. Правила довольно конкретные: например, для ряда дежурств GitLab ожидает, что сотрудник подтвердит полученный сигнал в течение 15 минут. Если человек не отвечает, срабатывает заранее прописанная цепочка эскалации — зовут следующего специалиста или руководство. А если сотрудник понимает, что в назначенную смену дежурить не сможет, для этого тоже существует процедура замены. Похожую механику поддерживает и Atlassian: в ее системе управления инцидентами можно создавать графики on-call, назначать смены, чередовать сотрудников и прописывать, кому уйдет сигнал, если первый дежурный не отвечает. То есть смысл ритуала не в том, чтобы заставить всю инженерную команду круглосуточно смотреть в ноутбук. Наоборот. В каждый момент понятно, кто именно сейчас отвечает за реакцию на аварию. Остальным не нужно жить в режиме "а вдруг что-нибудь сломается". И здесь появляется интересная управленческая сторона. Если один и тот же инженер постоянно просыпается в три часа ночи из-за одного и того же алерта — хороший on-call устроен не так, чтобы человек просто привык страдать. Это сигнал: систему нужно исправлять. Поэтому дежурства тесно связаны с мониторингом, документацией, автоматизацией и последующими разборами инцидентов. В идеале команда постепенно делает так, чтобы поводов разбудить дежурного становилось все меньше. ✏️ Урок ритуала: ответственность работает гораздо лучше, когда она не размазана на "ну кто-нибудь увидит", а заранее понятно, кто, когда и что делает, если все пошло не по плану. #ритуалы