Принципы AI-driven инфраструктуры
AI-агенты отлично генерируют шаблонный код, разбирают логи и объясняют legacy-код. Но инфраструктура — не обычный код. У неё есть состояние, необратимость, каскадные зависимости, слабые связи и секреты прямо в рабочем потоке. Для LLM переименование ресурса и удаление базы — просто изменение строк.
Мои принципы, возможно, не идеальны, но это то, что сложилось за полтора года работы с агентами в инфраструктуре.
Подготовка среды
1. Принудительные ограничения
Агент не должен решать не ломать production — у него не должно быть возможности это сделать.
LLM нестабильно следуют запретам, особенно в длинных сессиях. Поэтому среда агента должна работать с инфраструктурой только в read-only. Мутирующие операции — только через отдельный pipeline после явного апрува человеком.
2. Секреты вне контекста агента
Контекстное окно — потенциальный канал утечки. State-файлы OpenTofu/Terraform содержат пароли, ключи и эндпоинты в открытом виде. Helm values и Ansible group_vars часто содержат учётные данные. Реальные атаки показали, что агенты, по умолчанию, обращаются с приватными данными как с любыми другими. Не делая для них исключений.
Методы защиты:
- Полная недоступность секретов
- Блокировка доступа к файлам
- Отсутствие упоминания файлов и их нестандартное размещение
- Использование файлов-обманок
3. Верификация источников и цепочки поставок
Агент использует MCP-серверы, skills, сторонние модули, community charts, расширения для IDE — каждый из них потенциальный вектор атаки.
Правило: агент подключает только явно разрешённые источники с фиксацией версий и lock-файлами. Новый MCP/skill/модуль/расширение добавляется только после ревью команды.
Постановка задачи
4. Контекст = код + состояние + решения
LLM видит файлы конфигурации, но не знает, что реально сейчас работает на серверах. Без контекста агент подставит “разумные значения по умолчанию” из обучающих данных. Поэтому агент должен получать данные из кода, от вас, из tofu plan, kubectl get, ansible-inventory, из описаний зависимостей, ограничений (бюджет, SLA, compliance) и причин решений (ADR, SRS). Всё, включая то, что “все и так знают” — все должно быть в контексте агента.
5. Делегируй только то, что дёшево проверить
Агент всегда может ошибиться — вопрос в том, насколько быстро и надёжно вы это обнаружите.
Стоимость проверки складывается из нескольких критериев:
| Критерий | Дёшево проверить | Дорого проверить |
|---|---|---|
| Автоматизация проверки | Есть инструменты: tofu validate, helm lint, molecule test | Только ручной анализ и экспертная оценка |
| Явность изменений | Изменения видны в plan/diff целиком | Побочные эффекты скрыты (DNS propagation, IAM policy evaluation, сетевые маршруты) |
| Количество зависимостей | Изолированный ресурс, мало связей | Каскадные зависимости между компонентами |
| Обратимость | Откат за секунды: tofu apply предыдущего состояния | Откат невозможен или требует даунтайма (миграция данных, смена CIDR) |
| Требуемая экспертиза | Любой инженер команды поймёт plan | Нужен глубокий контекст (сетевая топология, порядок миграции, compliance) |
6. Явная иерархия приоритетов
Агент не «чувствует», что такое потеря данных или даунтайм. Они для него по умолчанию менее важны, чем инструкции, а тем более запрос пользователя.
Без иерархии агент может в попытке оптимизации скорости или “чистоты” кода пренебречь, например, данными. Явный порядок в AGENTS.md:
- Сохранность данных и доступность сервисов
- Безопасность
- Соответствие стандартам
- Корректность реализации
- Скорость и удобство
Каждый уровень нельзя нарушать ради нижестоящего. Агент не удаляет и не пересоздаёт RDS ради “чистоты” (удобство vs сохранность данных). Не открывает 0.0.0.0/0, чтобы “заработало” (корректность vs безопасность). Не ставит force_destroy = true на S3, чтобы упростить код (удобство vs сохранность данных).
На этот же порядок должны быть настроены независимые автоматические ревьюеры, которые будут рассматривать правки как “чужой” код и не будут склонны его “оправдывать”.
Генерация кода
7. Маленькие шаги, частые контрольные точки
LLM деградируют на длинных цепочках рассуждений, а инфраструктурные изменения каскадны, там мало типизации и менее явные связи, чем в обычном коде.
Одна итерация = одно логическое изменение = один tofu plan / helm diff / ansible --check = один коммит. Не “мигрируй VPC целиком”, а “добавь subnet в новый AZ, покажи plan”. Каждая контрольная точка — место, где человек может остановиться и откатить один коммит, а не весь рефакторинг.
Верификация результата
8. Детерминистическая верификация вместо доверия
LLM плохо находит свои ошибки — просьба “проверь” часто приводит к убедительному обоснованию ошибочного ответа.
Результат агента проверяется цепочкой инструментов. Ключевой усилитель — замкнутый цикл обратной связи: агент видит вывод, исправляет ошибку, повторяет проверку. Качество результата пропорционально качеству обратной связи.
9. Автоматическая оценка зоны поражения
AI не понимает последствий — для него замена instance type и удаление RDS равнозначны. Поэтому зона поражения должна вычисляться автоматически из вывода инструментов: OPA/Sentinel policies на tofu plan, классификация операций (create/update/destroy), подсчёт затронутых ресурсов и их критичности.
Агент может подсвечивать несоизмеримость зоны поражения относительно решаемой задачи, но не должен даже оценивать степень, т.к. это расхолаживает оператора.
10. Контроль стоимости
AI-агент генерирует “разумную” конфигурацию из обучающих данных, но не имеет представления о вашем бюджете.
GPU-инстанс вместо CPU, NAT Gateway в каждом AZ, RDS с избыточными ресурсами — всё это выглядит корректно в plan, проходит валидацию, но может стоить в разы дороже необходимого.
Оценка стоимости (infracost, usage-based estimation) должна быть частью цикла обратной связи наравне с tofu validate и plan. Агент видит дельту стоимости и останавливается, если она превышает порог.
Команда и процесс
11. Противодействие деградации навыков
AI-код выглядит профессионально, проходит линтеры — и притупляет бдительность.
Исследования показывают более слабую когнитивную вовлечённость у пользователей AI-инструментов: хуже запоминают, меньше чувствуют ответственность. Команда, которая перестала понимать свою инфраструктуру, не сможет самостоятельно отреагировать на инцидент в ситуации, когда агент недоступен или не может получить полный контекст.
Контрмеры: регулярные “ручные дни” без агента, ротация on-call с обязательным разбором инфраструктуры, code review AI-кода с таким же вниманием, как к коду джуниора, периодические учения по инцидентам без доступа к AI.
Все принципы сводятся к одной идее: AI-агент — мощный генератор, но не арбитр. Он пишет код, а детерминистические инструменты и люди решают, можно ли этот код применять. Чем дешевле проверить результат — тем больше можно делегировать.