Amvera за сутки подняла новый регион после отказа Yandex Cloud

Что произошло, почему это важно и что взять в работу.

Кейс доказывает: независимые от облака бэкапы и быстрый перезапуск региона — не паранойя, а условие выполнения SLA для любого SaaS/PaaS.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Четыре утра, и российского региона больше нет

Кирилл Косолапов проснулся в 4:00 11 октября и увидел, что основного российского региона Amvera не существует. Не «деградация», не «частичная недоступность», не «повышенный процент ошибок». Площадка, на которой жила основная часть клиентских проектов, выведена из строя целиком. В поддержку уже шли обращения, а личный кабинет не открывался, то есть объяснить клиентам хоть что-то было негде.

Amvera делает PaaS: человек привязывает репозиторий и получает работающий сайт, бота или сервис без возни с сервером. Раз платформа снимает с клиента настройку инфраструктуры, она же берёт на себя бэкапы и безотказность. Когда ЦОД теряет условное облако, это беда клиента. Когда ЦОД теряет PaaS, это беда PaaS. Владельцу бизнеса в этот момент всё равно, кто виноват: у него не работает запись, не принимаются заказы, не идут платежи.

Дальше была не теория, а сутки в авральном режиме. Разбор полезен не сочувствием к команде, а тем, что он показывает: где именно проходит граница между «у нас всё забэкаплено» и «мы реально можем пережить потерю региона».

Хроника: что происходило по дням и часам

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

Обратите внимание на 9 октября. За два дня до катастрофы клиентов уже просили переехать. Часть, судя по всему, не отреагировала: письмо в ящике не выглядит как авария. Это типичная проблема аварийных коммуникаций в SMB. Пока ничего не болит, письмо от подрядчика читают в лучшем случае по диагонали.

Что было до: «паранойя», которая сработала

За несколько месяцев до инцидента Косолапов начал поднимать на планерках неудобную тему: что будет, если мы потеряем регион целиком. Не на пару часов, как иногда бывает у любого облака, а полностью. Коллеги поначалу возражали: мы и так делаем больше, чем принято на рынке.

Формально возражение было честным. Бэкапы в Amvera жили в два уровня. Полный системный бэкап всех дисков с репликацией в трёх экземплярах. Плюс пользовательский уровень: атомарные бэкапы постоянного хранилища и кластеров PostgreSQL, которыми клиенты управляли сами.

Слабое место пряталось в одном слове: «внутри». Все эти копии лежали в том же Yandex Cloud, разложенные по разным зонам доступности и S3. Схема выглядит надёжной ровно до момента, когда перестаёт существовать всё облако сразу. И тут начинается второе ограничение, которое редко всплывает в разговорах про бэкапы: для российского региона копии нельзя хранить в зарубежном ЦОДе. Требования локализации данных для многих клиентов не пожелание, а условие работы. То есть «вынесите бэкапы в другой регион» здесь не работает: зарубежный ЦОД сам превращается в нарушение.

Решение получилось некрасивым и дорогим. Репликация собственной СУБД в несколько независимых ЦОДов плюс готовый механизм быстрого переключения мастер-реплики. И дополнительные бэкапы всех дисков в независимый от Яндекса ЦОД, но физически в России. В этих бэкапах лежали данные тысяч приложений, так что удовольствие не из дешёвых. Часть задуманного сделать не успели.

11 октября эта паранойя нас спасла.

Вот здесь и находится главный смысл истории. Не в героической ночи и не в скорости команды. В том, что за два дня до аварии бэкапы уже физически лежали на чужой площадке. Иначе спасать было бы нечего.

Бэкап внутри того же облака не считается бэкапом

Самая недооценённая деталь во всей хронологии: в уцелевших зонах Yandex Cloud восстановиться из копий было нельзя. Провайдер ограничил квоты.

Восстановиться из бэкапов в Яндексе в их уцелевших зонах будет невозможно – Яндекс ограничит квоты, чтобы пользователи не положили им оставшуюся инфраструктуру.

Логика провайдера понятна и, если честно, рациональна. Если сотни клиентов одновременно начнут разворачивать копии в последней живой зоне, они положат и её. Квота тут не злой умысел, а предохранитель. Но для вас как для клиента вывод один: в момент крупной аварии вы конкурируете за ресурсы с остальными пострадавшими. И проигрываете, если ваш план восстановления целиком зависит от инфраструктуры того же поставщика.

