🚧 Агенты нашли причину сбоя, подготовили исправление и прогнали проверки. Дальше по процессу правка ждёт инженера.
Так описан разбор IT-сбоев на портале послепродажного обслуживания TASP! в Daimler Truck: 36+ приложений, 130 000+ пользователей. Материал описывает один портал, а не всю IT компании.
Раньше инженер надёжности искал причину, делал небольшую правку и выкатывал её. Теперь подготовка и выпуск разведены по шагам процесса.
🧯 Пример авторов: сервису выделили слишком мало памяти, и он падает. Один агент ищет причину и предлагает правку, но может только читать. Другой применяет её в изолированной среде, только для разрешённых хранилищ кода, и прогоняет проверки.
🧾 Если они прошли, агент открывает заявку на изменение с правкой, причиной и результатами проверок. Её утверждает инженер, и только потом правка идёт в выпуск.
Цифры от участников проекта: ручной разбор с подготовкой правки занимал в среднем 2–3 часа на инцидент, а на отработанных классах ошибок автоматический цикл вместе с проверкой и утверждением человеком занимает 15 минут.
🖊️ Какую долю правок инженеры возвращают, материал не раскрывает. По этому числу я и судил бы, докуда пускать агента. Но в любой такой схеме мало возвратов может значить и сильного агента, и проверку, ставшую формальностью.
🛑 Какие исправления вы разрешили бы агенту готовить, но не выпускать без инженера?
Источник: разбор Daimler Truck, CGI и AWS, 12.10.2026.
· 12 ч
Мне тут больше всего зацепило, что правку агент только готовит, а утверждает инженер. 15 минут против 2-3 часов звучит красиво, но без доли возвратов цифра мало что говорит.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён