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

Отказоустойчивость против аварийного восстановления

Это два разных уровня, их полезно различать.

  • Отказоустойчивость (high availability) — система переживает отказ части себя без остановки. Упал узел или целая зона — трафик ушёл на оставшиеся, пользователь ничего не заметил. Это про «продолжать работать».
  • Аварийное восстановление (disaster recovery, DR) — как поднять систему после крупной аварии, которая всё-таки её уронила: потеря целого региона, порча данных, ошибочное массовое удаление. Это про «как вернуться к жизни и с какими потерями».

Первое строят заранее в архитектуре; второе — это план и бэкапы, которые понадобятся в худший день.

Зоны и мультирегион

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

От крупной аварии всего региона защищает мультирегиональная схема: копии приложения в нескольких регионах за глобальным балансировщиком (он сам направит пользователей в живой регион) и данные, реплицируемые между регионами. Это дороже и настраивается отдельно, но переживает потерю целого региона. Глобальный HTTP-балансировщик GCP делает мультирегиональную схему проще, чем во многих других облаках.

RPO и RTO: язык восстановления

Планируя восстановление, оперируют двумя числами.

  • RPO (Recovery Point Objective) — сколько данных вы готовы потерять, измеряется временем. RPO = 1 час означает «в худшем случае теряем последний час изменений». Определяется частотой резервных копий.
  • RTO (Recovery Time Objective) — как быстро надо вернуть сервис к жизни. RTO = 30 минут означает «через полчаса после аварии система снова работает».

Эти два числа — не технические детали, а бизнес-решение: чем меньше RPO и RTO, тем дороже подготовка. Сначала договариваются, что приемлемо, потом строят под это.

Резервные копии и репликация

Отказоустойчивость не спасает от порчи или удаления данных: если ошибочный запрос удалил строки, реплики честно повторят удаление. Здесь спасают только копии, отдельные от боевых данных:

  • автоматические резервные копии Cloud SQL — с восстановлением на момент в прошлом; их частота задаёт RPO;
  • снимки дисков (snapshots) виртуальных машин — точечная копия состояния диска;
  • версионирование и мультирегиональные бакеты в Cloud Storage — защита файлов от перезаписи и хранение копий в нескольких регионах; бэкапы часто складывают в дешёвый класс Archive.

Ключевое правило, которое нарушают чаще всего: бэкап, который ни разу не восстанавливали, — это не бэкап, а предположение. Восстановление надо проверять, иначе в худший день выяснится, что копии битые или неполные.

Где это применяется

Практический минимум для боевого сервиса: копии приложения в нескольких зонах за балансировщиком, Cloud SQL с резервом в другой зоне и автопереключением, регулярные копии с осознанным RPO и хотя бы раз проверенным восстановлением. Этого достаточно, чтобы пережить самые частые сбои без потери данных и с предсказуемым простоем.

Типичные ошибки новичков:

  • всё в одной зоне — «отказоустойчивая» система падает целиком при аварии зоны;
  • нет резервных копий, потому что «есть же реплики» — реплики повторяют и ошибочное удаление;
  • никогда не проверяли восстановление — узнают о битых бэкапах в день аварии;
  • не договорились про RPO/RTO — строят наугад, переплачивая или недозащищаясь.

Что учить дальше: как строится доступность в норме — в масштабировании и доступности; где хранят копии — в Cloud Storage; принципы устойчивых распределённых систем не привязаны к облаку — их разбирает системный дизайн. Аналогичный разбор для AWS — отказоустойчивость и аварийное восстановление в AWS.