Изменения инфраструктуры, созданные ИИ, требуют более строгого согласования

Как выглядит эта проблема в реальной жизни

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

Это и есть радиус поражения простыми словами: насколько далеко разойдётся плохое изменение после релиза. Баг с маленьким радиусом поражения раздражает одну группу пользователей или ломает одну страницу. Баг с большим радиусом поражения может одновременно положить вход в систему, платежи, админку, плановые задания и процессы поддержки.

С AI-generated infrastructure changes риск выше, потому что результат часто выглядит аккуратно и уверенно. Инструмент может за секунды изменить правило firewall, настройку load balancer, имя секрета или права базы данных. Патч выглядит безобидно. Последствия затрагивают всех.

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

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

Помогает простое сравнение:

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

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

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

Почему инфраструктурные правки требуют более строгого согласования

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

Инфраструктурные изменения так не работают. Одна правка в сетевом правиле, load balancer, DNS-записи, секрете или настройке базы может затронуть всех пользователей одновременно. Поэтому AI-generated infrastructure changes нуждаются в более строгом ревью, чем обычные изменения кода.

Разница хорошо видна. Если ИИ предлагает плохое изменение UI, одна страница может выглядеть неправильно. Если он предлагает плохое правило firewall, путь health check или ingress policy, трафик может остановиться для всего продукта. То же самое касается хранилищ, очередей и service discovery. Общие системы создают общий отказ.

С базой данных нужно быть ещё осторожнее. Миграция может выглядеть безобидно в diff и всё равно заблокировать загруженную таблицу, удалить данные или заставить старый и новый код по-разному понимать формат записи. ИИ может написать корректный SQL и всё равно не учесть тайминг, порядок или план отката. Production-базы быстро наказывают за мелкие ошибки.

Изменения секретов — ещё одна частая ловушка. Если менять API token, environment variable или переносить учётные данные в новое хранилище, можно одним деплоем сломать логины, вызовы платежей, фоновые задания и внутренние сервисы. Команда часто замечает проблему только после того, как сессии истекут или начнут накапливаться повторы запросов.

Почему обычного согласования недостаточно

Обычное code review спрашивает: «Это работает?» Контроль инфраструктурных изменений должен спрашивать другое: «Кого ещё это затронет?» «Можно ли откатить это за минуты?» «Что будет, если ИИ ошибся?»

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

Командам, которые быстро работают с ИИ, нужны более строгие согласования по радиусу поражения, а не более мягкие. Здесь осторожность — не бюрократия. Это базовая безопасность.

Какие изменения должны идти по узким цепочкам согласования

Большая часть кода приложения может идти через обычный flow pull request. Инфраструктурным правкам нужен более узкий путь, с меньшим числом людей, которые могут их утвердить, и с более понятной ответственностью. Одна неверная строка в policy-файле может отключить трафик, открыть данные или сломать деплои для всех сервисов сразу.

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

Отправляйте в строгую цепочку такие изменения

Начните с сетевых правил. Правки firewall, изменения security group, ingress- и egress-правила, VPC routing, настройки VPN, DNS-записи для production-трафика и обновления policy в service mesh могут менять, кто с кем разговаривает. Небольшая ошибка может заблокировать платежи, открыть внутреннюю админку или сломать вызовы между сервисами.

Изменения базы данных должны идти по той же цепочке. Сюда входят schema migrations, удаление индексов, переименования таблиц, изменения политики хранения, настройки репликации, правила резервного копирования и любые изменения ролей базы или прав доступа. ИИ может написать миграцию, которая хорошо выглядит в diff, но всё равно заблокирует горячую таблицу или удалит данные, которые понадобятся задаче через час.

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

Сюда же относятся изменения идентификации и прав. IAM roles, права облачного аккаунта, токены для деплоя, права CI runner и production admin access заслуживают назначенных ревьюеров. Если права на утверждение слишком широкие, ошибки распространяются быстро.

