В сфере технологий всё меняется с головокружительной скоростью — за исключением инфраструктуры DevOps.
На самом деле, Джордж Фахми, соучредитель и генеральный директор Stakpak, говорит, что управление инфраструктурой становится все сложнее — и это несмотря на волну искусственного интеллекта. Или, может быть, именно из-за нее?
«С появлением LLM [больших языковых моделей]… мы поняли, что они действительно хорошо справляются с программированием — и большинству разработчиков это действительно нравится», — отмечает он. «Но они совершенно не справляются со всем остальным, с чем приходится иметь дело разработчикам».
Именно это он и команда Stakpak решили изменить: «сделать LLM надежными во всех тех задачах, которые разработчики на самом деле не любят выполнять».
«Дела», которые разработчики не любят делать (и с которыми ИИ не справляется)
Фахми считает, что настало время кардинально пересмотреть инфраструктуру DevOps, отмечая, что даже автономные транспортные средства за последние годы добились большего прогресса, чем инструментарий для инфраструктуры.
Как он сам говорит: «Мы пытаемся сделать инфраструктуру автономной, чтобы разработчики могли уделять больше времени… созданию реальных продуктов».
Так что же это за «задачи», которые разработчики не любят выполнять?
Это трудно определить. DevOps превратился в разношёрстный набор обязанностей, выходящий за рамки программирования и включающий такие задачи, как настройка локальных машин, конфигурация облачных сред, а также управление конвейерами развёртки и производственными системами.
Именно эта смесь «всего, кроме кухонной раковины» сделала DevOps таким неудобным пространством для LLM.
«[При] задачах по программированию вы просто генерируете код, и он работает… Но в DevOps есть миллион вещей… помимо программирования, и LLM с этим плохо справляются», — говорит Фахми. Хуже того, разработчики «ненавидят заниматься всем этим».
Проблемы возникают с обеих сторон. Мало того, что задачи DevOps известны как обуза для разработчиков, так еще и навыки, необходимые для их выполнения, в отрасли просто не хватает. В отчете Linux Foundation «Состояние рынка технических талантов 2024» 51% организаций назвали DevOps одной из «ключевых технологических областей, приоритетных для найма персонала», при этом среднее время на заполнение этих вакансий составляет почти шесть месяцев.
«На мировом рынке существует огромный дефицит специалистов, обладающих такими знаниями и опытом», — подтверждает Фахми. «Люди постоянно пытаются нанять специалистов по DevOps… и DevSecOps… но не могут найти нужных талантов».
В наши дни идея заключается в том, чтобы автоматизация — а точнее, ИИ — вышла на первый план и заполнила пробелы, когда не хватает времени и квалифицированных кадров. Но Фахми говорит, что это не работает для инфраструктуры:
«Мы видели, что агенты по кодированию… они хороши в кодировании, но они не были созданы для такого рода инфраструктурной работы».
С его точки зрения, все сводится к трем основным проблемам.
Задача 1: обеспечение безопасности производственных систем и секретной информации
DevOps требует работы с действующими системами и обработки конфиденциальных данных, но Фахми говорит, что инструменты, на которые сегодня полагаются большинство агентов ИИ, не соответствуют требованиям безопасности производственного уровня.
«Именно поэтому мы начали перестраивать этот инструментальный слой и сделать его открытым исходным кодом, — объясняет он, — потому что мы хотим установить стандарт безопасности, необходимой для работы в производственной среде».
Он имеет в виду Stakpak — полностью открытый агент DevOps, который помогает разработчикам защищать, развертывать и поддерживать инфраструктуру, готовую к производственному использованию.
По словам Фахми, Stakpak решает эту проблему безопасности, позволяя LLM взаимодействовать с конфиденциальными системами, не раскрывая секретов: «Мы занимаемся редактированием конфиденциальной информации и секретов и позволяем LLM работать с конфиденциальными данными, не видя самих данных».
Задача 2: Предотвращение разрушительных операций в разрозненных инструментах
Безопасность — не единственная проблема, мешающая разработчикам безопасно автоматизировать работу с инфраструктурой. Растущее число инструментов управления инфраструктурой также создает проблемы.
«Существуют сотни различных инструментов и сотни различных способов выполнения одной и той же задачи», — объясняет Фахми. «Поэтому можно использовать три или четыре разных инструмента… или объединить их».
Звучит удобно: больше вариантов, больше гибкости. Но на самом деле огромное количество инструментов (и все противоречивые мнения, которые с ними связаны) только создает больше путаницы, трений и рисков.
Проблема усугубляется, когда ИИ-агенты — те, которые должны помогать разработчикам управлять этими инструментами — в итоге создают новые проблемы.
Фахми вспоминает печально известный провал Replit, когда агент случайно стер всю кодовую базу какой-то несчастной компании.
«Эти агенты и модели — они очень креативны», — говорит он. «Они могут найти множество разных способов сделать одно и то же… Это кошмар для людей, пытающихся держать их под контролем».
По его словам, Stakpak может положить конец этому кошмару с помощью Warden — системы защиты, которая не дает агентам выполнять разрушительные операции.
Как это возможно? Фахми говорит, что система изолирует агенты-программисты в песочнице, где явные правила безопасности блокируют небезопасные операции: «Например, вы можете перечислить свои ресурсы в AWS, но не можете их удалить, независимо от того, какой инструмент вы используете для работы с AWS».
По его словам, это радикальный отход от типичных методов управления агентами, которые, как он утверждает, не работают: «Невозможно использовать одного агента, чтобы помешать другому агенту что-то сломать». Также нельзя просто занести определенные действия в черный или белый список, поскольку это создает невыполнимую задачу — вручную перечислить все возможные сценарии.
Вместо этого Warden предоставляет детерминированный способ предотвращения выполнения агентами разрушительных операций, независимо от того, какой инструмент (или инструменты) они используют.
По признанию Фахми, это не особенно ценно для программирования. Но он утверждает, что это кардинально меняет ситуацию при выполнении операционных задач, таких как миграция баз данных, обновления или другие изменения инфраструктуры, где «одна неправильная команда может привести к сбою всей системы».
Задача 3: Научить агентов учиться, делиться и запоминать знания
Фахми не сдерживается: «LLM [ужасно] справляются с работой с инфраструктурой».
Он объясняет это в основном фрагментацией: команды DevOps по уши в инструментах, но каждый из них говорит на своем языке. LLM усугубляют ситуацию, надежно обрабатывая только самые распространенные языки программирования.
Вот почему Фахми говорит, что Stakpak направила значительную часть своих исследований и разработок на устранение пробелов в знаниях LLM: «чтобы научить LLM использовать новые инструменты, на которых они никогда не обучались…; [чтобы] приобрести новые знания, которые они никогда раньше не [видели]… что является огромным вызовом».
В отличие от агентов кодирования, где можно добавлять знания путем создания новых файлов правил, агентам DevOps для эффективной работы нужна общая база знаний — и, по словам Фахми, Stakpak решает эту задачу с помощью централизованных сборников правил и объединенной памяти:
«Мы считаем, что это станет прорывом, потому что в сфере инфраструктуры не хватает не столько инструментов…; здесь не хватает эффективного способа усваивать новые знания и затем передавать их».
Stakpak решает эту задачу с помощью централизованных сводов правил, которые определяют стандартные операционные процедуры, а также внутренних оценочных критериев, которые измеряют соответствие, чтобы гарантировать, что агенты последовательно следуют правильным процедурам при адаптации к каждой среде.
Это лишь одна часть уравнения. Между тем, объединенная память позволяет агентам учиться на прошлых сессиях. Когда член команды завершает задачу, модели рассуждений извлекают ключевые воспоминания, так что когда агент используется другим членом команды, он запоминает и применяет эти усвоенные знания.
Этот общий пул памяти разрушает информационные барьеры, которые Фахми описывает как самое большое препятствие в DevOps: «Команда платформы или инфраструктуры [могла] создать что-то, а разработчики до сих пор не знают [об этом]… [или о том, что это] может облегчить им жизнь».
Следующий вызов
Конечно, это не конец пути для автоматизации инфраструктуры. Фахми говорит, что Stakpak уже занимается следующим шагом: обеспечением самосовершенствования агентов.
«Что, если вы сможете брать плохие или хорошие примеры и передавать их обратно в систему, чтобы помочь ей точно настроить свои собственные параметры и становиться лучше по мере работы?»
По мере развития автоматизации инфраструктура DevOps, возможно, наконец-то начинает наверстывать упущенное — долгожданное обновление для разработчиков, уставших заниматься всем этим «барахлом».
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться