В первой части мы разделили отказы VM, зоны и всего провайдера, назначили сервисам RPO/RTO и рассмотрели два подхода: независимую резервную площадку и несколько зон внутри одного облака с внешними резервными копиями.
Теперь провайдер уже нестабилен, часть ресурсов недоступна, а бизнес спрашивает не об архитектуре будущего, а о времени возвращения GitLab, сети, документации и рабочих стендов. В этот момент скорость нужна, но хаотичные действия увеличивают риск потери последних исправных данных.
Ниже — практический порядок аварийного переезда, сформированный на опыте миграции внутренних сервисов из недоступной зоны в другое облако.
О чём эта часть
