Infrastructure as Code (IaC) с AWS CloudFormation — автоматизация AWS

AWS CloudFormation: где ручная настройка облака ломается

Ручная настройка облака ломается не на первом запуске, а на третьем-четвёртом изменении. Инженер добавляет правило в security group, поднимает инстанс, навешивает теги — и повторяет это в dev, stage и prod по памяти. Через неделю окружения расходятся: в stage включено логирование, в prod нет, версия образа на одном стенде обновлена, на другом осталась прошлая. Какая конфигурация была рабочей в момент инцидента — не знает никто.

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

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

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

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

Первый контур, собранный по описанию, задаёт точку отсчёта: если раньше окружение поднимали руками несколько дней и каждый стенд выходил немного другим, то теперь развёртывание занимает 15-20 минут. В стенде воспроизводятся сеть, права, группы безопасности и параметры сервисов — без «забытых» настроек из чек-листа.

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

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

Стоимость простоя перестаёт быть неизвестной величиной. Окно недоступности больше не растягивается на диагностику: оно ограничено временем применения шаблона, а это время известно заранее и его можно закладывать в соглашение об уровне сервиса.

На дистанции месяцев эффект накапливается: изменения проверяются до применения, стенды поднимаются под каждую задачу и так же сносятся, окружения остаются идентичными. AWS CloudFormation здесь работает не как инструмент ради инструмента, а как исполняемое описание инфраструктуры, которое лежит в репозитории рядом с кодом сервиса.

Способы описания инфраструктуры: сравнение подходов

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

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

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

Порядок внедрения: от аудита до передачи регламентов

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

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

2. Схема зависимостей. Раскладываем ресурсы по стекам: сеть, вычисления, хранилища, доступы. Определяем порядок создания и то, что нельзя менять без простоя, — это задаёт границы шаблонов CloudFormation.

3. Сборка шаблонов. Описываем ресурсы декларативно, параметризуем различия сред и выносим секреты отдельно от описаний. Повторяющиеся блоки сворачиваем в общие фрагменты — правка делается в одном месте.

4. Проверка на стенде. Разворачиваем копию контура в изолированной среде и прогоняем полный цикл: создание с нуля, изменение, удаление. Расхождения с ожидаемым планом изменений ловим до продуктивной среды.

5. Вывод в продуктив. Переводим ресурсы под управление описаниями поэтапно, сверяя состояние после каждого шага. Предыдущая конфигурация сохраняется до подтверждения результата — откат остаётся возможным.

6. Передача регламентов. Отдаём описания шаблонов, схему стеков, порядок правок и правила проверки изменений, инструкции по откату. Команда заказчика вносит изменения сама, без обращения к нам по каждому шагу.

Комплект шаблонов, схемы и регламенты передачи

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

• Шаблоны окружений — описания CloudFormation для разработки, тестового и продуктивного контуров. Различаются параметрами, а не копиями кода: правка в одном месте не расходится по трём версиям.
• Схемы зависимостей — порядок создания и удаления ресурсов, вложенные стеки, передача значений между ними. По схеме видно, что затронет изменение конкретного ресурса.
• Политики доступа — роли для развёртывания и для приложений, границы прав, разделение ручных правок и изменений через шаблон.
• Регламент изменений — ветка, сборка, проверка вторым инженером, подтверждение для продуктивного контура, порядок отката на предыдущую версию.
• Документация — назначение параметров, выходные значения, инструкция по развёртыванию с нуля, известные ограничения и обходные решения.
• Защиты от случайного разрушения — запрет удаления стека, политики на обновление критичных ресурсов, регулярная сверка фактического состояния с описанием.
• Каталог переиспользуемых фрагментов — типовые блоки сети, хранилища и прав, которые подключаются в новые сервисы вместо копирования.

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

Кейс: как сократилось время развёртывания контура

Контур для приёмки и предпродакшена собирался вручную по инструкции: сети, балансировщик, базы, права доступа. Полное развёртывание занимало 6–8 часов работы двух инженеров, а расхождения между средами всплывали уже на тестировании — часть изменений откатывали обратными правками прямо в консоли.

Мы описали инфраструктуру декларативно в шаблонах Amazon Web Services CloudFormation: отдельный стек на каждую среду, общие параметры вынесены в отдельный слой, изменения проходят ревью до применения. Откат перестал быть ручной операцией — возврат к предыдущему стеку занимает один шаг.

До и после

Развёртывание контура с нуля сократилось с 6–8 часов до 20–25 минут, и запускает его один инженер, не дожидаясь остальных. Доля отказов при выкатке снизилась примерно втрое: среда воспроизводится один в один, потому что изменения приходят из описания, а не из ручных правок. Время восстановления после сбоя конфигурации упало с нескольких часов до 10–15 минут — контур просто пересобирается.

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

Чем AWS CloudFormation отличается от ручных сценариев?

Скрипт выполняет последовательность команд: создать, настроить, подключить. Он не знает, что уже сделано, поэтому повторный запуск либо падает на существующем ресурсе, либо создаёт дубликат. AWS CloudFormation работает по другой модели — шаблон описывает желаемое состояние, а не порядок действий, и система сама приводит инфраструктуру к этому описанию.

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

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

Обновления тоже идут иначе: перед применением видно, что будет создано, изменено или удалено, а при ошибке стек возвращается к предыдущему состоянию. Неудачный прогон не оставляет половину среды в неизвестном виде — восстановление и развёртывание новой среды выполняются по одному сценарию.

Технические сомнения перед началом работ

Сомнения перед стартом обычно технические: что будет с работающим контуром, как контролировать правки в обход шаблонов и кто получает доступ к продакшену.

Можно ли внедрять частями?

Да, по слоям: сеть, данные, приложения. Каждый слой — отдельный стек с явными зависимостями, поэтому автоматизация одного участка не блокирует остальные и не требует останавливать работы.

Как отслеживать ручные правки?

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

Как делить права доступа?

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

Что с откатом изменений?

Перед применением показываем план: что создаётся, меняется, удаляется. Откат — возврат к предыдущей версии шаблона, состояние стека приводится к ней.

Обсудим задачу и вернёмся с планом внедрения

На первом разборе смотрим не на формулировку «нужен код вместо ручных правок», а на фактическое состояние инфраструктуры: что уже описано в шаблонах AWS CloudFormation, а что до сих пор поднимается руками из консоли. Уточняем число окружений и учётных записей, разделение боевого и тестового контуров, схему доступа команды и то, как изменения сейчас попадают в боевую среду — ручной правкой или через автоматизированное развёртывание. Отдельно фиксируем, что нельзя трогать без крайней необходимости: базы с данными, сетевые правила, привязки доменов.

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

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

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