Агенты искусственного интеллекта незаметно создают хаос и инженерные сбои, которые предприятия пока не отслеживают.

Саяли Патил

Существует категория производственных инцидентов, которые инженерные группы пока не отслеживают, поскольку они не вписываются ни в один из существующих шаблонов анализа причин сбоев.

Агент инициировал действие. Действие было технически корректным, учитывая контекст, в котором находился агент. Контекст был неполным. Инфраструктура дала сбой. И к моменту анализа инцидента три команды спорили о том, был ли это сбой агента или сбой инфраструктуры, потому что концепции, позволяющие рассматривать эти два явления, никогда не были связаны между собой.

Масштабы этой проблемы уже не теоретические. 79% организаций уже используют ту или иную форму ИИ-агента в производственной среде, а 96% планируют расширение. Gartner прогнозирует, что к 2028 году 33% корпоративного программного обеспечения будет включать в себя агентный ИИ, но отдельно предупреждает, что 40% этих проектов будут отменены из-за недостаточного контроля рисков.

Ни одна из этих статистических данных не отражает режим отказа, происходящий между этими двумя показателями: работающие агенты, которые не отменяются и которые незаметно генерируют события в инфраструктуре, которые никто не классифицировал как риск.

Я шесть лет занимался разработкой систем автоматизации инфраструктуры корпоративного масштаба, сначала в Cisco (где руководил платформами управления жизненным циклом на основе ИИ, развернутыми у более чем 20 глобальных корпоративных клиентов), а затем в Splunk (разрабатывал рабочие процессы анализа первопричин и мониторинга с использованием ИИ в тысячах корпоративных сред).

В это же время я подал заявку на патент на методологию хаос-инженерии, основанную на намерениях. И на протяжении всего этого времени я наблюдал, как организации совершают одну и ту же структурную ошибку: рассматривают автономных агентов и хаос-инженерию как отдельные дисциплины. Это не так. Это одна и та же дисциплина, и разрыв между ними незаметно порождает следующую волну крупных производственных инцидентов.

Решение, которое агенты упускают из виду.

Чтобы понять, почему это важно, необходимо разобраться в том, что на самом деле не так в том, как предприятия управляют хаосом сегодня, прежде чем добавлять к этой картине агентов.

Большинство зрелых инженерных организаций инвестировали в программы по изучению хаоса. Это и игровые дни, и контроль радиуса взрыва, и эксперименты с ограничением по уровню значимости (SLO). Когда инженер-человек запускает эксперимент по изучению хаоса, последовательность действий обладает критически важным свойством: человек принимает решение о том, способна ли система выдержать возмущение прямо сейчас. Он проверяет панели мониторинга. Он смотрит на скорость расходования бюджета ошибок. Он оценивает стабильность зависимостей. Это несовершенно и часто интуитивно понятно, но, по крайней мере, есть человек, который задает правильный вопрос, прежде чем что-либо запустится.

Когда вы внедряете автономного агента по устранению неполадок, способного перезапускать сервисы, перенаправлять трафик, масштабировать ресурсы или изменять конфигурации в ответ на обнаруженные аномалии, этот вопрос исчезает. Агент видит аномалию. Агент предпринимает действие. Это действие — событие хаоса. Никакой проверки скорости расхода SLO. Никакого расчета радиуса взрыва. Никакого человеческого суждения о том, подходящее ли сейчас время для дополнительной нагрузки на систему, которая уже может испытывать давление с трех других сторон.

Вот конкретный пример сбоя, который я наблюдал. Агент восстановления обнаруживает повышенную задержку в микросервисе и реагирует перезапуском кластера сервисов; это разумное действие, учитывая его обучающие данные и узкое понимание инцидента. Чего агент не знает: три других сервиса обрабатывают пиковый трафик. Общий пул соединений уже загружен на 87%. Зависимая база данных выполняет фоновое перестроение индексов. Перезапуск запускает массированную атаку на восстанавливающийся сервис.

То, что начиналось как скачок задержки, который агент был призван устранить, превращается в каскадную реакцию, которую агент никогда не был предназначен моделировать. Радиус поражения от действий агента не ограничивался перезапуском службы. Он затронул все, что произошло после перезапуска, в состоянии системы, о котором агент не имел полного представления.

Ни в одной программе по хаотической инженерии не проверяли именно такое сочетание. Ни в одном расчете радиуса взрыва агент не рассматривался как действующее лицо. Потому что мы не воспринимаем агентов как инжекторы хаоса. А следовало бы.

