В ночь на 11 октября остановился дата-центр Яндекса во Владимире, и вместе с ним замолчала зона доступности ru-central1-a. За неделю до этого вышли из строя площадки в Сасово и Калуге, а 11 октября Yandex Cloud официально объявил аварийный режим и рекомендовал клиентам задействовать «любые другие альтернативные планы по аварийному восстановлению». Проблема в том, что у многих команд такого плана попросту не было: реплика жила в соседней зоне, снапшоты хранились в том же регионе, а бэкапы лежали в том же облаке. Спустя три недели после аварии зона ru-central1-b на странице статуса всё ещё числилась недоступной.

Масштаб происшествия оказался значительным. Площадка в Сасово мощностью около 12 МВт получила повреждения и встала полностью, в Калуге вышла из строя часть модулей крупнейшего дата-центра Яндекса на 63 МВт и примерно 3800 стоек, а во Владимире остановилась вся площадка примерно на 40 МВт вместе с суперкомпьютером «Галушкин». Несколько тысяч жителей города остались без света. Последствия быстро вышли за пределы инфраструктуры: ложились Яндекс Про и почта, Циан и Twinby, такси в трёх соседних странах, в Yandex Cloud заморозили квоты на создание новых ресурсов, а поддержка отвечала с перебоями. К вечеру 11 октября компания договорилась с Selectel, VK Cloud и К2Cloud о приоритетном приёме клиентов по программе CloudBro и позже добавила в соглашение пункты о форс-мажоре.

Техническая причина уязвимости кроется в устройстве зон доступности. В документации Yandex Cloud зона описывается как изолированная внутри дата-центра инфраструктура, устойчивая к аппаратным и программным сбоям соседних зон: пожар в одном здании не гасит соседнее, отказ стойки не затрагивает рядом стоящую. Развёртывание в двух зонах действительно закрывает отказ железа, питания и сети одной площадки, но зоны ru-central1 разнесены по Владимиру, Рязани и Калуге и при этом принадлежат одному региону. Второй регион платформы находится в Казахстане, с отдельной консолью и отдельным биллингом, и мало кто держит там резерв про запас. Когда одновременно выходят из строя несколько площадок, расстояние между зданиями внутри региона уже ничего не решает, а control plane, создающий виртуальные машины и выдающий квоты, живёт в том же регионе, что и ресурсы клиента.

Отдельная проблема связана с тем, где фактически лежат резервные копии. Если ничего не настраивать специально, облако складывает копии рядом с данными: снапшот диска остаётся в той же зоне, автоматические копии управляемой базы — в том же регионе, а бакет Object Storage считается глобальным ресурсом, но глобальным внутри региона. Галочка резервного копирования включена с первого дня проекта, и вопрос кажется закрытым вплоть до момента аварии. Кроме того, снапшот диска представляет собой crash-consistent копию, выглядящую так, будто у машины выдернули питание: PostgreSQL переживёт это за счёт WAL, но только если весь журнал лежит на том же диске и успел сброситься, иначе после подъёма можно получить битые данные и узнать об этом лишь при проверке. Забрать данные наружу тоже непросто: образ или снимок диска штатно не скачивается, и путь один — создать вспомогательную ВМ, подключить к ней диск из снапшота, конвертировать qemu-img в qcow2, загрузить файл в бакет и уже оттуда скачать.

Время восстановления на практике оказывается заметно больше обещанного «поднимем за час». Тест на базе, похожей на настоящую — PostgreSQL 15 на локальной машине с SSD, таблица заказов на 10 млн строк объёмом 2,5 ГБ с двумя индексами и текстовым payload, — показал, что pg_dump -Fc занимает 43 секунды и даёт файл на 453 МБ, а pg_restore -j1 длится 85 секунд, из которых 40 уходит на загрузку данных и 44 на построение индексов. Восстановление заняло вдвое больше времени, чем создание копии, и половину этого времени съели индексы, от которых в дампе остаётся лишь одна DDL-строка. При этом параллельный режим pg_restore -j4 на трёх ядрах дал те же 86 секунд, то есть рассчитывать на кратное ускорение за счёт распараллеливания не приходится.

Для российского рынка октябрьская серия аварий стала наглядным уроком о границах применимости облачных схем отказоустойчивости. Годами клиентам советовали держать реплику в соседней зоне и бэкап в том же облаке, и против отказа отдельного железа такая конфигурация действительно работает. Однако отказ целого региона в эту модель не входит, и многие команды осознали это только тогда, когда привычные runbook'и начали с первого пункта «создать машину» упираться в перегруженную поддержку. Отрасль столкнулась с необходимостью пересмотреть подход: хранить копии за пределами региона и желательно за пределами облака, а также заранее прописывать сценарии на случай недоступности control plane. Программа CloudBro с приоритетным приёмом клиентов у Selectel, VK Cloud и К2Cloud отчасти смягчила ситуацию, но она появилась уже после того, как проблема проявилась в полный рост.

В первые часы простоя имеет смысл начинать не с восстановления, а с наблюдения: проверить на странице статуса, какие зоны и сервисы затронуты, и написать в поддержку с описанием недоступных данных и вопросами о сроках. Пока ответа нет, ничего не удалять и не перезаписывать, поскольку файл, который не открывается, ещё не потерян. Далее стоит зафиксировать список остановившихся процессов — приём заказов, клиентскую базу, отправку документов, выставление счетов — и первыми поднимать то, от чего зависят выручка и обязательства перед клиентами, предупредив аудиторию на сайте и в соцсетях без обещания конкретных дат. Отдельного внимания заслуживает реклама: показы в Яндекс Директе во время сбоя продолжались, кампании остановить было невозможно, деньги списывались за клики и конверсии, поэтому после восстановления статистику и списания нужно сверять и при расхождениях обращаться в поддержку. Главный открытый вопрос на будущее — станут ли межрегиональные и мультиоблачные схемы резервирования нормой, а не исключением, и как быстро провайдеры предложат инструменты, позволяющие пережить потерю региона без потери данных.