On-call для DevOps: как оценить дежурства до оффера и не выгореть

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

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

В этой статье: как проверять on-call до оффера, какие метрики спрашивать, какие красные флаги видеть на интервью, как договориться о здоровых условиях и как защищать себя от хронического перегруза.

1. Почему on-call стал критичной темой для DevOps

• увеличилась сложность инфраструктур и число взаимозависимых сервисов;

• бизнес требует высокой доступности 24/7;

• алертов стало больше из-за микросервисов и сложной телеметрии;

• часть компаний снижает затраты, и нагрузка on-call распределяется на меньшее число инженеров.

В таких условиях «нормальные дежурства» и «режим постоянного пожара» отличаются не должностью, а зрелостью процессов в команде.

2. Модели on-call: какая из них безопаснее для инженера

3. Какие вопросы нужно задать до принятия оффера

1. Сколько инженеров участвуют в ротации?

2. Как часто моя смена и сколько длится?

3. Сколько вызовов ночью бывает в среднем?

4. Есть ли вторичный дежурный и четкий путь эскалации?

5. Как оплачиваются дежурства, вызовы и переработки?

6. Есть ли recovery day после тяжелой ночи?

7. Как часто команда проводит postmortem и устраняет первопричины?

Важно: просите не общие слова, а конкретные цифры за последние 1-3 месяца. Это самый быстрый тест зрелости процесса.

4. Метрики on-call, которые реально показывают качество процесса

5. Красные флаги on-call на интервью

• «У нас редко инциденты», но никто не может назвать цифры;

• нет runbook и стандартного процесса реагирования;

• нет разделения зон ответственности между командами;

• вызовы ночью считаются «нормальной частью культуры»;

• оплата дежурств описывается расплывчато или «обсудим после оффера»;

• нет явного ownership за устранение первопричин.

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

6. Как быстро оценить риск выгорания по вакансии

Используйте простую оценку в баллах:

+2: нет вторичного дежурного
+2: нет прозрачной оплаты on-call
+2: нет цифр по алертам и ночным вызовам
+1: нет recovery day
+1: нет регулярных postmortem

0-2 балла: умеренный риск
3-5 баллов: высокий риск
6+ баллов: критический риск

Эта модель не идеальна, но хорошо работает как фильтр «принимать / уточнять / отказываться».

7. Что должно быть в здоровом on-call-процессе

1. Понятная ротация минимум из нескольких инженеров.

2. Runbook для типовых инцидентов и четкая эскалация.

3. Техническая работа по снижению шума алертов.

4. Регулярный разбор причин и приоритизация профилактики.

5. Компенсация дежурств и восстановление после тяжелых смен.

8. Как обсуждать on-call в оффере и трудовых условиях

9. Как уменьшать нагрузку on-call уже после выхода в команду

• снижайте шумные и дублирующие алерты;

• переводите частые инциденты в задачи на автоматизацию;

• улучшайте наблюдаемость: метрики, логи, трассировку;

• добавляйте self-healing механизмы для типовых сбоев;

• фиксируйте SLO и связывайте их с приоритетами работы.

10. Антипаттерны, которые почти гарантируют выгорание

Антипаттерн 1: «тушим пожар, потом разберемся»

Если это повторяется каждую неделю, команда теряет эффективность и мотивацию.

Антипаттерн 2: дежурный без полномочий и доступа

Инженер отвечает за восстановление, но не может быстро применить решение.

Антипаттерн 3: нет владельца устранения первопричин

Инциденты повторяются, а нагрузка остается на дежурных.

Антипаттерн 4: «героизм вместо процесса»

Культура постоянного «подвига» разрушает команду и качество инфраструктуры.

11. Шаблон короткой оценки вакансии по on-call

Проверка перед принятием оффера:

• Ротация: раз в N недель / число людей в ротации

• Ночные вызовы: X за неделю в среднем

• Эскалация: есть/нет secondary

• Компенсации: фикс за смену + оплата вызовов

• Recovery: есть/нет

• Process maturity: runbook/postmortem/alert hygiene

Заполните этот шаблон после интервью. Если 2-3 пункта «серые», задайте дополнительные вопросы до подписания оффера.

12. Чек-лист «здорового on-call» для DevOps-инженера

1. Есть прозрачная нагрузка и исторические данные.

2. Есть понятная оплата и условия в договоре.

3. Есть вторичная линия поддержки.

4. Есть техническая работа по снижению алерт-шума.

5. Есть постмортемы и реальные действия после них.

6. Есть политика восстановления после тяжелых смен.

7. Есть уважение к личному времени инженеров.

13. Частые вопросы

Нормально ли, если дежурный получает 5-10 ночных вызовов в неделю?

Обычно это сигнал проблемной системы мониторинга и неустойчивой инфраструктуры. Такая нагрузка без изменений процесса опасна.

Можно ли на DevOps-позиции избежать on-call полностью?

Иногда да, но часто on-call входит в роль. Важно договориться о границах и адекватных условиях, а не игнорировать тему.

Что важнее при выборе: зарплата или качество on-call?

Нужно оценивать баланс. Высокая компенсация не всегда окупает хронический стресс и потерю восстановления.

Когда стоит отказаться от оффера из-за on-call?

Когда процесс непрозрачен, нет поддержки и компенсаций, а команда не демонстрирует намерения снижать системные причины инцидентов.

14. Итог: on-call — это не «мелкая деталь», а часть качества жизни

Ключевой вывод: хороший оффер DevOps — это не только зарплата, Kubernetes и CI/CD, но и зрелая модель дежурств. Именно on-call чаще всего определяет, будете ли вы работать устойчиво или выгорите через несколько месяцев.

Оценивайте on-call заранее по цифрам, фиксируйте условия до выхода и выбирайте команды, где инциденты не героизируют, а системно устраняют.

А лучшие вакансии для DevOps ищите на hirehi.ru