Cloud Exit Plan: какие документы, бэкапы и Terraform-файлы нужно иметь до смены провайдера

Cloud Exit Plan — это не папка “на случай переезда”, а проверяемый сценарий выхода из текущего облака. До смены провайдера компания должна понимать, какие сервисы критичны, где лежат данные, чем они зашифрованы, какие зависимости есть у приложений и за какое время всё это реально восстановить в другой среде.

Минимальный набор артефактов включает:

• Инвентаризацию облачных ресурсов: аккаунты, проекты, регионы, сети, DNS, базы, очереди, хранилища и управляемые сервисы;
  
• Карту зависимостей сервисов: приложения, данные, IAM-роли, секреты, ключи, внешние API, DNS и очереди;
  
• Архитектурные и операционные документы: схемы сетей, описание окружений, runbook-и, порядок переключения и отката;
  
• Договорные документы: срок уведомления, окно доступа к данным, условия выгрузки, стоимость исходящего трафика и поддержка на этапе выхода;
  
• Реестр бэкапов: состав, формат, расположение, срок хранения, шифрование, владелец ключей и процедура восстановления;
  
• Результаты тестового восстановления вне текущего провайдера;
  
• Terraform-репозиторий, lock-файл, state, описание backend, outputs, переменные Окружений и карту импорта ресурсов;
  
• Реестр секретов, сертификатов и ключей с планом переноса, перевыпуска или ротации;
  
• Миграционный план с последовательностью работ, ответственными, критериями успеха и планом отката.

Главная проверка простая: можно ли восстановить критичный контур вне текущего облака в пределах RTO/RPO и договорного окна. Если Terraform state хранится у подрядчика, бэкап читается только через старый KMS, карта зависимостей не заполнена, а восстановление ни разу не тестировалось в независимой среде, Cloud Exit Plan пока не готов.

Почему “при необходимости переедем” часто не работает

Представим B2B SaaS-компанию, у которой есть клиентский API, авторизация, биллинг, база клиентов, объектное хранилище, очереди, DNS и несколько внешних интеграций. На бумаге всё выглядит спокойно: инфраструктура описана в репозитории при помощи Terraform, бэкапы выполняются по расписанию, доступы есть у подрядчика и внутренней команды.

Но необходимость выйти из текущего облака редко возникает в идеальный момент. Это может быть коммерческий спор, расторжение договора, изменение требований compliance, деградация SLA, рост стоимости или стратегическая миграция. И тогда выясняется, что “у нас есть Terraform” и “у нас есть бэкапы” — ещё не план выхода.

State Terraform может храниться в аккаунте подрядчика. Часть ресурсов могла быть создана вручную и не попала в код. Бэкапы могут восстанавливаться только внутри старого облака. Ключи шифрования могут быть завязаны на KMS текущего провайдера. Платёжный шлюз может принимать запросы только с прежних IP-адресов. А договор может давать ограниченное окно на выгрузку данных и проверку восстановления.

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

Что должен фиксировать Cloud Exit Plan до смены провайдера

Cloud Exit Plan начинается не с выгрузки всех данных и не с копирования Terraform-репозитория. Сначала нужно определить, что именно компания должна уметь восстановить, в какие сроки и при каких ограничениях.

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

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

Перед сбором артефактов стоит зафиксировать несколько вещей:

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

Для такой классификации можно использовать уровни критичности. Например, Tier 0 — системы, без которых бизнес-процесс останавливается сразу: авторизация, биллинг, платёжный контур, клиентские данные. Tier 1 — важные сервисы, которые допускают чуть большее окно восстановления: обработка заказов, внутренние интеграции, клиентские API второго уровня.

Эту критичность лучше связывать с BIA — анализом влияния на бизнес. Он помогает определить, какие системы действительно влияют на выручку, обязательства перед клиентами и регуляторные требования. После этого сервисы привязывают к RTO/RPO: что должно восстановиться за минуты, что — за часы, а что можно переносить позже с приличными даунтаймами.

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

Если эта рамка не зафиксирована, бэкапы, Terraform-файлы и договоры остаются разрозненными активами. Когда рамка понятна, её можно переводить в конкретный комплект артефактов: документы, карту зависимостей, резервные копии, Terraform-state, журналы тестов и договорные условия, которые должны быть у команды до смены провайдера.

Обязательные артефакты Cloud Exit Plan: что должно лежать в руках команды

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

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

Такой комплект не обязан быть огромным на старте. Важно, чтобы он был связанным. Terraform без бэкапов не восстанавливает данные. Бэкапы без ключей не гарантируют чтение. Документы без тестов не подтверждают, что план можно выполнить. А карта зависимостей нужна, чтобы не поднять “пустой” сервис без DNS, секретов, очередей и внешних интеграций.

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

