Gremlin представила Foresight AI — надстройку, которая самостоятельно запускает контролируемые сбои в инфраструктуре, анализирует телеметрию и предлагает исправления. Для команд, развивающих хаос-инжиниринг с ИИ, это попытка переложить на модель самую рутинную часть работы SRE: подготовку эксперимента, разбор последствий и поиск вероятной первопричины.
Как сообщает The Register, новый инструмент дополняет существующую платформу Gremlin для chaos engineering. Компания позволяет намеренно добавить задержку в сеть, остановить Kubernetes-поды, исчерпать память или вывести из работы отдельный компонент — и проверить, продолжит ли сервис обслуживать пользователей. Смысл не в том, чтобы эффектно уронить прод, а в том, чтобы обнаружить слабое место в контролируемых условиях, до реального инцидента.
Gremlin основал Колтон Андрус, ранее занимавшийся хаос-инжинирингом в Netflix. Именно Netflix больше десяти лет назад сделал подход популярным за пределами узкого круга специалистов по надёжности: распределённую систему нельзя признать устойчивой только потому, что она пережила набор unit- и integration-тестов. Она должна выдерживать пропавший сервер, медленную сеть, нехватку ресурсов и частичную недоступность облачного региона.
Foresight AI строит работу вокруг агентов, установленных в инфраструктуре клиента. Они выполняют разрешённые воздействия, а облачный сервис Gremlin сопоставляет их с сигналами мониторинга и алертами. После этого система должна определить причину деградации, подготовить изменение конфигурации или кодовый фикс и либо передать результат инженеру, либо применить его — если такой уровень автоматизации разрешён правилами компании. Цикл повторяется, пока эксперимент больше не воспроизводит отказ.
Главный аргумент Gremlin — не просто использование большой языковой модели, а привязка её ответов к собственной базе Failure Atlas. По словам Андруса, в ней собраны миллионы экспериментов по хаос-инжинирингу, проведённых за десятилетие на десятках тысяч систем. Компания утверждает, что эта база помогает модели опираться на проверенные сценарии, а не собирать объяснение из случайных знаний интернета. Для работы используются разные открытые и закрытые модели: выбор зависит от того, какая из них лучше справляется с задачей в конкретный момент.
Это важное отличие от многих AIOps-инструментов, которые подключаются уже после падения сервиса и предлагают вероятную причину инцидента. Хаос-инжиниринг с ИИ меняет последовательность: сначала безопасно моделируется неприятный сценарий, затем система ищет исправление. В теории это сокращает время от гипотезы до проверки. На практике качество результата будет зависеть от полноты наблюдаемости, корректности алертов и того, насколько команда умеет ограничивать эксперимент.
С ограничениями у Gremlin всё ожидаемо строго. Платформа использует права доступа и защитные механизмы заказчика, чтобы сузить так называемый радиус поражения. Это не декоративная деталь: агент, который умеет убивать поды и потреблять память, без жёсткой политики доступа превращается из средства проверки надёжности в готовый сценарий инцидента. Поэтому автоматическое применение исправлений выглядит разумным только для хорошо описанных сред и обратимых изменений; для критичных систем логичнее оставить финальное решение SRE.
Основная аудитория Gremlin — крупные компании с вычислительно сложной инфраструктурой, включая финансовый сектор, ритейл и корпоративные SaaS-платформы. Там сервис используют для проверки планов аварийного восстановления, тестов Kubernetes-масштабирования и работы систем в деградированном режиме. Для российских команд картина знакомая: распределённые сервисы растут быстрее, чем способность вручную проверять все комбинации отказов, особенно когда инфраструктуру и прикладной код всё активнее генерируют ИИ-инструменты.
Аналитик Intellyx Джейсон Инглиш предупреждает, что сервис, намеренно ломающий систему «во благо», потребует одобрения на самом высоком уровне компании. И это, пожалуй, ключевой вопрос для рынка: смогут ли инженерные и риск-команды договориться, где заканчивается полезный эксперимент и начинается неприемлемый риск. Чем быстрее ИИ помогает выпускать код и конфигурации, тем ценнее становятся системы, способные так же быстро и контролируемо искать в них сбои. Детали подхода и комментарии главы компании приведены в материале .