Daimler Truck автоматизував виправлення IT-інцидентів на AWS

Покроковий сценарій: як агенти лікують помилку OOM

Джерело описує конкретний випадок з пам'яттю. Розробник задає для сервісу занадто низький ліміт пам'яті й розгортає зміну через CI/CD у кластер Kubernetes. Під час пікового навантаження под перевищує виділену пам'ять, ядро Linux вбиває контейнер, і Kubernetes фіксує стан OOMKilled, після чого под циклічно перезапускається (CrashLoopBackOff).

Instana виявляє повторні перезапуски й надсилає структурований алерт через Amazon API Gateway на ендпоінт SRE-агента /invocations, що працює на Amazon Bedrock AgentCore Runtime. SRE-агент перевіряє обов'язкові поля (ID алерту, рівень критичності, сервіс, середовище) і нормалізує дані у формат, який описано як SRE Skill Envelope, після чого звертається до AWS DevOps Agent, що працює в режимі лише читання. DevOps Agent аналізує телеметрію і повертає звіт про розслідування разом із готовим diff-патчем для виправлення лімітів пам'яті.

Далі SRE-агент передає цей звіт Dev-агенту. Той перевіряє, чи репозиторій входить до дозволеного списку і чи встановлено прапорець fix_applicable = true, автентифікується через GitHub App за допомогою RS256 JWT, застосовує патч у сенд-боксі й прогонує перевірки (наприклад, terraform fmt або pytest). Якщо все проходить, агент створює робочу гілку, комітить зміну від імені бота, пушить її і відкриває pull request з повним таймлайном інциденту, причиною та результатами тестів. Подію фіксують у CloudWatch, а в Microsoft Teams з'являється посилання на PR — саме на цьому кроці розробник приймає фінальне рішення перед мерджем.

Захисні механізми проти збоїв і зайвих витрат

Команда заклала у систему кілька запобіжників. AWS Lambda-функція, яка запускає SRE-агента, має механізм дедублікації через Amazon DynamoDB — він ігнорує однакові або схожі алерти, що приходять поспіль, щоб уникнути паралельних запусків на один і той самий інцидент. Dev-агент діє лише в межах дозволених репозиторіїв, тож не витрачає ресурс на нерелевантні проєкти, а будь-яке виправлення спочатку перевіряється в сенд-боксі — і лише потім потрапляє в pull request.

Додатковий рівень безпеки — вбудовані в Amazon Bedrock AgentCore тимчасові політики авторизації агентів зі збереженням стану та обмеження частоти звернень для ШІ-трафіку. Окремо є запобіжник на витрати: алерт CloudWatch разом з Lambda-функцією зупиняє всю систему, якщо загальна вартість її роботи перевищує заданий порогом рівень — це «жорсткий запобіжник» проти аномального використання.

Де система ще не працює

Рішення налаштоване діяти лише на ретельно перевірених і протестованих типах помилок — саме це дає високу надійність результату, але одночасно означає вузький наразі діапазон застосування. На момент розробки сам AWS DevOps Agent ще не вмів готувати виправлення коду, тому команді довелося будувати окрему багатоагентну архітектуру з виділеним Dev-агентом для написання й перевірки патчів.

У найближчих планах — розширити перелік типів інцидентів: автоматизувати обробку помилок на рівні застосунків, прогнозовано блокувати помилковий код ще до деплою, побудувати окрему базу знань на основі стандартів кодування Daimler Truck і запускати тести прямо в сенд-боксі для перевірки pull request-ів ще до затвердження розробником. Усе це — наступні кроки, які описані як плани, а не як вже реалізована функціональність.

Результат і що перевірити перед довірою

За даними джерела, ручне розслідування й підготовка виправлення раніше займали в середньому 2–3 години на інцидент; з автоматизованим процесом на час людської перевірки й затвердження залишається приблизно 15 хвилин — це скорочення часу вирішення приблизно на 88%. Також згадується потенційне скорочення трудовитрат на рівні підтримки на 10–20%, а автоматично згенеровані pull request-и з повним таймлайном інциденту додатково покращують документацію та готовність до аудиту.

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