На новом месте я сразу полез смотреть как устроен on-call. И увидел знакомую картину: алертов много, реальных инцидентов мало (если сравнивать с ложными), дежурят одни и те же люди, runbook'ов нет - или они не актуальные, или пустые.
Но пришло время всё исправлять.
Тема горячая: Catchpoint SRE Report 2026 показывает - 70% SRE называют on-call стресс прямой причиной выгорания, тойл вырос до 34% рабочего времени. PagerDuty фиксирует: из ~50 алертов в неделю на инженера только 2-5% требуют действия.
1. Все алерты - P1
Нет severity → каждый алерт будит ночью → через неделю мозг отключается. 44% организаций получили аутедж из-за проигнорированных алертов, 67% инженеров признаются, что dismissают без разбора.
Решение: DISASTER → CRITICAL → HIGH → WARNING. Если всё P1 - значит ничего не P1.
2. Один герой на линии
Один человек дежурит неделями, потому что «знает систему лучше всех». Google SRE рекомендует: макс. 2 инцидента за смену, минимум 50% времени - на проектную работу, не на тушение пожаров.
Решение: primary + secondary, ротация раз в неделю. Wheel of Misfortune - чтобы дежурить мог каждый, а не только «тот самый Андрей».
3. Runbook? Какой runbook?
Алерт в 3 ночи, on-call не понимает что делать. 40 минут на пинги в Mattermost и эскалацию. incident.io подтверждает: без runbook время разрешения x3-4.
Решение: нет runbook = нет алерта. Внутри: что случилось, что проверить, как чинить, когда эскалировать. Цель - 10 минут без эскалации.
4. Дежурство без компенсации
Инженер не спит ночами. Компенсация:
5. Нет follow-up после инцидента
Починили → забыли → через неделю тот же алерт в 3 ночи. Runframe: тойл вырос до 30%, при этом 16% говорят что AI только добавил работы.
Решение: инцидент → постмортем (мой шаблон) → action items с владельцем. Без follow-up вы чините симптомы, а не систему.
Здоровый on-call - не героизм, а инженерная практика. Плохой on-call - инцидент без конца.
Что из этого есть у вас?:)
#sre #oncall #alerts #burnout
