AWS DevOps Agent на практиці: простори агентів, розслідування, перевірки випусків та навички.

Команди з операційних питань витрачають багато годин на повторювані завдання: з’ясування причин збоїв у потоках обробки даних, перевірка стану інфраструктури, порівняння журналів подій із показниками ефективності та відповідь на щоденні запитання типу „Що зараз не працює?“. AWS надає чудові інструменти для цього, серед яких CloudWatch, IAM, CodePipeline та Lambda, проте залишається прогалина між первинними даними та висновками, на основі яких можна вжити дій.

Далі наведено практичний огляд AWS DevOps Agent: як налаштовується простір агента, як виглядає розслідування з початку до кінця, що додають новітні функції керування випусками та як Agent Skills дозволяють агенту запам’ятовувати власні процедури команди. Цей матеріал призначений для інженерів DevOps, SRE, платформ та штучного інтелекту, які вже використовують робочі навантаження на AWS та прагнуть автоматизації, яка виходить за межі простих скриптів.

Що таке агент DevOps та чим він не є

Тут цей термін означає операційного асистента, який не замінює інженерів. Це система, яка:

• має право на читання ресурсів AWS, а іноді — обмежене право на запис
• розуміє оперативний контекст середовища
• може відповідати на запитання, такі як чому зазнала невдача розгортання, що змінилося протягом останньої години чи яка служба є причиною зростання кількості помилок
• виступає як з’єднувальний шар між API AWS, журналами подій, метриками та людьми, які знаходяться на чергуванні

Він не замінює інженерів. Його завдання — зменшити інтелектуальне навантаження під час рутинних розслідувань та прискорити їх проведення.

Створення простору агента

Знайдіть службу

Відкрийте AWS Management Console та знайдіть AWS DevOps Agent. Основні функції для керування виробничими процесами вже доступні. Новіші можливості керування версіями, про які йдеться нижче, все ще знаходяться у пробному режимі.

Створення простору

Виберіть опцію «Створити простір агента» та введіть дві речі: назву, наприклад Demo-DevOps-Agent, та короткий опис середовища або його призначення. Простір агента стає логічним межовим об’єктом для досліджень, аналізу топології та рекомендацій.

Надання доступу до ресурсів

У розділі з наданням доступу простору до ресурсів AWS виберіть опцію автоматичного створення нової ролі DevOps Agent. AWS створює та приєднує роль IAM із обмеженими правами, які дозволяють їй читати показники та журнали CloudWatch, перевіряти ресурси EC2 та пов’язані з ними об’єкти, а також створювати графи топології. Більшість проблем, пов’язаних із IAM, які зазвичай уповільнюють впровадження, зникає на цьому етапі.

Увімкніть веб-додаток

У розділі «Увімкнути веб-додаток» залиште обраною опцію автоматичного створення ролі. Це увімкне інтерактивний інтерфейс, який використовується для досліджень, чату та панелей керування. Після цього створіть простір Agent.

Відкрийте перегляд оператора

Перейдіть до нового простору Agent та відкрийте розділ Operator Access. Тут знаходяться три секції: DevOps Center, Incident Response та Prevention.

DevOps Center та видимість, заснована на топології

Усередині цього інтерфейсу DevOps Center відображає живу топологічну діаграму середовища AWS. Водночас виділяються кілька аспектів: ресурси виглядають пов’язаними, а не ізольованими, залежності між сервісами є видимими, а агент працює на основі цих зв’язків, а не лише метрик. Ця топологія має величезне значення для подальшого аналізу первинних причин.

Проведення розслідування

Саме тут агент починає проявляти свою корисність. На панелі керування виберіть опцію «Почати розслідування». Проблему можна описати простою мовою або вибрати типову причину, таку як високе навантаження на CPU, різкий зростання кількості помилок чи відсутність метрик та журналів.

Прикладом тут була ситуація з відсутністю даних. Запит звучав так: чи можете ви перевірити, чому дані про CPU у CloudWatch недоступні для моїх інстанцій EC2? Агент негайно визначив уражені інстанції, показав їх на карті топології та звернувся до метрик CloudWatch у відповідному регіоні.

Хронологія та результати

У хронології розслідування описано, як просувалася робота: збір контексту, виявлення ресурсів, оцінка метрик та формулювання висновків. Один з виборів дизайну заслуговує уваги. Коли метрики відсутні, агент прямо про це повідомляє та не працює мовчки. Це невелике рішення, але воно суттєво впливає на довіру.

Аналіз кореневої причини

У вкладці «Коренева причина» агент назвав кілька факторів, що сприяли проблемі, а не лише один:

• Детальний моніторинг вимкнений на інстанціях EC2. На цих інстанціях було відображено Monitoring: disabled, і без детального моніторингу ці показники CPU ніколи не надсилаються до CloudWatch.
• Агент CloudWatch не встановлений. На інстанціях нічого не було налаштовано, тому детальні дані про CPU були недоступні.
• Інстанції зупинені. Вони працювали у зупиненому стані протягом тривалого часу, а зупинені інстанції не генерують жодних показників.

