Як контекст перетворює AI SRE-агента з демо на реальний інструмент

Проблема контексту в AI DevOps

AI DevOps-агенти, які чудово працюють на демонстраціях, часто виявляються неефективними в реальних виробничих середовищах. Цей розрив виникає не через брак інтелекту великих мовних моделей (LLM), а через відсутність специфічного контексту. Хоча LLM розуміють загальні концепції, їм бракує знань про унікальні особливості конкретних систем, такі як проблемні перевірки життєздатності, відповідальність команд або причини минулих інцидентів. Ці знання зазвичай містяться в ранбуках, постмортемах, архітектурній документації та досвіді старших інженерів.

Два типи знань для SRE-агента

Для ефективної роботи SRE-агенту потрібні два принципово різні види знань, які мають бути архітектурно розділені:

• "Живий" рівень (Live Plane): Це поточний стан системи, що включає метрики з Prometheus, логи контейнерів, події Kubernetes, історію розгортань та дані сповіщень. Ці дані є свіжими, фактичними та генеруються машинами. Агент отримує їх за допомогою обмежених інструментів лише для читання під час розслідування.
• Організаційний рівень (Organizational Plane): Це всі знання команди, які не відображаються на дашбордах: ранбуки, стандартні операційні процедури (SOP), плейбуки, постмортеми, архітектурна документація, відповідальність за сервіси та правила ескалації. Ці дані змінюються повільно, створюються людьми та містять суб'єктивні оцінки. Вони відповідають на питання, на які "живий" рівень не може дати відповіді, наприклад: "чи є цей симптом нормальним для цього сервісу?", "до кого звертатися?", "що ми робили минулого разу?".

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

Retrieval-Augmented Generation (RAG) для організаційних знань

Вирішенням проблеми стало використання підходу Retrieval-Augmented Generation (RAG), розглядаючи організаційні знання як задачу пошуку. Вся організаційна інформація — ранбуки, постмортеми, архітектурні нотатки, карти відповідальності — зберігається у форматі Markdown в репозиторії Git.

Процес виглядає так:

1. Пайплайн розбиває документи на фрагменти, створює їхні вбудовування (embeddings) та завантажує їх у векторну базу даних.
2. При кожному злитті змін у гілку main, вбудовування для змінених файлів перестворюються. Це гарантує, що база знань завжди актуальна, відстаючи від реальності не більше ніж на одне злиття.
3. Під час інциденту агент не отримує всю бібліотеку знань. Він витягує лише те, що стосується конкретного інциденту. Наприклад, сповіщення про затримку на checkout-api призводить до вилучення ранбука checkout, постмортемів, що згадують checkout, та архітектурної документації, що описує його залежності.

Як працює RAG-агент під час інциденту

Цикл розслідування інциденту за допомогою RAG-агента виглядає наступним чином:

1. Надходить сповіщення; агент ідентифікує задіяні сервіси.
2. Вилучення (Retrieval): Агент отримує відповідні ранбуки, постмортеми та документацію.
3. "Живе" розслідування: Збір метрик, логів та відмінностей розгортань за допомогою інструментів лише для читання.
4. Кореляція: Інтерпретація "живих" сигналів у світлі вилучених знань.
5. Якщо доказів недостатньо, агент вилучає більше інформації або ескалує проблему до людини.

Цінність цього підходу зосереджена на етапі кореляції. Наприклад, сирі телеметричні дані можуть вказувати на "падіння коефіцієнта влучань кешу". Вилучений постмортем може містити інформацію: "ми бачили таку ж картину в березні; причиною була неправильна конфігурація TTL; виправленням був PR #1203". Поєднання цих двох джерел дає точний діагноз.

