Когда дрейф инфраструктуры делает ваш Terraform plan бесполезным

Вы запускаете пайплайн для развертывания новой версии приложения. Terraform plan выполняется, и на выходе показывает, что хочет изменить размер инстанса базы данных в продакшене. Никто в команде не собирался трогать базу. Ревьюер пул-реквеста смотрит на план в замешательстве. Это побочный эффект новой версии? Требование безопасности, которое он пропустил? Кто-то одобряет план просто чтобы разблокировать релиз, и внезапно ваша база данных работает на менее мощном оборудовании во время пиковой нагрузки.

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

Что на самом деле означает дрейф

Дрейф инфраструктуры — это разрыв между тем, какой инфраструктура должна быть по коду, и тем, что на самом деле существует в вашем облачном окружении. Вы написали код Terraform, Pulumi или CloudFormation, который определяет ваши ресурсы. Кто-то заходит в облачную консоль и меняет тип инстанса, добавляет правило группы безопасности или подкручивает параметр базы данных. Это изменение никогда не попадает в ваш репозиторий кода. Оно не проходит через пайплайн. Оно просто происходит.

Инфраструктура все еще работает. Приложения все еще запускаются. Но ваш код больше не описывает реальность. Он описывает то, какой реальность была раньше.

План, который вам лжет

Инструменты Infrastructure as Code, такие как Terraform, работают путем сравнения двух вещей: ваших определений кода и файла состояния (который отслеживает, что существует в облаке). Когда оба совпадают, план, который вы получаете, точен. Он показывает именно то, что изменится на основе вашего последнего коммита кода.

Следующая диаграмма показывает, как дрейф создает несоответствие между кодом, состоянием и фактической инфраструктурой, что приводит к неточному плану:

flowchart TD A[Code Definitions] --> B[Terraform Plan] C[State File] --> B D[Actual Infrastructure] -.->|drift| C D -.->|out of sync| B B --> E[Plan Shows Unintended Changes] style D fill:#f9f,stroke:#333,stroke-width:2px style E fill:#f96,stroke:#333,stroke-width:2px

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

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

Три способа, которыми дрейф разрушает ваш пайплайн

Неожиданное уничтожение

Это самый опасный исход. Представьте группу безопасности сети, которую ваша команда безопасности создала вручную для изоляции чувствительной рабочей нагрузки. Этого ресурса нет в вашем коде IaC. Когда ваш пайплайн запускает terraform apply, используя код, который никогда не определял этот ресурс, Terraform видит его как то, чего не должно быть. Он уничтожает его. Ваша конфигурация безопасности исчезает бесшумно, и никто не замечает, пока что-то не сломается.

Потраченное время на ревью

Ревьюеры пул-реквестов видят план, который показывает изменения ресурсов, не связанных с развертываемой функцией. Они не могут понять, являются ли это случайными побочными эффектами, обязательными обновлениями или чем-то подозрительным. Время тратится на исследование изменений, которые на самом деле не являются частью работы. Циклы ревью растягиваются. Команды начинают задавать вопросы вроде «Кто-то снова трогал продакшен?» вместо того, чтобы сосредоточиться на фактическом изменении кода.

Потеря доверия к автоматизации

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

Почему дрейф возникает в реальных командах

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

  • Инцидент требует немедленного изменения. Дежурный инженер исправляет его в консоли, потому что писать код, коммитить и ждать пайплайн слишком долго.
  • Администратор базы данных настраивает параметры напрямую в облачной консоли, потому что не работает с инструментами IaC ежедневно.
  • Команда безопасности добавляет временные правила брандмауэра во время аудита и забывает задокументировать их.
  • Разработчику нужно быстро что-то протестировать, и он вручную создает ресурс, планируя «добавить его в код позже».

Каждое из этих действий по отдельности имеет смысл. Вместе они создают разрыв между кодом и реальностью, который растет до тех пор, пока пайплайну нельзя доверять.

Обнаружение дрейфа до того, как он навредит

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

Большинство инструментов IaC предлагают функции обнаружения дрейфа. Terraform Cloud и Enterprise имеют обнаружение дрейфа, которое запускает планы по расписанию и оповещает, когда реальная инфраструктура отличается от состояния. OpenTofu, форк Terraform с открытым исходным кодом, включает аналогичные возможности. Вы также можете создать собственное обнаружение с помощью запланированных запусков пайплайна, которые сравнивают состояние с фактическими облачными ресурсами.

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

Практический чек-лист обнаружения дрейфа

Если вы управляете инфраструктурой с помощью IaC, рассмотрите возможность добавления этих проверок в вашу рутину:

  • Запланируйте еженедельный запуск обнаружения дрейфа для продакшен-сред
  • Оповещайте команду при обнаружении дрейфа, а не только когда он вызывает сбои
  • Обсуждайте отчеты о дрейфе на регулярных командных синхронизациях
  • Документируйте четкий процесс устранения дрейфа: либо обновить код, либо откатить изменение
  • Относитесь к ручным изменениям в консоли как к временным обходным решениям, а не постоянным решениям

Реальная цена игнорирования дрейфа

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

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