В работе с заказчиками мы часто видим такую картину: Terraform, Ansible, GitLab CI – все это уже есть. А ручной работы меньше не стало. Сеть по-прежнему настраивают в отдельной консоли, доступы согласуют по почте, мониторинг подключают после запуска, а изменения в продуктивную среду иногда вносят вручную.
Меня зовут Василий Демидов, я руковожу практикой виртуализации, контейнеризации и частных облаков в К2Тех. Разберу, почему IaC – подход «инфраструктура как код» – буксует даже в зрелых командах, где проходят границы автоматизации и как превратить набор скриптов в управляемый инфраструктурный контур.
Как мы брали инфраструктуру под контроль
Когда компании нужно часто создавать и обновлять среды разработки и тестовые контуры, ручная подготовка окружений становится узким местом. Особенно заметен этот разрыв в командах, которые используют ИИ-инструменты для подготовки кода: изменения уже готовы к проверке, а среду для них еще нужно заказать, согласовать и собрать. В такой ситуации важно ускорить не отдельную операцию, а весь путь от запроса до готового окружения. Для этого вместе с автоматизацией приходится менять привычный порядок работы.
Начнем с примера из практики. В одной логистической компании среднего размера регулярно падала инфраструктура. К сбоям все давно привыкли, но в какой-то момент объем ручной работы, необходимой для оперативного восстановления, просто превысил возможности системных администраторов. Прежнюю команду реорганизовали, а нас наняли как антикризисную группу: взять неуправляемую систему под контроль.
Мы начали с полного сетевого аудита. Внятной проектной документации не было, а сведения о топологии сети держали в голове несколько инженеров. Но, как выяснилось, даже у них не было полной картины. Мы прозвонили все порты и составили карту коммутации, которая отражала реальные соединения.
Неподписанные порты, неочевидные маршруты, петли и разнобой в конфигурациях – в сети хватало самых разнообразных проблем. Только устранив большинство из них, можно было переходить к настройке управляемых коммутаторов через Ansible, затем – к настройке операционных систем и лишь потом – к сервисам и прикладному ПО. Это последовательная работа: на каждом следующем этапе опираешься на уже приведенный в порядок уровень инфраструктуры.
Сервисы, работавшие на физических серверах, мы перенесли в виртуальную среду. Подключались к каждому серверу, разбирали конфигурацию, описывали ее в духе IaC и запускали сервисы заново в автоматически развернутых виртуальных машинах, а на освободившееся оборудование устанавливали гипервизоры. Так за один цикл охватили виртуализацией почти весь актуальный парк оборудования и попутно избавились от ручной настройки значительной части инфраструктуры.
По ходу этой работы провели инвентаризацию, чтобы не переносить в код весь накопленный беспорядок. Вообще, переход на IaC – хорошая возможность разобраться, какие ресурсы задействованы, какие сервисы на них работают и кто за них отвечает.
Параллельно мы с самого начала разворачивали новые сервисы по модели IaC. Компания как раз расширялась и активно наращивала мощности. Мы отладили GitOps, выстроили регламенты и наладили постоянное обновление документации. Технически контур стал управляемым. А вот с процессами дело обстояло сложнее – межфункциональные согласования не были формализованы, и часть из них по-прежнему держалась на личных договоренностях.
Как выглядит управляемая инфраструктура
Общий порядок работы с IaC может выглядеть так: конфигурации хранятся в Git, изменения проходят проверку и применяются через CI/CD. Автоматизируется настройка сети, операционных систем, инфраструктурных сервисов и прикладного ПО. При этом команда заранее определяет, кто готовит изменения, кто их проверяет и как они попадают в рабочую среду.
Новые сервисы сразу разворачиваются по новым принципам, а существующие постепенно автоматизируются. Для этого, эксперты по IaC сначала разбирают их настройки и описывают в коде. Затем регулярно проверяют соответствие кода реальной конфигурации. Если кто-то внес ручную правку, сначала выясняют, зачем она понадобилась, и решают, нужно ли перенести ее в код или вернуть прежнюю настройку.
В крупных организациях эти процессы могут стать основой внутренней инфраструктурной платформы. С ее появлением разные подразделения получают единый способ заказывать ресурсы, например, через YAML-манифест с согласованным набором полей.
Такой запрос запускает согласованную цепочку действий: создание виртуальной машины, настройку сети, выдачу доступов и подключение мониторинга. Чтобы эта цепочка заработала, подразделениям придется договориться о составе запроса и распределении ответственности. Например, ИБ определяет требования к доступам, а эксплуатация – к мониторингу и сопровождению. Эти договоренности закрепляют в общих правилах обработки запросов.
Допустим, новому сотруднику нужно виртуальное рабочее место. Сотрудника оформляют в 1С, система передает запрос платформе, которая создает рабочее место с нужным ПО и предусмотренными доступами. Для типовых запросов заранее определяют допустимые конфигурации, необходимые проверки и ответственных за сопровождение, поэтому каждый такой запрос не приходится согласовывать заново.
Почему инструменты решают не все
Опыт показывает, что освоить инструменты проще, чем перестроить процессы внутри компании, причем меняться приходится не только ИТ-отделу, но и другим подразделениям. Однако на определенном этапе внедрения IaC это становится необходимым: всем участникам процесса нужно освоить согласованные инструменты и, главное, действительно ими пользоваться. И нет, больше нельзя просто открыть конфигурацию и вручную поправить переменную. Чем глубже автоматизация, тем больше усилий уходит на то, чтобы договориться о порядке работы.
Это часто сложнее, чем решить технические задачи. На старте проекта руководство охотно поддерживает изменения, но со временем трансформация неизбежно затрагивает привычную рутину: сдвигаются сроки, меняются права доступа, ломаются отлаженные процессы. Пользователи начинают выражать недовольство, и под этим давлением менеджмент нередко тормозит внедрение. Именно поэтому поддержка руководства очень важна в переходный период, когда неудобства уже появились, а польза еще неочевидна.
Новый порядок нужно проверить на обычных рабочих задачах. Инженеру должно быть понятно, где взять типовую конфигурацию, как проверить изменение и к кому обратиться, если что-то не сработало. Если каждый раз приходится заново разбираться в инструментах и искать нужного человека в соседнем отделе, пользоваться автоматизацией будет сложно даже при полной поддержке руководства.
Вдобавок переход на IaC редко начинается с чистого листа. Практически наверняка у компании уже есть работающая инфраструктура, и администраторы заняты ее эксплуатацией. К их повседневным обязанностям добавляются новые задачи: описать существующие системы в коде и перевести их под централизованное управление. Приходится одновременно поддерживать инфраструктуру и перестраивать ее. Причем остановка на полпути лишь увеличивает нагрузку на команду: если переход застревает, инженерам приходится поддерживать две среды – автоматизированную и старую ручную. Нагрузка растет, а бизнес обещанного эффекта не видит.
Первый работающий сценарий автоматизации можно быстро подготовить с помощью ИИ. Однако после этого команде предстоит проверить его поведение при ошибках, разграничить права доступа, организовать проверку изменений и определить, кто будет сопровождать решение. Эти задачи нужно учитывать при оценке сроков и трудозатрат проекта: быстрый первый результат может создать слишком оптимистичное представление об объеме оставшейся работы.
Что сделать для перехода
Прежде чем затевать трансформацию, стоит определить, какую бизнес-задачу вы решаете.
Если администраторы справляются с текущей нагрузкой, а бизнес не планирует быстро расти, то полномасштабное внедрение IaC, вероятно, не стоит свеч. Одного желания освоить новые инструменты для такого масштабного проекта недостаточно – в этом случае вполне можно обойтись точечной автоматизацией.
Другое дело, если компании нужно быстро наращивать мощности и без системной автоматизации становится трудно справляться с ростом. Еще на старте стоит определить, кто будет разрабатывать и сопровождать автоматизацию, и выделить на это время. Администраторов нужно обучить работе с Git и выбранными инструментами, а также заранее согласовать правила работы.
Прежде всего нужно разделить полномочия так, чтобы ошибка одного сотрудника не ставила под угрозу всю инфраструктуру. Нужно продумать ролевую модель и разграничение прав, а затем закрепить их на уровне службы каталогов и других систем управления доступом, если они есть.
Необходимо учесть требования информационной безопасности. ИБ-службу нужно подключать еще при проектировании автоматизации: договориться, какие проверки обязательны, какие изменения можно применять автоматически, а где требуется отдельное согласование. Эти требования закладывают в сценарии автоматизации, чтобы соблюдать общие правила в разных системах. Результаты проверок и согласований тоже нужно сохранять, чтобы было понятно, кто и на каком основании разрешил изменение.
Какую бы совершенную инфраструктуру мы ни построили, по завершении проекта она передается в ведение заказчика и продолжает развиваться. Для этого необходима проектная документация. Для повседневной работы потребуется еще и эксплуатационная база знаний, объясняющая, как проверить изменение, что делать при сбое и к кому обращаться за помощью.
И, конечно, нужно отказаться от ручных правок. Если продолжать менять настройки непосредственно в рабочей среде, код перестанет отражать ее реальное состояние, поэтому в IaC повседневные изменения вносят в код, проверяют и применяют средствами автоматизации. Исключение составляет разве что break-glass – особый порядок действий в экстренных ситуациях, когда счет идет на минуты. Тогда инженер приостанавливает автоматическое применение изменений, устраняет сбой вручную, а затем составляет отчет об инциденте. По итогам разбора обязательно создается срочная задача на перенос ручных правок в код, иначе очередной запуск автоматизации может перезаписать исправление.
При этом проблема может возникнуть и там, где процессы уже формализованы. Заявки оформляются, ответственные назначены, согласования проходят по регламенту – но подготовка окружения все равно занимает слишком много времени. Перед внедрением полезно измерить весь путь от запроса до готовой среды: сколько времени занимает техническая работа, а сколько – ожидание согласований и передача задачи между подразделениями. Это поможет определить, какие изменения действительно сократят срок предоставления ресурсов.
Зона особого внимания
Отдельно стоит поговорить об управлении секретами. IaC упрощает управление типовыми конфигурациями, однако при неправильном использовании создает риск утечки паролей и API-ключей.
Допустим, сервису нужно подключаться к базе данных. Логин и пароль записали прямо в конфигурацию, а затем отправили ее в Git. Теперь вместе с кодом в репозитории лежат и данные для доступа к базе.
Поэтому при внедрении IaC конфиденциальные данные лучше сразу изолировать: например, использовать инструмент для управления секретами. При этом политики доступа и правила регулярной ротации ключей требуют отдельной проработки и внимания со стороны ИБ-службы компании.
Что (не) стоит автоматизировать
Немало дополнительных сложностей возникает при работе с системами хранения данных (СХД). Бывает, что для нужной модели или редкой операции у вендора просто нет готового модуля автоматизации. В таких случаях приходится вызывать из Ansible самописные Bash-скрипты или выполнять команды напрямую через CLI устройства, а это не лучшая практика: такие обходные решения увеличивают технический долг и усложняют сопровождение инфраструктуры. Польза от IaC обычно перевешивает эти проблемы, но в некоторых случаях от автоматизации СХД проще отказаться.
В целом же целесообразность автоматизации зависит от двух факторов: как часто повторяется операция и сколько должна проработать система.
Если сервис нужно развернуть один-два раза за все время существования инфраструктуры, то сложный пайплайн для его полного развертывания и настройки, скорее всего, просто не окупится. Допустим, на промышленном предприятии годами стабильно работают три контроллера домена – и менять порядок их развертывания необязательно. При этом сами виртуальные машины вполне можно создавать средствами автоматизации, сохраняя в коде описание того, что развернуто.
Зато автоматизация приносит максимальную отдачу там, где инфраструктуру активно масштабируют или регулярно перестраивают. Поэтому при аудитах мы в первую очередь обращаем внимание на среды разработки и различные тестовые контуры.
Как выводить сервисы из эксплуатации
Еще один важный аспект, который мешает компаниям достичь действительно высокого уровня зрелости IaC, – организация вывода ресурсов из эксплуатации. Этот процесс должен быть так же строго регламентирован, как и ввод: когда систему заменяют или закрывают, важно вовремя освободить мощности и удалить оставшиеся конфигурации. Увы, организовать вывод может быть сложнее, чем развертывание.
Если убрать из конфигурации Terraform описание ресурса, которым он управляет, инструмент включит его удаление в план изменений. После проверки и применения плана ресурс будет удален. С Ansible все иначе: исключение задачи из плейбука не отменяет ранее выполненные действия. Чтобы вывести сервис из эксплуатации, необходимо написать обратный сценарий, который отзовет сетевые доступы, освободит подсети и удалит связанные правила безопасности.
Такие сценарии тоже хранят в Git. В заявке и базе знаний фиксируют, что запускали, в какой последовательности и с каким результатом.
При уничтожении данных нужна особая осторожность. Здесь неправильная автоматизация может доставить массу неприятностей, так что в малом и среднем бизнесе при высокой цене ошибки мы рекомендуем автоматизировать только выделение дискового пространства на СХД, а удаление томов и резервных копий оставить ручной операцией с отдельной проверкой.
А вы действительно готовы к IaC?
Итого: установка утилит и написание конфигураций сами по себе не делают инфраструктуру по-настоящему управляемой. Куда важнее то, совпадает ли код с реальными настройками серверов, соблюдает ли команда регламент изменений и поддерживает ли документацию в актуальном состоянии.
Планируя переход на IaC, оценивайте не только вычислительные мощности и стоимость лицензий. Учитывайте время команды и готовность руководства довести проект до конца. Брошенная на полпути трансформация лишь увеличит издержки.
Перед переходом ответьте на несколько вопросов. Они помогут определить, какую задачу должна решить автоматизация, какой объем работ команда сможет взять на себя и что нужно подготовить до старта.
Зачем и что автоматизировать:
Какую задачу бизнеса должен решить переход?
Сколько времени сейчас проходит от заявки до готового ресурса и какой срок нужен бизнесу?
На каком этапе возникают основные задержки и какие из них должна устранить автоматизация?
Что подготовить для перехода:
Кто отвечает за разработку и сопровождение автоматизации?
Есть ли у команды время на эти задачи помимо текущей эксплуатации?
Согласованы ли права доступа и требования ИБ?
Понятно ли, как проверять изменения и действовать при аварии?
Кто обнаружит и разберет расхождения между кодом и реальными настройками?
Готово ли руководство поддерживать переход при временных неудобствах?
Важен не подсчет положительных ответов, а конкретность договоренностей. Если бизнес-задача не определена, сначала нужно понять, ради чего затевать переход. Если задача понятна, но нет ответственных, выделенного времени команды или согласованных требований ИБ, эти вопросы нужно решить до начала работ.
При этом не всем компаниям нужна собственная инфраструктурная платформа. Можно получить ощутимую пользу от автоматизации отдельных сценариев – как в кейсе, описанном в начале статьи. Важно довести выбранный контур до состояния, в котором изменения проходят через код, а команда действительно соблюдает новый порядок работы. Иначе новые плейбуки так и останутся дополнением к старым порядкам.