Важливо те, як працював агент. Він не обрав одного пояснення, а розумно рангував причини та підкріплював кожну з них даними, отриманими з API AWS.

Коли правильною відповіддю є бездіяльність

У вкладці «План зменшення наслідків» було повідомлено, що не можна визначити жодних негайних заходів зі зменшення наслідків. Це хороший результат, а не поганий. Система працювала саме так, як налаштовано. Жодні зміни чи регресії не спричинили цих проблем. Будь-яке виправлення буде вважатися плановою зміною налаштувань, а не заходом щодо усунення інциденту. Встановлення такого розмежування має велике значення у продакшні, оскільки запобігає непотрібним скасуванням змін.

Профілактика

У вкладці «Профілактика» аналізуються попередні розслідування, щоб вирішити, чи потрібні проактивні рекомендації. Тут нічого нового не було створено, і агент правильно визначив відсутність повторюваних операційних ризиків. Категорії, які він оцінює, — це інфраструктура, можливості моніторингу, управління та оптимізація коду.

Чому це може бути важливим для команд

Це не просто ще один інструмент моніторингу. Його цінність полягає у чотирьох аспектах: скороченні часу розслідувань, структурованому аналізі первинних причин, зменшенні втоми від постійних сповіщень та можливості для команд зрозуміти, чому їхні системи поводяться саме так. Інакше інженерам доводилося б вручну поєднувати дані з CloudWatch, налаштування EC2, стан IAM та історію розгортання. Агент виконує цю кореляцію замість них.

Функції керування випусками (попередня версія)

Новіша функція дозволяє використовувати агента ще на ранніх етапах, ще до того, як код потрапить у продакшн.

Перевірка готовності до випуску. Кожна зміна коду оцінюється за критеріями готовності до експлуатації, ризиками залежностей між репозиторіями та будь-якими стандартами, визначеними організацією; у разі відсутності таких стандартів застосовуються загальні найкращі практики. Серед конкретних перевірок — вплив зміни на сервіси в інших репозиторіях та зміни в системі IAM чи контролі доступу, оцінювані за критеріями AWS Well-Architected Framework. Крім того, агент запускає процес будування в ізольованому середовищі, яким керує AWS, та тестує його за допомогою кількох простих тестів користувацького процесу. Це дозволяє підтвердити, що процес будування вдалося, додаток працює та базові функціональні перевірки пройдені, ще до того, як зміна потрапить у конвеєр обробки.

Результати відображаються у консолі DevOps Agent та як коментарі до запитів на підтягування коду у GitHub чи GitLab. Їх також можна активувати за потреби з IDE за допомогою плагінів Kiro power чи Claude Code, щоб розробники могли виявити ризики, пов’язані з залежностями, порушення стандартів та проблеми з контролем доступу ще до збереження змін.

Автономні тести на випуск. Це дозволяє перейти до етапу попереднього об’єднання коду. Замість виконання фіксованого набору тестів система створює плани тестування, спеціально розроблені для конкретних змін, які виконуються у середовищах, схожих на продакшн, наданих клієнтом, для веб- та API-додатків. Оскільки система аналізує значення змін, вона може створювати тести на функціональну коректність, виявлення регресій та інтеграцію між сервісами, які ручно підтримуваний набір тестів ніколи б не передбачив. Кожне виконання створює структуровані результати — показники, журнали, трекери та короткий огляд виконання, що забезпечує перевіряючим послідовний та піддаємий аудиту запис про охоплення тестами та результати для кожної зміни.

Обидві функції знаходяться у пробному режимі та не передбачають додаткових витрат протягом цього періоду. Вони доступні у регіоні Східна частина США (Північна Вірджинія).

Що таке навички агента

Навички — це модульні набори інструкцій, які розширюють можливості агента спеціалізованими знаннями в певній галузі та методами дослідження, пристосованими до інфраструктури та практик конкретної команди. Навичка — це самодостатній каталог інструкцій у форматі Markdown, який надає агенту нові можливості. Сервіс підтримує частину специфікації Agent Skills, приймаючи лише невиконуваний матеріал: інструкції у форматі Markdown, PDF-файли, зображення та файли даних.

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

• Робочі процеси дослідження для певних сценаріїв чи типів інфраструктури
• Матеріали для посилання, такі як архітектурні шаблони та процедури експлуатації

Цілювання за типом агента — це можливість застосування певної навички до конкретних типів агентів (Загальні, За запитом, Тріаж інцидентів, Аналіз причин інцидентів, Зменшення наслідків інцидентів чи Їх оцінка) для економії контексту та підвищення фокусу.

Навіщо це потрібно?

Навички перетворюють універсального асистента на спеціаліста для певного середовища. Інструкція, введена один раз у чат, зникає після цього, тоді як навичка може використовуватися багаторазово та завантажуватися автоматично, коли це необхідно під час виконання завдання. Існує чотири переваги:

