У компании два облачных провайдера. В одном работает приложение, в другом — аналитика. Это Multi-Cloud, но не резервирование приложения. Другой вариант: у второго поставщика лежат копии данных. Это полезная защита, однако между копией и работающим сервисом ещё остаются восстановление, доступы и запуск.
Поэтому сначала надо назвать цель: использовать разные возможности, пережить потерю основного поставщика или сохранить возможность уйти от него. Эти задачи могут пересекаться, но оплачивать и проверять их придётся по-разному. Различие целей помогает не построить дорогой дубль там, где требовался переносимый архив.
Какое событие должно пережить приложение
Потеря отдельной зоны, региона, доступа к учётной записи и всего поставщика — разные сценарии. Несколько регионов одного облака могут решить часть задач с меньшей операционной сложностью. Второй провайдер рассматривают отдельно, когда важен риск, который такое размещение не покрывает.
Для аварии определяют целевое время восстановления, RTO, и допустимый разрыв по свежести данных, RPO. Учитывают весь нужный процесс, включая вход и подтверждённые изменения. Для планового ухода важнее срок переноса, период совместной работы и допустимая остановка. Отработанный переезд за месяц не доказывает восстановление за часы.
Сравнение вариантов непрерывности работы есть в руководстве Google Cloud. Оно полезно как набор вариантов, а не доказательство, что именно второй поставщик нужен любому продукту.
Проверяем независимость без помощи первой площадки
Допустим, резервное приложение запускается, но ключ расшифрования копии доступен только через основной аккаунт. Или инженеры не могут войти: корпоративная авторизация размещена там же. Две площадки существуют, а восстановление по-прежнему требует исправности той, которую потеряли.
Пройдите зависимости: имена, сертификаты, секреты, файлы, очередь, реестр образов, средства запуска и доступ сотрудников. Важна не только передача обычного запроса, но и возможность создать замену во время отказа. Проверка уже работающего резерва не отвечает на вопрос, удастся ли его заново развернуть.
Общие внешние системы тоже остаются. Если обе площадки ждут одного поставщика платежей, второй cloud не восстановит его. Одновременный неудачный выпуск может затронуть обе стороны. Независимость относится к выбранным причинам отказа, а не ко всему продукту сразу.
Формат данных важнее одинаковых контейнеров
Перенести образ приложения часто проще, чем его состояние. Снимок управляемой базы может требовать исходной услуги для восстановления. Наличие файла у второго провайдера не доказывает, что его можно прочитать, расшифровать и использовать там. Нужен испытанный формат переноса и совместимая целевая система.
Проверяют не только строки, но и права, расширения, правила сортировки, поведение запросов и версии приложения. Аналогичный по названию сервис другого облака может иметь иные ограничения. Крупная выгрузка добавит время передачи, квоты и расходы. Всё это входит в путь восстановления, а не остаётся за рамками сравнения серверов.
Асинхронный перенос оставляет промежуток, в котором подтверждённые изменения ещё не попали на другую сторону. При синхронной координации запись зависит от связи и доступности нужных участников. Выбор гарантий нужно проверять в конкретной технологии; универсального режима «быстро, независимо и без потерь» нет.
Между облаками не стоит делать лишних обязательных вызовов
Если каждый рабочий запрос требует ответа от обоих провайдеров, доступность второго становится дополнительным условием успеха, а не запасным путём. Так иногда оправданно разделяют функции, но такую схему нельзя представлять как независимый резерв. Синхронные межсредовые зависимости отдельно отмечены в руководстве Google Cloud по непрерывности работы.
Для переключения также нужен порядок владения записью. Основная сторона может быть недоступна части клиентов и всё ещё обслуживать остальных. Простая смена DNS не гарантирует, что старый путь прекратил менять данные. Новая площадка должна принимать работу по согласованным правилам, а не по предположению, что сосед точно выключился.
Переносимость тоже имеет постоянную цену
Можно отказаться от специфических услуг и самостоятельно эксплуатировать общие компоненты. Иногда это оправданно. Но теперь компания оплачивает обновления, восстановление и компетенции, которые раньше покупала вместе с услугой. Сравнение подробно разобрано в Managed vs Self-Hosted.
Не обязательно уравнивать обе площадки во всём. Иногда достаточно сохранить читаемые данные, отделить несколько интеграций и поддерживать проверенный путь миграции. Такие варианты стратегии рассматривает разбор причин и ограничений Multi-Cloud. Разница между услугами должна быть известна, а не спрятана за общей обёрткой.
В расчёт входят обе среды, передача, поддержка, безопасность, обучение и испытания. Команда должна уметь работать на резервной стороне не только в день первоначальной настройки. Скидки и обязательства текущего поставщика также влияют на реальную цену выхода.
Два разных результата проверки
Для аварийного резерва проверяют нужный пользовательский путь без доступа к первой площадке, с согласованной нагрузкой и доступными там данными. Фиксируют время, потерянные изменения и ручные шаги. После появления новых записей обратное переключение требует сверки, а не простого возврата адреса.
Для плана выхода достаточно другой доказательной работы: перенос данных, запуск требуемых операций, оценка сроков и замены оставшихся зависимостей. Результат честно называют готовностью к миграции. Тогда руководство понимает, за что платит сейчас и какие действия потребуются, когда названный риск действительно реализуется.