Oncall Bot и мониторинг фронтенда

Проблема

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

Подход

• Относительные базовые линии вместо фиксированных порогов. Сервис оповещений выполняет SQL-запросы к ClickHouse и сравнивает каждую метрику с тем же часом прошлой недели. Падение конверсии на 20 % означает разное в 3 часа ночи в Токио и в полдень в Берлине, и колебания мирового трафика больше не вызывают ложных тревог.
• Оповещение приходит вместе с контекстом. Сработавшее оповещение публикует карточку инцидента во внутреннем чате. Затем фоновый обработчик собирает свежие стек-трейсы ошибок фронтенда из ClickHouse, активную версию конфигурации из сервиса конфигурации и логи деплоя Kubernetes и отправляет их структурированным промптом в корпоративный LLM API.
• Сводка прямо в треде. Бот отвечает вероятной первопричиной, например: конверсия на шаге 3 в Японии упала на 32 %, ошибка нулевого указателя в обёртке NFC-моста, изменение конфигурации выкачено за 15 минут до этого, а шлюз поставщика на бэкенде отвечает по таймауту.

Результат

Время обнаружения сократилось с часов или дней до менее чем 5 минут, время до смягчения — на 65 %, ложных оповещений стало на 80 % меньше. Также отслеживались соотношение сигнал/шум оповещений (доля, связанная с реальными инцидентами) и среднее время между отказами фронтенд-модулей.

Почему так

Обычное оповещение лишь сообщает, что что-то сломалось. Автоматический сбор данных и сводка сокращают разрыв между метрикой и человеком, который её понимает, — а именно там уходила большая часть времени реагирования.