В ИТ-департаментах дежурства давно стали чем-то само собой разумеющимся. Круглосуточные сервисы, SLA (соглашения об уровне сервиса), бизнес-процессы клиентов, которые не останавливаются ни днём, ни ночью, — всё это логично приводит к необходимости иметь людей «на подхвате». RSE-инженеры, SRE, администраторы, служба технической поддержки — почти в любой инфраструктуре есть тот, кто отвечает, когда что-то идёт не так.
На уровне здравого смысла дежурства выглядят просто: составили график, назначили ответственного, выдали телефон — система работает. Именно здесь и кроется ошибка. Во многих компаниях дежурства воспринимаются как техническая формальность, а не как управляемый процесс с последствиями для людей и команды.
Проблема не в том, что инженеры дежурят. Проблема в том, как именно это организовано. Когда дежурства существуют без правил, границ, полномочий и обратной связи, они начинают незаметно разрушать команду изнутри. Не сразу, не громко, без скандалов — но стабильно.
Такие дежурства редко приводят к мгновенным увольнениям или открытым конфликтам. Чаще они проявляются в другом: усталости, снижении вовлечённости, формальном отношении к работе, росте раздражения и цинизма. Команда продолжает выполнять задачи, сервисы формально работают, но система уже трещит — просто это пока не видно в отчётах.
Эта статья — не про то, что дежурства «плохие». Она про то, почему отсутствие системы превращает необходимый инструмент поддержки бизнеса в фактор, который ломает людей, процессы и, в итоге, устойчивость ИТ функции.
Формальные дежурства vs реальность
За свою практику я много раз видел, как дежурства формально «есть», но системы при этом нет. На бумаге всё выглядит правильно: составлен график, назначен ответственный, определён канал связи. Руководство искренне считает, что вопрос закрыт — дежурный есть, значит риски под контролем. Часто в этот момент ещё добавляют: «У нас же есть мониторинг» — и на этом тема считается исчерпанной. Реальность почти всегда другая.
В большинстве случаев дежурство отвечает только на один вопрос — кто сегодня дежурит. Всё остальное остаётся за скобками. Даже при наличии Zabbix, Grafana и десятков дашбордов никто толком не может сказать, какие алерты действительно критичны, а где проблема может подождать начала рабочего времени. Мониторинг есть, но он не встроен в управленческое решение.
Я не раз наблюдал ситуацию, когда дежурному говорят: «У нас же всё видно в графане, разберёшься по ходу». Предполагается, что он сам интерпретирует алерты, вспомнит архитектуру, поймёт взаимосвязи метрик, найдёт нужные доступы, разбудит нужных людей и примет решение. При этом инфраструктура сложная, сигналы противоречивые, знания распределены «4по головам», а документация либо частично, либо полностью устарела. Во время рабочего дня дежурный еще способен разобраться со всеми проблемами, но ночью это практически нерешаемая задача.
В таких условиях мониторинг начинает подменять систему. Алерт сработал — значит, дежурный должен реагировать. Почему он сработал, что именно он означает, насколько это влияет на бизнес и какие действия допустимы — эти вопросы остаются без ответа. Инструменты наблюдаемости работают, а управляемость — нет. С точки зрения менеджмента дежурство в этот момент выглядит как пассивное ожидание инцидента, подкреплённое графиками и метриками.
Для инженера же дежурство выглядит иначе: он не просто ждёт звонка, а несёт ответственность за всю систему: чужие решения и их последствия, технический долг плохо настроенный мониторинг. Формально он «дежурит». По факту он становится последней линией защиты — тем человеком, который отделяет поток технических сигналов от реального ущерба для бизнеса.
Именно на этом этапе особенно сильно заметен разрыв — между управленческой картиной «всё под контролем» и реальным состоянием дежурного инженера. Формально дежурства есть, системы мониторинга работают, отчёты сходятся, SLA соблюдаются. Но внутри команды постепенно накапливается напряжение. Потому что дежурство без чётких правил интерпретации сигналов, полномочий и границ решений — это не процесс, а постоянная неопределённость. И она почти всегда обходится команде дороже, чем кажется на первый взгляд.
Как инженеры ощущают на себе дежурства?
Когда смотришь на дежурства со стороны, легко представить их как редкие ночные звонки или отдельные «аварийные» ситуации. Изнутри это ощущается совсем иначе: это не событие, а состояние, которое длится всё время, пока дежурный работает в графике.
В период дежурства невозможно по-настоящему отключиться от работы. Даже если инцидентов нет, телефон всегда рядом, звук включён, сон поверхностный. Любой сигнал, уведомление, вибрация, случайный звонок нарушает покой. Формально человек отдыхает, но организм живёт в режиме ожидания.
Со временем это ожидание начинает давить сильнее самих инцидентов. Инженер заранее прокручивает в голове сценарии: что может упасть, кто не ответит, какие доступы могут понадобиться, где документация не найдётся. Это не осознанный анализ, а фоновый шум, который не выключается ни вечером, ни в выходные.
Я видел, как даже у сильных инженеров со временем меняется поведение. Они становятся осторожнее, менее инициативными, начинают избегать сложных зон ответственности. Не потому что разучились работать, а потому что постоянно находятся в состоянии внутреннего напряжения. В какой-то момент дежурство перестаёт быть временной нагрузкой и становится фоном всей жизни.
И именно в этом месте часто совершается ошибка. Снаружи всё выглядит нормально: сервис работает, инциденты закрываются. Но изнутри инженер постепенно теряет ощущение контроля и устойчивости. А это всегда первый шаг к выгоранию — тихому и незаметному.
Первые признаки выгорания и деградации команды
Выгорание из-за дежурств почти никогда не начинается резко. Оно проявляется постепенно — через изменения в поведении команды, которые по отдельности легко списать на усталость или «сложный период».
Первое, что обычно меняется, — отношение к инициативе. Инженеры продолжают делать свою работу, но без желания идти дальше необходимого минимума. Исчезает интерес к улучшениям, к переработке старых решений, к снижению технического долга. Появляется негласная установка: лучше не трогать то, что может привести к очередному дежурству ночью.
Параллельно усиливается формализм в работе и коммуникации. Обсуждения становятся суше, решения — осторожнее, диалоги — короче. Это не признак профессиональной деградации, а защитная реакция. Когда ответственность регулярно выходит за рамки рабочего времени, команда учится минимизировать риски не архитектурой и процессами, а собственным поведением.
Следующий заметный сигнал — снижение готовности брать на себя ответственность. Люди всё реже предлагают взять сложный участок или «подхватить» проблемную зону. Не потому что не могут, а потому что прошлый опыт научил: за дополнительную ответственность почти всегда следует дополнительная ночная нагрузка.
Наконец, меняется фокус работы команды. Вместо развития и улучшений появляется режим выживания: сделать так, чтобы система просто не стала хуже. Это состояние особенно опасно тем, что внешне всё выглядит стабильно — задачи закрываются, сервисы работают, — но внутренний запас прочности команды постепенно исчерпывается.
Со временем это начинает отражаться и на атмосфере внутри команды. Появляется раздражение, ирония, негласное разделение ролей. Даже без открытых конфликтов ощущение единой команды ослабевает. Люди всё ещё профессиональны, но внутренне начинают дистанцироваться от продукта и процессов.
Самое сложное здесь — вовремя распознать момент. Потому что снаружи всё выглядит стабильно. Именно в такие периоды возникает иллюзия, что проблема надумана. по опыту могу сказать, что если сигналы игнорировать, то команда продолжит работать, но до тех пор, пока запас прочности не закончится.
Дежурства как наказание и источник несправедливости
В какой-то момент я понял ещё одну неприятную вещь: при отсутствии системы дежурства начинают восприниматься как наказание. Формально этого никто не планирует, но на практике всё складывается именно так — и у нас в компании я тоже сталкиваюсь с подобными перекосами.
Со временем дежурить начинают одни и те же люди. Обычно это самые надёжные, самые ответственные и те, кто лучше всех знает систему. Они реже отказываются, быстрее реагируют, спокойнее ведут себя в инцидентах. В результате нагрузка распределяется неравномерно — не по справедливости, а по принципу «на кого можно положиться».
Для команды это считывается мгновенно. Дежурство перестаёт быть функцией и становится маркером: кто «тащит», а кто может оставаться в стороне. Даже если формально график существует, фактическая нагрузка ощущается как перекошенная. И именно здесь появляется чувство несправедливости — одно из самых токсичных для команды.
Особенно опасно, когда дежурства начинают использоваться как неформальный инструмент управления. Не напрямую, а через ожидания: если ты инициативен, глубоко погружаешься в систему, предлагаешь улучшения — будь готов к дополнительным дежурствам и инцидентам. Со временем люди делают простой вывод: безопаснее быть менее вовлечённым.
Я видел, как в таких условиях сильные инженеры начинают защищаться. Они перестают лезть в сложные зоны, избегают архитектурных решений, которые могут «стрельнуть» ночью, и формально ограничивают свою ответственность. Не из равнодушия, а из желания сохранить личные границы.
Когда дежурства ощущаются как наказание, команда перестаёт воспринимать их как часть профессии. Они становятся источником скрытого напряжения и разобщённости. И это один из самых надёжных способов медленно, без скандалов, потерять самых ценных людей — тех, на ком система держалась изначально.
Ответственность без полномочий
За годы работы я пришёл к выводу, что именно ответственность без полномочий ломает дежурства сильнее всего. Это та точка, где даже зрелые и мотивированные инженеры начинают выгорать быстрее всего — и в моей практике такие ситуации тоже возникали. Интуитивно это чувствуется сразу, но важно, что подобные эффекты хорошо описаны и в исследованиях в области организационной психологии.
Один из подходов, который помогает это объяснить, — модель требований-ресурсов (Job Demands-Resources, JD-R). Она рассматривает рабочую нагрузку как баланс между требованиями, которые предъявляются к человеку, и ресурсами, которые у него есть для их выполнения.
С этой точки зрения дежурства в подобных условиях — классический пример дисбаланса. Требования к человеку максимально высокие: доступность сервиса, соблюдение SLA, давление времени, ожидания бизнеса и клиентов. А вот ресурсы — полномочия, доступы, право принимать решения, поддержка системы — оказываются ограниченными или отсутствуют вовсе.
На практике это выглядит так: дежурному инженеру вменяется ответственность «за всё». За восстановление сервиса, за коммуникацию, за результат. Но в момент инцидента выясняется, что у него нет нужных прав, он не владеет полной картиной архитектуры или не может принять решение, которое действительно влияет на ситуацию — например, откатить релиз, изменить конфигурацию или временно отключить проблемный компонент.
В результате дежурство превращается в цепочку вынужденных эскалаций. Инженер не столько решает проблему, сколько ищет тех, кто имеет право её решить: будит коллег, пытается договориться, объясняет контекст, снижает давление со стороны бизнеса и параллельно несёт формальную ответственность за происходящее. С точки зрения JD-R это ситуация, где требования продолжают расти, а ресурсы остаются недоступными — один из самых устойчивых источников стресса.
Особенно болезненно ощущается момент, когда инженер понимает, что именно нужно сделать, но не может этого сделать официально. Он знает решение, видит корень проблемы, но лишён права действовать. В таких условиях ответственность перестаёт быть профессиональной задачей и превращается в эмоциональную нагрузку, которая быстро накапливается и плохо компенсируется чем бы то ни было.
Я не раз наблюдал, как в ответ на это дежурные начинают действовать чрезмерно осторожно,так как любое самостоятельное действие может обернуться персональными последствиями. В терминах модели требований-ресурсов это предсказуемый эффект: при дефиците ресурсов люди снижают инициативу как защитную стратегию.
Если ответственность не подкреплена доступами, правами и понятными границами принятия решений, дежурство перестаёт быть управляемым процессом. Оно становится стресс-тестом для конкретного человека, а не для системы. И в долгой перспективе такие дежурства разрушают не только команду, но и доверие между инженерами и управлением — потому что система требует результата, не давая средств для его достижения.
Повторяющиеся инциденты и отсутствие обучения системы
В несистемных дежурствах почти всегда повторяются одни и те же инциденты. Меняются даты, люди в графике, уровень усталости — но причины остаются прежними. И это один из самых демотивирующих факторов для команды, в том числе и в нашем опыте.
Каждый инцидент проживается как отдельный пожар. Его нужно срочно потушить, восстановить сервис, закрыть тикет, успокоить бизнес. На этом всё и заканчивается. Формально задача решена, SLA соблюдены, отчёт отправлен. Но сама система при этом ничему не научилась.
Отсутствие post-mortem и анализа первопричин приводит к тому, что дежурства становятся механизмом компенсации плохих решений. Вместо того чтобы улучшать мониторинг, устранять архитектурные слабые места или снижать технический долг, компания полагается на людей, которые снова и снова будут реагировать ночью.
Для инженеров это особенно тяжело. Когда ты в третий или четвёртый раз за месяц просыпаешься по одной и той же причине, возникает ощущение бессмысленности происходящего. Ты понимаешь, что проблема известна, предсказуема и давно требует системного решения — но по какой-то причине его постоянно откладывают.
В такие моменты дежурство перестаёт восприниматься как часть надёжной эксплуатации. Оно начинает выглядеть как костыль, который поддерживает нестабильную систему за счёт человеческого ресурса. И чем дольше это продолжается, тем сильнее накапливается внутреннее сопротивление: почему мы снова решаем последствия, а не причины?
Самый опасный эффект здесь — потеря веры в изменения. Когда инженеры перестают ожидать, что инциденты приведут к улучшениям, они начинают относиться к ним цинично и формально. А система без обучения — это система, которая гарантированно будет повторять одни и те же ошибки, пока люди не закончатся.
Почему компенсации не решают проблему
Почти в каждой компании, где дежурства начинают вызывать напряжение, рано или поздно появляется «простое решение» — компенсации. Доплаты за ночные инциденты, повышенные ставки за дежурство, отгулы после сложных смен. Я сам проходил через этот этап и хорошо понимаю, почему к нему приходят: это быстрый, понятный и формально справедливый шаг.
Проблема в том, что компенсации лечат симптомы, но не причину.
Деньги не возвращают нормальный сон. Отгулы не убирают постоянное ожидание звонка. Даже щедрые выплаты не компенсируют нарушение ритма жизни, когда человек неделями живёт в режиме повышенной готовности. Организм и психика реагируют не на размер компенсации, а на сам факт постоянного стресса.
Есть и другой, менее очевидный эффект. Когда дежурства «покупают» деньгами, компания фактически признаёт: проблема есть, но решать её мы будем не системно, а через нагрузку на людей. В краткосрочной перспективе это работает — инженеры соглашаются, инциденты закрываются. В долгосрочной — закрепляется порочная модель, где устойчивость системы обеспечивается за счёт личных ресурсов команды.
Со временем компенсации перестают мотивировать и начинают восприниматься как плата за неудобства. Причём планируемые неудобства. В таких условиях люди вроде продолжают работать спокойно и профессионально и никак не проявляют усталость внешне, но внутренне начинают считать месяцы до следующего шага — смены проекта, команды или компании. Компенсации могут отсрочить этот момент, но почти никогда не отменяют его.
Если система дежурств не меняется, любые выплаты — это не решение, а способ купить время. Иногда это оправдано. Но важно честно понимать: время покупается не у системы, а у людей.
Как построить системные дежурства: 5 основных признаков
За время работы мне доводилось видеть и другой опыт — когда дежурства не ломают команду, а воспринимаются как нормальная, хотя и непростая часть профессии. Общий признак у таких случаев всегда один: дежурства там являются частью системы, а не заменой её слабых мест.
Первый и самый важный признак — чёткие границы. Понятно, какие инциденты действительно критичны и требуют немедленной реакции, а какие могут подождать до рабочего времени. Это снимает большую часть фона напряжения: инженер понимает, что его поднимут только тогда, когда это действительно необходимо.
Второй признак — прозрачность и справедливость. График дежурств заранее известен, нагрузка распределена равномерно, нет «вечных дежурных» и скрытых перекосов. Если система сложная, это учитывается в ротации и компенсациях, а не замалчивается.
Третий признак — полномочия и подготовка. Дежурный имеет доступы, инструкции, понятные сценарии действий и право принимать решения в рамках инцидента. Он не просто отвечает за ситуацию, а действительно способен на неё влиять. Это радикально снижает стресс и повышает качество реакции.
Четвёртый признак — обучение системы на каждом инциденте. Post-mortem — не формальность и не поиск виноватых, а обязательный элемент процесса. Каждый сбой приводит к улучшению мониторинга, документации или архитектуры. Инженеры видят, что ночные инциденты не проходят бесследно.
И, наконец, восстановление. После тяжёлых дежурств люди действительно должны отдыхать, а не «догонять задачи». Это воспринимается не как бонус, а как часть заботы о устойчивости команды.
Такие дежурства не становятся любимой частью работы, но они перестают быть источником хронического напряжения. И именно в этом состоянии команда способна поддерживать сервисы долго, без выгорания и потери качества.
Дежурства как индикатор зрелости управления в компании
Со временем я всё чаще прихожу к простой, но жёсткой мысли: дежурства — это не про героизм инженеров и не про их «стрессоустойчивость», а про системные процессы в компании.
Если дежурства держатся на личной ответственности, энтузиазме и готовности «потерпеть», значит система недостроена. Она перекладывает собственные слабости на людей — и какое-то время это действительно работает. Но цена такого подхода всегда одна: выгорание, потеря инициативы и постепенная деградация команды.
Зрелое управление проявляется не в том, что инцидентов нет вовсе, а в том, как компания с ними работает. Есть ли понятные правила? Есть ли границы ответственности? Учатся ли процессы и архитектура на каждом сбое? Защищает ли система людей так же последовательно, как бизнес?
Дежурства очень быстро вскрывают ответы на эти вопросы. Там, где есть система, они воспринимаются как тяжёлая, но управляемая часть работы. Там, где системы нет, они становятся источником хаоса и скрытого напряжения — даже если внешне всё выглядит благополучно.
Поэтому разговор о дежурствах всегда стоит начинать не с графиков и компенсаций, а с честного взгляда на процессы. Потому что в конечном итоге дежурит не инженер. Дежурит сама система управления.