Назад в ленту

ИИ-агенты: тихие диверсанты в вашей инфраструктуре. Обзор TechLoot

Привет, гики! С вами TechLoot, и сегодня мы поговорим о теме, которая может заставить поседеть даже самых опытных сисадминов. По данным VentureBeat, ваши ИИ-агенты, эти тихие трудяги, возможно, уже вовсю устраивают хаос в вашей инфраструктуре, а вы об этом даже не подозреваете.

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

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



И вот где кроется засада: агенты работают, но генерируют такие инциденты, которые никто не классифицирует как риски. Они просто "тихо" создают события в инфраструктуре, которые остаются незамеченными.

В чем же проблема? Все дело в том, что мы относимся к автономным агентам и chaos engineering как к разным дисциплинам. А это одна и та же дисциплина, и разрыв между ними порождает следующую волну серьезных инцидентов.

Чтобы понять, почему это важно, нужно разобраться, что сломано в том, как предприятия управляют хаосом сегодня, прежде чем добавлять агентов в картину. Большинство зрелых инженерных организаций инвестировали в программы chaos engineering. Game days, blast radius controls, SLO-gated experiments. Когда инженер-человек инициирует эксперимент с хаосом, у последовательности есть критическое свойство: человек принимает решение о том, есть ли у системы возможность поглотить возмущение прямо сейчас. Они проверяют панели мониторинга. Они смотрят на скорость сгорания бюджета ошибок. Они оценивают, стабильны ли зависимости. Это несовершенно и часто интуитивно, но, по крайней мере, есть человек в цикле, задающий правильный вопрос, прежде чем что-либо запустится.

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



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

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

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