Как мы учили ИИ тушить инциденты вместо нас (что из этого вышло) / Хабр

Привет, меня зовут Артем, я тимлид DevOps в одной аутстафф-компании. Столкнулись с классической ситуацией: десятки микросервисов, Kubernetes, куча observability-стека (Prometheus, Loki, Tempo, Grafana) и... постоянные ночные инциденты. «High CPU», «Pod CrashLoopBackOff», «5xx errors rising».

У нас есть runbooks, документация, скрипты для быстрого доступа к логам. Но в 3 ночи, когда срабатывает критический алерт, тратишь время на то, чтобы проснуться, сообразить, куда залогиниться и какую команду выполнить… Мы задались вопросом: а если первым на инцидент будет реагировать не человек, а ИИ-агент?

Боль, которую мы хотели решить:

Время реакции: Сократить Time To Acknowledge (TTA) с 10-15 минут до мгновенного.
Выгорание: Убрать необходимость вскакивать среди ночи по каждому мелкому, но шумному алерту (вспомните алерт по порогу в 85% CPU, который срабатывает каждую ночь).
Ошибки: Избежать человеческих ошибок в спешке (например, запуска kubectl delete pod вместо kubectl describe pod).

Что мы сделали:

Мы решили не строить сложную самоисцеляющуюся систему. Мы начали с малого - с ChatOps-бота с мозгом из GPT-4 API.

Архитектура нашего ночного дежурного:

Alertmanager (наш диспетчер алертов) вместо PagerDuty/Opsgenie стал слать вебхуки не людям, а нашему внутреннему сервису-адаптеру.
Адаптер (написанный на Python) структурировал алерт: имя, severity, метки (labels), аннотации (к where ссылке на дашборду Grafana).
Сердце системы - агент на LLM. Адаптер формировал для LLM промпт, который выглядел так:

Ты - Senior DevOps инженер. Получен алерт в продовой среде.
Контекст: Kubernetes кластер, observability стек (Prometheus, Loki, Grafana).
Алерт: {название_алерта}.
Детали: {метки_алерта: namespace, pod, service}.
Ссылка на дашборду для диагностики: {ссылка}.

Инструкции:
1.  Сначала оцени критичность. Если это 'warning' и связано с утилизацией CPU/RAM ниже 90% — это низкий приоритет.
2.  Сгенерируй конкретные, исполнимые команды kubectl/helm/grep для диагностики. Например: "kubectl -n {namespace} logs {pod_name} --tail=50 | grep -i error".
3.  Предположи возможную причину на основе названия алерта (например, 'High Memory Usage' -> возможна утечка памяти или недостаточно limits).
4.  Если алерт 'critical' и связан с 'Http5xxErrors' — предложи немедленные действия: проверить endpoint, перезапустить pod.

Ответ дай строго в формате JSON:
{
  "priority": "high/low",
  "diagnosis_steps": ["шаг1", "шаг2"],
  "immediate_commands": ["команда1", "команда2"],
  "likely_cause": "текст"
}

⠀⠀

Telegram-бот получал этот JSON и публиковал сообщение в наш операционный канал:

« Получен алерт: PodCrashLoopBackOff в namespace payment.
Приоритет: HIGH
Вероятная причина: Ошибка при старте приложения, проверь логи на предмет исключений.
Что выполнить:
kubectl -n payment logs payment-service-abcd1234 --previous
kubectl -n payment describe pod payment-service-abcd1234».

Честные результаты и грабли, на которые мы наступили:

Что сработало:

Мелкие инциденты тушились сами. Алерт на высокий процент ошибок в конкретном эндпоинте? Бот сразу предлагал команду для проверки логов и деплоймента этого сервиса. Time To Restore (TTR) для таких случаев упал с ~40 минут до ~10.
Контекст в один клик. Больше не надо было искать, в каком неймспейсе упал под. Бот давал готовую команду. Это экономило когнитивную нагрузку.
Обучение джуниоров. История сообщений бота стала отличной базой знаний: по каждому инциденту был зафиксирован предполагаемый путь диагностики.

С чем столкнулись (важно):

1. Галлюцинации в командах. Однажды бот в предложенной команде использовал несуществующий флаг --container-name вместо -c.

Вывод: все команды от ИИ должен проверять и подтверждать человек перед запуском. Мы внедрили кнопки «Выполнить» рядом с каждой командой в том же Telegram, которая шла на отдельный валидационный микросервис.

2. Контекстных ограничений не хватало. ИИ не знал про нашу внутреннюю структуру каталогов или специфичные скрипты.

Решение: мы добавили в промпт ссылку на векторную базу знаний (использовали Qdrant), где были заиндексированы наши внутренние runbooks и конфиги.

3. Стоимость. Первые пару недель с ужасом смотрели на счёт от OpenAI. Тысячи алертов и тысячи промптов.

Что сделали: жестко ограничили длину промпта, кэшировали ответы на одинаковые алерты, перешли на gpt-3.5-turbo для всех warning-алертов, оставив gpt-4 только для critical.

4. Ложное чувство безопасности. Однажды бот классифицировал memory leak как «low priority», потому что usage был 89%. Но это был медленный рост на критическом stateful-сервисе.

Вывод: ИИ - отличный ассистент, но не ответственный. Дежурный инженер всегда должен сохранять окончательный контроль и проверять критические действия системы.

⠀⠀

Итоги и совет тем, кто хочет повторить:

Наш эксперимент мы считаем успешным. Мы не заменили себя, но создали неустающего стажёра, который:

Мгновенно реагирует.
Не п��никует.
Всегда помнит, где лежат runbooks.

С чего начать вам, если хотите такого же ночного дежурного:

Возьмите самый частый и надоедливый алерт.
Напишите для него идеальный промпт, как если бы вы объясняли задачу джуниору.
Сделайте простой PoC: алерт → вебхук → скрипт с вызовом OpenAI API → вывод в Slack.
Обязательно встройте человеческое подтверждение на любые action.

Новая метрика - количество спокойный ночей :-)

ИИ в DevOps = усиление и ускорение. Чтобы тратить силы на сложные, интересные задачи, которые действительно требуют человеческого интеллекта. А ночи... пусть будут спокойными :-)

*Сейчас мы экспериментируем с open-source моделями (Llama 3, Mistral), развёрнутыми внутри кластера, чтобы закрыть вопросы безопасности и стоимости. Но это уже тема для следующей статьи.

Как мы учили ИИ тушить инциденты вместо нас (что из этого вышло)