Отсюда практическое правило, которое стоит держать в голове каждому, кто арендует облако, а не строит своё. Бэкап, лежащий в том же аккаунте, у того же провайдера, в том же регионе, защищает от случайного удаления файла, кривого релиза и человеческой ошибки. От потери региона он не защищает никак. Это разные риски, и лечатся они разными деньгами. Проверять нужно второй, потому что первый и так обычно закрыт.

Полдня вместо недели: как это вообще возможно

Новый регион Москва_1 запустили к 21:30 того же дня. По плану на ввод в эксплуатацию отводилась неделя.

Изначально мы рассчитывали, что ввод региона в эксплуатацию займёт неделю, а не половину дня.

Полдня вместо недели объясняются не только скоростью людей. Задолго до аварии была подготовлена почва: репликация СУБД в независимых ЦОДах, готовый механизм переключения мастер-реплики, дополнительные копии дисков. Команда не изобретала восстановление с нуля, а собирала регион из заранее заготовленных деталей. Разница между «у нас есть план» и «у нас есть план, и половина железа уже стоит» измеряется днями простоя.

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

Итоги к ночи 12 октября: более 99% запущенных приложений восстановлено. PostgreSQL на быстрых дисках восстановлен полностью на 99,7%. На медленных дисках полностью восстановлено 95%, ещё 4% частично. По оставшимся кластерам либо были атомарные пользовательские бэкапы, либо восстановление делали руками по запросу через поддержку.

Считать эти проценты идеальными не стоит. Хвост в десятые доли процента для конкретного бизнеса означает не статистику, а простой. Просто у платформы, которая обещала взять инфраструктуру на себя, был выбор: признать потерю или вытащить почти всё. Выбрали второе.

Чем заплатили: переезд клиентов и смена доменов

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

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

С 15 октября платформа принимает заявки на возмещение по SLA. Автор разбора честно предупреждает: компенсации обычно небольшие и привязаны к фактическим тратам на платформе. Это не покрытие упущенной выручки и не оплата репутационных потерь. Заявку можно подать в свободной форме в чате личного кабинета.

Что взять в работу: шесть вопросов своему подрядчику

Если ваш продукт живёт на чужой платформе, эта история даёт конкретный список проверок. Не абстрактных «а вдруг что», а вполне проверяемых пунктов.

• Где физически лежат бэкапы. Тот же аккаунт, тот же регион, тот же провайдер? Тогда от потери региона вы не защищены вообще.
• Сколько стоит восстановление. Бэкап без замеренного времени развёртывания это файл, а не план. Спросите, за какой срок поднимут ваш проект.
• Что с локализацией. Требования к хранению данных в России могут запрещать зарубежную копию. Проверьте, как подрядчик развязывает этот узел, а не только наличие галочки в договоре.
• Как устроена аварийная связь. Если личный кабинет лежит, куда вам писать? У Amvera остались чат сообщества и почта, потому что кабинет восстановили только к полудню.
• Что меняется в конфигурации при переезде. Домены, DNS, привязка адресов. Проверьте заранее, что у вас не захардкожены адреса, которые после восстановления станут другими.
• Размер компенсации по SLA. Сравните её со стоимостью дня простоя вашего бизнеса. Обычно цифры несопоставимы, и это повод держать собственный план на случай отказа платформы.

Отдельно про рассылку 9 октября. Клиентов предупредили за двое суток, а эффект был близок к нулю. Если вы получаете от подрядчика письмо «рекомендуем переехать», не откладывайте в папку «потом». Через двое суток может быть поздно, а массовый переезд в момент аварии добьёт то, что ещё работает.

Вердикт

Это не история про удачу и не история про героическую ночь. Это история про то, что подготовка к худшему сценарию оказалась дешевле, чем его последствия.

Независимые от облака бэкапы и отработанный перезапуск региона выглядят как избыточная трата ровно до первого серьёзного сбоя. Потом они выглядят как единственное, что вообще имело значение. Для владельца SaaS или PaaS это условие выполнения SLA, а не гигиена на будущее. Обещать клиенту доступность сервиса и держать единственную копию данных на той же площадке, где живёт сервис, это обещание без обеспечения.

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

Если ваш подрядчик сегодня не может внятно ответить, где лежат копии ваших данных и за сколько часов он поднимет регион, считайте, что ответа нет. Пока всё работает, это никого не беспокоит.