Как сделать ИИ-агента для мониторинга и DevOps

Что получится в результате

Соберем ИИ-агента для мониторинга и DevOps, который помогает on-call инженеру быстрее разбирать инциденты: читает alerts, метрики, логи, deploy-события, runbooks и incident history, собирает контекст, формулирует гипотезы, предлагает безопасные проверки, готовит status update и postmortem draft.

Рабочая версия будет делать так:

1. настройки хранятся в `settings`;
2. сервисы хранятся в `service_catalog`;
3. окружения хранятся в `environments`;
4. владельцы и escalation хранятся в `oncall_roster`;
5. источники наблюдаемости хранятся в `observability_sources`;
6. alert rules хранятся в `alert_rules`;
7. активные alerts пишутся в `alert_inbox`;
8. обогащенные alerts пишутся в `alert_enrichment`;
9. метрики и PromQL-запросы пишутся в `metric_snapshots`;
10. логи пишутся в `log_samples`;
11. deploy-события пишутся в `deploy_events`;
12. runbooks хранятся в `runbook_catalog`;
13. безопасные команды хранятся в `safe_commands`;
14. опасные действия хранятся в `dangerous_actions`;
15. инциденты пишутся в `incident_queue`;
16. первичный разбор пишется в `triage_notes`;
17. гипотезы пишутся в `root_cause_hypotheses`;
18. status updates пишутся в `incident_updates`;
19. задачи на действия пишутся в `remediation_tasks`;
20. спорные и опасные действия уходят в `approval_queue`;
21. одобренные действия попадают в `execution_queue`;
22. черновики postmortem пишутся в `postmortem_drafts`;
23. итоги инцидентов хранятся в `incident_results`;
24. еженедельная сводка пишется в `weekly_devops_report`;
25. все решения пишутся в `audit_log`;
26. ошибки интеграций пишутся в `error_log`.

В первой версии агент не перезапускает production, не делает rollback, не меняет alert rules, не закрывает incident, не гасит alerts и не выполняет команды без подтверждения. Он собирает контекст и готовит действия, а on-call принимает решение.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для MVP-таблиц.
• Prometheus HTTP API для метрик и alerts.
• Grafana HTTP API для dashboards и ссылок на панели.
• PagerDuty API, Opsgenie, Grafana OnCall или другой incident manager.
• Источник логов: Loki, Elasticsearch, Datadog, CloudWatch или выгрузка логов.
• Список сервисов, владельцев и окружений.
• Runbooks по критичным alerts.
• Канал approval: Telegram, Slack, Teams или PagerDuty note.
• API-ключ LLM-провайдера.
• On-call инженер, который подтверждает production-действия.

Шаг 1. Выберите первый DevOps-сценарий

Не начинайте с “агент чинит production”. Для MVP выберите один безопасный сценарий.

Подходящие варианты:

1. обогащение alerts контекстом;
2. поиск runbook по alert;
3. сбор метрик и логов вокруг инцидента;
4. подготовка incident summary;
5. подготовка status update;
6. группировка связанных alerts;
7. postmortem draft после инцидента.

Самый безопасный старт: `alert -> сервис -> метрики -> логи -> deploys -> runbook -> triage note -> approval`.

Проверка: сценарий можно пройти на одном тестовом alert без изменения production.

Шаг 2. Запретите опасные действия

В первой версии запретите агенту:

1. перезапускать production-сервисы;
2. делать rollback;
3. менять Kubernetes deployments;
4. менять Terraform;
5. менять alert rules;
6. закрывать incident;
7. silencing alerts;
8. менять on-call escalation;
9. удалять логи;
10. выполнять shell-команды;
11. менять базы данных;
12. отправлять публичный status без approval.

Разрешите агенту:

1. читать alerts;
2. читать метрики;
3. читать логи с маскированием секретов;
4. читать runbooks;
5. читать deploy-события;
6. создавать triage note;
7. готовить status update draft;
8. готовить postmortem draft;
9. создавать remediation task;
10. отправлять опасные действия в approval.

Проверка: любое действие, которое меняет инфраструктуру, должно попадать в `approval_queue`.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу `devops_agent_mvp`.

Добавьте листы:

settings
service_catalog
environments
oncall_roster
observability_sources
alert_rules
alert_inbox
alert_enrichment
metric_snapshots
log_samples
deploy_events
runbook_catalog
safe_commands
dangerous_actions
incident_queue
triage_notes
root_cause_hypotheses
incident_updates
remediation_tasks
approval_queue
execution_queue
postmortem_drafts
incident_results
weekly_devops_report
audit_log
error_log