Документы, которые нужно иметь до смены провайдера

Документы в Cloud Exit Plan нужны не для формальности. Их задача — убрать зависимость от текущего провайдера, подрядчика и отдельных сотрудников, которые “просто знают, как всё устроено”. Перед сменой провайдера у команды должен быть комплект материалов, по которому можно понять архитектуру, выполнить переключение и проверить договорные ограничения.

Удобно разделить документы на три группы:

В архитектурных документах важно показать не только список ресурсов, но и связи между ними. Например, публичный API может зависеть от DNS, балансировщика, клиентской базы, очереди, IAM-ролей, KMS-ключа и внешней CRM. Если эта связь не описана, команда может перенести сервер и базу, но получить нерабочий сервис.

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

Договорный блок часто недооценивают, хотя именно он связывает технический план с реальностью. Если по договору данные доступны 30 дней после уведомления, а тестовая выгрузка с учётом каналов, объёма и проверок занимает 45 дней, это риск Cloud Exit Plan. Его нужно зафиксировать до расторжения договора, а не после того, как старый провайдер уже начал отсчитывать срок.

После документов становится понятно, что именно нужно переносить и какие ограничения есть у процесса. Следующий шаг — описать зависимости сервисов: без этого инвентаризация ресурсов останется просто списком объектов, а не рабочей картой восстановления.

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

Типичный сценарий: команда восстановила приложение и базу в новой среде, но публичный сервис не стартовал. Причина оказалась не в коде: не перенесли секрет для платёжного API, роль доступа к объектному хранилищу и DNS-запись для клиентского домена. В инвентаризации эти ресурсы были видны, но связи между ними не были зафиксированы как обязательные условия запуска.

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

Например:

• Клиентский API. Зависит от клиентской БД, кэша, публичного DNS, балансировщика, приватных подсетей, роли чтения БД, роли записи в логи, ключей шифрования, API-токенов, CRM и системы поддержки. Если перенести только приложение и базу, сервис может подняться технически, но не сможет обслуживать клиентов.
  
• Биллинг. Зависит от базы платежей, счетов, очередей, приватного доступа, исходящего NAT, роли доступа к БД, секрета платёжного шлюза, KMS-ключа, платёжного провайдера и бухгалтерской системы. Для такого сервиса важно отдельно проверить соответствие RTO/RPO, потому что потеря платежных событий обычно критичнее, чем задержка внутренней аналитики.
  
• Авторизация пользователей. Зависит от базы учётных записей, сессий, DNS auth-домена, балансировщика, роли доступа к каталогу пользователей, ключей подписи токенов, SSO и почтового сервиса. Если забыть ключи подписи или интеграцию с SSO, пользователи не смогут войти даже при восстановленной базе.
  
• Обработка заказов. Зависит от заказов, событий, очередей, внутренних маршрутов, роли чтения очередей, записи в хранилище, секретов сервисных учётных записей, склада и доставки. Такой сервис нельзя переносить отдельно от очередей и внешних контрагентов, иначе часть бизнес-процесса остановится.

Карта зависимостей показывает не просто “что есть”, а что должно заработать вместе. Если у критичного сервиса не заполнены доступы, ключи, DNS или внешние интеграции, он не готов к выходу даже при наличии всех ресурсов в инвентаризации.

Особое внимание нужно уделять управляемым сервисам: базам, очередям, бессерверным и событийным сервисам, облачному IAM, политикам доступа и сервисам управления ключами. Их нельзя считать переносимыми только потому, что они есть в списке ресурсов. Для каждого такого компонента нужно указать, что с ним происходит при выходе:

• Переносится как данные;
• Заменяется аналогом в новой среде;
• Пересобирается заново;
• Временно остаётся зависимостью от старого провайдера;
• Исключается из первого этапа миграции.

После карты зависимостей становится понятно, какие данные и настройки нужно переносить вместе.

Бэкапы: какие копии нужны и как их проверять

Резервная копия в Cloud Exit Plan должна отвечать не только на вопрос “есть ли копия”. Важно понять, где она лежит, чем зашифрована, в каком формате хранится, можно ли прочитать её вне текущего провайдера и сколько времени займёт восстановление.

Для выхода из облака обычно нужны копии нескольких типов данных:

• Базы данных — полные дампы, журналы транзакций или point-in-time recovery, если он доступен;
  
• Объектные хранилища — копии бакетов, версии объектов, метаданные и политики жизненного цикла;
  
