Как провести пилотный проект (POC) платформы IaC: что тестировать за две недели

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

В этой статье мы рассмотрим наиболее частые причины провала POC платформ IaC, необходимые предварительные условия перед началом, двухнедельный план POC платформы IaC, то, что действительно стоит протестировать (контрольный список для оценки в рамках POC), а также способы сравнения платформ после завершения POC.

Что мы рассмотрим:

• Каковы наиболее частые причины провала POC платформ IaC?
• Перед началом: предварительные условия для POC
• Двухнедельный план POC платформы IaC
• Что действительно нужно протестировать: контрольный список для оценки в рамках POC
• Как сравнить платформы после завершения POC

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

Прежде чем что-то планировать, полезно узнать, почему POC платформ IaC часто терпят неудачу.

• Вы тестируете идеальный сценарий: Вендоры дают вам чистый пример репозитория с четырьмя ресурсами, и все работает ожидаемо. В вашей реальной конфигурации есть файл состояния на 3000 строк, модуль, к которому никто не прикасался с 2024 года, и провайдер с жестко зафиксированной версией по непонятным уже причинам. Если ваш POC не включает хотя бы один сложный сценарий, вы тестируете маркетинг, а не продукт.
• Вы не определяете, что такое «хорошо»: Без предварительных критериев вы в итоге выберем то, что больше всего впечатлило вас на последней демонстрации. В следующем разделе мы рассмотрим, как этого избежать.
• В POC не участвуют реальные пользователи: Если ваши платформ-инженеры провели POC и считают его отличным, это не значит, что, например, команда разработки приложений будет думать так же. Если люди, которые будут пользоваться платформой каждый день, ни разу ее не попробовали, вы тестировали не удобство внедрения, а собственные предпочтения.
• Вы забыли, что сама платформа создает дополнительную работу: Вы выбираете инструмент, а затем спустя семь месяцев ваша команда тратит большую часть времени на поддержку самой платформы вместо доставки инфраструктуры. Ваша цель — сосредоточиться на написании, планировании и применении инфраструктуры, не перегружая себя управлением лежащей в основе платформой. Поэтому во время POC спросите себя, сколько усилий потребуется на обслуживание каждого варианта, а не сколько работы он экономит вам сегодня.
• Две недели могут превратиться в два месяца: Из-за отсутствия фиксированной даты завершения сроки POC могут размываться. Чтобы избежать этого, установите двухнедельный срок и строго придерживайтесь его.

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

• Способность масштабироваться вверх и вниз в зависимости от нагрузки: Инфраструктурные нагрузки могут существенно колебаться; у вас могут быть спокойные дни, а затем день релиза, когда поступает двадцать запусков одновременно. Платформа должна справляться с этим без необходимости вручную контролировать пул воркеров.
• Простые рабочие процессы для инженеров: Ваши команды приложений должны иметь возможность создать pull-request, увидеть план и применить свои изменения без изучения нового процесса. Каждый лишний шаг, который вам приходится объяснять, — это шаг, на котором теряется внедрение.
• Оперативная техническая поддержка: Если что-то пойдет не так в продакшене в неурочный час, скорость ответа вендора является характеристикой продукта, и POC — это ваш единственный шанс проверить ее до подписания контракта.
• Модель ценообразования, которая остается логичной по мере масштабирования: Вам нужно понимать свои затраты не только на текущую инфраструктуру, но и на случай, когда у вас будет в три раза больше стеков и вдвое больше инженеров. Ценообразование ведет себя совершенно иначе по мере роста.
• Готовность к внедрению агентских рабочих процессов в инфраструктуре: Сегодня команда генерирует код Terraform с помощью LLM, настраивает серверы MCP и позволяет агентам открывать pull-requests для инфраструктуры. Проверьте, есть ли у платформы API, поддержка MCP и план взаимодействия агентов с инфраструктурой; если нет, вам придется заменить ее раньше, чем вы думаете.

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

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

Заранее разберитесь с доступами, поскольку интеграция с VCS, учетные данные облака и сетевой доступ — это частые причины застоя POC. Если вашей службе безопасности требуется неделя на одобрение соединения OIDC или новой роли IAM, отправьте запрос заранее и расставьте приоритеты соответствующим образом.

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

Запишите свои базовые показатели. Сколько времени сейчас занимает построение плана? Сколько ручных шагов существует между слиянием (merge) и применением (apply)? Как часто вы обнаруживаете дрифт конфигурации (drift)? Вы не сможете продемонстрировать улучшение без начальной точки отсчета.

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

День 1 и День 2: Подключение и импорт

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

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

День 3: Запуск базового рабочего процесса от начала до конца

Создайте pull request, получите план, просмотрите его, выполните merge и проследите за применением (apply). Это тот цикл, в котором ваши инженеры будут жить каждый день.

Проверьте, какая часть плана отображается непосредственно в самом pull request, а для какой требуется отдельно открывать платформу. Затем повторите этот цикл с изменением, которое должно завершиться ошибкой, и посмотрите, достаточно ли понятно сообщение об ошибке, чтобы инженер мог исправить ее самостоятельно.

День 4: Добавление зависимостей и модулей

