Что делать банку, если исчезло облако
Основная платформа Monzo работает в AWS. Команда построила отдельную систему Monzo Stand-in в Google Cloud, чтобы при крупной аварии клиенты сохраняли доступ к важным операциям. Во время реального часового сбоя основного контура Stand-in включили вскоре после обнаружения проблемы.
Самое интересное в кейсе — резерв не пытался стать вторым Monzo. Он делал ограниченный набор вещей, необходимых человеку прямо сейчас. Такая скромность и делает дорогую идею выполнимой.
Резервируют не сервисы, а обещание
Классический план часто начинается со списка серверов: поднять базу, очередь, API, аналитику. Пользователю этот список безразличен. Его обещание звучит иначе: карта работает, баланс не потерян, перевод не исчез.
Для интернет-магазина аварийный режим может принять заказ и отправить подтверждение позже. Для производственной системы — сохранить показания локально. Для корпоративного портала — дать сотрудникам скачать критичный документ. Сначала определяют обещание, затем минимальную архитектуру.
Независимый значит действительно отдельный
Реплика в том же аккаунте, с тем же SSO и тем же pipeline может упасть вместе с основной системой. Monzo вынес Stand-in в другое облако и спроектировал отдельный путь. Но два облака сами по себе не дают устойчивость: можно оставить общий DNS, единый секрет или ошибку приложения и получить две одинаково неработающие копии.
Карту зависимостей нужно проходить до конца: доступы, домены, сертификаты, ключи, поставщики сообщений, репозитории, ноутбуки дежурных.
Самая сложная часть — свежие данные
Резервная платформа должна знать достаточно о счетах и картах, чтобы принимать безопасные решения. Чем ближе к реальному времени репликация, тем выше сложность и риск распространить повреждение из основного контура.
Поэтому DR-проекту нужны явные RPO и RTO. RPO отвечает, сколько данных допустимо потерять. RTO — сколько времени можно восстанавливаться. Фразы «ничего и никогда» без бюджета и измерения не являются требованиями.
Multi-cloud — последний этаж, не фундамент
Для небольшого бизнеса два облака часто уменьшают надёжность: две панели, две сети, две модели IAM и вдвое больше того, что команда плохо знает. Сначала стоит довести до ума один контур: инфраструктура как код, мониторинг, отдельные бэкапы, восстановление в чистое окружение и понятное дежурство.
Второе облако появляется, когда есть регуляторное требование или стоимость полного отказа действительно оправдывает постоянную эксплуатацию дублёра.
Тренировка важнее схемы
Failover, который никогда не включали, — гипотеза. Переключение нужно репетировать: сначала в тесте, затем ограниченно в production. Проверять не только HTTP 200, но и то, видит ли пользователь правильный баланс, приходит ли сообщение, может ли поддержка объяснить режим.
После каждой тренировки runbook укорачивают. Если для активации нужны десять экспертов и сорок ручных шагов, ночью система не спасёт бизнес.
Практичная лестница устойчивости
Начните с инвентаризации и бэкапов. Добавьте восстановление, мониторинг и дежурство. Затем — деградированный режим внутри того же облака. После этого — отдельный регион. И только потом решайте, нужно ли второе облако.
Кейс Monzo не говорит «всем нужен GCP вдобавок к AWS». Он показывает более важную мысль: во время аварии продукт может стать меньше, но не должен перестать выполнять своё главное обещание.