Как мы автоматизируем поиск первопричин инцидентов
В 3 ночи падает latency на API-gateway. Дежурный открывает Grafana — там красные всё: и CPU на нодах, и time_wait сокеты, и error rate на трёх микросервисах одновременно. Что первопричина? Обычно инженер тратит 20–40 минут на ручную корреляцию метрик, логов и трейсов, прежде чем найти виновный компонент. Мы внедрили AIOps RCA (Root Cause Analysis) для двух десятков клиентов и сократили это время до 2–5 минут — именно столько нужно системе, чтобы построить цепочку от симптома к корню. AIOps RCA — ключевой инструмент для современной observability. Автоматический RCA сокращает время поиска первопричины в 4–8 раз по сравнению с ручной корреляцией.
Почему ручная корреляция не масштабируется
При 10 микросервисах держать в голове граф зависимостей ещё реально. При 50+ — нет. Типичный инцидент выглядит так: Prometheus показывает рост http_server_duration_seconds_bucket у сервиса order-service. Казалось бы, проблема там. Но на самом деле order-service замедлился из-за inventory-service, который упёрся в тайм-аут к PostgreSQL, который начал деградировать из-за autovacuum на большой таблице после batch-импорта. Цепочка причин проходит через 3 сервиса и одну БД.
Автоматический RCA строит граф зависимостей на основе трейсов (Jaeger, Tempo, AWS X-Ray), метрик и топологии — и идёт по цепочке к первопричине, а не застревает на симптоме.
Как работает автоматический RCA на практике?
Ключевой компонент — topology-aware correlation. Системе нужно знать, какой сервис от какого зависит. Это получается из нескольких источников:
- Distributed traces в Jaeger/Tempo — там явно видны parent_span_id и child_span_id, по ним строится граф вызовов;
- Service mesh (Istio, Linkerd) — автоматически собирает топологию без изменений в коде;
- CMDB/Service Catalog — ручной источник для legacy-компонентов без трейсинга.
Dynatrace Davis AI
Наиболее зрелое коммерческое решение. Davis автоматически строит smartscape топологию (процессы, хосты, сервисы, приложения), корреллирует события и выдаёт Problem с указанием root cause компонента. По данным вендора Dynatrace, Davis AI правильно определяет root cause в 95% случаев. На практике по нашему опыту точность составляет ~70–80% — остальные 20% требуют уточнения инженером.
OpenTelemetry + собственный RCA-движок
Собираем трейсы через OTel Collector в Tempo, метрики в Prometheus, логи в Loki — весь стек в Grafana. Корреляцию делаем через Grafana Asserts (бывший Asserts.ai, теперь часть Grafana Labs). Конфиг asserts-config.yaml описывает правила корреляции между assertion-events.
Elastic Observability
Для команд, которые уже на стеке ELK/Elastic: умеет связывать APM traces, logs и metrics в единый view по trace.id и transaction.id. Это не полноценный автоматический RCA, но значительно ускоряет ручной поиск — примерно в 3–5 раз по нашим замерам.
Что реально автоматизируется, а что нет
Автоматический RCA хорошо работает для:
- Каскадных сбоев по цепочке зависимостей;
- Деградации после деплоя (сравнение before/after по метрикам);
- Ресурсных проблем (CPU/memory saturation на конкретном хосте).
Плохо работает для:
- Проблем в сетевом оборудовании без мониторинга (SNMP, Flow);
- Логических ошибок в коде, которые не проявляются в стандартных метриках;
- Внешних зависимостей (третий-party API, DNS-провайдер).
Поэтому задача настройки AIOps RCA — не убрать инженера из процесса, а дать ему правильный стартовый контекст. Получить точку входа за 2 минуты вместо 20 — это уже огромный выигрыш для MTTR.
Сравнение инструментов AIOps RCA
| Инструмент | Тип | Точность (наш опыт) | Время внедрения | Требования к данным |
|---|---|---|---|---|
| Dynatrace Davis AI | Коммерческий | ~75% | 2–3 недели | Агенты Dynatrace на всех узлах |
| Grafana Asserts | Open Source | ~60% | 3–6 недель | OpenTelemetry, Prometheus, Loki |
| Elastic Observability | Коммерческий | ~50% (ручная помощь) | 1–2 недели | Elastic APM + Beats |
Свяжитесь с нами, чтобы получить детальное сравнение инструментов для вашего стека.
Типичные ошибки при внедрении и как их избежать
| Ошибка | Последствие | Решение |
|---|---|---|
| Отсутствие трейсинга | RCA превращается в шум | Внедрить OpenTelemetry как обязательный этап |
| Слишком низкие пороги чувствительности | Alert-storm | Калибровать пороги на исторических данных |
| Неполное покрытие сервисов | Граф зависимостей неполный, RCA пропускает цепочки | Покрыть все критические сервисы трейсингом |
Процесс внедрения
- Аудит observability — проверяем покрытие трейсингом, метриками и логами. Если сервисы не инструментированы OpenTelemetry или проприетарными агентами — RCA будет работать только на метриках, без понимания цепочки вызовов. Внедрение трейсинга — отдельный этап, часто занимает больше времени, чем сам RCA-движок.
- Выбор инструмента — под ваш стек и бюджет. Мы помогаем сравнить Dynatrace, Grafana Asserts и Elastic по критериям точности и стоимости лицензий.
- Настройка topology discovery — подключение источников топологии (traces, service mesh, CMDB).
- Калибровка порогов — задаём правила корреляции и чувствительность, чтобы снизить число false positives.
- Тестирование на исторических инцидентах — прогоняем 10–20 реальных кейсов, корректируем.
- Запуск в промышленную эксплуатацию — обучаем команду работе с новыми дашбордами и runbook.
Что входит в работу
- Письменный отчёт по аудиту observability-инфраструктуры;
- Рекомендация по инструменту RCA (Dynatrace / Grafana / Elastic);
- Настройка topology discovery и правил корреляции (до 50 сервисов);
- Калибровка порогов и тест на исторических инцидентах;
- Runbook для дежурной смены;
- 2 часа обучения команды.
Сроки и как начать
Внедрение занимает от 2 до 6 недель в зависимости от зрелости observability. Стоимость рассчитывается индивидуально после аудита. Закажите аудит observability сегодня — мы расскажем, какой инструмент RCA подходит вашему стеку, и спрогнозируем экономию времени на инцидентах. Просто напишите нам, чтобы получить оценку проекта.