• Диски и образы машин — снимки критичных серверов, если восстановление из образа входит в сценарий;
  
• Очереди и события — экспорт сообщений, если бизнес-процесс не допускает их потери;
  
• Конфигурационные данные — параметры приложений, feature flags, настройки маршрутизации;
  
• Логи и аудит — журналы безопасности, операционные логи, данные для расследований и отчётности;
  
• Секреты и сертификаты — не пароли в открытом виде, а управляемый процесс экспорта, перевыпуска или ротации.

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

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

После этого главный вопрос уже не “есть ли бэкап”, а “можно ли его восстановить вне старого облака”. Это нужно проверить отдельно.

Проверка восстановимости данных вне текущего провайдера

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

Проверку лучше выполнять по одному шаблону:

1. Выбрать набор данных: критичную базу, часть объектного хранилища, конфигурации, логи, секреты или сертификаты.
   
2. Забрать копию из текущего облака через штатный экспорт, репликацию или выгрузку в независимое хранилище.
   
3. Проверить доступ к ключам: подтвердить, что данные можно расшифровать вне старого KMS или есть утверждённый процесс перевыпуска ключей.
   
4. Восстановить данные в независимой среде, не используя внутренний механизм восстановления, доступный только у текущего провайдера.
   
5. Сверить целостность: количество записей, контрольные суммы, выборочные бизнес-проверки, связи между таблицами и объектами.
   
6. Измерить время восстановления и сравнить его с RTO.
   
7. Оценить потерю данных и сравнить точку восстановления с RPO.
   
8. Зафиксировать ограничения: несовместимые форматы, пропущенные метаданные, зависимость от сервисов провайдера, ручные шаги.
   
9. Назначить владельцев исправлений, если восстановление не прошло.

Результат проверки должен быть оформлен как протокол: дата, объём данных, источник копии, целевая среда, использованные ключи, время восстановления, результат сверки и список ограничений. Без такого протокола фраза “бэкапы есть” не подтверждает готовность к выходу.

Когда данные проверены, остаётся второй крупный слой — инфраструктура. Здесь Terraform помогает, но только если у компании есть не один репозиторий с .tf-файлами, а полный комплект артефактов, связывающих код с реальной средой.

Terraform-файлы: что нужно иметь кроме кода

Terraform помогает описывать инфраструктуру как код, но для смены провайдера одного репозитория недостаточно. В Cloud Exit Plan важно собрать не только .tf-файлы, но и всё, что связывает код с реальной инфраструктурой:

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

Перед выходом стоит выполнить минимум четыре проверки:

• Репозиторий доступен компании, а не только подрядчику;
  
• State выгружен, защищён, имеет контрольную сумму и доступен вне текущего провайдера;
  
• Terraform plan выполняется в изолированной среде без скрытых зависимостей от рабочих учётных записей;
  
• Все ресурсы из инвентаризации либо есть в Terraform, либо попали в карту импорта или список ручной замены.

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

Задача Cloud Exit Plan — сохранить эту информацию в управляемом виде до начала смены провайдера. После этого можно собирать уже не отдельные документы и проверки, а полноценный план миграции: что делаем, в каком порядке, кто отвечает, как проверяем успех и когда выполняем откат.

Шаблон плана миграции

Мы подготовили примерный шаблон миграции, ведь Cloud Exit Plan без него быстро превращается в набор намерений. В нём вроде есть бэкапы, Terraform и документы, но непонятно, кто нажимает кнопку, в каком порядке поднимаются сервисы, где точка невозврата и что делать, если проверка не прошла.

Чтобы было проще ориентироваться в нём – разберём всё поэтапно.

Что должно быть в плане до начала миграции

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

План должен объяснять, зачем выполняется смена провайдера и какой результат считается успешным. Например, цель может звучать так: перенести критичный контур продукта в новое облако без нарушения RTO/RPO и без потери клиентских данных.

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

Отдельно описывают критичность сервисов, владельцев, договорное окно и ответственных. Команда должна заранее знать, какие системы относятся к Tier 0/Tier 1, сколько времени есть на выгрузку данных и кто отвечает за инфраструктуру, данные, безопасность, приложение, договоры и бизнес-проверку.

Что должно быть готово технически

Техническая часть плана должна связывать все артефакты, которые уже были собраны раньше. Здесь важно не просто указать “бэкапы есть” или “Terraform есть”, а описать, какие именно материалы используются при миграции.

Удобно держать это в короткой таблице:

Такая таблица помогает быстро увидеть, где план ещё не готов. Если данные восстановлены, но ключи не перевыпущены, сервис не заработает. Если инфраструктура поднята, но DNS и allowlist у контрагентов не обновлены, пользователи всё равно не попадут в новый контур.

