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

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

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

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

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

Несколько зон доступности

Основной инструмент отказоустойчивости в Yandex Cloud — распределение по зонам доступности одного региона (ru-central1-a, -b, -d). Зоны — это независимые дата-центры, поэтому авария в одной не задевает другие. На практике:

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

Так падение целой зоны становится не катастрофой, а незаметным событием — при условии, что вы действительно разложились по зонам, а не собрали всё в одной.

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

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

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

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

Резервные копии и снимки

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

  • Автоматические резервные копии управляемых баз — с восстановлением на момент в прошлом; их частота и срок хранения задают RPO.
  • Снимки дисков (snapshots) виртуальных машин — точечная копия состояния диска, из которой можно развернуть машину заново.
  • Версионирование в Object Storage — защита файлов от перезаписи и удаления; бэкапы часто складывают именно в бакет, в дешёвый холодный класс.

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

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

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

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

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

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