Согласно базе данных инцидентов, связанных с ИИ, количество зарегистрированных инцидентов, связанных с ИИ, выросло на 21% с 2024 по 2025 год. Эта цифра почти наверняка занижает реальный уровень риска, поскольку большинство организаций не имеют классификации инцидентов, которая бы фиксировала действия автономного агента как первопричину каскада. Инцидент регистрируется как перезапуск службы, перегрузка пула соединений или событие задержки. Агент остается невидимым при анализе причин сбоя.

Поглощающая способность — это ресурс; большинство систем не рассматривают его как таковой.

Основная проблема заключается в том, что в корпоративных системах отсутствует общий язык для оценки допустимой нагрузки — оценки в реальном времени того, какой дополнительный стресс может выдержать система, прежде чем она нарушит свои обязательства по уровню обслуживания (SLO). Программы хаос-инженерии управляют этим неявно, посредством человеческого суждения и статических пороговых значений, которые срабатывают после того, как предел уже превышен. Агенты вообще этим не управляют.

В ходе структурированного первичного исследования с участием специалистов по обеспечению надежности сайтов (SRE) и платформенной инженерии из таких организаций, как Intuit и GPTZero, я разработал модель бюджета отказоустойчивости. Основная идея заключается в том, чтобы рассматривать поглощаемую мощность как постоянно пересчитываемый, потребляемый ресурс, а не как статический порог, который вы стараетесь не превышать.

Бюджет отказоустойчивости основан на четырех классах сигналов, находящихся в режиме реального времени.

• Основной входной параметр — скорость расходования SLO, поскольку она напрямую отражает разницу между текущим поведением системы и действительно важным обязательством. Если система расходует свой ежемесячный бюджет ошибок в пять раз быстрее, чем ожидалось, то бюджет отказоустойчивости близок к нулю независимо от загрузки ЦП.

• Динамика задержки P99 важнее, чем абсолютное значение задержки, поскольку тенденция к росту показателя за сорок минут говорит об обратном, в отличие от показателя, который оставался стабильным на том же абсолютном значении.

• Состояние насыщения зависимостей — это наиболее часто упускаемый из виду сигнал; эксперимент по созданию хаоса или действие агента, предполагающее свободную доступность общего пула соединений, когда он заполнен на 87%, приведет к сбоям, которые никто не предусмотрел.

• Сигналы поведения приложений, показатели завершения сессий, изменения в шаблонах вызовов API, снижение конверсии и нагрузка на систему проявляются раньше, чем это делают инфраструктурные метрики, поскольку пользователи ощущают ухудшение до того, как Prometheus сообщит об этом.

Отличие этого бюджета от порогового значения заключается в том, что он является расходным. Каждый эксперимент по созданию хаоса использует доступные ресурсы. Каждое действие агента использует их. В организациях с несколькими командами, где одновременно могут проводиться многочисленные эксперименты и действовать несколько агентов, бюджет распределяется между всеми участниками.

Без общего реестра потребления две команды, проводящие эксперименты с пересекающимися зависимостями, приводят к суммарному взрывному эффекту, который ни одна из команд не планировала. Добавьте к этому автономных агентов, действующих полностью вне этого реестра, и учет рухнет.

Где языковые модели помогают, и где именно они терпят неудачу.

В настоящее время несколько инженерных организаций проводят эксперименты с использованием больших языковых моделей (LLM) для генерации гипотез о причинах хаоса на основе графов зависимостей и корпусов данных, полученных в результате анализа инцидентов. Результаты имеют важное значение. Языковые модели выявляют правдоподобные режимы отказов, которые опытные инженеры SRE считают достойными проверки, и генерируют гипотезы быстрее, чем ручные процессы, особенно при работе с обширной историей инцидентов.

Предел — это устаревание графа зависимостей, и это жесткий предел. Гипотеза, сгенерированная на основе графа, который не отражает извлечение сервисов за прошлый месяц или новую зависимость от общей библиотеки, добавленную два спринта назад, предложит эксперимент с неверными предположениями о радиусе взрыва. Проблема не в том, что модель совершает ошибку, а в том, что модель не знает о своей ошибке. Она будет уверенно ошибаться относительно границы системы, которой больше не существует, а в хаос-инженерии уверенная неточность в производственной среде означает незапланированный сбой.

Исследовательская лаборатория Trustworthy AI при Стэнфордском университете обнаружила, что одних лишь защитных механизмов на уровне модели недостаточно: атаки с тонкой настройкой обходили ведущие модели в большинстве протестированных случаев. Для генерации гипотез хаоса это имеет прямое значение: модели, которая не может надежно поддерживать собственные границы безопасности, нельзя доверять в точном моделировании радиуса взрыва действия, которое она никогда не видела в графе зависимостей, который она не проверяла.

