Когда изменения инфраструктуры ломают продакшен: восстановление после IaC-катастроф

Вы сделали всё правильно. План Terraform проверили два старших инженера. Изменение прошло проверки политик в пайплайне. Три дня оно отработало в стейджинге без нареканий. Затем вы применили его в продакшене — и через десять минут пользователи начали сообщать об ошибках.

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

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

Почему откат инфраструктуры — это другое

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

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

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

Ключ к безопасному откату инфраструктуры сводится к двум вещам: управлению состоянием и версионированию конфигурации.

Управление состоянием: знайте, что у вас есть

Инструменты Infrastructure as Code, такие как Terraform, Pulumi или OpenTofu, ведут файл состояния. Этот файл записывает каждый ресурс, которым управляет инструмент, его текущую конфигурацию и то, как ресурсы связаны друг с другом. Без точного состояния инструмент не может знать, что существует, не говоря уже о том, как это изменить.

Файлы состояния — критически важные активы. Они должны храниться безопасно, с контролем доступа и версионироваться при каждом изменении. Если вы потеряете файл состояния, вы потеряете возможность управлять этой инфраструктурой через IaC. Вы вернётесь к ручному восстановлению, гадая, какие ресурсы существуют и как они связаны.

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

Версионирование конфигурации: знайте, что у вас было

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

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

Это звучит очевидно, но многие команды относятся к конфигурации инфраструктуры как к «просто разверни последнее» без тегирования релизов. Когда что-то ломается, они в панике ищут последний известный рабочий коммит, надеясь, что никто не запустил между делом наполовину завершённое изменение.

Планирование отката до применения

Лучшее время для планирования отката — до применения изменения. В вашем пайплайне сохраняйте копию текущего состояния перед выполнением шага apply. Если изменение вызовет проблемы, пайплайн сможет немедленно выполнить apply с сохранённым состоянием. Никаких поисков, никаких догадок, никаких ручных шагов.

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

Например, если проблема вызвана изменением одного ресурса, такого как EC2-инстанс, вы можете нацелиться именно на этот ресурс:

# Сохраняем текущее состояние перед применением любых изменений
terraform state pull > state-backup-$(date +%Y%m%d-%H%M%S).json

# Применяем предыдущую конфигурацию только для проблемного ресурса
terraform apply -auto-approve -target=aws_instance.web

# Проверяем откат с помощью проверок работоспособности
terraform output instance_health

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

Когда отката недостаточно

Некоторые изменения инфраструктуры по своей природе разрушительны. Если ваше изменение удалило том базы данных, откат конфигурации IaC не вернёт данные. Тома больше нет. Файл конфигурации говорит, что он должен существовать, но реального ресурса больше нет в вашем облачном провайдере.

Следующая блок-схема иллюстрирует процесс принятия решений, когда изменение ломает продакшен:

flowchart TD A[Изменение ломает продакшен] --> B{Можно ли чисто откатить изменение?} B -->|Да| C[Восстановить предыдущее состояние из сохранённого файла состояния] B -->|Нет| D{Был ли сделан снимок до изменения?} D -->|Да| E[Восстановить из снимка, затем применить старую конфигурацию] D -->|Нет| F{Старое окружение ещё работает?} F -->|Да| G[Переключить трафик обратно на старое окружение] F -->|Нет| H[Создать новые ресурсы из последней рабочей конфигурации] C --> I[Запустить проверки работоспособности] E --> I G --> I H --> I I --> J{Проверки проходят?} J -->|Да| K[Восстановление завершено] J -->|Нет| L[Эскалировать дежурному инженеру]

Для таких случаев нужны стратегии восстановления, выходящие за рамки отката:

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

Эти стратегии увеличивают стоимость и сложность, но они дешевле, чем продолжительный сбой.

Тестируйте свой откат

План отката, который никогда не тестировался, — это не план. Это пожелание.

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

Делайте это регулярно. Раз в несколько месяцев или всякий раз, когда ваша инфраструктурная настройка существенно меняется. Цель — не просто проверить, что механизм работает, но и укрепить уверенность вашей команды. Когда продакшен ломается в 2 часа ночи, вы хотите, чтобы ваша команда точно знала, что делать, а не читала документацию в первый раз.

После отката: учитесь и документируйте

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

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

Практический чек-лист готовности к откату инфраструктуры

  • Файлы состояния хранятся удалённо с контролем доступа и версионированием
  • Каждое изменение инфраструктуры помечено версией в системе контроля версий
  • Пайплайн сохраняет текущее состояние перед применением изменений
  • Автоматизированные проверки работоспособности запускаются после каждого apply
  • Откат запускается автоматически при сбое проверок работоспособности
  • Для разрушительных изменений предусмотрены стратегии снимков или параллельного развёртывания
  • Откат тестируется в стейджинге не реже одного раза в квартал
  • Документация инцидента создаётся и анализируется после каждого отката

Конкретный вывод

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