Порядок переключения и проверки

Самая важная часть миграционного плана — последовательность работ. Она должна быть написана так, чтобы команда могла выполнить её в стрессовом окне, а не восстанавливать порядок действий по памяти.

Обычно последовательность выглядит так:

1. Заморозить изменения в старой среде и согласовать исключения;
2. Поднять или обновить инфраструктуру в целевой среде;
3. Восстановить данные и проверить доступ к ключам;
4. Настроить секреты, сертификаты, роли и внешние интеграции;
5. Выполнить технические проверки: сеть, DNS, API, очереди, логи, мониторинг;
6. Выполнить бизнес-проверки: авторизация, биллинг, платежи, клиентские операции;
7. Переключить DNS или балансировщики;
8. Наблюдать метрики, ошибки API, очереди и обращения в поддержку;
9. Зафиксировать результат переключения.

Критерии успеха должны быть конкретными. Не “сервис работает”, а “авторизация проходит, платежи создаются, клиентский API отвечает, количество записей совпадает, ошибки API в пределах нормы, новые события появляются в целевой базе и логах”.

Откат, риски и вывод старой среды

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

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

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

Отдельно описывают коммуникации: кого уведомлять до, во время и после переключения. В зависимости от сервиса это могут быть внутренние команды, поддержка клиентов, владельцы договора, внешние контрагенты и партнёры по интеграциям.

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

Что считать готовностью к выходу

Cloud Exit Plan можно считать рабочим не после сбора файлов, а после проверки. Важно не просто иметь Terraform, бэкапы, документы и договоры, а доказать, что критичный контур можно восстановить вне текущего провайдера в заданных ограничениях.

Минимальная проверка готовности выглядит так:

Главный признак зрелого Cloud Exit Plan — команда может доказать, что выход возможен в заданных условиях. Документы показывают, что переносить и в каком порядке. Бэкапы подтверждают доступность данных. Terraform фиксирует инфраструктурные факты. Карта зависимостей показывает, какие сервисы нельзя восстанавливать по отдельности. Тесты доказывают, что данные читаются вне текущего провайдера.

Если один из этих элементов отсутствует, план не обязательно провален, но риск должен быть явно описан:

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

После такой проверки можно переходить к финальному выводу: Cloud Exit Plan нужен не для красивого архива документов, а для управляемого выхода из облака без аварийной импровизации.

Заключение

Cloud Exit Plan — это не папка с Terraform-кодом, бэкапами и схемами на случай будущей миграции. Это проверяемый сценарий: что переносим, в каком порядке, какими данными, с какими ключами, за какое время и кто отвечает за каждый шаг.

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

Хороший Cloud Exit Plan не делает миграцию простой, но убирает самый опасный сценарий — выход “по памяти”, в условиях спора, дедлайна или деградации сервиса. Компания заранее понимает, где у неё реальные переносимые активы, где зависимость от провайдера, а где ещё не план, а надежда.

FAQ

Cloud Exit Plan нужен только перед реальной миграцией?

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

Достаточно ли Terraform-кода для смены провайдера?

Нет. Terraform-код без state, backend, lock-файла, outputs, переменных и карты импорта не показывает полную связь с реальной инфраструктурой. Кроме того, при смене провайдера ресурсы и managed-сервисы могут отличаться, поэтому код часто становится источником фактов, а не готовым рецептом переноса. Terraform state хранит связь между объектами в удалённой системе и ресурсами в конфигурации, а импорт нужен, чтобы взять уже существующие ресурсы под управление Terraform.

Почему бэкапы нужно проверять вне текущего провайдера?

Потому что копия может существовать, но быть пригодной только внутри старого облака: из-за формата снимка, зависимости от managed-сервиса или ключа в KMS. Для Cloud Exit Plan важно доказать, что данные можно прочитать, расшифровать и восстановить в независимой среде.

Что делать, если часть сервисов невозможно перенести напрямую

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

Как понять, что Cloud Exit Plan действительно готов?

Готовность подтверждается не количеством файлов, а проверкой: критичный контур восстановлен вне текущего облака, RTO/RPO измерены, зависимости заполнены, Terraform-state доступен компании, ключи и секреты имеют план переноса, а миграционный план содержит ответственных, критерии успеха и откат. NIST SP 800-34 Rev. 1 отдельно подчёркивает важность contingency planning как процесса подготовки к восстановлению информационных систем после нарушений работы.

Список источников

1. HashiCorp Developer — Terraform State

2. HashiCorp Developer — Import Existing Infrastructure Resources

3. NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems