Обнаружение дрейфа Terraform: автоматизация, CI/CD, уведомления

Обнаружение дрейфа Terraform: автоматизация, CI/CD, уведомления

Представьте: ваш продакшен работает стабильно, но внезапно после очередного terraform apply падает сервис. Выясняется, что кто-то из коллег вручную изменил security group в консоли AWS «на 5 минут», а следующий apply перезатёр эту правку. Это дрейф (drift) — расхождение между кодом и реальностью. Он накапливается незаметно и проявляется в самый неподходящий момент. Согласно отраслевым данным, более половины инцидентов в облачной инфраструктуре связаны с дрейфом. На одном проекте с 500 ресурсными записями дрейф накапливался 3 недели, пока не упала критическая нода Kubernetes. После нашей настройки автоматического plan расхождения выявлялись за 10 минут до apply. Мы — команда DevOps-инженеров с опытом в облачной инфраструктуре. Настроим автоматическое обнаружение дрейфа под ключ, чтобы вы всегда знали о расхождениях до того, как они вызовут инцидент. Получите консультацию по автоматизации дрейфа уже сегодня.

Что такое дрейф и почему он опасен

Drift — это расхождение между тем, что описано в Terraform-конфигурации (и закреплено в state), и тем, что реально существует в облаке. Причины: ручные правки в консоли, автообновление полей провайдером, apply из устаревшей ветки. Дрейф может привести к неожиданным простоям, потере данных или нарушению безопасности. Например, случайное изменение правил firewall открывает доступ к базе данных.

terraform plan — главный инструмент обнаружения дрейфа. Он сравнивает state с реальными ресурсами и показывает изменения. Если plan показывает изменения там, где никто не менял код — это сигнал дрейфа.

Почему автоматизация обнаружения дрейфа критична?

Ручной запуск plan перед каждым деплоем — недостаточно. Дрейф может возникнуть между релизами. Автоматизация даёт:

• Раннее выявление расхождений (до применения изменений)
• Снижение MTTR с часов до минут — в 10 раз быстрее ручного поиска
• Аудит изменений в облаке, не прошедших через Git

Мы гарантируем стабильность вашей инфраструктуры: после настройки вы получите регулярные уведомления о дрейфе в удобный канал.

Как мы настраиваем drift detection?

Настраиваем на любом CI/CD: GitLab CI, GitHub Actions, Atlantis, Terraform Cloud, Spacelift. Пример для GitLab CI:

# .gitlab-ci.yml drift-detection:
  stage: check
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  script:
    - terraform init -reconfigure
    - terraform plan -detailed-exitcode -out=drift.plan 2>&1 | tee plan.log
  after_script:
    - |
      if [ $? -eq 2 ]; then
        curl -X POST $SLACK_WEBHOOK -d '{"text":"Terraform drift detected in production!"}'
      fi

Ключевое — -detailed-exitcode: код 0 — нет изменений, 1 — ошибка, 2 — дрейф. Реагируем только на код 2.

Для Atlantis используем отдельный drift PR, который пересоздаётся при каждом запуске. Spacelift и Terraform Cloud имеют встроенный drift detection — мы подключаем его за 1 день.

Сравнение методов drift detection

Рекомендуемая частота проверок

Что делать с обнаруженным дрейфом?

Три варианта:

• Восстановить через apply — если изменение в облаке нежелательное (кто-то поправил руками), terraform apply вернёт конфиг в соответствие с кодом. Это основной сценарий.
• Обновить конфиг — если изменение намеренное, обновляем .tf-файл, делаем PR, мержим. После merge дрейф исчезнет.
• Добавить lifecycle { ignore_changes } — если поле управляется внешним сервисом (например, desired_capacity у Auto Scaling Group).

resource "aws_autoscaling_group" "main" { lifecycle { ignore_changes = [desired_capacity] } } 

Процесс работы

1. Аудит текущей инфраструктуры Terraform: анализируем state-файлы, pipeline, провайдеры. Определяем объем и узкие места.
2. Выбор оптимального метода drift detection под ваш стек и бюджет. Учитываем частоту изменений, количество ресурсов, требования к безопасности.
3. Настройка scheduled job (CI/CD или внешний сервис) с нужной частотой. Пилим под вашу инфраструктуру.
4. Интеграция уведомлений (Slack, PagerDuty, Telegram) с детализацией изменений. Добавляем агрегацию алертов для снижения шума.
5. Документация по процессу и runbook для инцидентов. Обучаем команду работе с drift detection.
6. Поддержка после запуска: 1 месяц консультаций и донастроек.

Что входит в работу

• Результаты аудита: отчёт по текущему состоянию инфраструктуры, выявленные риски и рекомендации.
• Настроенный drift detection: выбранный метод с нужной частотой и уведомлениями.
• Документация: описание процесса, runbook, инструкции для команды.
• Обучение: воркшоп для ваших инженеров по работе с drift и реагированию.
• Поддержка: месяц сопровождения после внедрения, включая корректировку настроек.

Метрики и визуализация

Для крупных проектов дополняем алертинг метриками: экспортируем количество ресурсов с drift в Prometheus через кастомный экспортер. Но для 90% команд достаточно Slack-уведомлений с текстом terraform plan. Дополнительно можно настроить дашборды в Grafana для отслеживания дрейфа по окружениям.

Сроки и как начать

Стандартная настройка занимает от 1 до 3 дней в зависимости от количества state-файлов и платформы. Свяжитесь с нами — оценим ваш проект и предложим решение. Получите консультацию по автоматизации дрейфа уже сегодня.