Во время аварии инженер меняет сетевое правило через облачную консоль. Сервис снова работает. Через неделю обычный выпуск возвращает прежнюю настройку, и проблема повторяется. Сотрудники действовали разумно каждый в своём эпизоде, но рабочая инфраструктура и её описание успели разойтись.
Infrastructure as Code, или IaC, позволяет хранить и проверять описание ресурсов как код. Чтобы это принесло пользу, описание должно участвовать в реальных изменениях, включая аварийные. Папка с конфигурацией, которую однажды применили и забыли, не является достоверной моделью рабочей среды.
Что именно становится повторяемым
Вместо набора ручных кликов команда описывает нужные сети, вычислительные ресурсы, хранилища и связи между ними. Изменение можно обсудить до применения, связать с задачей и проверить в другой среде. Разные инструменты делают это по-разному: одни описывают желаемое состояние, другие выполняют последовательность действий.
Это описание не обязано содержать всё имущество компании. Для начала достаточно понятного участка с одним владельцем. Опаснее ситуация, когда два средства управления независимо меняют один ресурс и каждое пытается вернуть свою версию. Граница ответственности нужна и между командами, и между автоматическими процессами.
Повторяемость также зависит от версий инструментов, модулей и внешних интерфейсов. Вчерашний код с сегодняшними непроверенными зависимостями может предложить другой результат. Версии фиксируют и обновляют осознанно, проверяя изменения, а не ожидая, что однажды записанный рецепт останется вечным.
План показывает намерение, но не гарантирует успешное выполнение
В декларативных инструментах можно получить предварительный план: что создать, изменить, заменить или удалить. В Terraform он строится на сопоставлении конфигурации, известных ресурсов и сведений от провайдера. Режимы и ограничения описаны в документации plan.
Для ревью важно увидеть последствия. «Изменить параметр» может потребовать замены базы или диска. «Удалить неиспользуемое» — убрать ресурс, которым продолжает пользоваться внешний партнёр. Количество строк в изменении плохо отражает размер риска. Проверяющему нужны цель, затронутая среда и объяснение разрушительных действий.
План не резервирует всю будущую мощность и не доказывает, что полномочия сохранятся до конца. Квоты, доступность и внешнее состояние могут измениться. Если перед выполнением формируется новый план, нужно проверять именно его, а не ссылаться на согласование другого набора действий.
Код, рабочие ресурсы и учётное состояние — разные вещи
Некоторые инструменты хранят state — сведения о том, какие реальные ресурсы соответствуют описанию. В Terraform это, в частности, связи между адресами в конфигурации и объектами провайдера. State не заменяет конфигурацию и не является резервной копией содержимого базы. Его назначение объясняет руководство по состоянию.
Для совместной работы нужны контролируемое хранение и защита от конфликтующих запусков. Блокировка state, где она поддерживается, помогает избежать одновременных изменений этого учёта. Она не мешает другому администратору напрямую изменить ресурс в консоли и не делает всю облачную операцию транзакцией.
В state и планах могут оказаться чувствительные значения. Пометка sensitive обычно скрывает значение в выводе, но сама по себе не гарантирует его отсутствие в файле. Возможности исключения зависят от инструмента и конкретного ресурса. Поэтому права, шифрование и обращение с этими файлами требуют отдельной политики; нюансы разобраны в документации о чувствительных данных.
Что делать с аварийной ручной правкой
Вернёмся к сетевому правилу. После восстановления нужно выяснить, было ли изменение временным обходом или новым правильным состоянием. Затем либо внести его в управляемое описание, либо подготовить безопасный возврат. Автоматически сохранять любую ручную правку так же опасно, как автоматически уничтожать её.
Расхождение с описанием называют drift. Проверка может обнаружить его, но решение о смысле расхождения остаётся за владельцем. Например, обновление учётного state отражает реальность, но не обязательно изменяет желаемую конфигурацию. Следующий обычный запуск всё ещё может предложить возврат. Это различие хорошо показано в разборе drift в Terraform.
У аварийного доступа должны быть разрешённые владельцы, журнал действий и срок последующей сверки. Полный запрет ручного вмешательства может мешать восстановлению. Полное отсутствие сверки лишает автоматизацию достоверной основы. Нужен выполнимый порядок, который команда сможет соблюдать и после тяжёлой ночи.
Неудачный запуск может оставить половину изменений
Инструмент создал сеть и хранилище, но не получил разрешения на следующий ресурс. Ошибка в конце не означает, что всё вернулось в начало. В частности, Terraform сохраняет сведения об успешных изменениях и позволяет продолжать после устранения причины; поведение разобрано в руководстве по apply.
Перед повтором нужно проверить фактическое состояние и новый план. Возврат прежнего коммита только меняет желаемое описание. Он не возвращает данные из удалённого хранилища и не отменяет внешние последствия. Для критичных ресурсов нужны отдельная защита от удаления, резервные копии и проверенный путь восстановления.
Поэтому инфраструктуру полезно менять ограниченными частями. Рабочая среда не должна обновляться вместе со всеми тестовыми только потому, что их удобно описать одним запуском. Разделение областей применения уменьшает последствия ошибки, но требует явно управлять зависимостями между ними.
Проверка, которая обнаруживает недостающую память
Попросите другого инженера создать согласованное тестовое окружение из описания. Дайте ему предусмотренные права и инструкции, но не устные подсказки автора. Проверьте доступ приложения, сетевые ограничения и удаление временных ресурсов. Затем в испытании внесите одну разрешённую ручную правку и убедитесь, что процесс обнаружит её и даст понятный выбор.
Отдельно проверьте недоступность хранилища state и остановку применения посередине. Порядок действий не должен требовать секретов, которые есть только у отсутствующего коллеги. Для восстановления после аварии добавьте данные, ключи и зависимости приложения: создание пустой инфраструктуры ещё не возвращает бизнес-процесс.
После такого упражнения будет видно, какие действия действительно стали повторяемыми. Их и стоит расширять на следующие среды. Сложность модулей, число файлов и процент ресурсов «в коде» мало помогают, если обычное изменение по-прежнему требует догадаться, что однажды сделал другой человек.