Під час тестування, коли було імітовано збій, якого агент ніколи не бачив (скидання з'єднань на сервісі за стороннім API), "живі" сигнали були неоднозначними. Однак, рівень вилучення знань виявив постмортем попереднього інциденту, який описував щомісячне технічне обслуговування стороннього постачальника та його характерну ознаку: скидання з'єднань, що починаються точно в зазначений час. Агент зіставив часову мітку та шаблон, змінивши свою відповідь з "ймовірна проблема мережі" на "це відповідає шаблону обслуговування постачальника, задокументованому в червневому постмортемі; рекомендована дія — це пом'якшення з того документа; зміни коду не потрібні".

Підтримка актуальності та достовірності знань

Для забезпечення надійності RAG-агента застосовуються три основні правила:

• Ранбуки в Git: Ранбуки зберігаються в Git-репозиторії поруч із сервісами, які вони описують. Оновлення поведінки агента відбувається через злиття PR, що вимагає перевірки коду. Це дозволяє виявляти застарілі ранбуки під час рев'ю.
• Постмортеми як цінний ресурс: Постмортеми є найціннішими документами, оскільки вони кодують відповідності "симптом-причина", яких немає більше ніде. Агент створює структурований постмортем після кожного вирішеного інциденту, публікуючи його в Confluence для людей та зберігаючи копію Markdown у Git-корпусі для себе. Кожен інцидент робить наступне розслідування розумнішим, а база знань постійно зростає.
• Вилучений контент — це контекст, а не команда: Вилучені документи інформують діагноз, але дії все ще проходять через ті ж обмежені інструменти, перевірки та людське схвалення. Це важливо для безпеки, оскільки документи можуть бути неправильними, застарілими або навіть скомпрометованими. Рівень знань має лише вплив, а не повноваження.

Виклики та подальші кроки

Існують проблеми, які ще не повністю вирішені:

• Пропуски вилучення: Якщо термінологія інциденту не збігається з термінологією ранбука, потрібний документ може не бути знайдений. Наприклад, сповіщення про "вичерпання пулу з'єднань" може не витягнути ранбук під назвою "проблеми насичення бази даних", якщо вбудовування не зможуть подолати цей розрив. Автор пише ранбуки з симптомами в першому абзаці, що допомагає, але не усуває проблему.
• Конфліктні документи: Два ранбуки, написані з різницею в два роки, можуть рекомендувати протилежні заходи. Агент не може знати, який з них актуальний, якщо це не вказано в корпусі. Додавання дати last_validated до заголовка ранбука та налаштування вилучення на перевагу новіших документів є тимчасовим рішенням.
• "Відмивання" впевненості: Вилучений документ може зробити слабкий діагноз переконливим. Фраза "як задокументовано в ранбуку" є переконливою, навіть якщо ранбук лише опосередковано релевантний. Тепер агент вказує, які документи сформували його гіпотезу, щоб людина, яка переглядає діагноз, могла перевірити, чи дійсно цитування підтверджує його.

Висновок

Якщо ваш AI DevOps-агент працює на демонстраціях, але провалюється в продакшені, ймовірно, бракує не кращої моделі, а організаційних знань, які ваша команда вже задокументувала. Ці знання мають бути вилучені в потрібний момент і підтримуватися в актуальному стані за допомогою тих самих процесів перевірки, що й код. "Жива" телеметрія повідомляє агенту, що відбувається, а ранбуки та постмортеми пояснюють, що це означає у вашій системі, з вашою історією. Агент, що володіє обома типами знань, є корисним колегою. Агент лише з першим — це лише демонстрація.

Що це означає для розробників

Для розробників та SRE-інженерів це означає, що ефективність AI-агентів у продакшені залежить не лише від складності моделі, а й від якості та доступності внутрішньої документації. Інтеграція RAG вимагає зберігання ранбуків, постмортемів та архітектурної документації у структурованому форматі (Markdown у Git) та підтримки їхньої актуальності через процеси, подібні до рев'ю коду. Це підкреслює важливість дисципліни в документуванні та управлінні знаннями для успішного впровадження AI-агентів.

Ключові факти

• AI DevOps-агенти часто провалюються в продакшені через брак специфічного організаційного контексту, а не інтелекту.

• SRE-агенту потрібні два типи знань: "живий" рівень (метрики, логи) та організаційний рівень (ранбуки, постмортеми, архітектурна документація).

• Ефективне рішення для організаційних знань — Retrieval-Augmented Generation (RAG), де знання зберігаються як Markdown у Git та індексуються у векторній базі даних.

• Агент витягує лише релевантні документи під час інциденту, поєднуючи їх з "живими" даними для точного діагнозу.

• Для підтримки достовірності знань ранбуки зберігаються в Git з рев'ю, постмортеми створюються агентом після інцидентів, а вилучений контент є контекстом, а не командою.

Джерела

• Runbooks + RAG: How I Gave My AI SRE Agent the Context It Was Missing