MTTR (mean time to recovery) — один из честных показателей зрелости эксплуатации. Долгое время мы боролись за него «количеством»: добавляли метрики, дашборды, проверки. Но среднее время восстановления почти не двигалось. Оказалось, проблема была не в данных, а в задержке сигнала.
Где терялось время
Мы разложили инцидент на этапы и измерили каждый:
- Обнаружение — от поломки до срабатывания алерта.
- Оповещение — от алерта до того, как дежурный его увидел.
- Диагностика — от «вижу алерт» до «понимаю причину».
- Устранение — собственно исправление.
Больше всего времени съедали первые два этапа. Опрос метрик раз в минуту плюс буферизация давали задержку обнаружения до 90 секунд ещё до того, как кто-то получал уведомление.
Переход на стриминг
Мы перевели доставку метрик и срабатывание правил на потоковую модель: значения приходят по WebSocket-каналу, а правила вычисляются на лету. Подробнее транспорт описан в документации WebSocket API.
// правило срабатывает на потоке, а не по опросу
when("errRate").above(1).for("30s")
.notify("telegram:oncall");Задержка обнаружения упала с десятков секунд до единиц. Дежурный получал сообщение почти одновременно с самим отклонением.
Что ещё помогло
- Дедупликация и подавление шума. Один корневой инцидент — одно уведомление, а не двадцать.
- Контекст в самом алерте. Ссылка на дашборд и связанные логи прямо в сообщении.
- Эскалации. Если за 5 минут никто не отреагировал — сигнал уходит выше.
Результат
За квартал медианный MTTR снизился с 48 до 11 минут. Главным рычагом оказалась не глубина мониторинга, а скорость, с которой сигнал доходит до человека.
Попробуйте DevSec на своих сервисах — живые метрики и алерты подключаются за несколько минут.