Реальная инфраструктура — это не просто плоский список конфигураций; в ней есть организационный стек, управляющий папками и IAM, отдельные стейджинг- и продакшн-стеки, на которых работают ваши кластеры, хранилища и базы данных, а также стек общих служб, содержащий такие вещи, как развертывание ArgoCD и ваши CI-раннеры.

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

День 5: Дайте приложению пройти тестирование инженером

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

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

Дни 6 и 7: Политики и ограничения

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

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

День 8: Масштабирование и нагрузка

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

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

День 9: Режимы сбоев и поддержка

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

Для дрифта измерьте время получения уведомления и выясните, может ли платформа устранить изменения самостоятельно или только сообщает о них. Основывайте тикет в поддержке на реальной проблеме из пилотного проекта (POC), а не на тестовом вопросе.

День 10: Стоимость и итоговый отчет

Оцените стоимость при вашем текущем размере и при увеличении масштаба в три раза. Затем запишите свои выводы и решите, подходит ли вам эта платформа по-прежнему.

Запросите письменное коммерческое предложение с указанием всех допущений и проверьте, как изменится цена при добавлении еще одного окружения, 20 новых инженеров или единого входа (SSO). Ограничьте отчет одной страницей на каждую платформу и завершите его на десятый день.

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

Способность масштабироваться вверх и вниз в зависимости от нагрузки

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

Простые рабочие процессы для инженеров

• время до первого успешного плана и время импорта существующего стека с реальным состоянием
• читаемость вывода плана в пул-реквесте
• понятность утверждений и истории запусков для кого-то еще, кроме вас
• связывание стеков и передача результатов между ними
• реестр модулей, версионирование и шаблоны для новых стеков
• способность необученного инженера самостоятельно выкатить изменения
• поддержка инструментов, которые вы уже используете, например OpenTofu, Terraform, Pulumi, Ansible, Kubernetes

Оперативная техническая поддержка

• время отклика по реальному тикету, открытому во время POC
• полнота и качество документации для экстренных ситуаций
• вы общаетесь с очередью или с живым человеком

Модель ценообразования, которая остается логичной по мере масштабирования

• как выглядит счет при увеличении объема в три раза
• как устроено тарифицирование (за ресурс, за пользователя, особенности работы воркеров)
• скрытые затраты: дополнительные окружения, дополнительные воркеры, SSO как платный аддон

Готовность к внедрению рабочих процессов агентской инфраструктуры

• покрытие API и поддержка MCP
• достаточно ли строгие политики и RBAC для безопасной работы агента
• качество аудиторского следа, так как вам нужно знать, что именно сделал агент

Команды уже настраивают рабочие процессы Terraform, созданные с помощью LLM, строят внутренние инфраструктурные агенты, используют MCP для получения сводок по стекам и экспериментируют с агентскими процессами. Эта работа возможна только на платформе, которая изначально к ней готова.

Оценив каждую платформу, просмотрите результаты и взвесьте те критерии, которые вы определили как принципиальные.

Еще один вопрос, который стоит задать себе перед принятием решения о том, какая платформа подходит вам лучше:

• Какую из них предпочли инженеры приложений? Выбирайте платформу, которую ваши инженеры не избегают, иначе вы платите за нее дважды.
• Какая платформа потребует меньше всего времени на обслуживание? Здесь следует подумать о поддержке пула воркеров, обновлениях и пользовательском коде, который пришлось написать для адаптации платформы под ваши процессы. Нужно помнить, что нагрузка на обслуживание со временем возрастает.
• Какая система продолжает работать при увеличении масштаба в три раза? Сопоставьте результаты нагрузочного тестирования и масштабируемого ценообразования, ведь дешевизна сегодня и проблемы при масштабировании — плохой выбор.

Если по итогам оценки две платформы набрали примерно одинаковое количество баллов, выберите ту, которая обеспечила лучшую поддержку во время POC.

Как Spacelift подходит к оценке и проведению POC

Spacelift проводит пилотные проекты на вашей инфраструктуре, а не в песочнице. Вы подключаете свою систему контроля версий (VCS), импортируете существующие стеки и используете собственные облачные аккаунты, получая полный контроль над всем происходящим внутри платформы.

Вам доступна поддержка нескольких инструментов инфраструктуры (Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes и Ansible), политика как код на основе Open Policy Agent (OPA) в нескольких точках принятия решений, зависимости с возможностью обмена выводами между конфигурациями, инфраструктура самообслуживания, общие переменные, хуки жизненного цикла и монтируемые файлы для конфигураций, встроенный ИИ и многое другое.

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

Команды, выбирающие Spacelift, обычно останавливаются на нем по трем конкретным причинам:

• Надежность в масштабе (автоматическое масштабирование под нагрузку)
• Простота в эксплуатации (легкость подключения и очень отзывчивая служба поддержки в случае возникновения трудностей)
• Создано с расчетом на будущее (гибкость OpenTofu, политики и шаблоны, а также путь к агентским рабочим процессам)

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

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

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

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

Если вы хотите узнать больше о Spacelift и начать работу с пилотным проектом (POC), запишитесь на демонстрацию к одному из наших инженеров.