Сломается обязательно: диск, дата-центр, ошибочный запрос, который удалил половину таблицы. Разница между катастрофой и штатной ситуацией в одном: заранее ли известно, что произойдёт, когда сломается, и сколько это займёт.
Облако даёт для этого готовые кирпичи — зоны, реплики, копии, — но не собирает их за вас и не проверяет, что собранное работает. В этой статье — две разные задачи, которые часто путают, два числа, которые определяют схему, и правило про непроверенную копию.
Две разные задачи: от отказа дата-центра спасают живые копии по зонам, а от ошибочного запроса, который удалил данные, только резервная копия. Реплика в другой зоне удалит таблицу вслед за мастером за миллисекунды.
Две разные задачи
Отказоустойчивость — про то, чтобы сервис продолжал работать, когда сломалась часть железа: диск, машина, целый дата-центр. Её строят дублированием: несколько копий приложения, реплика базы, всё раскидано по зонам. Отказ одной части незаметен для пользователя или стоит секунд.
Восстановление — про другое: данные испорчены или потеряны, и их надо вернуть. Ошибочный запрос удалил строки, миграция сломала таблицу, регион лёг целиком. Дублирование здесь не помогает — реплика честно повторит удаление. Спасают только копии, отдельные от боевых данных, и заранее известный порядок их возврата.
Путают их постоянно: «у нас есть реплика, значит, копии не нужны». Реплика защищает от отказа узла, копия — от ошибки. Нужны обе.
Отказоустойчивость: зоны и реплики
Основной инструмент в облаке — зоны доступности одного региона. Копии приложения раскладывают по зонам за балансировщиком: выпала зона — балансировщик перестал слать туда трафик, оставшиеся копии подхватили. Управляемую базу берут с репликой в другой зоне и автоматическим переключением: провайдер переведёт адрес на реплику за десятки секунд, приложение увидит это как разрыв соединений и должно уметь переподключиться.
Это дёшево относительно выигрыша: задержка между зонами — миллисекунды, а отказ дата-центра перестаёт быть катастрофой. Чего зоны не закрывают — отказ самого облака в регионе: управляющий слой общий, региональные аварии случаются. От них защищает только второй регион.
Восстановление: RPO, RTO и копии
Два числа определяют всю схему. RPO — сколько данных вы готовы потерять: если копия снимается раз в сутки, потеряете до суток. RTO — сколько времени готовы стоять: восстановление из копии на новую базу занимает часы, переключение на тёплый резерв — минуты. Оба числа называет бизнес, а инженер под них подбирает механизмы, и чем меньше числа, тем дороже схема.
Копии у управляемых сервисов снимает провайдер: ежедневный снимок плюс журнал транзакций, восстановление на любой момент внутри окна хранения. Окно ограничено неделями, и данные, которые должны переживать месяцы, копируют отдельно. Копии объектного хранилища — версионирование и правила жизненного цикла; копии машин — снимки дисков.
Ключевое правило, которое нарушают чаще всего: копия, которую ни разу не восстанавливали, — не копия, а надежда. Восстановление прогоняют по расписанию, на отдельной базе, с замером времени, и это же время и есть ваш реальный RTO.
Четыре стратегии восстановления
От дешёвой к дорогой. Копия и восстановление: только копии, при аварии поднимаем всё заново — часы простоя, минимум денег. Тлеющий огонёк: в резервном регионе есть база с репликацией и минимальная инфраструктура, приложение поднимают при аварии — десятки минут. Тёплый резерв: уменьшенная копия системы работает постоянно, при аварии её масштабируют — минуты. Активный-активный: оба региона обслуживают трафик всё время — секунды, вдвое дороже и сложнее в данных. Выбирают по RPO и RTO, а не по красоте: для большинства продуктов правильный ответ — первая или вторая.
Глубже: что ломается при переключении на репликурасширенное
Переключение на реплику — не мгновение. Провайдер должен убедиться, что основной узел действительно недоступен, поднять реплику до основной и перевести на неё адрес; на это уходят десятки секунд, и всё это время запросы к базе падают. Приложение обязано пережить это: пул соединений переподключается, повторяет упавшие запросы там, где это безопасно, а не валится с ошибкой инициализации. Проверить это можно только заранее: принудительно переключить реплику на тестовом стенде и посмотреть, что сделал сервис.
Второй эффект — потеря последних транзакций при асинхронной репликации: реплика отстаёт на секунды, и то, что не успело доехать, теряется. Синхронная реплика этого не допускает, но платит задержкой на каждой записи. Выбор между ними — это тоже про RPO.
Глубже: учения по восстановлениюрасширенное
Схема восстановления, записанная в документе, стареет: меняются адреса, права, версии. Единственный способ узнать, что она работает, — прогнать её. Раз в квартал команда восстанавливает базу из копии на отдельный стенд, поднимает сервис на нём и замеряет время. Расхождения с документом чинят сразу, а замер становится честным RTO вместо предполагаемого. Это скучная работа, и именно её пропускают чаще всего.
Глубже: что обещает провайдер: SLA, составная доступность и бюджет отказоврасширенное
Вся статья про доступность, и ни одной цифры обязательств. У каждого управляемого сервиса есть соглашение об уровне обслуживания, SLA, и его читают до архитектуры, а не после инцидента.
Что означает число. 99,9 % это до 43 минут недоступности в месяц, 99,95 % до 22 минут, 99,99 % до 4 минут. Типичные обязательства крупных провайдеров: одиночная виртуальная машина около 99,5 %, машины в нескольких зонах 99,99 %, управляемая база с репликой в другой зоне 99,95 %, объектное хранилище 99,9 % доступности при одиннадцати девятках сохранности данных, балансировщик 99,99 %. Это обещания по каждому сервису отдельно и внутри одного региона.
Составная доступность. Запрос проходит балансировщик, сервис на машинах, базу и очередь, и отказ любого звена это отказ запроса. Доступности последовательных звеньев перемножаются: пять звеньев по 99,9 % дают 0,999 в пятой степени, около 99,5 %, то есть три с половиной часа в месяц вместо сорока минут. Параллельные независимые копии наоборот складывают надёжность: две копии по 99,5 % дают 1 минус 0,005 в квадрате, 99,9975 %. Отсюда правило проектирования: цепочку укорачивать, каждое звено резервировать. Ваш собственный сервис в этой формуле тоже звено, и его доступность обычно ниже, чем у любого сервиса провайдера.
На что гарантия не распространяется. Плановые работы в объявленные окна, ваши ошибки конфигурации (закрыли порт, удалили роль), ваше приложение, превышение квот, форс-мажор, и почти всегда предварительные версии сервисов. Компенсация это не возмещение убытков, а кредит на счёт, 10–25 % месячной платы за этот сервис, который нужно запросить самому в срок (обычно тридцать дней) с журналами, доказывающими недоступность. То есть SLA это не страховка, а обещание, по которому вы сами ведёте учёт.
Бюджет отказов. Число из SLA переводят в бюджет: при цели 99,9 % у команды есть 43 минуты в месяц на всё: инциденты, выкаты, учения. Пока бюджет не исчерпан, выкатывают смело; исчерпан, и до конца месяца только исправления. Это единственный способ спорить о рисках цифрами, а не ощущениями, и он же задаёт, на что ставить сигнал тревоги: не на факт ошибки, а на скорость сгорания бюджета.
Коротко
- Отказоустойчивость и восстановление — разные задачи: первая переживает отказ железа, вторая возвращает данные после ошибки или катастрофы.
- Раскладка копий по зонам за балансировщиком и реплика базы в другой зоне закрывают отказ дата-центра; от ошибки в данных они не спасают, реплика повторит удаление.
- RPO — сколько данных вы готовы потерять, задаётся частотой копий; RTO — сколько времени готовы стоять, задаётся способом восстановления.
- Копии снимает провайдер, но восстановление проверяете вы: копия, которую ни разу не восстанавливали, — не копия, а надежда.
- Второй регион берут, когда потеря региона недопустима; для большинства продуктов достаточно зон одного региона и проверенных копий.
- Схему восстановления записывают и прогоняют по расписанию, а не вспоминают во время аварии.
- SLA читают в минутах: 99,9 % это 43 минуты в месяц; последовательные звенья перемножаются, параллельные копии складывают надёжность; гарантия не покрывает ваши ошибки и плановые окна, компенсация это кредит по заявке; цель переводят в бюджет отказов.
Что почитать дальше
- Регионы и зоны — из чего строится раскладка по зонам и от чего она не защищает.
- Отказоустойчивость и DR в AWS — те же стратегии на сервисах AWS.
- Корректность в распределённых системах — почему копии и реплики не заменяют проверку данных.