Идан Ялович, соучредитель и генеральный директор Bluebricks, рассказывает на портале The New Stack о том, как оркестрация среды с помощью схем (blueprints) и ограждений делает развертывание инфраструктуры с помощью искусственного интеллекта реальностью.

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

Ничего подобного не происходит в отношении инфраструктуры.

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

Таким образом, хотя ИИ может генерировать приемлемый Terraform, управление облачной инфраструктурой по-прежнему остается без участия генеративного ИИ.

Почему так происходит?

Три препятствия для инфраструктуры, управляемой ИИ

1. Отсутствие контекста, отсутствие организационных знаний

Каждая компания имеет свои собственные рамки соответствия нормативным требованиям, архитектуру и бизнес-потребности, что приводит к различиям в инфраструктуре. Эти особенности не отражаются в инфраструктуре как коде (IaC); они хранятся в коллективных знаниях команд DevOps, платформенного инжиниринга и безопасности.

Попросите агента ИИ запустить базу данных, и он может сгенерировать действующий Terraform для экземпляра AWS Relational Database Service (RDS). Но он не будет знать:

  • Должна ли эта база данных быть мультирегиональной или однорегиональной?
  • Какова политика репликации для аварийного восстановления?
  • Какие стандарты соответствия нормативным требованиям применяются к этому набору данных?

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

2. Сложные технологические стеки и скрытые зависимости

Современные среды представляют собой сеть взаимосвязанных инструментов: Terraform, Helm, Ansible, облачные интерфейсы командной строки (CLI) и настраиваемые скрипты. ИИ может генерировать фрагменты кода для каждого уровня, но их правильная оркестрация — в нужном порядке и с учетом зависимостей — это совсем другая задача.

Инфраструктура не развертывается изолированно. Кластер Kubernetes зависит от сетей виртуального частного облака (VPC), политик управления идентификацией и доступом (IAM), секретов, интеграции мониторинга и многого другого. Отсутствие или включение одного элемента в неправильной последовательности — или общая неправильная последовательность — могут привести к каскадному сбою в производстве.

Что действительно нужно инфраструктуре, так это разделение задач, чтобы можно было развязать сложность и зависимости, а затем безопасно ее развернуть.

3. Разрыв между рисками и соответствием нормативным требованиям

В отличие от кода приложений, ошибочные изменения инфраструктуры сопряжены с риском. Один неверный шаг может привести к простоям, нарушениям безопасности или неуправляемым затратам на облачные услуги.

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

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

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

Чтобы преодолеть этот разрыв, ИИ-агентам необходимы три основополагающих элемента:

  1. Контролируемый набор заранее утвержденных вариантов, а не бесконечные возможности конфигурации.
  2. Четкие определения зависимостей, чтобы знать, что развертывать, в каком порядке и при каких условиях.
  3. Встроенные защитные механизмы для автоматического обеспечения соблюдения политик в отношении затрат, безопасности и соответствия нормативным требованиям.

Короче говоря: ИИ не нуждается в дополнительном интеллекте, ему нужна структура, или схемы.

Для этого необходима оркестрация среды.

Оркестрация среды: предоставление агентам ИИ недостающего контекста

Этот подход берет исходный код инфраструктуры и превращает его в повторно используемые и версионированные схемы, которые определяют, как инфраструктура может быть безопасно создана, изменена и использована. В то же время он обеспечивает строгое разделение задач, позволяя осуществлять сквозную автоматизацию между различными инструментами IaC и поддерживать стандарты. Это приводит к созданию стандартизированных пакетов развертывания, которые кодируют организационные правила и зависимости.

На данный момент ИИ-агенты не пишут Terraform самостоятельно и не создают рабочие процессы развертывания. Они также не получают доступ к «контексту», закодированному во внутреннем портале разработчиков.

Вместо этого они получают доступ к каталогу «схем» — фиксированному, неизменяемому меню вариантов.

При таком подходе система автоматической оркестрации среды:

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

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

ИИ-агентам нужен каталог надежной инфраструктуры

Такой подход делает каталог единственным достоверным источником информации о том, как развертывается инфраструктура. Он не выводится агентами, а готовится командой платформенных инженеров.

ИИ-агенты могут напрямую запрашивать этот каталог, чтобы понять:

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

Таким образом, когда разработчик запрашивает тестовую среду, ИИ-агенту не нужно гадать. Он выбирает заранее утвержденную схему, которая включает сеть, группы безопасности, кластер Kubernetes и базу данных — все в соответствии с политиками компании.

ИИ-агент больше не исследует бесконечное пространство конфигураций. Он выбирает проверенные варианты в рамках контролируемой структуры.

Защитные ограждения, обеспечивающие соблюдение политик

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

Это означает, что:

  • контроль затрат применяется последовательно;
  • политики безопасности встроены в каждое развертывание;
  • требования соответствия обеспечиваются на уровне проектирования.

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

Человеческий фактор в дизайне

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

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

Где ИИ показывает себя с лучшей стороны

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

Эластичное масштабирование

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

  • Нужно больше вычислительных ресурсов для задачи, ориентированной на CPU? Увеличьте масштаб.
  • Обрабатываете пиковые рабочие нагрузки? Расширьте масштаб.
  • Хотите оптимизировать затраты? Выбирайте спотовые инстансы в непиковые часы.

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

Самообслуживание разработчиков

Еще одним важным преимуществом является самообслуживание с помощью ИИ. Вместо того чтобы ждать несколько дней, пока будут обработаны заявки на инфраструктуру, разработчики могут запрашивать среды на естественном языке. Они могут попросить ИИ «запустить промежуточный кластер для платежного сервиса», и ИИ мгновенно предоставит его, используя заранее утвержденные схемы.

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

Скорость, безопасность и более разумное управление ресурсами

Развертывание инфраструктуры с помощью ИИ дает три основных результата:

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

В совокупности эти возможности переопределяют возможности команд DevOps и платформенных команд — не как постепенное повышение эффективности, а как фундаментальное изменение в способе предоставления инфраструктуры.

Будущее: ИИ и DevOps работают в гармонии

Агенты ИИ уже изменили способ, которым разработчики пишут и проверяют код. Следующим рубежом является инфраструктура, но для этого ИИ нужно больше, чем просто генеративная мощность. Ему нужны структура, контекст и ограничения.

В этой новой модели инженеры платформы и DevOps становятся архитекторами стандартов, фиксируя институциональные знания в схемах. Агенты ИИ становятся надежными исполнителями, развертывая инфраструктуру, которая является быстрой, удовлетворяющей нормативным требованиям и согласованной с бизнесом.