LLM-диагностика инцидентов в Kubernetes и OpenStack: расследуем один раз, дальше выполняем без модели

Сегодня большинство LLM-ассистентов для эксплуатации умеют расследовать инциденты, но практически не умеют накапливать опыт. Каждый новый случай они разбирают с нуля, снова данные, снова токены, даже если инженер уже нашёл решение похожей проблемы.

Расскажем про альтернативный вариант для диагностики Kubernetes и OpenStack, в которой результат расследования становится исполняемым артефактом. После проверки инженером он попадает в библиотеку диагностических процедур и используется повторно без участия LLM. Таким образом модель занимается только поиском нового знания, а воспроизводимые сценарии выполняются детерминированно.

В докладе разберем весь путь инцидента: безопасный сбор фактов по белому списку команд, маскирование и нормализация доказательств, детерминированная классификация известных проблем, мультиагентное расследование новых случаев и публикация знания через ревью.

Отдельно поговорим о том, почему «память» таких систем деградирует. Покажем, какие механизмы позволяют этого избежать и сохранить базу знаний пригодной для автоматического выполнения. Сравним три подхода на обезличенных инцидентах: классический LLM-агент, агент с доступом к текстам прошлых расследований и наш ассистент с библиотекой исполняемых процедур.

Главная мысль: провести формальную границу между вероятностным расследованием нового случая и воспроизводимым выполнением проверенной процедуры, и тогда LLM работает только там, где действительно нужна. Слушатель унесет с собой модель данных диагностического знания, процесс его проверки и публикации, и набор метрик, чтобы сравнить такой подход с универсальным агентом у себя.