Что можно оставить в обычной цепочке

Не каждую правку конфигурации нужно отправлять в строгий путь. Изменение текста, не production-настройка логов, подпись на дашборде или feature flag для одного сервиса обычно не требуют такого же барьера. Граница не в том, лежит ли файл в папке infrastructure. Граница — в последствиях.

Для большинства команд работает простое разделение. Оставьте одну цепочку для изменений, которые затрагивают один сервис, одно окружение или удобство разработчиков. Используйте строгую цепочку для изменений, которые влияют на общие сетевые пути, общие хранилища данных, секреты, доступ, резервное копирование или восстановление production. Для срочных исправлений держите отдельную emergency-цепочку, но требуйте короткое follow-up review, когда пожар уже потушен.

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

Как настроить правила шаг за шагом

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

Большинство команд уже по-разному проверяют код приложения и доступ к production. Инфраструктуре нужно такое же разделение, особенно когда AI-generated changes могут затронуть сеть, базы данных, секреты и пути деплоя в одном pull request.

Постройте цепочки согласования

Сортируйте изменения по тому, что они затрагивают, а не по тому, кто их написал. Terraform-правка, которая меняет теги или логирование в непроизводственной среде, — это не то же самое, что изменение VPC routes, firewall rules, database roles или rotation секрета. Разложите всё по небольшим risk bucket, чтобы ревьюерам сразу было понятно, в какую цепочку попало изменение.

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

Назначенная ответственность важна. У каждой рискованной области должен быть конкретный человек, а не alias команды, в политике согласования. Если за production networking никто лично не отвечает, никто не заметит, что ИИ-инструмент открыл порт, который в diff выглядел безобидно, но изменил реальную поверхность атаки.

Ограничьте каждый запрос одной рискованной областью. Не позволяйте одному pull request одновременно менять security groups, database grants и значения секретов. Более маленькие запросы ускоряют ревью. И ещё они делают откат гораздо безопаснее.

До любого согласования требуйте письменные шаги отката. Делайте их короткими и простыми:

1. Укажите, что именно изменится.
2. Укажите, как это отменить.
3. Укажите, как проверить, что откат сработал.
4. Назовите человека, который выполнит откат, если что-то пойдёт не так.

Сделайте правило удобным

Команды пропускают правила, если они кажутся тяжёлыми. Сделайте решение простым: короткий шаблон в каждом рискованном запросе на изменение — затронутая область, владелец, второй ревьюер, план отката и окно деплоя.

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

Один практический пример: AI-ассистент предлагает изменение, которое обновляет Kubernetes manifests и одновременно ротирует production API secret. Разделите это на два запроса. Пусть владелец платформы проверит изменение manifests. Пусть владелец секрета проверит план ротации, место хранения и заметку по откату. Два маленьких согласования обычно занимают меньше времени, чем одно большое и запутанное ревью, и при этом уменьшают радиус поражения, если инструмент ошибся в части изменения.

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

Простой пример из растущей команды

Небольшая SaaS-команда работает быстро. У них шесть инженеров, один product manager и AI coding assistant, который помогает с pull request, тестами и небольшими рефакторингами. В обычную неделю такая схема экономит им часы.

В одну пятницу команда добавляет новую страницу отчётности для клиентов. ИИ предлагает два изменения в одном pull request. Сначала он обновляет API-код, чтобы страница могла загружать данные отчёта. Потом он меняет слой доступа к базе данных, чтобы reporting service мог читать из billing table, к которой раньше не имел доступа.

На первый взгляд pull request выглядит аккуратно. Код приложения понятен, тесты проходят, а функция работает в staging. Вот здесь команды и попадают в неприятности с AI-generated infrastructure changes. Один diff может смешивать безопасную правку UI или API с гораздо более рискованным изменением прав.

Эта команда не относится к обоим изменениям одинаково.

