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

Вы просматриваете pull request, который меняет одну строку в конфигурации файрвола. Изменение открывает порт 443 для публичного трафика. Достаточно просто, верно?

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

Именно эту ситуацию призван предотвратить workflow plan-review-apply.

Проблема прямого применения

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

Прямое применение превращает каждое изменение в азартную игру. Вы узнаете, что проиграли, только когда что-то сломается.

Как работает Plan-Review-Apply

Workflow состоит из трех этапов, и каждый служит определенной цели.

Диаграмма ниже иллюстрирует поток:

flowchart TD A[Start: Code Change] --> B[Plan: Generate Diff] B --> C[Review: Human Checks Plan] C -->|Approved| D[Apply: Execute Changes] C -->|Rejected| B D --> E[End]

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

Review — это этап, на котором люди изучают этот план. Вы проверяете на предмет сюрпризов. Вы убеждаетесь, что план соответствует намерению изменения. Вы замечаете такие вещи, как «это удаление группы безопасности затронет production-серверы», прежде чем кто-то нажмет «применить».

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

Как на самом деле выглядит план

План — это не расплывчатое описание. Это конкретный список операций. Например, план может показывать:

  • Добавить новое правило группы безопасности для порта 443
  • Изменить существующий слушатель балансировщика нагрузки для использования нового сертификата
  • Удалить группу подсетей базы данных, на которую больше нет ссылок

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

Превращение плана в жесткое требование

Наиболее эффективные команды относятся к плану как к обязательному шагу. Их пайплайн настроен так, чтобы останавливаться, если план не был сгенерирован или если план не был проверен и одобрен. Это инфраструктурный эквивалент требования code review перед мержем pull request. Вы же не будете мержить непроверенный код в production. Почему вы должны применять непроверенные изменения инфраструктуры?

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

Планы как журналы аудита

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

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

Без сохраненных планов у вас остаются только ручные логи, сообщения в чате и память. Ничто из этого не является надежным, когда вы пытаетесь отладить production-сбой в 2 часа ночи.

Обработка конкурентных изменений

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

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

Что план не решает

Plan-review-apply — мощный инструмент, но у него есть ограничения. Он может сравнивать только то, что говорит ваш код, с тем, что сообщает ваша инфраструктура в данный момент. Если кто-то вносит ручное изменение вне вашего пайплайна, план может не заметить все несоответствия. Если у вашего провайдера инфраструктуры есть баг или неожиданное поведение, план может показать нечто отличное от того, что на самом деле выполнится.

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

Практический чеклист

Прежде чем внедрять plan-review-apply в свой пайплайн, учтите следующие моменты:

  • Генерируйте планы автоматически после каждого смерженного pull request, а не только по запросу
  • Сохраняйте каждый план как артефакт пайплайна с временными метками и метаданными об утверждении
  • Блокируйте применение, если план отсутствует или не был проверен
  • Проверяйте планы на предмет сюрпризов перед утверждением, а не только на корректность
  • Используйте планы при расследовании инцидентов как первый источник истины о недавних изменениях

Основная идея

Plan-review-apply превращает изменения инфраструктуры из слепых азартных игр в просчитанные, проверенные операции. План показывает, что произойдет, до того, как это произойдет. Ревью выявляет проблемы до того, как они попадут в production. Apply выполняет только то, что было проверено. Этот workflow не устраняет весь риск, но он устраняет риск применения изменений, не зная их полного влияния.

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