Как подготовить ИТ-инфраструктуру к работе ИИ-агентов и не потерять контроль

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

— Илья, расскажите коротко, чем вы занимаетесь?

Уже много лет работаю с крупной распределенной ИТ-инфраструктурой: начинал как инженер, сейчас руковожу техническими программами, отвечающими за её надёжность и безопасность. Последние три года моя основная задача - встраивание ИИ-агентов в процессы эксплуатации: как сделать так, чтобы агенты реально снимали нагрузку с дежурных инженеров, а не создавали новые риски. Через мои проекты прошли и внедрение агентов в реагирование на инциденты, и защита от самих агентов, и перестройка инфраструктуры под их работу - обо всём этом расскажу подробнее.

— С чего компании стоит начинать, если она хочет, чтобы ИИ-агенты «бесшовно» встроились в инфраструктуру?

Не с агентов - они уже готовы работать, вопрос в готовности компании. Начинать нужно с инвентаризации: какие сервисы есть, какие операции критичны, где агент реально снимет нагрузку. Дальше, разложить всё по уровням критичности: что должно работать всегда, что может быть затронуто, но восстановлено в короткий срок (минуты-часы), а что вспомогательное. И только потом - доступы, причём агенту сначала даётся доступ только на чтение: диагностика, сбор данных, отчёты. Запись - отдельный, более поздний этап.

По опыту, самая частая проблема - наблюдаемость. Системы спроектированные для людей не различают, кто сделал изменение: человек или агент. Когда значимая часть изменений в инфраструктуре создаётся агентами, а в логах это выглядит как действия людей, вы фактически слепы. Вторая проблема - интерфейсы, рассчитанные только на человека: если агенту не дать безопасный программный путь, он найдёт небезопасный обходной. Третья - отсутствие аварийного выключателя: возможности за секунды отключить агентов от сервиса, не влияя на доступ инженеров.

— Что вообще меняется в архитектуре систем, когда в контур добавляются агенты?

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

— Как понять, что инфраструктура готова к агентам, а что — рано?

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

— Вы говорите, что функционал и безопасность здесь вступают в противоречие. Можете объяснить на примере?

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

Это не единичный случай. За последний год появился целый класс инцидентов - их называют «захват агентом»: агент действует не со зла, а просто оптимизирует результат без границ и выходит за рамки того, что ему разрешили. При активном внедрении агентов мы поначалу фиксировали рост числа инцидентов на 40% и рост времени на расследование на 70% - это ожидаемо на старте, а дальше эффект уходит в плюс за счёт того же внедрения агентов в реагирование.

— Что тогда обязательно нужно ограничивать?

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

— Как в итоге найти баланс, чтобы не «убить» пользу агентов и не создать риск?

Считать, а не гадать. У нас 99,95% агентских операций - это чтение, диагностика, генерация кода и конфигов, и только 0,05% - потенциально катастрофические операции записи. Значит, ограничивать нужно именно эти доли процента, а не всё подряд. Дальше - измерять «трение»: где агент остановлен правильно и это предотвратило инцидент, а где зря - это ложное срабатывание и потерянная продуктивность, и убирать именно вредное трение. И правило по умолчанию простое: сначала закрыть доступ, потом решать, кому и когда его открыть, а не наоборот.

— Расскажите о проекте, где ИИ-агенты сами реагируют на инциденты.

Контекст: инфраструктура данных с более чем 60 показателями доступности, тысячами сервисов, тремя серьезными инцидентами за полгода и перегруженными дежурными инженерами. Раньше на сбор контекста при инциденте, что горит, что менялось, какие есть зависимости - уходило 30–60 минут даже у опытного инженера. Теперь агент за 2–5 минут собирает хронологию, ищет корреляции с прошлыми похожими инцидентами и выдаёт дежурному готовую сводку с рекомендацией действий. Это 10–12-кратное ускорение на самом критичном этапе, пока причина не найдена, система не чинится. Часть действий, вроде перезапуска некритичных задач, агент выполняет сам, а на откат прод-конфигурации всегда запрашивает подтверждение человека.

— А что с защитой от самих агентов и перестройкой инфраструктуры под их работу?

Здесь задача в том, что агент - не человек: он делает не пять изменений в день, а пятьсот, у него нет интуиции «что-то не так», и его проще обмануть вводными данными. Мы построили программу защиты на четырёх столпах: идентификация - у каждого агента своя идентичность, отдельная от пользователя, который его запустил; контроль - блокировка катастрофических операций на уровне ядра операционной системы и API; наблюдение - дашборд агентской активности и детектор аномалий в реальном времени; реагирование - восстановление меньше чем за час во всех сервисах где агентам разрешены изменения. В итоге «трение» на уровне критичных API - меньше 0,0004%: защита практически не мешает нормальной работе, но надежно ловит опасное.

Параллельно пришлось перестраивать саму инфраструктуру - она изначально проектировалась под людей. Консольные команды с текстовым выводом «для глаз» заменяли на структурированные интерфейсы с понятными агенту кодами ошибок, доступы - с принципа «есть ключ, делай что хочешь» на точечные разрешения по типу агента, а конвейер доставки кода научили отличать, когда автор изменения не человек, и применять к таким изменениям более строгие проверки.

— Какой измеримый результат в итоге?

Сбор контекста при инциденте — с 30–60 минут до 2–5, это в 10–12 раз быстрее. Ежемесячные отчёты по надёжности для нескольких инфраструктурных подразделений с двух дней ручной работы до двух часов. Классификация сервисов по риску, которая вручную заняла бы месяцы, — теперь занимает дни, а при повторном прогоне обрабатываются только изменившиеся сервисы. Пятая часть всех изменений в коде инфраструктуры сейчас создаётся агентами, и это чистый прирост, а не замена людей. Операционные затраты в итоге сократились примерно вдвое. Но главный результат - изменился характер работы: раньше инженер тратил 60% времени на рутину и 40% на настоящие инженерные задачи, сейчас пропорция разворачивается в обратную сторону.

— Куда, на ваш взгляд, движется это направление в ближайший год-два?

Думаю, в первую очередь закончится этап «первопроходцев». То, что сегодня в каждой компании изобретается заново - идентификация агентов, разделение доступов по зонам доверия, аварийные выключатели, станет стандартной практикой, как в своё время CI/CD или мониторинг. Появятся общепринятые протоколы описания инструментов для агентов - что-то в духе того, что сейчас каждая компания строит у себя, но уже на уровне отрасли, а не внутри одной организации.

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

А по-человечески изменится сама профессия инженера эксплуатации: меньше «тушить пожар в три часа ночи», больше - учить систему тушить его самостоятельно.