Проверка: названия листов совпадают один в один, потому что n8n будет обращаться к ним по имени.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description

Добавьте строки:

llm_model | gpt-4.1-mini | модель для triage и summary
max_logs_per_alert | 50 | лимит строк логов
metric_window_minutes | 30 | окно метрик вокруг alert
deploy_window_minutes | 120 | окно поиска deploy-событий
allow_production_actions | false | production-действия запрещены
allow_silence_alerts | false | silence только через approval
allow_incident_close | false | закрытие incident только человеком
approval_channel | telegram | канал согласований
report_channel | email | канал отчетов
mask_secrets | true | маскировать токены и пароли

Проверка: `allow_production_actions=false`, `allow_silence_alerts=false`, `mask_secrets=true`.

Шаг 5. Заполните service_catalog

В `service_catalog` добавьте колонки:

service_id
name
team
owner
criticality
slo
dashboard_url
runbook_id
status

Пример:

SVC-API | public-api | backend | backend-oncall | critical | 99.9 | https://grafana/d/api | RB-API-5XX | active
SVC-WEB | web-frontend | frontend | frontend-oncall | high | 99.5 | https://grafana/d/web | RB-WEB-LATENCY | active

Проверка: у критичного сервиса есть dashboard и runbook.

Шаг 6. Заполните environments

В `environments` добавьте колонки:

env_id
name
cluster
region
is_production
allowed_actions
status

Пример:

ENV-PROD | production | k8s-prod | ru-central | yes | read_only,approval_required | active
ENV-STAGE | staging | k8s-stage | ru-central | no | read_only,safe_checks | active

Проверка: production должен иметь `approval_required`.

Шаг 7. Заполните oncall_roster

В `oncall_roster` добавьте колонки:

roster_id
service_id
team
primary_oncall
secondary_oncall
escalation_channel
pagerduty_service_id
status

Пример:

ROSTER-API | SVC-API | backend | ivan | maria | #backend-oncall | PD-SVC-API | active

Проверка: агент знает, кого уведомлять при high и critical incidents.

Шаг 8. Заполните observability_sources

В `observability_sources` добавьте колонки:

source_id
source_type
api_slug
base_url
credential_ref
scope
status

Пример:

SRC-PROM | prometheus | prometheus-api | https://prometheus.example.com | n8n:prometheus | metrics,alerts | active
SRC-GRAF | grafana | grafana-http-api | https://grafana.example.com | n8n:grafana | dashboards,folders,alerts | active
SRC-PD | pagerduty | pagerduty-api | https://api.pagerduty.com | n8n:pagerduty | incidents,notes | active
SRC-LOKI | loki | loki-api | https://loki.example.com | n8n:loki | logs | active

Проверка: ключи хранятся в credentials, а не в таблице.

Шаг 9. Создайте alert_rules

В `alert_rules` добавьте колонки:

alert_rule_id
service_id
alert_name
severity
promql
threshold
for_duration
runbook_id
owner
status

Пример:

AR-API-5XX | SVC-API | High5xxRate | critical | rate(http_requests_total{status=~"5.."}[5m]) > 0.05 | 5% | 10m | RB-API-5XX | backend | active

Проверка: у каждого critical alert есть `runbook_id`.

Шаг 10. Создайте alert_inbox

В `alert_inbox` добавьте колонки:

alert_id
alert_rule_id
service_id
env_id
alert_name
severity
status
starts_at
ends_at
labels_json
annotations_json
source_url
created_at

Статусы:

firing
resolved
acknowledged
suppressed
unknown

Проверка: alert связан с сервисом и окружением.

Шаг 11. Подключите Prometheus HTTP API

Создайте workflow `DevOps Agent MVP`.

Добавьте узлы:

1. `Manual Trigger`;
2. `Read settings`;
3. `Read service_catalog`;
4. `Read alert_rules`;
5. `HTTP Request: Prometheus alerts`;
6. `Normalize alerts`;
7. `Write alert_inbox`;
8. `Write audit_log`.

Endpoint:

GET /api/v1/alerts

Проверка: в `alert_inbox` появились только active alerts, без изменения Prometheus.

Шаг 12. Создайте alert_enrichment

В `alert_enrichment` добавьте колонки:

enrichment_id
alert_id
service_id
dashboard_url
runbook_id
owner
related_alerts
recent_deploys
metric_summary
log_summary
risk_level
created_at

Проверка: enrichment не должен содержать секреты из логов.

Шаг 13. Создайте metric_snapshots

В `metric_snapshots` добавьте колонки:

snapshot_id
alert_id
service_id
metric_name
promql
window_start
window_end
value
baseline_value
change_percent
status
created_at

Минимальные метрики:

1. error rate;
2. latency p95;
3. request rate;
4. saturation;
5. CPU;
6. memory;
7. queue length;
8. dependency errors.

Проверка: LLM не считает метрики сама. Метрики считаются PromQL или monitoring API.

Шаг 14. Создайте log_samples

В `log_samples` добавьте колонки:

log_sample_id
alert_id
service_id
env_id
query
window_start
window_end
sample_json
masked
created_at

Правила:

1. маскируйте токены;
2. маскируйте email и телефоны, если они не нужны;
3. берите последние уникальные ошибки;
4. храните ограниченный sample;
5. не выгружайте полные production-логи в LLM.

Проверка: `masked=true` для production.

Шаг 15. Создайте deploy_events

В `deploy_events` добавьте колонки:

deploy_id
service_id
env_id
version
commit_sha
author
started_at
finished_at
status
deploy_url

Откуда брать deploy-события:

1. GitHub Actions;
2. GitLab CI;
3. Argo CD;
4. Kubernetes events;
5. manual deployment log.

Проверка: агент ищет deploys в окне `deploy_window_minutes`, но не делает вывод “deploy виноват” без evidence.

Шаг 16. Создайте runbook_catalog

В `runbook_catalog` добавьте колонки:

runbook_id
service_id
alert_name
title
symptoms
safe_checks
dangerous_actions
escalation_rules
source_url
owner
status

Пример safe checks:

проверить dashboard API; посмотреть 5xx по endpoint; проверить последний deploy; сравнить p95 latency; открыть логи с request_id

Проверка: у runbook есть безопасные проверки и список действий, которые нельзя выполнять без approval.

Шаг 17. Создайте safe_commands

В `safe_commands` добавьте колонки:

command_id
service_id
env_id
command_type
command_text
description
requires_approval
status

Примеры:

CMD-PROM-API-5XX | SVC-API | ENV-PROD | promql | rate(http_requests_total{service="api",status=~"5.."}[5m]) | проверить error rate | no | active
CMD-K8S-PODS | SVC-API | ENV-PROD | kubectl_read | kubectl get pods -n api | посмотреть состояние pod | yes | restricted

Проверка: даже read-only kubectl в production лучше держать через approval или отдельный безопасный proxy.

Шаг 18. Создайте dangerous_actions

В `dangerous_actions` добавьте колонки:

action_id
service_id
env_id
action_type
description
why_dangerous
required_approval
status

Примеры:

DA-ROLLBACK | SVC-API | ENV-PROD | rollback | откатить release | может усилить инцидент или потерять данные | primary_oncall | active
DA-RESTART | SVC-API | ENV-PROD | restart_service | перезапустить deployment | может вызвать downtime | primary_oncall | active
DA-SILENCE | SVC-API | ENV-PROD | silence_alert | заглушить alert | можно скрыть активную проблему | secondary_oncall | active

Проверка: агент не предлагает опасное действие как выполненное. Только draft + approval.

Шаг 19. Создайте incident_queue

В `incident_queue` добавьте колонки:

incident_id
alert_id
service_id
env_id
severity
title
status
impact
commander
created_at
resolved_at
incident_url

Статусы:

suspected
open
investigating
mitigating
resolved
closed
false_positive

Проверка: агент может предложить incident, но не закрывает его автоматически.

Шаг 20. Настройте prompt для incident triage

Prompt:

Ты DevOps incident assistant. Собери первичный разбор alert.

Правила:
1. Не выполняй production-действия.
2. Не называй root cause без evidence.
3. Разделяй факты, гипотезы и действия.
4. Используй runbook как главный источник действий.
5. Если данных мало, верни needs_more_data.
6. Опасные действия отправляй в approval.
7. Не назначай виновных.

alert:
{{$json.alert}}

metrics:
{{$json.metrics}}

logs:
{{$json.logs}}

deploys:
{{$json.deploys}}

runbook:
{{$json.runbook}}

Верни JSON:
{
  "status": "triaged | needs_more_data | needs_human",
  "facts": ["..."],
  "hypotheses": ["..."],
  "safe_checks": ["..."],
  "dangerous_actions": ["..."],
  "impact": "...",
  "recommended_next_step": "...",
  "approval_required": true
}

Проверка: root cause не появляется в facts, если нет доказательств.

Шаг 21. Создайте triage_notes

