Аномалии без алёрт-спама начинаются не с “умной модели”, а с минимального стандарта мониторинга.

Типичный сценарий: вы поставили детект на всё подряд, алёрты сыпятся ночью и днём, дежурный “приглушает”, потом отключают канал целиком. Итог: настоящий инцидент тонет в шуме, доверие к данным падает, а команда перестаёт отличать “плохие данные” от “плохого продукта”.

Почему так ломается: мониторинг строят как один слой “увидел отклонение → пинг всем”. Но данные живут в цепочке. Сырьё может быть битым, витрина может быть неполной, дашборд может быть неправильно собран. Один и тот же сбой триггерит десятки метрик, а сезонность делает “аномалией” обычный понедельник. Без владельца и SLA алёрт превращается в уведомление “на всякий случай”, то есть ни о чём.

Минимальный стандарт, чтобы мониторинг был поддерживаемым, а не мёртвым шумом:

  1. Уровни сигналов разделены: сырьё (поступление, схемы, доли null, дубли), витрины (полнота джойнов, обновление, контрольные суммы/балансы), дашборды (ключевые бизнес-метрики). Алёрт верхнего уровня не должен лечиться проверкой сырья “вручную”.

  2. Дедуп и корреляция: один корневой инцидент должен давать один основной алёрт, остальные уходят в “сопутствующие” или подавляются, пока активен корень. Иначе вы не мониторите, вы DDOS-ите свою команду.

  3. Сезонность учтена по умолчанию: сравнение с “вчера” почти всегда ловит календарь, а не проблему. Нормой считаются профили по дням недели и часам, плюс отдельные правила для праздников и маркетинговых активностей.

  4. Пороги не “красивые”, а операционные: алёрт должен означать действие. Если у метрики нет понятного порога вмешательства, это кандидат в отчёт, а не в пейджер. Для шума используйте предупреждения, для боли используйте инциденты.

  5. У каждого алёрта есть owner и SLA: кто смотрит, в какое время, за сколько минут должен отреагировать, и что считается закрытием. Без этого алёрт не существует, он просто мигает.

В правильной практике это выглядит скучно: небольшой набор критичных сигналов, ясная иерархия причин, понятные “что делать дальше”, и регулярная чистка: если алёрт не приводил к действиям, его либо чинят, либо удаляют. Ограничение простое: при низких объёмах и редких событиях автоматический детект часто бессилен, там лучше контроль поставки и ручные проверки по расписанию. Обычно спорят про “насколько умный” детект, но выигрывает тот, у кого дисциплина по уровням, дедупу и владельцам.