API-код идёт по обычному пути ревью. Два инженера проверяют логику, запускают тесты и утверждают изменения. У этой части радиус поражения ограничен. Если в коде есть баг, команда быстро откатит его.

Изменение доступа к базе идёт по другому пути. Их правила говорят, что любая правка, которая меняет сетевые правила, права базы данных, доступ к секретам или production roles, должна проходить через более узкую цепочку согласования. Backend-ревьюер проверяет область запроса. Владелец инфраструктуры проверяет изменение прав. Один человек вне feature-команды подтверждает, что сервис получает только тот доступ, который ему нужен.

Этот дополнительный шаг находит настоящую проблему. ИИ выдал reporting service слишком широкий доступ на чтение всей billing schema, а не только к данным, нужным для новой страницы. Он также предложил переиспользовать существующий production secret вместо того, чтобы выдать отдельный.

Команда исправляет обе части до merge. Они создают view, который показывает только нужные столбцы. Они выпускают новый secret с более узким scope и коротким окном ротации. Код приложения почти не меняется, а риск сильно падает.

Без такого более строгого пути функция, скорее всего, вышла бы с более широким доступом, чем кто-либо хотел. Позже один баг, утёкший токен или неправильный запрос могли бы раскрыть billing data или замедлить базу для всех.

Команда по-прежнему работает быстро. Просто они принимают, что code review и access review — это разные задачи. Одно это правило не даёт маленькой функции превратиться в полноценный outage.

Ошибки, которые команды совершают, когда слишком доверяют инструменту

Обычно проблема не в том, что модель каждый раз пишет плохой код. Проблема в том, что люди начинают относиться к AI-generated infrastructure changes как к обычным pull request, даже когда одна маленькая правка может закрыть доступ пользователям, сломать деплой или открыть данные.

Частая ошибка — собирать несвязанные изменения в одну пачку. Один набор правок может включать исправление в приложении, изменение security group, миграцию базы и ротацию секрета. На бумаге это экономит время ревью, но на деле ухудшает оценку риска. Ревьюеры просматривают всё бегло. Они утверждают безобидное изменение в приложении и пропускают сетевое правило, которое открывает слишком много доступа. Когда у инфраструктуры широкий радиус поражения, каждому рискованному изменению нужна своя цепочка и свой ревьюер.

Секреты — ещё одно место, где команды быстро начинают халтурить. Если AI-инструмент может менять tokens, API keys или credentials базы без названного человека-владельца, никто не несёт полной ответственности, когда что-то идёт не так. Кто-то должен владеть каждым изменением секрета, подтверждать, откуда взялось новое значение, и проверять, кто или что от него зависит.

Экстренные исправления вызывают другой тип ущерба. Команды спешат с production-патчем, пропускают заметки по откату и говорят себе, что задокументируют всё позже. Позже почти никогда не наступает. Потом патч ломается под нагрузкой, и никто не помнит старую настройку, предыдущий image tag или порядок, нужный, чтобы отменить изменение. План отката не обязан быть длинным. Он просто должен существовать до деплоя.

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

Staging тоже вызывает слишком много доверия. Изменение может пройти там все тесты и всё равно провалиться в production, потому что там другой профиль трафика, размер данных, таймауты, права и ограничения сторонних сервисов. Миграция базы, которая выглядит чисто на маленькой копии, может тянуться минуты на живой таблице. Изменение секрета может работать в staging, потому что его использует меньше сервисов.

Когда команда видит тревожные признаки, ей нужно остановиться до merge. Обратите внимание, если pull request смешивает правки приложения, сети, базы и секретов или если у изменения нет названного владельца для обновления учётных данных. Остановитесь, если заметка по откату отсутствует или слишком расплывчата, чтобы выполнить её в стрессе. Остановитесь, если одни и те же люди утверждают вообще все типы изменений. И остановитесь, если staging прошёл, но никто не проверил риски, которые есть только в production.

Эта пауза кажется раздражающей. Восстанавливать доступ в 2 часа ночи гораздо хуже.

