Проще говоря, агент получает alert, находит сервис, окружение, владельца, dashboard, последние метрики, связанные логи, недавние deploy-события, похожие incidents и нужный runbook. После этого он готовит triage note: что затронуто, насколько критично, какие факты есть, каких данных не хватает и что on-call может проверить дальше.
Хороший DevOps-агент работает с явными объектами: `service_catalog`, `alert_inbox`, `metric_snapshots`, `log_samples`, `deployment_events`, `runbook_index`, `incident_queue`, `triage_notes`, `root_cause_hypotheses`, `incident_updates`, `remediation_tasks`, `approval_queue`, `postmortem_drafts`, `weekly_devops_report` и `audit_log`.
Главное ограничение: агент не должен сам перезапускать production, делать rollback, менять alert rules, закрывать incident, silencing alerts, удалять логи, менять on-call escalation, выполнять `kubectl` или shell-команды без подтверждения. В первой версии он собирает контекст, формулирует гипотезы и готовит действия, а решение принимает человек.
Для мониторинга агент обычно читает Prometheus или cloud metrics, открывает Grafana dashboards, берет логи из Loki, Elasticsearch, Datadog или CloudWatch, проверяет deploy history и добавляет заметки в PagerDuty, Opsgenie или другой incident manager. Начинать безопаснее с read-only доступа.
DevOps-агент особенно полезен там, где alert сам по себе слишком бедный. Например, `High5xxRate` говорит только о росте ошибок, а агент добавляет: какой endpoint пострадал, была ли выкладка, какие ошибки появились в логах, есть ли похожий incident, кто владелец сервиса и какой runbook открыть.
Важно, чтобы агент не выдавал гипотезы как факты. Правильный формат: факты, гипотезы, evidence, counter-evidence, missing data, safe checks и risky actions. Если метрик или логов недостаточно, агент должен прямо сказать, чего не хватает.
После инцидента агент может подготовить postmortem draft: timeline, impact, detected_at, mitigated_at, suspected cause, что сработало, что не сработало, follow-up tasks и владельцы. Финальный разбор должна подтверждать команда, потому что postmortem влияет на процессы и ответственность.
Минимальный хороший MVP: агент читает один тип alert, собирает метрики, логи, deploys и runbook, пишет triage note, предлагает только безопасные проверки, отправляет опасные действия в approval и оставляет audit log по каждому источнику и выводу.
Примеры
- Prometheus присылает alert High5xxRate. Агент находит сервис, последние deploy-события, логи с 500 ошибками, Grafana dashboard и runbook, затем готовит triage note для on-call.
- PagerDuty incident открыт ночью. Агент собирает факты, предлагает status update для внутреннего канала и помечает rollback как действие, требующее approval.
- После деплоя выросла latency. Агент сравнивает метрики до и после deploy, показывает affected endpoints и предлагает безопасные проверки без изменения production.
- У alert нет runbook. Агент фиксирует missing_runbook, предлагает владельца сервиса и создает follow-up задачу после инцидента.
- После восстановления агент готовит postmortem draft по audit log, incident updates, метрикам и действиям команды.
Где используется
- alert enrichment
- incident triage
- поиск связанных логов и метрик
- поиск runbook по alert и сервису
- объяснение падения сервиса как гипотезы
- подготовка safe checks для on-call
- status update для incident channel
- создание remediation tasks
- approval для risky actions
- postmortem draft после инцидента
- еженедельный отчет по incidents и noisy alerts
- контроль audit log и forbidden actions
Связанные термины
Частые вопросы
Что делает ИИ-агент для DevOps?
Он помогает on-call инженеру быстрее разобрать alert: собирает метрики, логи, deploy history, runbook, похожие incidents и готовит triage note, status update или postmortem draft. Опасные действия должны подтверждаться человеком.
Можно ли агенту самому чинить production?
В первой версии нет. Перезапуск сервисов, rollback, изменение alert rules, закрытие incident, silencing alerts и выполнение команд должны идти через approval. Агент может предложить действие и объяснить риск, но не выполнять его сам.
С чего начать внедрение DevOps-агента?
Начните с одного частого alert и read-only доступа к Prometheus, Grafana, логам и runbook. Проверьте, что агент корректно собирает контекст, не придумывает причину и явно разделяет факты, гипотезы и missing data.
Нужен ли runbook для каждого alert?
Для критичных alerts - да. Без runbook агент будет больше рассуждать и чаще ошибаться. Хороший runbook задает безопасные проверки, владельца сервиса, опасные действия и правила эскалации.
Какие данные нельзя передавать агенту без фильтрации?
Нельзя бездумно передавать секреты, токены, приватные ключи, персональные данные, полные production-логи и конфиги с доступами. Логи нужно сэмплировать и маскировать, а права API держать минимальными.
