Инфраструктура как код: что это и почему руководителю стоит разобраться
Понятное объяснение «инфраструктуры как кода» для нетехнических собственников и менеджеров - что это решает, чего стоит и какие вопросы задавать команде.
«Инфраструктура как код» - или IaC - одна из тех инженерных фраз, которые звучат понятно, но на деле таковыми не являются. Фраза точная, но неполная. Сегодня почти каждая команда выше определённого размера использует что-то подобное, но я всё ещё регулярно встречаю собственников и операционных директоров, которые смутно понимают, что это значит, не осознавая, что это подразумевает для бизнес-решений.
Этот пост для них.
Какую проблему это решает
Несколько лет назад стандартный способ настроить сервер или облачную среду - кликать по консоли, вручную конфигурировать настройки и записывать важные решения в документ, который обычно устаревал в течение месяца. Это работало, пока сред было мало и они были стабильны.
Облачные вычисления это сломали. Теперь у компании может быть среда разработки, тестовая среда, продакшн, среда аварийного восстановления и отдельная среда для нового продукта - каждая с десятками настроенных сервисов, сетевых правил, прав доступа и настроек хранилища. Поддерживать всё это в синхронизированном состоянии вручную и вести точную документацию практически невозможно.
Инфраструктура как код - это ответ на эту проблему. Вместо клика по консоли инженеры пишут конфигурационные файлы, описывающие, как должна выглядеть инфраструктура. Эти файлы хранятся в системе контроля версий рядом с кодом приложения. Когда нужна новая среда - запускаете конфигурационные файлы, и среда создаётся автоматически, идентично любой другой среде, созданной из тех же файлов.
Что это меняет для бизнеса
Практические последствия для руководителя существенны:
Воспроизводимость. Любую среду можно пересоздать с нуля за минуты. Если продакшн серьёзно сломался - его можно воссоздать. Если нужно протестировать что-то в среде, точно копирующей продакшн - к вечеру она будет готова.
Аудиторский след. Поскольку конфигурация живёт в системе контроля версий, можно увидеть, что именно изменилось, когда и кто это сделал. Это актуально для проверок безопасности, соответствия требованиям и отладки инцидентов.
Независимость команды. Разработчики могут создавать собственные среды без участия операционной команды. Это снижает время ожидания и риск человеческой ошибки при ручной настройке.
Контроль затрат. Среды, определённые в коде, можно создавать и удалять программно. Временные тестовые среды не должны работать по ночам и в выходные, что снижает расходы на облако.
Что это стоит
IaC не даётся бесплатно. Основная стоимость - обучение и начальная настройка. Написание конфигурации инфраструктуры требует навыков и дисциплины. Если конфигурационные файлы сами становятся непоследовательными или плохо организованными, получается другой вариант исходной проблемы - среда без документации, которую никто полностью не понимает, только теперь написанная на коде, который никто не решается редактировать.
Распространённые инструменты в этой области - Terraform, Pulumi, AWS CloudFormation, Ansible - каждый со своей моделью и ограничениями. Команды, которые используют их хорошо, инвестируют время в определение соглашений: как организованы файлы, как параметризованы среды, как изменения ревьюируются перед применением.
Что спросить у команды
Если ваша команда управляет облачной инфраструктурой и не использует инфраструктуру как код - стоит понять, почему. Ответ не всегда плохой. Иногда среда действительно простая и накладные расходы не оправданы.
Но если ответ «мы не дошли до этого» - спросите, что произойдёт, если ваш ведущий DevOps-инженер уйдёт. Сможет ли кто-то другой воссоздать продакшн с нуля? Сколько это займёт? Насколько команда уверена, что результат будет правильным?
Если ответы неопределённые - риск реален. IaC - не просто инструмент повышения продуктивности разработчиков. Это часть операционной устойчивости компании.
Если ваша команда уже использует IaC, полезные уточняющие вопросы:
- Хранятся ли конфигурации инфраструктуры в той же системе контроля версий, что и код приложения?
- Есть ли процесс ревью для изменений инфраструктуры - такой же, как для изменений кода?
- Может ли новый член команды создать среду разработки без помощи конкретного старшего инженера?
Эти вопросы покажут, реально ли используется IaC или только номинально.