Disaster recovery
Тема дорожной карты · Terraform
Аварийное восстановление с Terraform — это практика использования IaC-конфигураций для надёжного восстановления или переключения критической инфраструктуры AWS, Azure, GCP и Kubernetes в рамках определённых целевых RTO/RPO, гарантируя, что terraform apply против известного корректного state-файла сможет воссоздать полное окружение с нуля. Эффективное аварийное восстановление с Terraform требует, чтобы state-файл и его бэкенд (S3-бакет с включённым версионированием, Azure Blob с soft delete или Terraform Cloud) были защищены и реплицированы во вторичный регион, чтобы состояние никогда не являлось единой точкой отказа в сценарии восстановления. Команды реализуют аварийное восстановление с Terraform через корневые модули восстановления, использующие data "terraform_remote_state" для потребления выходных данных стеков основного региона, в сочетании с DNS-переключением через Route 53 health checks или Azure Traffic Manager, активируемым одним запуском terraform apply -var="active_region=us-west-2". Блокировка remote-state (DynamoDB для S3-бэкендов) предотвращает одновременные запуски terraform apply во время хаотичных операций восстановления, тогда как команды terraform state rm и terraform import позволяют инженерам согласовывать состояние с вручную созданными аварийными ресурсами без полного пересоздания. Регулярное тестирование аварийного восстановления с Terraform через плановые учения — создание DR-окружения, его валидация с помощью Terratest и очистка через terraform destroy — гарантирует работоспособность процедур восстановления в нужный момент.
Как это работает
Disaster recovery покрывает операционную гигиену: remote state с локингом + versioning, per-environment разделение, секреты вне git, CI/CD с PR-plan + ручным гейтом для prod, drift-detection по расписанию, policy-as-code гейты, версионирование модулей + приватный module registry, observability terraform apply-операций (логи, аудит), DR (бекапы state, runbook отката). Относитесь к Terraform-изменениям с той же осторожностью, что и к релизам приложения.
Когда применять
Применяйте эти практики с первого дня — ретрофит потом болезненный. Политика "destroy табу": production-ресурсы имеют prevent_destroy = true; удаление prod требует снятия флага, ревью PR, одобрения apply. Drift-detection еженочно — ручные изменения ловятся. Тренируйте recovery state на staging до нужды на prod.
Типичные ошибки
Ловушки Disaster recovery: нет бекапа state, потом коррумпированный state = дни ручной сверки; нет prevent_destroy на БД; apply с ноута в production (нет аудита); пропуск staging-среды ("это же просто конфиг, заработает"). Production-дисциплина не вытекает из добрых намерений — нужны гейты.