AI в DevOps: новый уровень мониторинга и observability

В последние годы Large Language Models (LLMs), такие как GPT и DeepSeek, стали универсальными помощниками — от генерации кода до объяснения сложных концепций. Однако их потенциал только начинает раскрываться в сфере DevOps, особенно в области наблюдаемости и устранения инцидентов.

Почему классический мониторинг уже не справляется?

В типичной системе наблюдаемости у нас есть метрики, логи и трейсы. Они собираются, визуализируются в красивых дашбордах, а дальше — вы сами. Даже с мощными инструментами типа Grafana, Prometheus или Loki, DevOps-инженер всё ещё вынужден вручную:

👉 анализировать причинно-следственные связи между событиями;
👉 копаться в корреляциях между spike'ами CPU и сетевыми аномалиями;
👉 искать аномальные запросы к базе в миллионах строк логов.

Это требует экспертизы и времени. А теперь представьте систему, которая сама интерпретирует все эти сигналы, объясняет, что пошло не так, и предлагает конкретные действия по исправлению.

Где вступает AI?

AI, обученный на технических данных, может:

👉 читать дашборды как человек;
👉 понимать паттерны нагрузки и выявлять отклонения;
👉 предполагать причину сбоя (например, блокирующий ALTER TABLE в PostgreSQL),
👉 советовать пошаговые действия: от SELECT pg_stat_activity до применения pg_repack.

Как это работает на практике?

Один из самых перспективных сценариев — это последний этап troubleshooting: когда ты уже знаешь, какой сервис глючит, но всё ещё неясно, почему именно.

Тут и подключается LLM:

➡️ Ввод: скриншот метрик, описание ошибки, лог-фрагмент.
⬅️ Вывод: понятное объяснение того, что происходит, какие метрики важны, какие запросы блокируют работу, и что с этим делать.

OpenAI vs DeepSeek: тест в боевых условиях

Интересный кейс опубликовала команда Coroot, работающая над платформой наблюдаемости. Они провели эксперимент, скармливая LLM реальные скриншоты с графиками PostgreSQL-нагрузки после проблемного запроса ALTER TABLE ... SET NOT NULL.

Результат?

🔵 GPT-4o не просто «прочитал» графики, а выдал диагноз, причину и рекомендации по исправлению (включая pg\_repack, lock timeout и рекомендации по миграциям).
🔵 DeepSeek-R1 выдал почти идентичный анализ — с адекватными SQL-командами и предостережениями.

Важно: всё это — без телеметрии, только по скрину с графиками.

Значит ли это, что AIOps наступил?

Да, если вы уже собираете достаточно данных — метрик, логов, трассировок. Потому что магия AI не в угадывании, а в понимании контекста и построении цепочки: симптом → причина → действие.

Почитать подробнее:

📚 Using AI for Troubleshooting: OpenAI vs DeepSeek (Coroot blog). Статья демонстрирует живой пример использования AI в DevOps-наблюдаемости, с реальными данными и точными выводами.

🎓 Лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации — на воркшопе «AI в DevOps» 5 июля. Подробности — в боте.