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

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

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

Вопрос, на который каждой команде нужно найти ответ: где тестировать изменения инфраструктуры до того, как они попадут в продакшен?

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

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

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

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

Основной принцип: изолируй перед тестированием

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

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

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

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

Практические уровни окружений

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

Окружение разработки (Development) предназначено для тестирования небольших изменений разработчиками. Оно может использовать минимальные ресурсы и упрощённые конфигурации. Один маленький сервер вместо кластера. Локальная база данных вместо реплицированного набора. Ключевое требование — изоляция от стейджинга и продакшена. Окружения разработки никогда не должны случайно касаться продакшен-ресурсов.

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

Продакшен-окружение (Production) работает как реальный сервис. Изменения попадают сюда только после успешного прохождения через окружения разработки и стейджинга.

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

Ловушка конфигурации

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

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

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

Как CI/CD управляет инфраструктурными окружениями

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

1. Проверка изменения через код-ревью или инструменты планирования
2. Автоматическое применение изменения к стейджингу
3. Запуск тестов для проверки корректности создания ресурсов
4. Валидация, что существующие ресурсы не сломаны
5. Применение того же изменения к продакшену

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

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

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

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

Что дальше

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

Здесь на помощь приходят политики и управление доступом. Следующий шаг — определение правил о том, какие изменения разрешены, кто может их утверждать и какие условия должны быть выполнены перед развёртыванием в продакшен. Но это тема для другой статьи.

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