Быстрые проверки перед merge или deploy

Небольшой инфраструктурный diff может менять гораздо больше, чем кажется. Одна подсказка ИИ может задеть правило firewall, роль базы данных и имя секрета в одном коммите. Этого достаточно, чтобы сломать вход в систему, заблокировать трафик или открыть данные, если никто не замедлится и не проверит точное изменение.

Перед тем как что-то утвердить, оцените радиус поражения простыми словами. Не спрашивайте: «Это выглядит разумно?» Спросите: «Какие системы почувствуют это в ближайшие 10 минут?» Если в ответе есть production-сетевые пути, клиентские данные, auth, резервные копии или секреты, относитесь к этому строже, чем к обычному коду приложения.

Перед merge хорошо работает короткая проверка:

• Назовите каждую систему, которую может затронуть эта правка, включая побочные эффекты.
• Подтвердите владельца каждой системы.
• Сначала протестируйте изменение в меньшем объёме.
• Сделайте откат быстрым и скучным.
• Прочитайте точный diff, а не только краткое описание ИИ.

Простой пример показывает, почему это важно. Ассистент предлагает commit с «чисткой», который удаляет старый secret, обновляет Kubernetes manifest и ужесточает права базы данных. В summary всё звучит безобидно. Diff показывает, что один сервис всё ещё читает старое имя секрета при запуске, а reporting job всё ещё нуждается в правах, которые только что удалили. Если команда смотрит только summary, она сливает ошибку в main.

Меньшие тесты ловят это раньше. Разверните manifest в staging, ротируйте secret для одного сервиса и запустите reporting job на копии или в ограниченной среде. Это займёт немного больше времени, но гораздо дешевле, чем production-инцидент в 16:00.

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

Что делать дальше

Начните с малого и выберите изменения, которые могут навредить быстрее всего. Для большинства команд это сетевые правила, изменения схемы или прав базы данных и всё, что касается секретов. Именно здесь AI-generated infrastructure changes могут за одно слияние перейти из полезных в дорогостоящие.

Не перестраивайте весь процесс сразу. Напишите короткий набор правил, который подходит размеру команды и скорости релизов. Команде из четырёх человек не нужен такой же путь согласования, как компании с отдельными владельцами platform, security и data. Сделайте правила простыми: кто может предложить изменение, кто обязан его проверить и какое подтверждение нужно до деплоя.

Хороший первый шаг прост. Вынесите сетевые, базовые и секретные правки в отдельную цепочку согласования. Требуйте ревьюера, который отвечает за эту область, а не просто любого инженера из дежурной очереди. Просите короткую заметку о влиянии, откате и затронутых системах. Заблокируйте auto-merge для этих файлов, даже если обычный код приложения может сливаться автоматически. Логируйте каждое исключение, чтобы команда могла позже его разобрать.

Потом смотрите назад, прежде чем смотреть вперёд. Возьмите выборку недавних infrastructure pull request и отсортируйте их по риску. Обычно вы увидите, что на вид маленькие изменения имели больший радиус поражения, чем ожидалось: открытый порт, переименование секрета, из-за которого сломались деплои, или изменение базы, которое выглядело безопасно, но заблокировало таблицу в неподходящий момент. Этот быстрый разбор даст вам реальные примеры, и ваши правила согласования будет легче отстаивать.

Поддерживайте процесс в живом состоянии. Раз в месяц для большинства команд достаточно. Пересматривайте инциденты, near miss, события отката и изменения, которые заняли больше времени, чем ожидалось. Если какое-то правило создаёт трение без пользы для безопасности, уберите его. Если один класс изменений продолжает создавать проблемы, ужесточите его.

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

Если вашей команде нужна внешняя помощь в настройке таких цепочек, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как fractional CTO и advisor. Он помогает командам ужесточить AI-assisted engineering, review инфраструктуры и правила согласования, не превращая каждый деплой в совещание.