Инфраструктурные метрики: когда нужен ML-детектор, а когда достаточно SLO и burn-rate?

Для метрик, у которых есть явное определение «плохо» — доля ошибок, задержка выше порога, доступность, — ML-детектор чаще всего избыточен. Практика SRE даёт более простой и предсказуемый инструмент: SLO и алерты по скорости сжигания бюджета ошибок, обычно в многооконной схеме, где быстрая пара окон ловит аварию, а медленная — тихую деградацию. Такой алерт понятен, не требует обучения, не устаревает и напрямую связан с обещанием пользователю. ML-детектор оправдан там, где порога не существует: продуктовые метрики без нормативного значения (заказы, регистрации, выручка по сегментам), метрики с сильной сезонностью, где статический порог не работает, и широкий парк метрик, для которого никто не будет вручную определять SLO. Разумная архитектура совмещает оба подхода: burn-rate — для сервисных показателей и звонков дежурному, детекция аномалий — для продуктовых метрик и раннего предупреждения в канал.