Natural language query через весь observability стек

Что делает автоматизация

AI-агент работает единой точкой входа в весь observability-стек. Инженер пишет вопрос в Slack, веб-чат или через CLI — агент разбирает намерение, обращается к нужным источникам через MCP-коннекторы, собирает данные и возвращает ответ с прямыми ссылками на dashboards и лог-строки.

Конкретные сценарии

1. Диагностика инцидента. «Что изменилось за последние 30 минут?» — агент собирает deploy events, alert history, аномальные метрики, возвращает хронологический ответ.
2. Поиск корневой причины. «Почему 500-е выросли на checkout-service?» — агент ищет по error logs, связывает с недавними коммитами, показывает trace с самым длинным span.
3. Контекст для on-call. «Что сейчас горит?» — агент агрегирует открытые инциденты, SLO burn rate, последние релизы.
4. Отчёты для stakeholders. «Собери статус для еженедельного синка» — агент формирует черновик по SLO, uptime, инцидентам, ключевым метрикам.
5. Онбординг инженера. «Как устроен payment-flow?» — агент объясняет по коду, docs, трейсам.

Особенность: агент не просто агрегирует данные, а связывает их контекстно. Запрос про checkout автоматически подтягивает и метрики, и логи, и последние коммиты в соответствующий сервис.

Что НЕ делает автоматизация

Грани важно провести сразу:

• Не заменяет дежурных инженеров. Агент даёт гипотезы, решения принимает человек.
• Не чинит инциденты. Агент не запускает runbooks и не делает деплой — только читает.
• Не заменяет алертинг. PagerDuty, Opsgenie, Sentry продолжают работать как раньше.
• Не даёт 100% точных ответов. Галлюцинации возможны — агент всегда возвращает источники для проверки.
• Не мигрирует стек. Все существующие инструменты остаются на месте, агент работает поверх.

Типичные варианты настройки

Solo / команда 1–5 человек. Минимальная сборка: подключить 2–3 ключевых источника — обычно логи, мониторинг и git. Агент отвечает в одном Slack-канале или через CLI. Для маленькой команды окупается за счёт экономии времени основателя-инженера, который отвечает за всё сразу. Настройка — один выходной, без сложной ролевой модели. Достаточно языковой модели через API и простой RAG-индекс. Ограничение: если источников больше пяти, без structured routing начинаются галлюцинации. На этом уровне проще держать фокус на одном кластере и одном типе инцидентов.

SMB / команда 6–30 человек. Полноценный observability-агент: 5–8 источников (logs, metrics, traces, errors, git, CI/CD, incident management, docs). Agent router по типу запроса, отдельные MCP-серверы для каждого источника. Ответы в Slack с разметкой по командам (backend, frontend, data). Добавляется audit log и role-based access для prod vs staging. На этом уровне появляется смысл в fine-tuning prompt templates под специфику стека. Типичная экономия — часы в неделю на команду за счёт исчезновения hunt-and-peck между консолями.

Enterprise / команда 30+ человек. Мульти-агентная архитектура: специализированные агенты для Kubernetes, database, security, networking. Центральный router определяет, к какому агенту направить запрос. Интеграция с внутренним каталогом сервисов, compliance-фильтры (PII, secrets), отдельный tenant на команду. Нужна dedicated группа поддержки (2–3 инженера) и ощутимый бюджет на LLM-токены. ROI — не столько экономия времени, сколько снижение MTTR на критичных инцидентах и ускорение онбординга новых команд в большой структуре.

Как это работает

Технически автоматизация — это компоновка из четырёх слоёв.

1. Интерфейс — Slack-бот, веб-чат или CLI. Инженер пишет вопрос на естественном языке.
2. Маршрутизатор запросов — LLM-оркестратор определяет, какие источники нужны для ответа, какие фильтры применить, нужен ли follow-up.
3. MCP-коннекторы к источникам данных — отдельный коннектор для каждого инструмента: logs, metrics, traces, errors, git, docs.
4. Синтезатор ответа — LLM собирает данные из источников, объясняет связи, возвращает ответ со ссылками на исходные данные.

Пошаговый flow

Для типичного вопроса «почему латенси чекаута вырос после 14:07?» агент делает следующее:

1. Парсит намерение: это root cause analysis по конкретному сервису и окну времени.
2. Определяет нужные источники: metrics (latency), logs (error patterns), deploy history (что менялось), traces (какой span тормозит).
3. Формирует параллельные запросы через MCP-коннекторы к каждому источнику.
4. Собирает результаты, находит пересечения — например, deploy в 14:06 → рост latency на p95 checkout-service → в логах ошибка DB timeout → trace показывает медленный query в new feature flag.
5. Генерирует связный ответ: гипотеза + доказательства + ссылки + предложение следующего шага.

Весь цикл занимает секунды вместо минут ручного hunt-and-peck.

Роль LLM

