Кейс: агрегатор метрик отправлял алерт раз в секунду вместо раза в час

Сервис собирал метрики ошибок с десятков подов и на превышение порога отправлял алерт в Slack. Условие было простое: если error_rate за окно больше 5%, слать уведомление. Работало нормально до дня, когда один из подов реально начал сыпать ошибками.

Окно агрегации считалось как скользящее — но пересчитывалось на каждое новое событие, а не раз в фиксированный интервал. Как только частота ошибок выросла, частота пересчёта окна выросла вместе с ней — и вместе с ней частота срабатывания алерта. Условие срабатывания было верным, частота проверки — нет.

void onErrorEvent(Metric metric) { window.add(metric); double rate = window.errorRate(); if (rate > THRESHOLD) { alertService.send(rate); } }

За час инцидента в Slack пришло больше тысячи одинаковых по смыслу сообщений — команда физически не успевала их читать, а важные сигналы тонули среди дублей.

Исправили через debounce: алерт может сработать не чаще раза в фиксированный интервал, независимо от частоты входящих событий. Отдельно завели состояние «уже уведомили, ждём восстановления» — чтобы не слать повторно, пока проблема не исчезла и не появилась снова.

Проверка условия и частота проверки условия — это два разных решения, и путать их в коде алертинга дорого стоит именно в момент, когда алерты нужнее всего.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки