Изменения инфраструктуры требуют ревью кода — как и код приложения

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

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

Почему инфраструктура заслуживает такого же контроля

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

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

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

Как работают пул-реквесты для инфраструктуры

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

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

На что обращать внимание при ревью инфраструктуры

Когда вы просматриваете пул-реквест с изменениями инфраструктуры, вы проверяете несколько вещей.

Во-первых, соответствует ли изменение требованию? Если кто-то открывает порт, действительно ли ему нужен этот порт? Есть ли более безопасная альтернатива? Соответствует ли изменение тому, о чём договорилась команда?

Во-вторых, корректна ли конфигурация? Проверьте синтаксис. Убедитесь, что номера портов, размеры инстансов и CIDR-блоки сети указаны верно. Ищите правила безопасности, которые слишком разрешительны. Правило, разрешающее трафик с 0.0.0.0/0 на порт 22, почти всегда является красным флагом.

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

В-четвёртых, соответствует ли изменение принятым в команде соглашениям об именовании и стандартам тегирования? Согласованное именование упрощает понимание того, для чего предназначены ресурсы и кто ими владеет. Теги помогают с распределением затрат и управлением ресурсами.

Историческая запись

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

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

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

Вопрос скорости

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

Реальность такова, что время, потраченное на ревью, почти всегда меньше времени, затраченного на восстановление после непроверенного изменения, которое сломало продакшен. Пятиминутное ревью может предотвратить двухчасовой простой. Математика проста.

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

Что происходит после ревью

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

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

Практический чек-лист для пул-реквестов инфраструктуры

• Соответствует ли изменение реальному требованию или запросу?
• Корректны ли все значения (порты, размеры инстансов, CIDR-диапазоны)?
• Являются ли правила безопасности максимально ограничительными, при этом разрешая необходимый трафик?
• Согласовано ли изменение с другими окружениями?
• Соблюдает ли оно соглашения об именовании и тегировании?
• Есть ли вывод плана, показывающий, что изменится, перед применением?

Вывод

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