Чем отличается Provisioning от Decommissioning: разбор жизненного цикла инфраструктуры

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

Ключевые различия: создание и уничтожение

Provisioning — это фаза построения, когда сервис превращается из задумки в рабочую систему. Decommissioning — фаза вывода из эксплуатации, когда система безопасно и полностью удаляется. У них разные цели, метрики и риски.

Обе фазы должны управляться через Infrastructure as Code (IaC). Тогда весь жизненный цикл — от первого запроса до полного удаления — становится предсказуемым, воспроизводимым и задокументированным. Код определяет не только то, как и что создаётся, но и то, как это будет уничтожено.

Provisioning: как построить систему правильно

Provisioning — это исполнение чёткого плана (blueprint) по созданию рабочего окружения из «сырых» ресурсов. Процесс разбит на шесть шагов:

1. Определение желаемого состояния. Документируем результат и переводим его в исполняемый код: Terraform-скрипты, описания ресурсов, правила масштабирования и группы безопасности.
2. Выделение ресурсов. Инструмент автоматизации обращается к API облачного провайдера и создаёт виртуальные машины, сети, базы данных.
3. Настройка конфигурации. Устанавливаем ОС, middleware, разворачиваем приложения. Здесь помогают Ansible, Chef и другие системы управления конфигурацией.
4. Связывание компонентов. Прописываем сетевые пути, настраиваем Load Balancer, DNS, IAM-роли — чтобы всё общалось друг с другом.
5. Подключение наблюдаемости. Ставим мониторинг, логирование и алерты ещё до запуска сервиса.
6. Проверка. Прогоняем приёмочные тесты (UAT), убеждаемся, что система соответствует плану и готова к продакшену.

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

Decommissioning: контролируемое уничтожение

Decommissioning — это обратный процесс. Его суть не просто «потушить сервер», а полностью ликвидировать цифровой след системы. Пять шагов, которые тут критичны:

1. Картирование зависимостей. Нужно убедиться, что на систему не завязаны другие сервисы: скрипты мониторинга, бэкапы, внешние потребители. Иначе можно случайно обрушить что-то важное.
2. Миграция и архивация данных. Переносим нужное в долговременное хранилище или в систему-преемника. Уничтожение данных должно соответствовать политике хранения.
3. Плавное завершение работы. Переводим сервис в режим обслуживания, чтобы все текущие операции и транзакции завершились естественно.
4. Уничтожение ресурсов. Запускаем IaC-скрипты в обратную сторону: удаляем виртуальные машины, убираем из Load Balancer, удаляем правила безопасности, разрываем биллинг.
5. Аудит и подпись. Фиксируем весь процесс, чтобы остался официальный след, доказывающий, что система выведена из эксплуатации.

Итог: нулевые облачные расходы, чистое состояние без активной поверхности атаки.

Единый взгляд через призму IaC

Код — это общий язык для обеих фаз. Terraform, например, в фазе создания использует terraform apply, а при уничтожении — terraform destroy. Один и тот же план описывает и создание, и удаление ресурсов, поэтому процесс становится предсказуемым.

Типичные ошибки при работе с жизненным циклом

• Не используют IaC для удаления ресурсов. Создали через Terraform, а удаляют руками в консоли — в итоге что-то остаётся и начинает копить деньги.
• Пропускают шаг картирования зависимостей при выводе. И потом в 3 часа ночи падает прод, потому что какой-то скрипт обращался к удалённому серверу.
• Не архивируют данные. Удалили всё, спохватились, а восстановить уже нечего.
• Забывают про аудит. После удаления не остаётся записи, что система была безопасно выведена. Для комплаенса это может стать проблемой.

Что в итоге

Правильно настроенный жизненный цикл — это когда вы управляете и созданием, и удалением ресурсов с одинаковым вниманием. Provisioning и Decommissioning — две стороны одной медали. Один процесс невозможно считать завершённым без второго. Поэтому выстраивайте оба через код, документируйте каждый шаг и обязательно проверяйте, что после деплоя рано или поздно последует чистый, безопасный демонтаж.