языковая модель — ключевой компонент. Его сильные стороны для этой задачи:

• Длинный контекст позволяет одновременно анализировать выдержки из 5+ источников без перегрузки.
• Хорошая работа с tool use — MCP-коннекторы вызываются через структурированные tool calls без парсинга свободного текста.
• Способность к chain-of-thought reasoning для сложных корреляций между метриками и событиями.
• Аккуратное обращение со ссылками — агент возвращает источники, а не додумывает.

MCP-коннекторы

Model Context Protocol (MCP) — стандарт подключения LLM к внешним источникам. Для observability-сценария типичный набор коннекторов:

• logs-mcp — читает лог-агрегатор (Loki, Elastic, CloudWatch Logs).
• metrics-mcp — PromQL/Prometheus и/или Grafana API.
• traces-mcp — Tempo, Jaeger или OpenTelemetry-совместимый бэкенд.
• errors-mcp — Sentry, Rollbar, Honeybadger.
• git-mcp — истории коммитов и deploy events.
• docs-mcp — внутренние runbooks, Notion, Confluence.

Каждый коннектор — отдельный процесс с read-only доступом и собственным rate limit.

Альтернативные подходы

Ручной разбор работает, пока команда маленькая и стек простой. Когда источников больше трёх и инженеров больше пяти, каждый инцидент превращается в охоту за контекстом. No-code решения от вендоров хорошо работают внутри своей экосистемы, но плохо соединяют разные источники — а реальный observability-стек обычно собран из нескольких инструментов разных поставщиков. AI-автоматизация на MCP работает поверх того, что уже есть, и не требует мигрировать на один vendor-стек. Минус — нужна внутренняя экспертиза для настройки и мониторинга качества ответов.

Безопасность и compliance

Observability-данные часто содержат чувствительную информацию: PII в логах, tokens, внутренние URL. Три базовых требования к setup-у:

1. Read-only доступ. Агент не должен иметь прав на изменение данных или на запуск runbooks. Только чтение через API-токены с минимальными scope-ами.
2. Фильтрация на уровне коннектора. PII-редактирование и маскирование secrets до того, как данные попадают в LLM-контекст.
3. Audit log. Все запросы и ответы логируются — для разбора инцидентов и для compliance (SOC 2, GDPR, HIPAA по необходимости).

Если команда работает с персональными данными пользователей, используйте LLM-провайдера с политикой zero retention (AI-модель через Anthropic API это поддерживает) либо self-hosted инференс для чувствительных контуров.

Что нужно заранее

Перед запуском агента соберите инфраструктуру и команду.

Технические предпосылки

1. Список observability-источников. Какие инструменты используются: Grafana, Datadog, Sentry, CloudWatch, Prometheus, что-то ещё. Минимум два источника — иначе агент превращается в обёртку над одним API.
2. API-токены с read-only scope. Для каждого источника отдельный токен. Без прав на запись, без admin-привилегий.
3. MCP-коннекторы. Либо готовые (для популярных инструментов они есть), либо написать свои — день-два работы на инструмент.
4. LLM-провайдер. LLM через Anthropic API — рабочий дефолт благодаря длинному контексту и качественному tool use.
5. Канал доступа. Slack, Microsoft Teams, веб-чат или CLI — где команда будет задавать вопросы. Slack — типичный выбор.
6. Sandbox на pre-prod. Протестировать запросы и ответы две недели, прежде чем дать доступ всей команде.

Роли и ответственность

• DevOps / SRE lead — настраивает MCP-коннекторы, валидирует доступы.
• Tech lead — определяет типы вопросов, собирает feedback по качеству ответов.
• Security — ревьюит compliance-настройки, PII-фильтры, audit log.
• Product engineer — адаптирует prompt templates под специфику команды.

Возможные подводные камни

• Галлюцинации без источников. Если не настроить обязательную выдачу ссылок на исходные данные, агент начинает фантазировать цифры и events. Фикс: требовать в system prompt показывать источник каждого факта, отвергать ответы без ссылок.
• Перегрузка контекста. Если тащить в LLM весь лог за последний час, контекст забивается и ответы деградируют. Фикс: фильтрация на уровне коннектора, только релевантные фрагменты попадают в LLM.
• Фантомные корреляции. Агент может найти «связь» между двумя случайными событиями. Фикс: явно просить гипотезы, а не утверждения, добавлять confidence score, валидировать на регрессионном наборе запросов.
• Секреты в контексте. API-ключи, tokens, passwords из логов попадают в LLM-промпт. Фикс: regex-фильтры на коннекторе + политика zero retention у LLM-провайдера + ротация скомпрометированных ключей при утечке.
• Дрейф качества. Через месяц источники меняются, схемы логов эволюционируют — ответы деградируют без видимых ошибок. Фикс: еженедельный sample review 10–20 запросов, регрессионные тесты на типовые сценарии, алерт на падение confidence.