Что получится
ИИ-агент для мониторинга и DevOps помогает разбирать alerts, искать связанные логи и метрики, открывать runbook, объяснять вероятную причину инцидента, готовить incident summary и предлагать действия on-call инженеру.
Главное ограничение: агент не должен сам перезапускать production, делать rollback, гасить alerts, менять правила мониторинга или закрывать incident без подтверждения человека.
Где агент полезен
- Incident triage: понять, что сломалось и где.
- Alert enrichment: добавить графики, логи и links.
- Runbook assistant: найти правильную инструкцию.
- On-call summary: коротко объяснить ситуацию.
- Noise reduction: сгруппировать похожие alerts.
- Postmortem draft: собрать timeline и факты.
- Status updates: подготовить текст для команды или status page.
- Monitoring hygiene: найти шумные или устаревшие alert rules.
Шаг 1. Выберите первый сценарий
Не начинайте с “агент сам чинит production”. Безопасный MVP - read-only помощник on-call.
Хороший старт:
- собрать контекст по alert;
- найти связанные метрики;
- найти последние ошибки в логах;
- открыть runbook;
- предложить вероятные причины;
- подготовить сообщение в Slack/Teams;
- создать incident summary.
Remediation-действия добавляйте позже и только через approval.
Шаг 2. Подключите мониторинг
Типичный стек:
- Prometheus для метрик и alert rules;
- Grafana для dashboards и alerting;
- PagerDuty для incidents и on-call;
- Loki, Elasticsearch или другой лог-хранилище;
- Kubernetes API;
- cloud monitoring;
- status page;
- GitHub Actions или CI/CD.
Для MVP достаточно Prometheus/Grafana/PagerDuty и одного источника логов.
Шаг 3. Настройте минимальные права
Агенту нужны read-only права:
- читать активные alerts;
- читать метрики;
- читать dashboards;
- читать logs;
- читать incidents;
- читать runbooks;
- читать deploy history.
Write-действия только через approval:
- добавить comment в incident;
- назначить responder;
- создать status update;
- запустить runbook action;
- сделать silence;
- перезапустить сервис;
- выполнить rollback.
На старте лучше вообще запретить действия, влияющие на production.
Шаг 4. Нормализуйте alert
Разные системы присылают alerts в разном формате. Агенту нужен единый объект.
{
"alert_name": "HighErrorRate",
"severity": "critical",
"service": "checkout-api",
"environment": "production",
"started_at": "2026-05-22T10:15:00Z",
"labels": {
"region": "eu",
"cluster": "prod-1"
},
"annotations": {
"summary": "5xx rate above threshold"
}
}Единая структура помогает группировать alerts, искать dashboards и связывать события.
Шаг 5. Соберите контекст
Для одного alert агент должен найти:
- сервис;
- владельца;
- severity;
- affected environment;
- последние deploys;
- связанные alerts;
- графики по метрикам;
- error logs;
- runbook;
- недавние incidents;
- текущий on-call.
Если контекста нет, агент должен честно сказать, чего не хватает.
Шаг 6. Подключите runbooks
Runbook - основа безопасного DevOps-агента. Без него модель будет импровизировать.
В runbook храните:
- описание alert;
- возможные причины;
- первые проверки;
- команды диагностики;
- безопасные действия;
- опасные действия;
- кто владелец сервиса;
- когда эскалировать;
- ссылки на dashboards.
Агент должен сначала искать runbook, а не придумывать remediation.
Шаг 7. Работайте с логами аккуратно
Логи могут содержать персональные данные, токены, payload и секреты.
Правила:
- маскировать tokens, emails, phones и payment data;
- ограничивать период;
- ограничивать количество строк;
- показывать агрегаты и примеры, а не полный dump;
- не отправлять secrets в модель;
- логировать, какие источники были использованы.
Для incident triage обычно достаточно последних ошибок и статистики по кодам.
Шаг 8. Объясняйте причину как гипотезу
Агент не должен уверенно заявлять root cause без проверки.
Формат:
- что известно;
- какие метрики изменились;
- какие логи появились;
- что было задеплоено;
- вероятная гипотеза;
- что проверить дальше;
- ссылка на runbook;
- кого позвать.
Причинность должна быть осторожной: “похоже связано с deploy X” лучше, чем “deploy X сломал сервис”, пока нет подтверждения.
Шаг 9. Настройте approval для действий
Если агент предлагает действие, показывайте карточку:
- действие;
- цель;
- сервис;
- окружение;
- риск;
- ожидаемый эффект;
- rollback plan;
- кто подтверждает;
- ссылка на runbook.
Действия вроде restart, scale, rollback, silence и rule change не выполняются без подтверждения on-call.
Шаг 10. Создайте incident updates
Агент может готовить обновления:
- для внутреннего канала;
- для status page;
- для менеджеров;
- для postmortem.
Шаблон:
- что произошло;
- какие пользователи затронуты;
- что уже проверено;
- что делаем сейчас;
- когда будет следующее обновление.
Публичные сообщения должны проходить через человека.
Шаг 11. Подготовьте postmortem draft
После инцидента агент может собрать:
- timeline;
- alerts;
- deploys;
- действия on-call;
- изменения статуса;
- impact;
- links на dashboards;
- гипотезы;
- открытые вопросы;
- follow-up tasks.
Он не должен назначать виновных. Цель postmortem - обучение и улучшение системы.
Шаг 12. Протестируйте на учебных инцидентах
Соберите сценарии:
- высокий error rate;
- latency spike;
- база недоступна;
- диск заполнен;
- memory leak;
- упал deploy;
- alert storm;
- ложный alert;
- нет runbook;
- пользователь без прав просит restart.
Проверяйте, что агент не выполняет опасные действия без approval и не раскрывает secrets из логов.
Минимальная архитектура
ИИ-агент для мониторинга и DevOps состоит из восьми блоков.
- Monitoring connector: Prometheus, Grafana, cloud metrics.
- Incident connector: PagerDuty, Opsgenie или аналог.
- Logs connector: Loki, Elasticsearch, cloud logs.
- Runbook index: инструкции, владельцы, dashboards и escalation.
- Context builder: alerts, metrics, logs, deploys и incidents.
- Reasoning layer: hypotheses, checks и next steps.
- Action layer: comments, status updates, runbook actions через approval.
- Audit layer: запросы, источники, proposed actions, approvals и timeline.
Модель помогает связать факты. Production-действия контролирует on-call и policy layer.
Частые вопросы
Можно ли агенту самому перезапускать сервис?
Для первой версии нет. Перезапуск production-сервиса должен подтверждать on-call. Агент может предложить действие и показать риск.
Что важнее: alerts или runbooks?
Alerts говорят, что что-то случилось. Runbooks говорят, что делать дальше. Для DevOps-агента runbook почти обязательный источник.
Можно ли отправлять логи в модель?
Можно только после фильтрации и маскирования. Не отправляйте токены, персональные данные, payload с платежами и большие dumps.
Как избежать alert noise?
Группировать связанные alerts по сервису, окружению, времени и labels. Агент может делать summary alert storm, но правила alerting лучше менять через review.
Что автоматизировать первым?
Alert enrichment, поиск runbook, summary для on-call и postmortem draft. Remediation-действия добавляйте позже через approval.
