DEV Community

Sergey Shinder
Sergey Shinder

Posted on

Мы тонули в алертах и не видели настоящий пожар

Был период, когда наш дежурный канал в мессенджере выдавал под триста алертов в сутки. Звучит как отличный мониторинг, а на деле это была катастрофа. Когда алертов триста, ни одного из них никто не читает всерьёз. И именно в такой обстановке мы однажды прозевали настоящий инцидент: критичный алерт утонул в потоке шума про то, что диск на тестовой ноде заполнен на 81 процент.

Проблема была не в нехватке мониторинга, а в его переизбытке без смысла. Кто-то навесил алерт на каждую метрику, до которой дотянулся: CPU выше 70, память выше 80, любой всплеск latency, каждый пятисотый код от любого сервиса. Все они срабатывали постоянно, потому что пороги были взяты с потолка, а не из реального поведения системы.

Мы сели и переосмыслили подход целиком. Ключевая идея, которую я теперь повторяю всем: алерт должен звать человека только тогда, когда человек реально нужен и может что-то сделать. Всё остальное — это дашборд, а не пейджер. Высокий CPU сам по себе — не проблема, это просто работающий процессор. Проблема — когда из-за него страдают пользователи.

Поэтому мы перешли на алерты по симптомам, а не по причинам. Не «CPU высокий», а «пользователи получают ошибки» или «время ответа вышло за оговорённый порог». Мы завязали алертинг на SLO: пока бюджет ошибок в норме, система молчит, даже если внутри что-то шумит. Как только сжигание бюджета ускоряется — вот тогда будит человека.

Отдельно навели порядок в трёх столпах наблюдаемости. Метрики отвечают на вопрос «что-то сломалось?». Логи — «что именно?». Трейсы — «где в цепочке сервисов?». Раньше у нас были только метрики и разрозненные логи, и в распределённой системе мы часами гадали, какой из десяти сервисов виноват. Сквозной трейсинг с единым trace-id сократил это до минут.

Итог был почти обидно простым. Мы выключили около двух третей алертов, оставили десяток по-настоящему важных, привязанных к пользовательской боли. И знаете что? Мы стали ловить инциденты быстрее, а не медленнее. Тишина в дежурном канале снова начала что-то значить. Хороший мониторинг — это не когда видно всё, а когда видно главное.

– Sergey Shinder

Top comments (0)