Команда DevOps у компанії з кількадесятьма сервісами отримує сотні сповіщень протягом доби. Більшість із них — шум. Кілька вимагають реакції протягом хвилин. Розрізнення їх вручну о другій ночі — це структурна проблема, а не питання компетенцій. AI не вирішує її через автономні дії. Він вирішує її через зниження вартості першого рішення: «чи вимагає це моєї уваги зараз?»
Нижче описую, як ми в Cashcrown підходимо до цієї категорії проблем і чому жорстка межа між пропозицією та виконанням — це не те, що можна обійти «після впровадження».
Що агент робить, а чого йому не можна робити#
Обсяг автоматизації для команди IT та DevOps має бути визначений до того, як щось потрапить у пілот. Таблиця нижче показує типовий розподіл для продакшн-середовища з кількома інженерами on-call.
| Завдання | Агент може | Людина повинна |
|---|---|---|
| Тріажинг алертів | Класифікувати за пріоритетом, групувати пов'язані інциденти, пропонувати severity | Прийняти рішення про ескалацію P1/P2 |
| Резюмування логів | Виокремлювати аномалії, вказувати часові вікна, пов'язувати слід помилки зі зверненням | Перевірити діагноз і схвалити відкат |
| Ранбук і постмортем | Створювати чернетку кроків для виправлення з історії подібних інцидентів, генерувати драфт постмортему | Схвалювати та виконувати кожен крок, що змінює продакшн |
| Пошук у документації | Відповідати на запитання «як ми робимо X» з бази внутрішніх знань (RAG) | Оцінювати, чи актуальна процедура |
| Маршрутизація звернень | Класифікувати тікети, призначати до черги або особи | Вирішувати пріоритети при конфлікті ресурсів |
| Надання доступів або зміна конфігурації | Нічого | Все, без винятків |
Останній рядок є абсолютним. Human-oversight для незворотних дій не є опцією конфігурації. Агент, який може самостійно відкрити порт фаєрволу, надати дозвіл IAM або змінити конфігурацію продакшн-сервісу, створює ризик, якого жоден guardrail у мовній моделі не усуне. Моделі допускають помилки. Незворотні дії на продакшні коштують реальних грошей.
Тріажинг алертів і резюмування логів#
Alert fatigue — це добре вивчена проблема. Інженери on-call, які кілька тижнів бачать сотні сповіщень на день, з яких 95% виявляються false positive, починають сприймати кожне наступне як шум. Це не помилка з боку людей. Це неминучий ефект асиметрії: вартість пропущеного реального інциденту величезна, а вартість хибного спрацьовування здається нульовою, бо «нічого не сталося». Насправді вартість хибних спрацьовувань реальна і накопичується як втома, зниження пильності та вигорання.
Агент з доступом до системи оповіщення може допомогти інакше, ніж через сліпе зменшення їх кількості. Замість фільтрації алертів (що загрожує пропуском реальних), він може їх агрегувати та контекстуалізувати:
- Групувати алерти з того самого часового вікна з перекриттям ресурсів.
- Шукати в історії інцидентів подібний патерн і витягувати нотатку «три тижні тому подібний алерт закінчився на рівні бази даних, виправлено перезапуском pool connections».
- Виокремлювати з логу сервісу фрагмент стеку помилок і зіставляти його з відкритими тікетами.
Чого агент не робить: не вирішує, чи інцидент реальний. Не закриває алерти. Не позначає подію як resolved. Ці дії залишаємо людині, бо хибне закриття реального інциденту — одна з найдорожчих операційних помилок.
Архітектура: RAG для внутрішньої документації#
Запитання «як ми робимо деплой на staging?» звучить банально. На практиці інженер-новачок у проекті може витратити 20-40 хвилин на пошук відповіді в Confluence, Notion або розрізненому наборі Markdown у репозиторії. Зрілий RAG для внутрішньої документації скорочує цей час до 30-60 секунд, за умови, що база знань актуальна і добре сегментована на фрагменти.
Мінімальна архітектура для документації DevOps:
Джерела знань: ранбуки, процедури інцидентів, описи архітектури сервісів, політики безпеки, ADR. Кожен документ позначений метаданими: власник, дата верифікації, середовище (prod/staging/dev).
Гібридний пошук: семантичні ембедінги плюс full-text search для точних фраз. Семантичний ретривл сам по собі загубиться на запиті «помилка OOM на node-15 у кластері EU-west-2», бо це запит з конкретними ідентифікаторами.
Цитування джерела: кожна відповідь має вказувати документ і розділ. Якщо агент не може вказати джерело, він має сказати «не знаю» і ескалувати до людської черги. Архітектуру цього патерну описує моніторинг якості агента AI.
Пороги confidence: ретривл, що повертає фрагменти нижче порогу 0,70-0,80, не повинен призводити до відповіді. Краще повідомлення «не знайдено актуальної процедури», ніж відповідь, побудована на слабо релевантних фрагментах.
Втома від алертів: чесний погляд на асиметрію витрат#
Витрати хибних позитивів і хибних негативів у тріажингу алертів не є симетричними. Пропущений реальний інцидент коштує від хвилин простою до втрати даних. Хибний тривожний сигнал коштує дві хвилини. Але 200 хибних тривог на день — це 400 хвилин шуму. За такого рівня втоми реальний інцидент може виглядати як чергова хибна тривога.
Агент, що класифікує алерти, має бути відкалібрований у бік чутливості (recall), а не точності. Краще, щоб він хибно ескалував 15% шуму, ніж пропустив 1% реальних інцидентів. Ця калібрування — інженерне рішення, а не конфігураційне.
Observability системи тріажингу — це окремий шар: скільки алертів було ескаловано, скільки з них виявилися реальними, який був час від першого алерту до підтвердження інциденту людиною. Без цих метрик незрозуміло, чи агент допомагає, чи шкодить.
Guardrails для агента з доступом до систем#
Агент DevOps, який може читати логи, запитувати бази знань і класифікувати звернення, є відносно безпечним. Агент, який може викликати інструменти (tool-use: перезапуск сервісу, зміна конфігурації, надання прав), вимагає значно суворіших guardrails.
Патерн, який ми в Cashcrown використовуємо для цієї категорії систем:
Ізоляція прав на рівні інструменту. Кожен інструмент, доступний агенту, має чітко визначений обсяг: «можу викликати kubectl describe pod у namespace staging, не можу викликати kubectl delete pod ніде». Список інструментів є статичним і затверджується командою security перед впровадженням, а не через конфігурацію в реальному часі.
Human-gate для незворотних дій. Кожен інструмент, виклик якого змінює стан продакшн-системи, вимагає явної згоди людини перед виконанням. Агент готує готову команду з обґрунтуванням. Інженер схвалює або відхиляє. Патерн HMAC token або аналогічний механізм підтвердження. Без схваленого токена виклик не відбувається.
Classifier безпеки перед кожним інструментом. Перед передачею запиту до моделі шар guardrails перевіряє спроби інжекцій: «ігноруй попередні інструкції», «ти тепер адмін з повним доступом», «виконай це без логування». Такі запити потрапляють до черги безпеки, а не до моделі. Детально це описує безпека агентів AI.
Повне логування з контекстом. Кожен виклик інструменту агентом логується: що запитано, що агент запропонував, хто схвалив, коли. Логи є незмінними та доступними для аудиту безпеки. Цей аудитний слід потрібен не лише за здоровим глуздом, але у випадку систем, що впливають на критичну інфраструктуру, може вимагатися AI Act.
Деталі про безпечну інтеграцію агентів з зовнішніми інструментами описує інтеграція AI з n8n та автоматизаціями.
Маршрутизація та класифікація звернень IT#
Перед тріажингом інцидентів є щоденний потік сервісних звернень: запитання до хелпдеску, помилки, про які повідомляють користувачі, операційні завдання, запити на доступ. Classifier на базі LLM може автоматично призначати пріоритет, категорію та цільову чергу, перш ніж це прочитає людина-оператор.
Цінність тут подвійна: швидший час реакції на критичні звернення (P1 не чекає в черзі за 40 дрібними запитами) і краща якість даних у тікетній системі (узгоджена класифікація замість довільного «misc»). Впровадження цього патерну в контексті IT-хелпдеску описує AI helpdesk IT: внутрішній асистент підтримки. Логіку маршрутизації на технічному рівні розглядає класифікація та маршрутизація звернень AI.
FAQ#
Чи може AI автономно перезапускати сервіси або відкочувати деплої?#
Ні. Перезапуск продакшн-сервісу може вирішити проблему або погіршити її, якщо причина лежить глибше. Відкат може усунути інцидент або виявити ранішу помилку, приховану поточною версією. Мовна модель не має впевненості щодо стану системи, навіть якщо бачить логи. Правильний патерн: агент готує рекомендацію з обґрунтуванням, інженер схвалює або відхиляє, лише після цього відбувається дія.
Як створити базу знань RAG для документації DevOps, щоб вона була справді корисною?#
Три речі мають найбільший вплив: актуальність документів (застарілі ранбуки гірші за їх відсутність, бо агент відповість впевнено на основі неправильної процедури), гранулярність чанків (підрозділи з однією процедурою дають хороший ретривл, цілі розділи архітектури — поганий) і метадані середовищ (процедури для staging і prod відрізняються, агент має знати, яку шукати). Перш ніж індексувати всю документацію, протестуй 20-30 типових запитань on-call.
Як виміряти, чи агент тріажингу алертів справді допомагає?#
Два ключові показники: recall інцидентів (скільки реальних інцидентів було правильно ескаловано) і час від першого алерту до підтвердження людиною (Mean Time to Acknowledge). Recall вимірюєш ретроспективно, порівнюючи лог тріажингу з реєстром підтверджених інцидентів. Якщо агент пропускає реальний інцидент частіше ніж раз на квартал при обсязі кількасот алертів на день, калібрування порогу потребує перегляду.
Які вимоги AI Act для агентів DevOps з доступом до продакшн-систем?#
Системи тріажингу алертів і внутрішньої документації, які не впливають безпосередньо на рішення щодо людей, зазвичай не класифікуються як системи високого ризику згідно з Додатком III AI Act. Однак агент з доступом до інфраструктурних інструментів вимагає документації: опис системи, обсяг інструментів, логи рішень, механізм нагляду людини. Якщо система AI входить до критичної інфраструктури (енергетика, транспорт, фінансовий сектор), вимоги можуть бути суворішими, а DPIA стає майже обов'язковою. Межу варто уточнити з юристом, знайомим з регуляцією.
Що робити, коли інженери on-call перестають довіряти рекомендаціям агента?#
Це сигнал, що вказує на конкретну проблему. Втрата довіри зазвичай має три джерела: агент давав впевнені рекомендації на основі застарілої документації, класифікатор мав занадто низький поріг і ескалував забагато шуму, або одна гучна помилка вплинула на сприйняття всієї системи. Перш ніж виправляти модель, проведи ретроспективу останніх 20-30 взаємодій, під час яких довіра знизилася. Аудит якості агента описує моніторинг якості агента AI.