Алертинг у нас построен на правилах Grafana. Сами правила описаны в Terraform, хранятся в Git и применяются через CI/CD-пайплайн. Такой подход даёт review, историю изменений и воспроизводимую конфигурацию вместо ручного редактирования правил в интерфейсе.
Дальше Grafana Alertmanager маршрутизирует уведомления по labels в несколько каналов внутреннего Mattermost. За этими каналами следит дежурная смена. В Grafana также есть отдельная доска, которая выводит активные алерты списком. Она помогла видеть общую картину, но не решила вопрос, что происходит с каждым алертом после доставки.
Во время всплеска нужное сообщение иногда теряется среди десятков похожих. Некоторые алерты горят неделю, а обновления по ним появляются раз в несколько дней и каждый раз начинаются почти с нуля, как будто сигнал пришёл только что. Дежурные меняются и не всегда помнят, разбирали ли этот алерт раньше, занимается ли им другой инженер и кто сейчас ведёт исправление — инфраструктура или команда разработки. Получается своеобразная карусель: алерт продолжает гореть, люди меняются, а контекст приходится восстанавливать заново.
В статье описан подход, при котором вокруг Grafana построен операционный слой: единая карточка алерта, назначение владельца, история повторных срабатываний, автогруппировка связанных алертов, метрики MTTA/MTTR и автоматическая подготовка postmortem с использованием LLM. При этом AI не принимает решений, а только помогает анализировать уже собранные данные — вся логика жизненного цикла алерта остается детерминированной.
Очередное напоминание о том, что наблюдаемость — это не только сбор метрик, но и грамотно организованный процесс реагирования на инциденты.
Читать на Хабре.
📱 Telegram | 📲 MAX