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

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

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

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

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

Зоны и парные регионы

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

От крупной аварии всего региона защищает парный регион (region pair) — у каждого региона Azure есть заранее назначенная пара, куда реплицируют данные и куда можно переключиться. Это дороже и настраивается отдельно, но переживает потерю целого региона.

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

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

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

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

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

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

  • Azure Backup — резервные копии виртуальных машин и баз с заданной частотой и сроком хранения; частота задаёт RPO;
  • автоматические копии управляемых баз — с восстановлением на момент в прошлом;
  • гео-избыточное хранилище (GRS) для Blob Storage — копия данных в парном регионе; бэкапы часто складывают в дешёвый уровень Archive;
  • Azure Site Recovery — сервис, который оркестрирует переключение целой системы в другой регион по плану DR.

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

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

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

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

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

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