Drift detection

Дрейф состояния Terraform возникает, когда фактическое состояние инфраструктуры в AWS, Azure, GCP или Kubernetes расходится с тем, что зафиксировано в state-файле Terraform — как правило, из-за ручных изменений в облачной консоли, внеполосных скриптов или других инструментов автоматизации, изменяющих управляемые Terraform ресурсы. Обнаружение дрейфа состояния Terraform просто: запуск terraform plan без изменений кода даёт непустой diff, показывающий ресурсы, которые Terraform намерен вернуть к объявленной конфигурации, — это автоматизированный отчёт о дрейфе при планировании в CI/CD-конвейере (GitHub Actions, GitLab CI) как ежедневный или почасовой запуск только плана. Варианты устранения дрейфа включают запуск terraform apply для перезаписи ручных изменений и восстановления объявленного состояния, использование terraform refresh (или terraform apply -refresh-only) для обновления state-файла в соответствии с реальностью без изменения ресурсов, или terraform import для перевода обнаруженного ресурса под управление Terraform. Предотвращение дрейфа состояния Terraform в масштабе требует применения IAM-политик и Azure RBAC, ограничивающих прямой консольный доступ к управляемым Terraform ресурсам, чтобы terraform apply через Atlantis или Terraform Cloud был единственным разрешённым путём изменений. Инструменты driftctl (drift scan) и функция обнаружения дрейфа Terraform Cloud обеспечивают непрерывный мониторинг дрейфа во всех воркспейсах, генерируя оповещения при расхождении состояния, чтобы команды могли реагировать до того, как дрейф конфигурации перерастёт в инцидент безопасности или доступности.

Как это работает

Drift detection покрывает операционную гигиену: 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.

Типичные ошибки

Ловушки Drift detection: нет бекапа state, потом коррумпированный state = дни ручной сверки; нет prevent_destroy на БД; apply с ноута в production (нет аудита); пропуск staging-среды ("это же просто конфиг, заработает"). Production-дисциплина не вытекает из добрых намерений — нужны гейты.

Связанные понятия

• Production практики
• Резервное копирование state
• Infracost — оценка стоимости
• Sentinel и OPA политики