Когда ваша инфраструктура отклоняется от кода

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

У этого расхождения есть имя: drift (дрейф).

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

Дрейф — это разрыв между тем, что, согласно вашему коду инфраструктуры, должно существовать, и тем, что на самом деле существует в вашем облачном провайдере или на сервере. Ваши файлы Terraform или Pulumi определяют желаемое состояние. Ресурсы, работающие в AWS, Google Cloud или Azure, представляют фактическое состояние. Когда эти два состояния не совпадают, возникает дрейф.

Звучит просто, но последствия глубоки. Инфраструктура как код (IaC) работает на критическом допущении: ваш код является единственным источником истины для того, как всё должно быть настроено. Это допущение работает только тогда, когда каждое изменение инфраструктуры проходит через ваш пайплайн. Как только что-то меняется вне этого пайплайна, допущение нарушается.

Три пути проникновения дрейфа

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

Диаграмма ниже показывает, как каждый путь обходит предполагаемый пайплайн IaC и приводит к дрейфу.

flowchart TD A[Предполагаемый путь: пайплайн IaC] --> B[Желаемое состояние в коде] C[Ручное изменение в консоли] --> D[Прямая модификация] D --> E[Дрейф] F[Реагирование на инцидент] --> G[Экстренное изменение] G --> E H[Внешние инструменты / автоскейлеры] --> I[Автоматическое изменение вне пайплайна] I --> E B -.->|Нет дрейфа| J[Фактическое состояние совпадает с кодом] E --> K[Фактическое состояние != Код]

Ручные изменения

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

Это не лень. Это рациональная реакция на систему, которая делает небольшие изменения дорогими. Но каждое прямое изменение в консоли создает разрыв между вашим кодом и реальностью.

Реагирование на инциденты

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

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

Внешние инструменты и процессы

Не весь дрейф возникает из-за действий человека. Автоскейлеры добавляют и удаляют инстансы в зависимости от нагрузки. Инструменты безопасности применяют политики через отдельные механизмы. Системы управления секретами автоматически ротируют учетные данные. Инструменты управления конфигурацией обновляют параметры вне вашего пайплайна IaC.

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

Почему дрейф важен

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

Самая непосредственная проблема — это доверие. Когда вы запускаете terraform plan, вы ожидаете увидеть только те изменения, которые запланировали. Но если существует дрейф, план показывает неожиданные модификации. Ресурсы, к которым вы не прикасались, будут возвращены к состоянию, определенному в коде. То правило безопасности, которое кто-то добавил вручную? Оно будет удалено при следующем apply. Тот измененный размер инстанса после инцидента? Он будет откачен.

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

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

Дрейф — это не признак неудачи

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

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

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

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

Если вы управляете инфраструктурой с помощью IaC, вот краткий чек-лист для начала работы с дрейфом:

  • Запускайте plan для вашего продакшен-окружения как минимум раз в неделю, даже если вы ничего не разворачиваете. Проверяйте вывод на предмет неожиданных изменений.
  • Настройте автоматическое обнаружение дрейфа. Большинство инструментов IaC имеют функции или интеграции, которые могут предупредить вас, когда фактическое состояние отличается от желаемого.
  • После каждого инцидента выделяйте время на обновление кода IaC в соответствии с любыми экстренными изменениями.
  • Документируйте, какие внешние инструменты и процессы изменяют инфраструктуру вне вашего пайплайна. Знайте, что меняется автоматически и почему.
  • Когда вы видите дрейф в плане, проводите расследование перед применением. Поймите, что вызвало расхождение и безопасно ли его откатывать.

Что дальше

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

Реальная опасность в том, что дрейф разрушает основу доверия, которая делает инфраструктуру как код ценной. Без доверия к вашему пайплайну вы теряете уверенность, чтобы вносить изменения быстро и безопасно. А эта уверенность и есть весь смысл автоматизации вашей инфраструктуры.