В `triage_notes` добавьте колонки:

triage_id
incident_id
alert_id
status
facts
hypotheses
safe_checks
impact
recommended_next_step
confidence
created_at

Проверка: `facts` и `hypotheses` должны быть разными полями.

Шаг 22. Создайте root_cause_hypotheses

В `root_cause_hypotheses` добавьте колонки:

hypothesis_id
incident_id
hypothesis
evidence
counter_evidence
confidence
status
created_at

Статусы:

open
confirmed
rejected
needs_data

Проверка: гипотеза не становится `confirmed` без evidence.

Шаг 23. Создайте incident_updates

В `incident_updates` добавьте колонки:

update_id
incident_id
audience
message
risk_level
status
reviewer
created_at
published_at

`audience`:

internal
support
customer_status
management

Проверка: внешние customer status updates всегда идут в approval.

Шаг 24. Создайте remediation_tasks

В `remediation_tasks` добавьте колонки:

task_id
incident_id
service_id
action_type
title
description
risk_level
owner
status
created_at

`action_type`:

safe_check
collect_logs
open_dashboard
escalate
rollback_candidate
restart_candidate
config_change_candidate
create_followup_bug

Проверка: `rollback_candidate`, `restart_candidate` и `config_change_candidate` отправляются в approval.

Шаг 25. Создайте approval_queue

В `approval_queue` добавьте колонки:

approval_id
source
source_id
action_type
action_text
risk_level
payload_json
approver
status
requested_at
approved_at
decision_comment

В approval отправляйте:

1. restart;
2. rollback;
3. scale up/down;
4. silence alert;
5. close incident;
6. change alert rule;
7. update dashboard;
8. run kubectl command;
9. change config;
10. publish external status update.

Проверка: `approval_queue.status` не может сразу быть `approved`.

Шаг 26. Сделайте Telegram approval

В n8n добавьте Telegram-узел после записи в `approval_queue`.

Сообщение:

DevOps Agent approval

Action: {{$json.action_type}}
Risk: {{$json.risk_level}}
Service: {{$json.service_id}}
Incident: {{$json.incident_id}}

{{$json.action_text}}

Approve: /approve {{$json.approval_id}}
Reject: /reject {{$json.approval_id}}
Escalate: /escalate {{$json.approval_id}}

Проверка: команда `/approve` меняет только одну строку по `approval_id`.

Шаг 27. Создайте execution_queue

В `execution_queue` добавьте колонки:

execution_id
approval_id
action_type
payload_json
status
executor
started_at
finished_at
result_url
error_message

В первой версии используйте `executor=manual`.

Проверка: агент не выполняет команду сам, даже если action approved.

Шаг 28. Подключите Grafana HTTP API

Для Grafana начните с read-only:

1. найти dashboard по service_id;
2. получить ссылки на панели;
3. получить alerting resources;
4. добавить dashboard_url в `alert_enrichment`.

Проверка: service account не имеет прав на изменение dashboards.

Шаг 29. Подключите PagerDuty API

Для PagerDuty начните с чтения и комментариев:

1. получить incidents;
2. получить alerts внутри incident;
3. получить service и escalation policy;
4. добавить note с triage draft только после approval или в тестовом режиме.

Проверка: агент не меняет incident status без approval.

Шаг 30. Создайте postmortem_drafts

В `postmortem_drafts` добавьте колонки:

postmortem_id
incident_id
summary
timeline
impact
detection
response
root_cause
contributing_factors
what_went_well
what_went_wrong
action_items
status
created_at

Правила:

1. не назначать виновных;
2. отделять confirmed root cause от hypotheses;
3. писать timeline по audit_log и incident_updates;
4. action items должны иметь владельцев;
5. спорные выводы отправлять на review.

Проверка: postmortem draft не становится финальным без человека.

Шаг 31. Создайте incident_results

В `incident_results` добавьте колонки:

result_id
incident_id
service_id
severity
mtta_minutes
mttr_minutes
customer_impact
root_cause_status
followup_tasks_count
closed_at

Проверка: MTTA и MTTR считаются по timestamps, а не формулируются LLM.

Шаг 32. Создайте weekly_devops_report

В `weekly_devops_report` добавьте колонки:

report_id
period
summary
incidents_count
critical_count
top_noisy_alerts
services_with_risk
missing_runbooks
followup_tasks
next_week_actions
status
created_at

Пример summary:

За неделю было 7 incidents, 1 critical. Главный источник шума - HighLatency на web-frontend, 14 срабатываний без customer impact. Для SVC-API не хватает runbook по dependency timeout. На следующей неделе: уточнить alert threshold, дописать runbook и закрыть 3 follow-up задачи.

