Дежурных будят алерты «загрузка CPU выше 90%», которые в большинстве случаев ни к чему не приводят. Как правильно перестроить алертинг?

Почему CPU 90% — плохой алерт. Высокая загрузка часто означает, что ресурс используется эффективно. Пользователи могут не замечать ничего, а дежурный просыпается зря. Через несколько недель алерты перестают читать — и пропускают настоящую аварию.

Симптомы значимы всегда: доля 5xx выросла, задержка превысила порог, очередь заказов не разбирается, SLO нарушается. Их видят пользователи.

Burn rate. Скорость прожигания — во сколько раз быстрее нормы расходуется бюджет ошибок. Схема из Google SRE:

• быстрая авария: burn rate 14 за 1 час и за 5 минут — страница сейчас;
• медленная деградация: burn rate 6 за 6 часов и за 30 минут — страница;
• ещё медленнее — тикет.

Два окна: длинное даёт значимость, короткое — быстрое снятие алерта, когда проблема прошла.

Гигиена:

• каждый ночной алерт — срочный (нельзя подождать до утра), действенный (есть что сделать) и со ссылкой на инструкцию;
• причинные метрики — на дашборды для диагностики, предупреждения — тикетами;
• разбор каждого ложного срабатывания: исправить порог, условие или удалить;
• метрика шума: число страниц на дежурство.