• Спеціалізація. Агент опановує процедури розслідування, найкращі практики та організаційні знання, характерні для конкретної інфраструктури.
• Менше повторень. Робочий процес, написаний один раз, автоматично використовується під час кожного відповідного розслідування, тому не потрібно повторювати однакові вказівки.
• Композиція. Кілька навичок поєднуються в єдиний цілісний процес роботи. Агент може використовувати кілька з них під час виконання завдання — наприклад, одну для отримання інформації про розгортання з власної CI/CD-системи та іншу для пошуку у репозиторіях коду.
• Краще використання власних інструментів. Навичка може підказати агенту, коли потрібно викликати певний інструмент сервера MCP, які параметри підходять для різних сценаріїв та як обробляти отримані результати.

Як вони використовуються

Коли агент стикається з відповідним завданням, він завантажує відповідні навички та діє згідно з ними. Наприклад, навичка під назвою «Дослідження продуктивності бази даних» може містити поетапні інструкції щодо регулювання пропускної здатності RDS, систематично допомагаючи агенту аналізувати статус сповіщень, показники з’єднань та повільні запити.

Структура навичок

Навичка — це каталог:

my-skill/
├── SKILL.md              # Main skill instructions
├── references/           # Optional: additional reference documentation
└── assets/               # Optional: images, diagrams, data files

Файл SKILL.md є єдиним обов’язковим елементом. Він має описувати, коли та як застосовується навичка, наводити поетапні процедури дослідження, включати дерева рішень для різних сценаріїв, а також вказувати очікувані результати та критерії успіху.

Зразки навичок та їх завантаження

AWS публікує збірку зразків навичок, створених для цього середовища виконання, у організації GitHub aws-samples. Це не універсальні Agent Skills – вони адаптовані під середовище виконання DevOps Agent, його типи агентів та робочі процеси, які він виконує в Agent Space.

Щоб скористатися однією з них, завантажте потрібний zip-файл з репозиторію або створіть пакет із такою структурою:

<skill-name>.zip
├── SKILL.md              # Required: main instructions + YAML frontmatter
├── references/           # Optional: reference documentation
│   ├── architecture.md
│   └── troubleshooting.md
└── assets/               # Optional: images, diagrams, data files

Розмістіть SKILL.md у корені архіву zip із дійсним frontmatter, який містить name та description. Приклад frontmatter може мати назву на кшталт eks-resilience-checker-skill-devops та опис приблизно такий: процедури розслідування для оцінки стійкості Amazon EKS, що охоплюють стан контрольної платформи, масштабування даних, проблеми в мережуванні та можливостях моніторингу; використовується під час оцінки чи виправлення рівня стійкості кластера.

Потім виконайте кроки завантаження:

1. Переконайтеся, що в архіві zip немає директорії scripts/ та що його розмір не перевищує 6 МБ.
2. Відкрийте Operator Web App та перейдіть на сторінку Skills.
3. Виберіть «Додати навичку», а потім «Завантажити навичку».
4. Перетягніть файл .zip у вікно для завантаження або знайдіть його в системі пошуку. Приймаються лише архіви zip розміром до 6 МБ.

Виберіть типи агентів, які мають використовувати цю навичку. Generic вже позначений та застосовується до всіх типів. Зніміть цю позицію, щоб вказати On-demand, Incident Triage, Incident RCA, Incident Mitigation або Evaluation.

Ознайомтесь з результатами перевірки, які відображає форма, а потім оберіть опцію «Завантажити», щоб додати навичку до простору агента.

Керування навичками пізніше

• Список та перегляд: будь-яку навичку на сторінці Навички можна відкрити, щоб переглянути її файли (SKILL.md, references/, assets/) — лише для читання.
• Активувати або деактивувати: у режимі детального перегляду перемикайте статус між Active та Inactive. Деактивовані навички залишаються збереженими, але не завантажуються під час нових розслідувань.

Перенаправлення цілі: вибір типів агентів можна змінювати кожного разу, коли це потрібно.

Заміна: навичка, отримана з zip-файлу, оновлюється шляхом завантаження новішої версії.

Створення навички в інтерфейсі користувача

Один файл SKILL.md без посилань чи ресурсів може повністю обійтися без zip-файлу:

1. На сторінці Навички виберіть «Додати навичку», а потім «Створити навичку».
2. Введіть Назву літерами малого регістру, цифрами та дефісами; довжина має становити не більше 64 символів, без дефісу на початку та в кінці.
3. Введіть Опис; ідеально — щонайменше 100 символів та не більше 1024.
4. Виберіть Статус (Активна або Неактивна) та один чи кілька типів агентів.
5. Вставте Markdown-текст у поле Інструкції.
6. Виберіть «Створити». Система автоматично генерує файл SKILL.md із необхідними метаданими.

Де це застосовується

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