Когда при формировании гипотез используются данные, полученные в ходе анализа инцидентов, проблема устаревания значительно уменьшается. Анализ инцидентов описывает сбои, которые действительно произошли в системе в определенный момент времени. Сигнал по своей сути подтверждается производственной реальностью. Это наиболее перспективное ближайшее применение ИИ в этой области, и оно действительно полезно для организаций с развитыми методами документирования инцидентов.

Искусственный интеллект не может и не должен принимать решения о выполнении задач, когда сигналы неоднозначны. Для этого требуется учитывать факторы, которые находятся вне любой системы мониторинга: незавершенные развертывания, изменившие структуру зависимостей час назад, уровень дежурства персонала в праздничные выходные, обязательства перед клиентом, которые делают любой дополнительный риск неприемлемым до понедельника.

Модель, не имеющая доступа к этому контексту, не должна принимать такое решение. Это не временное ограничение, ожидающее появления более совершенной модели. Это структурное ограничение того, что может представлять собой машинная наблюдаемость, и создание архитектуры агента, игнорирующей это ограничение, означает создание такой архитектуры, которая в конечном итоге примет важное решение, имея неполную информацию, — и без участия человека, который мог бы это учесть.

Что это означает для того, как предприятия управляют агентами в процессе производства?

Описать последствия управления довольно просто, но реализовать это сложнее, чем кажется. Каждое действие автономного агента, затрагивающее инфраструктуру, должно регистрироваться на том же уровне сигналов в реальном времени, который управляет экспериментами в условиях хаоса. Те же показатели расхода SLO, тенденции задержки, состояния насыщения зависимостей, которые инженер-человек проверил бы перед началом эксперимента, должны определять, что и когда разрешено делать агенту. Если бюджет отказоустойчивости ниже определенного уровня, агент ждет или переходит к эскалации. Он не действует.

Действия агентов также необходимо моделировать как эксперименты, а не просто регистрировать как события. Когда агент перезапускает службу, вопрос не только в том, успешно ли завершился перезапуск. Важно, был ли радиус поражения от этого действия пропорционален доступной поглощающей способности и какие каскадные эффекты он вызвал в зависимостях. Это данные для хаос-инженерии. Они должны быть включены в бюджетную модель, определяя следующее решение, которое должен принять агент или команда.

А когда сигналы действительно неоднозначны, когда оценка бюджета неясна, когда недавнее развертывание изменило топологию таким образом, что контекстное окно агента этого не фиксирует, когда состояния зависимостей находятся в постоянном изменении, решение о выполнении должно быть передано человеку. Не как постоянное ограничение автономности агента, а как жесткое инженерное требование для текущего состояния технологии.

Механизм автоматического отключения, передающий неоднозначные случаи человеку, не является недостатком архитектуры агента. Именно он делает архитектуру достаточно надежной для работы в производственной среде. Верификация на основе намерений формализует именно это: определение того, как должно выглядеть корректное поведение агента до развертывания, а затем непрерывная проверка того, соблюдаются ли эти границы в условиях реальной системы.

Организации, которые надежно используют автономных агентов в масштабах предприятия, — это не те, у кого самые сложные модели. Это те, кто еще до того, как что-то пошло не так, поняли, что каждое действие агента — это событие, вызывающее хаос, и построили свою систему управления соответствующим образом.

Первый практический шаг не отличается привлекательностью: проведите аудит каждого автономного агента, в данный момент взаимодействующего с инфраструктурой, сопоставьте его действия с сигналами скорости расхода SLO в реальном времени и определите четкие минимальные условия, ниже которых агент должен ждать или передать задачу на более высокий уровень. Этот аудит выявит агентов, действующих полностью вне рамок вашего учета отказоустойчивости.

Большинство организаций, использующих агентов в больших масштабах, сегодня имеют несколько таких агентов. Найдите их до того, как это сделает производственная среда.

Саяли Патил более 6 лет проработала в компаниях Cisco Systems и Splunk, занимаясь разработкой систем обеспечения надежности и автоматизации, которые поддерживают бесперебойную работу корпоративной инфраструктуры искусственного интеллекта в масштабах предприятия.

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций — это площадка, где технические эксперты делятся своими знаниями и предоставляют нейтральные, непредвзятые аналитические материалы по искусственному интеллекту, инфраструктуре данных, кибербезопасности и другим передовым технологиям, формирующим будущее предприятий.

Узнайте больше о нашей программе гостевых публикаций — и ознакомьтесь с нашими рекомендациями, если вы заинтересованы в написании собственной статьи!

Подпишитесь, чтобы получать самые свежие новости!

Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.

VB Daily AI Weekly Еженедельник AGI Еженедельник по безопасности Еженедельник по инфраструктуре данных Мероприятия VB Все они

Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.

Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.

Источник: venturebeat.com