Drift Detection: как обнаружить расхождение инфры с кодом

Мы просто и по делу рассказываем про ИИ-инструменты для работы: сравнения, пошаговые гайды, бесплатные альтернативы и реальные сценарии применения. Помогаем выбрать между ChatGPT, Gemini, Claude, локальными моделями и десятками узкоспециализированных сервисов — от дизайна и HR до аналитики и SEO. Меньше хайпа, больше практики и экономии времени каждый день.

drift detectioninfrastructure as codeTerraform

Drift Detection — это процесс поиска расхождений между тем, что описано в Infrastructure as Code (Terraform, Pulumi, CloudFormation), и тем, что реально работает в облаке или дата-центре.

Проще говоря: в Git всё красиво, а в проде кто-то “подкрутил руками” security group, изменил subnet, удалил тег или пересоздал ресурс. Это и есть configuration drift.

Почему это важно 🚨

  • Потеря предсказуемости
    IaC перестаёт быть источником истины. Команда думает, что инфраструктура одна, а по факту — другая.

  • Риски для безопасности
    Ручные изменения часто обходят ревью и контроль. Так появляются лишние доступы, открытые порты и неверные политики.

  • Проблемы с релизами
    Следующий apply может завершиться ошибкой, пересоздать ресурсы или затронуть рабочие настройки.

  • Сложный аудит
    Когда инфраструктура “уплыла” от кода, трудно понять: это баг, legacy или чьё-то срочное изменение ночью.

Как обнаружить drift 🛠️

  • Сравнение desired state и actual state
    Базовый подход: регулярно запускать проверку, которая сравнивает описание в коде с фактическим состоянием ресурсов.

  • Terraform plan
    Один из самых популярных способов. Если `terraform plan` показывает неожиданные изменения без коммита в репозитории — вероятен drift.

  • Облачные механизмы
    AWS CloudFormation Drift Detection, Azure Policy, Google Cloud Config Validator и похожие инструменты помогают искать отклонения на стороне провайдера.

  • CI/CD-проверки
    Полезно запускать drift detection по расписанию: например, раз в день или перед деплоем. Результат — в Slack, Telegram, Jira или SIEM.

  • Мониторинг критичных ресурсов
    Особенно важно отслеживать IAM, security groups, network ACL, load balancer rules, DNS, Kubernetes manifests.

Лучшие практики ✅

  • Запретить ручные изменения там, где это возможно
  • Ограничить права в проде по принципу least privilege
  • Логировать все изменения через CloudTrail, Audit Logs, Activity Logs
  • Делать drift checks частью пайплайна
  • Разделять “временный hotfix” и последующую фиксацию в IaC
  • Настроить алерты на изменения чувствительных ресурсов

Что делать, если drift уже найден 🧩

  1. Определить, изменение легитимное или нет
  2. Если изменение правильное — зафиксировать его в коде
  3. Если нет — вернуть инфраструктуру к состоянию из IaC
  4. Провести разбор, почему изменение прошло вне процесса

Главная мысль: drift detection — это не просто проверка Terraform, а механизм контроля реального соответствия инфраструктуры коду. Чем раньше находите расхождения, тем меньше риск инцидентов, простоев и “магии” в проде. ☁️

👀 Для тех, кто следит за DevOps, SRE, cloud и безопасностью инфраструктуры — стоит посмотреть подборку каналов про IT.

🗣 Подборки каналов
🧠 Каталог ботов и приложений
🗺 Навигация

Читайте так же