62% инженеров, находящихся на дежурстве, выгорают в течение 12 месяцев (PagerDuty 2026). Это не проблема людей. Это проблема инженерного дизайна. Три корневые причины, присущие каждому выгоревшему дежурству: 1. Оповещения о симптомах, а не причинах Пики CPU, глубина очереди, скорость запросов — ни один из этих показателей не является инцидентом. Все они будят людей в 3 часа ночи. 2. Устаревшие инструкции Приходит оповещение. Инструкция ссылается на переименованный сервис. Инженер восстанавливает работу системы на адреналине и без сна. 3. Симметричные смены для асимметричной нагрузки Выходные — это Супербоул. Будние дни — спринт. Одна и та же смена обрабатывает оба случая одинаково. Четыре решения, которые применяют лучшие команды: 1. Бюджет ошибок Ограничить незапланированную работу на дежурстве 25% недели. Превышение — остановка работы над новыми функциями. Google SRE создал методологию. 2. Оповещения, привязанные к SLO Если оповещение не связано с нарушением наблюдаемого пользователем SLO, оно является шумом. 23% времени дежурства — ложные срабатывания (Blameless 2026). 3. Инструкция или удаление Каждое оповещение в продакшене должно сопровождаться актуальной инструкцией, иначе оно удаляется. Вы потеряете половину своих оповещений. Именно в этом и суть. 4. Ротации с учетом нагрузки Пиковые окна требуют более плотного покрытия или более коротких смен. Одно решение под всех наказывает того, кто попал на пик. Если вы руководите инженерной командой, проектирование дежурства — ваша задача. Не HR. Не ваш EM. Ваша. На этой неделе: откройте дашборд, посчитайте количество оповещений и задайте вопрос: сколько из них должно было обрабатываться платформой, а не человеком. #EngineeringLeadership #OnCall #SRE