Инфраструктура, которая выживет при падении зоны доступности: проектируем до аварии

Долгое время облачные сервисы подавались как решение, которое само позаботится о доступности. Но реальность такова, что отказ целой зоны или потеря связи с API провайдера могут оставить без работы даже те проекты, где предусмотрено несколько виртуальных машин. Просто разнести инстансы по разным физическим серверам внутри одной стойки — ещё не отказоустойчивость.

Когда говорят о multi-AZ, подразумевают распределение нагрузки между изолированными дата-центрами в пределах одного региона. Это защищает от локальных аварий — пожара, перебоев с питанием, но не от проблем на уровне самого облачного провайдера. Если перестанет отвечать его API, все зоны в этом регионе могут стать недоступными одновременно.

Multi-cloud идёт дальше и подразумевает использование ресурсов независимых поставщиков. Такая архитектура спасает от глобальных инцидентов одного вендора, но требует серьёзной инженерной подготовки: нужно унифицировать развёртывание, мониторинг и маршрутизацию трафика между разными средами. Ключевые метрики, без которых нельзя проектировать аварийное восстановление, — RPO и RTO.

RPO показывает, сколько данных вы готовы потерять в момент сбоя, RTO — через какое время сервис должен заработать снова. Их значения определяют архитектуру: если бизнесу нужны нулевые потери и секундный простой, без active-active или хотя бы active-passive схемы не обойтись. Стратегия active-active подразумевает одновременную работу двух площадок, которые делят пользовательскую нагрузку.

При отказе одной вторая мгновенно принимает весь трафик. Active-passive держит резервную площадку в горячем резерве, но не направляет на неё запросы до момента аварии. Pilot light — это минимальная реплика инфраструктуры, готовая быстро развернуться, а восстановление из резервных копий — самый бюджетный, но и самый медленный вариант.

Недавний массовый сбой у одного из операторов Абоненты Мегафона 16 октября остались без связи: где случился сбой и как вернуть интернет напомнил, что даже крупные провайдеры не застрахованы от полного отказа. Для облачной инфраструктуры это лишь подтверждает необходимость резервирования на уровне, превышающем доверие к единственной точке входа. Когда действительно нужна вторая площадка?

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

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