OpsAgents: Десять агентів LangGraph для роботи в хмарі та у процесах DevOps.
Огляд десяти агентів DevOps з участю людини, створених на базі LangGraph, від Terraform та Kubernetes до сканування Trivy, з описом правил проектування та отриманих уроків.
Джерела: DevOps Agents From the 2026 Guide to a Real Working Repo in 10 Agents
Інженери постійно ставлять одні й ті самі запитання щодо агентів DevOps, тільки іншими словами: чи справді існує щось подібне, де знаходиться код та чи можна його запустити вже сьогодні? Концепції мають свої обмеження, тому практичною відповіддю є OpsAgents — набір з десяти ШІ-агентів для роботи в хмарі та у процесах DevOps, створений за допомогою LangGraph та Python. Він працює як інструмент командного рядка, так і як сервер MCP.
Увага щодо бета-версії: OpsAgents знаходиться у бета-версії. Не використовуйте його в продакшн-середовищах. Можливі раптові зміни без попередження, і ви використовуєте його на власний ризик.
Правила проектування
Людина підтверджує кожну руйнівну дію. Масштабування розгортання, застосування Terraform чи запуск посібника з діями змушують агента зупинитися та отримати підтвердження перед тим, як станеться щось незворотне. Це налаштування неможливо вимкнути, оскільки інфраструктура виробництва не повинна цього дозволяти.
Машини станів, а не крихкі ланцюги запитів. Кожен агент — це орієнтований граф, у якому стан переміщується між вузлами. Якщо якийсь крок зазнає невдачі, стан зберігається, і агент може відновитися. Завдяки функції перевірки стану агент може продовжити роботу після перезапуску, не втрачаючи досягнутого прогресу.
Справжні інтеграції. Агенти працюють з AWS Cost Explorer, CloudWatch, CloudTrail, IAM, SSM та EC2, виконують справжні операції в Kubernetes за допомогою kubectl, використовують Trivy для сканування на наявність CVE та створюють JSON-дані для панелі керування Grafana, які можна вставити в існуючу структуру. Жодна з цих функцій не є імітацією чи штучною.
Кілька постачальників моделей. Claude, GPT-4, Gemini, Mistral та Ollama — усі вони працюють, причому Ollama дозволяє запускати програми повністю локально, без зв’язку з інтернетом. Ця платформа не залежить від жодного конкретного постачальника.
Два способи її запуску
У режимі CLI ви можете запускати будь-який агент безпосередньо з терміналу, що підходить для епізодичних операцій, написання скриптів та тестування.
У режимі сервера MCP OpsAgents інтегрується з Claude Code, Cursor, Codex чи OpenCode, тож ви можете спілкуватися зі своєю інфраструктурою, як із колегою. Після налаштування сервера MCP у вашому редакторі кожен агент стає інструментом, який редактор може викликати. Ви можете попросити його перевірити кластер на наявність несправних елементів чи надати звіт про рахунок AWS за цей місяць, і відповідний агент обробить запит, попередивши вас про це перед будь-якими змінами.
Десять агентів
Хмарні агенти (AWS)
Забезпечувач інфраструктури. Цей інструмент охоплює весь цикл життя Infrastructure-as-Code. Ви описуєте бажану структуру простою англійською мовою, наприклад публічну VPC із двома підмережами у різних зонах доступності, і він генерує повний код у форматі Terraform чи CloudFormation. Потім він перевіряє синтаксис та запускає terraform plan, щоб ви точно бачили, що зміниться, перш ніж будь-які ресурси створяться, і застосовує зміни лише після інтерактивної підтвердження. Після цього він може аудитувати аккаунт AWS у реальному часі та виявляти відхилення від конфігурації, збереженої у Git, що дозволяє виявити ручні зміни, які обійшли процес IaC.
- Переклад з природної мови у повний код Terraform чи CloudFormation, а не лише скелет структури
- Перевірка синтаксису та тестовий план перед виконанням
- Застосування змін після підтвердження людини
- Виявлення відхилень між поточним станом AWS та конфігурацією, яка відстежується у Git
Безпека та відповідність стандартам. Рахунки AWS у продакшні поступово накопичують ризики. Політики IAM з часом стають менш суворими, групи безпеки відкриваються для діагностики та так і не закриваються, а бакети S3 опиняються неправильно налаштованими. Цей агент здійснює постійний аудит замість періодичних перевірок. Він шукає дозволи типу „вайлдкард“ у політиках IAM та надмірно привілейовані облікові дані, виявляє групи безпеки EC2 з публічним доступом (наприклад, SSH відкритий для 0.0.0.0/0), а також перевіряє бакети S3 на наявність шифрування та публічного права на читання. Результати порівнюються з критеріями CIS AWS Foundations Benchmark, тож ви отримуєте оцінки ступеня серйозності, а не простий список.
- Аналіз IAM, що включає перевірку дозволів типу „вайлдкард“, шляхів ескалації та невикористовуваних дозволів
- Аудит груп безпеки щодо публічних портів та надмірно відкритого доступу
- Аудит бакетів S3 щодо статусу шифрування та публічного доступу
- Порівняння показників CIS з визначенням рівня серйозності
Оптимізатор витрат. Рахунки AWS містять непотрібні витрати, на які ніхто не має часу звернути увагу вручну: непідключені томи EBS, інстанції EC2, які працюють на 3% потужності CPU протягом місяців, Еластичні IP, призначені ні для чого, а також покриття через зарезервовані інстанції, яке змінюється залежно від змін флоту. Агент запитує Cost Explorer щодо звітів про витрати, знаходить невикористані ресурси за типом та регіоном, пропонує коригування розміру для недостатньо використовуваних обчислювальних ресурсів та вказує, де можна скоротити витрати за допомогою планів економії чи зарезервованих інстанцій. Кожна рекомендація супроводжується орієнтовною сумою економії на місяць.
- Запити Cost Explorer за послугою, регіоном та періодом
- Виявлення непідключених томів, неактивних інстанцій та невикористаних Еластичних IP
- Рекомендації щодо коригування розміру з орієнтовною економією
- Аналіз покриття за допомогою планів економії та зарезервованих інстанцій
Реагування на інциденти. Після спрацьовування тривоги в продакшні найважливішими є перші 15 хвилин. Цей агент розпочинає розслідування одночасно, ще до того, як людина повністю прокинеться. Він збирає всі тривоги CloudWatch у стані ALARM, шукає останні помилки в Log Insights та перелічує виклики API CloudTrail, здійснені під час збою; таке поєднання зазвичай дозволяє з’ясувати, що саме змінилося. Якщо підходить стандартний посібник SSM, він може його запустити після вашого підтвердження. Після усунення проблеми агент створює структурований звіт у форматі markdown з описом хронології, первинної причини та заходів щодо її усунення.
- Агрегація тривог з відображенням того, що знаходиться у стані ALARM, з якого часу та які ресурси
- Аналіз первинної причини на основі даних Log Insights та історії CloudTrail
- Виконання посібника SSM за підтвердженням
- Створені звіти після аналізу інцидентів
Огляд архітектури. Більшість команд перевіряють свою архітектуру за критеріями AWS Well-Architected Framework лише під час запуску та рідко знову. Цей агент забезпечує постійний огляд. Він виявляє бази даних RDS, інстанції EC2, балансувальники навантаження, функції Lambda та контейнери S3 без необхідності вказування наявних ресурсів, а потім створює діаграми потоку Mermaid, які показують їхнє взаємозв’язок. Він оцінює налаштування за критеріями Well-Architected та виокремлює проблеми, такі як відсутність розгортання у кількох зонах доступу, RDS без автоматичних резервних копій та архітектури, призначені для кількох регіонів, але створені в одному регіоні.
- Автоматичне виявлення ресурсів, тому не потрібен ручний облік
- Діаграми топології Mermaid, створені на основі актуальних даних
- Оцінка критеріїв надійності, продуктивності та витрат
- Конкретні рекомендації щодо кількох зон доступу, резервних копій та «вузьких місць»
Агенти DevOps (операції з платформою)
CI/CD-канал. У всіх є власні думки щодо каналів, але ніхто не має часу на їх налаштування. Цей агент аналізує кодову базу та створює індивідуальну конфігурацію каналу замість того, щоб використовувати стандартну шаблонну структуру. Він визначає мову програмування, менеджер пакетів та систему збірки, а потім формує робочі процеси GitHub Actions із кешуванням залежностей, мінімальними правами доступу (OIDC замість довготривалих облікових даних) та розумним розподілом завдань. Коли канал не працює, він аналізує журнали та надає точний діагноз — не просто „збірка зазнала невдачі“, а щось на кшталт пропуску кешу, спричиненого зміною файлу блокування, що зробило хеш ключа кешу застарілим.
- Визначення мови програмування, менеджера пакетів та системи збірки
- Створення робочих процесів із кешуванням, підтримкою OIDC та контролем прав доступу
- Діагностика невдалих збірок із вказанням конкретної причини та способу виправлення
Операції з Kubernetes. Цей агент діє як адміністратор кластера з повними повноваженнями для діагностики та усунення проблем, і, ймовірно, є найкориснішим для роботи у режимі 24/7. Він узагальнює стан вузлів, просторів імен та системних подів у одній таблиці. Для несправних контейнерів він використовує спеціальні алгоритми діагностики для ситуацій CrashLoopBackOff, OOMKilled та ImagePullBackOff, аналізуючи події та умови. Він створює YAML-код для Deployments, Ingresses та Services, а також може масштабувати кількість копій чи здійснювати відкат безпосередньо після підтвердження.
- Узагальнення стану кластера у одній таблиці
- Структурована діагностика подів для поширених станів несправності
- Створення YAML-коду для Deployments, Ingresses та Services
- Масштабування та відкат із підтвердженням
Моніторинг та спостережуваність. Усі погоджуються, що конфігурація моніторингу має велике значення, але вважають її складною у використанні. Синтаксис PromQL є суворим, JSON-файли панелей Grafana надто об’ємними, а дерева маршрутизації Alertmanager легко піддаються непомітним помилкам. Цей агент створює правила сповіщень на основі PromQL для поширених показників, таких як частка помилок, перцентильні значення затримки та рівень насичення, готує JSON-файли панелей Grafana з запитами до імпорту та розробляє схеми маршрутизації для Alertmanager у Slack чи PagerDuty. Враховуючи цільовий рівень доступності, наприклад 99,9% або 99,95%, він також обчислює місячний бюджет помилок та максимально допустимий час простою.
- Шаблони PromQL для стандартних показників інфраструктури
- JSON-файли панелей Grafana для імпорту
- Схеми маршрутизації Alertmanager для Slack та PagerDuty
- Математичні розрахунки SLO, включаючи бюджет помилок та допустимий час простою
GitOps та випуски. Цей агент керує процесом випусків, пов’язаним із розгортанням: конфігураційними файлами, журналами змін, підвищенням версій та підготовкою до скасування змін. Він створює маніфести додатків ArgoCD із функціями самовідновлення та оптимізації, а також конфігурації Argo Rollouts для розгортання типу canary чи blue-green, включаючи шаблони AnalysisTemplates для автоматичного прийняття рішень щодо переходу на нову версію. Для випусків він підвищує версійні теги, створює журнали змін на основі історії комітів та може створювати запити на скасування змін, коли необхідно швидко скасувати розгортання.
- Маніфести ArgoCD із політиками самовідновлення, оптимізації та синхронізації
- Розгортання типу canary та blue-green із шаблонами AnalysisTemplates
- Підвищення версій та журнали змін на основі історії git
- Створення запитів на скасування змін
Безпека контейнерів та зображень. У 2026 році безпека ланцюга постачання вже не є факультативною, і цей агент виконує сканування та посилення захисту, які мають відбуватися перед тим, як будь-яке зображення потрапить у продакшн. Він перевіряє шари контейнерів на наявність CVE за допомогою Trivy та повідомляє про рівень серйозності та постраждалі пакети. Він аналізує Dockerfiles та оптимізує їх за допомогою багатоетапної компіляції для зменшення розміру зображення, очищення кешу для уникнення надмірного розміру шарів та використання користувачів, які не є root. Він сканує файли lock (poetry.lock, package-lock.json, Gemfile.lock) на наявність застарілих чи вразливих залежностей, а також для забезпечення відповідності стандартам генерує звіти про склад програмного забезпечення у форматах CycloneDX чи SPDX.
- Сканування CVE за допомогою Trivy із оцінкою рівня серйозності
- Посилення захисту Dockerfiles
- Перевірка файлів lock на наявність застарілих та вразливих пакетів
- Генерація звітів SBOM у форматах CycloneDX та SPDX
Чому в основі — LangGraph
Тут могли б бути використані кілька фреймворків, серед них LangGraph, Claude SDK, OpenAI Agents SDK, CrewAI та AutoGen. LangGraph переміг, оскільки його переваги відповідають вимогам DevOps.
Робочі процеси в продакшені не є лінійними. Сканування на безпеку, яке виявляє критичну проблему з IAM, має проходити інакше, ніж те, яке нічого не знаходить, а розслідування інциденту, яке не може визначити первинну причину в журналах, має бути передане до CloudTrail. Умовне маршрутизування в LangGraph ефективно вирішує цю проблему.
Стабільність стану означає, що агент, який працює над складною ситуацією, залишається активним після перезапуску, не втрачаючи своїх результатів. Функція створення контрольних точок дозволяє повторно запустити робочий процес з будь-якого вузла зі зміненими вхідними даними, що є вкрай важливим під час дебаггінгу агента, який прийняв несподіване рішення. Крім того, підтримка участі людини є частиною самої моделі графа, а не додатковим елементом. Ви самі вирішуєте, які вузли потребують підтвердження, і граф на цьому місці зупиняється.
Уроки зі створення
Три речі не були очевидними до появи агентів:
- Крок підтвердження — це все. Добре розміщений запит перед руйнівними діями відрізняє корисного агента від небезпечного. Правильне виконання цього кроку означає розглядати схвалення людини як архітектурну вимогу, а не просто як галочку, що змушує визначити, які вузли в кожному графі насправді мають побічні ефекти.
- Проектування стану — це складна частина. Запустити логіку агента легко. Вирішення питань про те, що має зберігатися, що залишається тимчасовим та як поширюються помилки, вимагає багатьох спроб; агент Kubernetes пройшов три перепроектування свого стану, перш ніж процес діагностики став зрозумілим.
- Інструменти мають вищу вагу, ніж вибір моделі. Агент є настільки ж ефективним, наскільки ефективні його інструменти. Створення функцій інструментів AWS, які повертають структурований та послідовний результат, принесло більшу користь, ніж коректування запитів, адже модель краще міркує, коли отримує чисті дані.
Що буде далі
Це лише вихідна точка, а не готовий продукт. Агенти покривають найпоширеніші робочі процеси в хмарах та DevOps, проте залишається ще багато роботи. Серед розглядуваних напрямків — підтримка кількох хмар за допомогою агентів GCP та Azure, виявлення аномалій у витратах на основі історичних даних замість статичних порогів, автоматичне усунення відхилень, коли агент генерує та застосовує виправлення після схвалення, а також більш тісна інтеграція з функціями Claude Code та Cursor MCP.
Як допомогти
Вам не потрібно бути експертом — достатньо бути цікавим. Найкорисніша допомога залежить від того, хто ви є:
- Інженер DevOps чи хмарних технологій: запустіть агента на реальній інфраструктурі та повідомте, що зламалося, які результати вас збентежили та який робочий процес ви очікували, що він обробить. Фідбек з реального світу є найціннішим даним на цьому етапі.
- Розробник: оберіть будь-якого агента, прочитайте його визначення у вигляді графа та внесіть покращення — чи то краще оброблення помилок, відсутній інструмент чи поле стану, яке потрібно відстежувати. База коду достатньо мала, щоб зрозуміти всю структуру агента приблизно за 30 хвилин.
- Початківець у сфері агентів DevOps: цей репозиторій також є середовищем для навчання. Створіть свою копію, запустіть її локально за допомогою Ollama, щоб уникнути витрат на API, та прочитайте код разом із загальним посібником про агентів DevOps. Отримання нової проблеми для постановки запитання також вважається внеском.
- Будь-хто, у кого є ідея щодо нового агента: створіть нову проблему, у якій опишіть процес роботи. Якщо щось, що зараз робиться вручну, має бути автоматизовано, зазначте це. Агент для аудиту Secrets Manager, агенти для кількох хмар та агент для виявлення аномалій у витратах — усі вони є у планах розвитку та готові до створення.
Підтримайте цей репозиторій, створіть заявку на вирішення проблеми або надішліть запит на з’єднання коду. Мета — агенти, які функціонують у продакшені та створюються відкрито.
Пов’язана література
- Практичні нотатки: RAG Systems: Повний посібник від нуля до професіонала (видання 2026 року) — Детальний огляд Практичних нотаток: RAG Systems: Повного посібника від нуля до професіонала (видання 2026 року): контракти, перевірки та шаблони коду для команд, які використовують цю модель.
- Створення вашого першого агента LangChain за допомогою LangGraph у 2026 році — Крок за кроком створіть агента LangChain з використанням LangGraph, інструментів, функцій пам’яті та відстеження, уникніть чотирьох поширених помилок та дізнайтеся, як це використовувало відділення підтримки буткемпу.