Запрос на изменение кода ещё не означает выпуск исправления. Инженер проверяет и одобряет предложенные правки до их внедрения. [1]
Поиск небольшой ошибки в настройках занимал часы
Портал послепродажного обслуживания Daimler Truck — Truck After Sales Portal (TASP!) — объединяет более 36 приложений. Они работают в семи кластерах Amazon EKS — группах серверов, на которых запускают приложения. По данным AWS, порталом пользуются более 130 000 человек, а над его модулями работают свыше 80 разработчиков. [1]
Например, приложению не хватает выделенной памяти, оно перезапускается, а система наблюдения за его работой сообщает о сбое. Инженеру предстоит сопоставить сообщение с последними изменениями, найти причину, подготовить и выпустить исправление. Даже небольшая ошибка в настройках требует всех этих шагов.
По данным AWS, до внедрения ИИ-агентов поиск причины и подготовка исправления занимали в среднем около двух-трёх часов на один сбой. [1]
Система готовит исправление для проверки инженером
Команда ИТ-поддержки послепродажного обслуживания Daimler Truck вместе с CGI и AWS описывает систему из нескольких ИИ-агентов — программ для отдельных задач с ИИ. Каждый агент выполняет свой этап: принимает сообщение о сбое, ищет причину, готовит или проверяет правки. В результате инженер получает запрос на изменение кода в GitHub и сам решает, принимать ли исправление и выпускать ли его. [1]
Система наблюдения за работой приложений передаёт сообщение о сбое. В примере AWS платформа Instana отправляет его через Amazon API Gateway агенту поддержки надёжности на Amazon Bedrock AgentCore.
Первый агент проверяет, есть ли в сообщении необходимые поля, и обращается к AWS DevOps Agent. Тот изучает данные о работе приложения и предлагает объяснение сбоя. Менять данные ему запрещено: доступ открыт только для чтения.
Отдельный агент разработки получает результаты поиска причины и проверяет, можно ли исправить этот случай автоматически. Затем он готовит правки в разрешённом репозитории — хранилище кода проекта.
Предложенное изменение применяют в изолированной тестовой среде и проверяют. В примере AWS названы команды terraform fmt и pytest.
Если проверки проходят, агент создаёт в GitHub запрос на изменение кода — pull request. В нём указаны история сбоя, найденная причина, предложенные правки и результаты тестов.
Команда получает уведомление в Microsoft Teams. Инженер изучает запрос и одобряет правки до их включения в основной код и выпуска. [1]
Пример: приложение перезапускается из-за нехватки памяти
AWS разбирает пример из среды разработки на Kubernetes — платформе для запуска приложений в контейнерах. При всплеске нагрузки одному контейнеру не хватает разрешённого объёма памяти. Система завершает его работу со статусом OOMKilled. После этого контейнер многократно перезапускается и попадает в состояние CrashLoopBackOff. [1]
По данным о работе приложения агент ищет причину сбоя
Система проверяет сообщение о сбое и приводит его к единому формату. Затем агент диагностики изучает данные с правами только на чтение, готовит сводку и предлагает изменения кода.
После тестирования правки передают в GitHub
Отдельный агент разработки проверяет свои права, тестирует исправление и создаёт запрос на изменение кода. Человек может изучить правки до их одобрения.
На момент разработки проекта AWS DevOps Agent ещё не умел самостоятельно вносить исправления в код. Поэтому команда разделила поиск причины, редактирование и проверку между разными агентами, каждому из которых дала только нужные права. [1]
Что агентам разрешено делать и когда процесс останавливается
AWS описывает несколько ограничений: что система может делать, где ей разрешено работать и в каких случаях она должна остановиться. [1]
Один сбой — один запуск процесса
Lambda и DynamoDB отсеивают одинаковые и похожие сигналы, которые приходят один за другим.
Только разрешённые хранилища кода
Агент разработки сверяет репозиторий со списком разрешённых и проверяет, подходит ли исправление для этого случая.
Проверка до запроса на изменение
Перед передачей инженеру предложенные правки проверяют в изолированной среде.
Правила доступа и частоты запросов
Временные правила Amazon Bedrock AgentCore определяют, какие действия доступны агенту на текущем этапе. Ограничения числа запросов не дают системе принимать слишком много обращений за короткое время.
Остановка при превышении бюджета
CloudWatch и Lambda могут остановить весь процесс, если общие расходы превысят установленный порог.
Выпуск разрешает человек
Инженеры получают запрос на изменение кода, проверяют его и принимают решение о выпуске.
По данным AWS, система пока работает только с тщательно проверенными типами ошибок. Расширение списка сбоев — план дальнейшего развития, а не уже доступная возможность. [1]
Около 15 минут вместо нескольких часов, включая проверку человека
AWS сообщает о сокращении времени устранения поддерживаемых сбоев примерно на 88%. Новое время включает работу автоматизированных этапов, а также проверку и одобрение инженером. [1]
По данным AWS, время устранения поддерживаемых сбоев сократилось.
Приблизительное среднее время, указанное AWS.
Включает автоматические этапы, проверку и одобрение инженера.
Это данные компании. Исходное время указано приблизительно; 88% — заявленный результат AWS, а не независимое измерение Maak.Digital.
Проверка расчёта: если взять исходные два часа, (120 − 15) ÷ 120 = 87,5%, или около 88% после округления. Для трёх часов процент будет другим. Источник не приводит данные по отдельным сбоям.
Возможная экономия, которая ещё не измерена
AWS оценивает возможное снижение трудозатрат поддержки в 10–20%. Это прогноз будущей экономии, а не независимо подтверждённый результат. В статье не указаны число проверенных случаев и полная методика измерений. [1]
Обнаружить → найти причину → предложить → проверить → одобрить → применить
В другом процессе можно так же поручить системе подготовку конкретного действия и передать его человеку для одобрения. Для этого каждому агенту нужны ограниченные права, а его предложению — обоснование и проверка.
Ниже — примеры применения этого подхода, предложенные Maak.Digital. Это не дополнительные внедрения Daimler Truck:
Сигнал об ошибке → сведения и журналы работы → предложение исправления → тестовая среда → проверка запроса → выпуск.
Входящий запрос → разбор требований → черновик документа → проверка правил → одобрение специалиста → отправка.
Нестандартная ситуация → данные заказа и поставщика → предложение решения → проверка правил → одобрение закупщика → обновление данных в системе учёта ресурсов (ERP).
Несогласованные данные сделки → сведения звонка и записи в системе работы с клиентами (CRM) → предложение правок → проверка → одобрение ответственного → синхронизация.
Инженер получает правки, результаты тестов и обоснование
ИИ готовит конкретное действие и сведения для его проверки. Окончательное решение принимает назначенный специалист.
В этом решении связаны все этапы подготовки: обнаружение сбоя, поиск причины, правки в разрешённом хранилище кода и тестирование. К моменту проверки у инженера есть само исправление, сведения о сбое и результаты тестов.
Инженер изучает правки в привычном процессе выпуска программы и одобряет их на заранее определённом этапе. Так система участвует в ответственной работе с ограниченными полномочиями и под контролем людей.
В другой задаче система могла бы подготовить обновление записи о клиенте в CRM, черновик заказа поставщику, расчёт стоимости или документ на согласование. Для каждого случая нужно определить, что программа готовит сама и на какое действие требуется разрешение человека.
Четыре вопроса перед тем, как дать агенту право действовать
Какие сбои повторяются и уже хорошо изучены?
Для начала подходят случаи с понятными входными данными, ожидаемым результатом и правилами передачи специалисту. Сразу охватывать все возможные ошибки не нужно.
Какие сведения нужны агенту, чтобы правильно найти причину?
Нужно определить, какие журналы, записи, исходные системы и последние изменения помогут подготовить предложение для проверки.
Как проверить предложенное действие?
Перед изменением рабочих данных можно использовать правила бизнеса, тестовую среду, проверку структуры данных или требований.
Кто может разрешить следующий необратимый шаг?
До выпуска нужно определить этап одобрения человеком, права доступа, историю действий и условия остановки.
Это независимый разбор Maak.Digital о внедрении Daimler Truck, описанном Daimler Truck, CGI и AWS. Maak.Digital не разрабатывала систему и не участвовала во внедрении. Сведения о реализации, масштабе платформы и результатах взяты из статьи AWS от 12 октября 2026 года. Это данные компании и партнёров, которые Maak.Digital независимо не проверяла. Примеры за пределами устранения сбоев обозначены как возможные применения подхода.