Проверка: отчет заканчивается действиями на следующую неделю.

Шаг 33. Настройте audit_log

В `audit_log` добавьте колонки:

audit_id
run_id
actor
action
entity_type
entity_id
before_json
after_json
reason
created_at

Логируйте:

1. чтение alert;
2. сбор метрик;
3. сбор логов;
4. поиск runbook;
5. triage note;
6. создание incident update;
7. отправку в approval;
8. решение approval;
9. postmortem draft;
10. weekly report.

Проверка: по `audit_log` можно восстановить, почему агент предложил конкретное действие.

Шаг 34. Настройте error_log

В `error_log` добавьте колонки:

error_id
run_id
node_name
error_type
message
payload_sample
retry_count
status
created_at

Типы ошибок:

prometheus_api_error
grafana_api_error
pagerduty_api_error
logs_api_error
missing_runbook
missing_service_owner
invalid_json
secret_mask_failed
approval_required

Проверка: если не удалось замаскировать секреты в логах, данные не передаются в LLM.

Шаг 35. Протестируйте на одном alert

Добавьте тестовый alert:

ALERT-001 | AR-API-5XX | SVC-API | ENV-STAGE | High5xxRate | critical | firing | 2026-05-23T10:00:00Z | | {"endpoint":"/api/orders"} | {"summary":"5xx rate high"} | https://prometheus/alerts | 2026-05-23

Добавьте runbook `RB-API-5XX`, metric snapshot, 10 строк логов и один deploy event.

Запустите workflow только для `ALERT-001`.

Ожидаемый результат:

1. в `alert_enrichment` появился dashboard и runbook;
2. в `metric_snapshots` есть error rate и latency;
3. в `log_samples` логи замаскированы;
4. в `triage_notes` есть facts и hypotheses отдельно;
5. в `remediation_tasks` есть безопасные checks;
6. опасное действие ушло в `approval_queue`;
7. в `audit_log` есть все шаги;
8. в `error_log` нет ошибок.

Шаг 36. Проверьте негативные сценарии

Проведите проверки:

1. удалите runbook у critical alert;
2. убедитесь, что создана ошибка `missing_runbook`;
3. добавьте в лог токен;
4. убедитесь, что он замаскирован;
5. попробуйте restart production;
6. убедитесь, что действие ушло в approval;
7. передайте пустой ответ Prometheus;
8. убедитесь, что агент не делает вывод без метрик;
9. создайте external status update;
10. убедитесь, что он требует approval;
11. передайте невалидный JSON от LLM;
12. убедитесь, что workflow остановился и записал `invalid_json`.

Проверка: агент должен ускорять on-call, но не становиться неконтролируемым исполнителем в production.

Что нельзя автоматизировать в первой версии

Не автоматизируйте сразу:

1. restart production;
2. rollback;
3. изменение Kubernetes ресурсов;
4. изменение Terraform;
5. silence alerts;
6. закрытие incidents;
7. изменение alert rules;
8. изменение dashboards;
9. выполнение shell-команд;
10. публикацию внешнего status page;
11. изменение базы данных;
12. назначение виновных в postmortem.

Минимальный хороший MVP: агент читает один alert, собирает метрики, логи, deploys и runbook, делает triage note, предлагает безопасные checks, отправляет опасные действия в approval и готовит postmortem draft после закрытия incident.

Частые вопросы

Может ли DevOps-агент сам чинить production?

В первой версии не должен. Он может собрать контекст, предложить безопасные проверки и подготовить rollback или restart как candidate action, но выполнение должно идти через on-call и approval.

Что важнее подключить первым: метрики или логи?

Для MVP лучше начать с alerts и метрик Prometheus, потому что они дают структуру инцидента. Логи добавляйте сразу после этого, но ограничивайте sample и маскируйте секреты.

Нужен ли runbook для каждого alert?

Для critical и high alerts - да. Без runbook агент будет импровизировать. Для low alerts можно начать с owner, dashboard и базовых безопасных checks.

Можно ли давать агенту kubectl?

Только очень осторожно. В MVP лучше не давать прямой kubectl. Если нужен доступ, используйте read-only proxy, allowlist команд и approval даже для production read operations.

Что считать готовым результатом MVP?

MVP готов, если по одному alert агент собирает контекст, показывает runbook, разделяет facts и hypotheses, создает triage note, не выполняет production-действия, отправляет опасные шаги в approval и оставляет понятный `audit_log`.