План выхода из облака: как не стать заложником одного провайдера

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

Что показал октябрь 2026 года

С 8 по 11 октября 2026 года дата-центры Яндекса пережили серию аварий. В ночь с 7 на 8 октября пожар остановил площадку в Сасово, и вместе с ней стала недоступна зона Yandex Cloud ru-central1-b. 9 октября в дата-центре в Калуге несколько модулей полностью вышли из строя. В ночь на 11 октября остановился дата-центр во Владимире. Многие инженеры провели эти дни без сна, спасая инфраструктуру своих проектов. Мы искренне сочувствуем коллегам. Мы пишем эту статью, чтобы извлечь инженерные уроки, и никого не критикуем.

Для клиентов облака это обернулось несколькими днями частичной деградации: консоль работала, часть сервисов тоже, но многое было недоступно или работало с ограничениями, и предсказать сроки восстановления было нельзя. По сводке на Хабре на 11 октября картина была такой:

• выдача новых квот приостановлена: заменить потерянные ресурсы новыми было нельзя;
• Object Storage доступен на чтение, с записью возможны проблемы;
• большинство отказоустойчивых кластеров баз данных переключились, но часть работала только на чтение или была недоступна;
• клиентам рекомендовали переносить ресурсы на другие площадки, а с Selectel, K2Cloud и VK Cloud договорились об ускоренном размещении пострадавших;
• 10 октября в пользовательское соглашение добавили пункт о форс-мажоре.

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

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

Та же логика относится к любой площадке: VK Cloud, Selectel, Cloud.ru и вашей собственной серверной. Провайдер может стать недоступен из-за пожара, наводнения, отключения электричества, блокировки аккаунта, банкротства или смены законодательства. Вопрос один: сможете ли вы уйти оттуда за понятное время.

План выхода, DR-план и vendor lock-in: в чём разница

Обычно про vendor lock-in вспоминают, когда уход от поставщика становится слишком дорогим или технически сложным. Привязка бывает технической (проприетарные сервисы и API), данными (их сложно или долго выгрузить) и договорной (предоплата, скидки за объём, обязательства по срокам).

План аварийного восстановления (DR-план) отвечает на вопрос «что делаем, если упал сервер, стойка или зона». Обычно он живёт внутри одного провайдера: переключились на другую зону, подняли реплику, восстановили из бэкапа. Как считать время восстановления, сколько стоит простой и чем холодный резерв отличается от горячего, мы подробно разбирали в статье про план аварийного восстановления.

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

Шаг 1. Инвентаризация: от чего вы на самом деле зависите

Начните с честного списка всего, что крутится у провайдера. Лучше идти прямо по функциям систем, потому что в ежемесячном счёте за облако не видно внутренних зависимостей. Для каждого сервиса ответьте на один вопрос: если завтра его нет, чем я его заменю?

Рядом с категорией поставьте уровень критичности системы. От него зависит, насколько подробным должен быть план:

• критичные (1С, CRM, боевые базы, сайт с заказами) - нужен проверенный путь выхода с замеренным временем;
• важные (внутренние сервисы, вики, тестовые среды) - достаточно описанного порядка восстановления;
• второстепенные - хватит строки «кто владелец, где данные, сколько стоит».

Отдельно выпишите скрытые зависимости. О них вспоминают последними:

• DNS. Если зона домена обслуживается тем же провайдером, переключить трафик на резервную площадку не получится: вы не попадёте в панель управления.
• Регистратор домена. Та же проблема, плюс риск потерять сам домен.
• Сертификаты, выпущенные через сервис провайдера.
• Офисные папки в облачном диске. Октябрь показал, что это одна из самых массовых зависимостей: люди приходят на работу, а рабочие файлы не открываются.
• Почта и документы. Если корпоративная почта и таблицы с паролями живут в той же экосистеме, во время аварии вы останетесь без инструкций и без связи.
• Мониторинг. Мониторинг внутри того же облака упадёт вместе с ним и ничего не сообщит.
• Секреты: ключи, токены и пароли в хранилище секретов провайдера.

Последняя строка таблицы - договор. Предоплаченный баланс, скидка за объём, обязательство тратить определённую сумму держат у провайдера не хуже проприетарного API. SLA тоже стоит перечитать: компенсация в нём обычно ограничена долей ежемесячного платежа, а форс-мажор её снимает. Октябрьская поправка к соглашению Yandex Cloud - хороший повод открыть свой договор с любым провайдером и посмотреть, что в нём написано про такие случаи. Простой бизнеса договор не покрывает.

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

Шаг 2. Бэкап, который переживёт провайдера

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

Управляемые базы данных делают резервные копии сами, и это удобно. Но копии хранятся внутри облака провайдера, и забрать их не всегда можно. В документации Yandex Managed Service for PostgreSQL прямо сказано, что выгрузить резервную копию локально средствами сервиса нельзя, для этого предлагают pg_dump. Автоматический бэкап спасёт от ошибки внутри базы. От потери площадки он не спасёт: он на ней и лежит.

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

Здесь работает старое правило резервного копирования 3-2-1 с облачной поправкой: три копии данных, два разных типа хранилища, одна копия вне площадки. В облачном мире «вне площадки» значит «вне провайдера». Расширенный вариант 3-2-1-1-0 добавляет копию, которую нельзя изменить или удалить (защита от шифровальщиков), и ноль ошибок при проверке восстановления. Подробнее про стратегии хранения - в статье про уровни резервного копирования.

Куда класть внешнюю копию:

• в S3-совместимое хранилище другого провайдера;
• на собственный сервер резервного копирования в офисе или в арендованной стойке;
• на ленту или съёмные диски, если объёмы большие, а допустимая потеря данных измеряется сутками.

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

Если база весит сотни гигабайт, обычный логический дамп не подойдёт - вы будете разворачивать его часами. В таких случаях лучше настроить физический бэкап с архивацией WAL-логов (через WAL-G или pgBackRest) или держать внешнюю реплику. Управляемая база такую реплику наружу может и не позволить. Это аргумент держать самую критичную базу на обычной виртуальной машине или своём сервере, где вы контролируете всё.

Объектное хранилище копируйте в другое хранилище через rclone, он работает с любым S3-совместимым API:

Образ виртуальной машины в формате конкретного облака - слабая страховка: его нужно экспортировать и конвертировать, а в аварию экспорт может не работать. Надёжнее уметь пересобрать машину с нуля (шаг 3) и отдельно бэкапить данные приложения.

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

Сколько займёт выгрузка данных

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

Ориентир при загрузке канала примерно на 80% (остальное съедают протоколы, повторные отправки и соседний трафик):

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

Шаг 3. Инфраструктура как код: чтобы поднять всё заново по описанию

Данные вы сохранили. Теперь их нужно куда-то восстановить: в сеть, с балансировщиком, правилами файрвола и нужными версиями ПО. Если всё это три года назад настраивали руками через веб-консоль три разных администратора, в день аварии придётся по чатам и памяти выяснять, кто и что там настраивал.

Инфраструктура как код (IaC) решает это: всё, что создано в облаке, описано текстом в репозитории.

• Terraform или OpenTofu описывают ресурсы: сети, виртуальные машины, балансировщики, бакеты. Для России есть нюанс: HashiCorp блокирует доступ к своему реестру с российских IP-адресов, поэтому провайдеры ставят через зеркало (у Yandex Cloud есть публичное зеркало реестра) или используют OpenTofu с его собственным реестром. Убедитесь, что установка не зависит от одного-единственного зеркала, иначе это та же зависимость от одного провайдера.
• Ansible и аналоги описывают, что происходит внутри машины: пакеты, конфиги, пользователи, службы.
• Helm-чарты и манифесты Kubernetes - для того, что живёт в контейнерах.

Код для Yandex Cloud не применится к VK Cloud или своему Proxmox одной командой: ресурсы у каждого провайдера описываются по-своему. Но переписать модули под другую площадку, имея перед глазами точное описание того, что было, несравнимо быстрее, чем восстанавливать инфраструктуру по памяти и скриншотам.

Чтобы IaC помогал именно при выходе:

1. Репозиторий хранится вне провайдера. Git-сервер в том же облаке - та же ловушка, что и бэкап в том же облаке.
2. State-файлы Terraform тоже копируются наружу. Без них теряется карта того, что было создано.
3. Секреты описаны и продублированы. Пароли в Git класть не надо. Нужна понятная схема: какие секреты есть, где их резервная копия (например, офлайн-хранилище паролей), у кого к ней доступ.
4. Логики в проприетарных сервисах - минимум. Если без serverless-функций провайдера не обойтись, держите их код и описание триггеров в том же репозитории с пометкой, чем их заменить.

Если у вас пять виртуальных машин, а не пятьсот

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

• инструкция по восстановлению каждой машины: какая ОС, какие пакеты, где лежат конфиги, в каком порядке поднимать;
• экспорт конфигураций (веб-сервер, база, файрвол, VPN) в репозиторий или хотя бы в архив вне провайдера, обновляемый при каждом изменении;
• пара скриптов, которые ставят нужное ПО на чистую машину.

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

Шаг 4. Куда выходить: резервная площадка

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

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

Во время крупной аварии клиенты пострадавшего провайдера ищут, куда переехать, одновременно. В октябре это было видно по фактам: выдача квот у Yandex Cloud была приостановлена, а партнёрам пришлось срочно договариваться об ускоренном размещении. Поэтому «решить заранее» значит:

• для облака: аккаунт создан, договор подписан, квоты на нужный объём согласованы, тестовая среда поднималась;
• для colocation или своей серверной: минимальный резервный контур уже стоит и настроен. Ждать поставку в разгар аварии - плохая идея.

Резервный контур на своём железе: из чего он состоит

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

Покупать новое железо под такой контур не обязательно. Большую часть времени эти серверы просто принимают бэкапы, а реальная нагрузка ложится на них только в момент аварии. Поэтому здесь хорошо подходит серверное оборудование б/у из крупных дата-центров: это экономия до 70% бюджета против новых серверов. Главный страх при покупке б/у - надёжность, поэтому диски в наших сборках ставим только новые, каждый сервер перед отгрузкой 72 часа работает под полной нагрузкой, а гарантия - до 5 лет с заменой на следующий рабочий день. Стоимость считаем под задачу: она зависит от объёма данных и числа виртуальных машин. Как сравнить экономику своего железа и облака на длинной дистанции - в материале свой сервер или облако.

Персональные данные при переезде

Если в системах есть персональные данные, к технической стороне переезда добавляется юридическая. Что проверить:

• новый провайдер обрабатывает данные по вашему поручению, а значит, нужен договор или условие договора с поручением обработки (ч. 3 ст. 6 152-ФЗ);
• площадка соответствует уровню защищённости, который требуется для ваших данных, и это подтверждено документами провайдера;
• место нахождения базы данных входит в сведения уведомления Роскомнадзора (п. 10.1 ч. 3 ст. 22 152-ФЗ). Если база переехала, сведения нужно обновить в срок, установленный ч. 7 той же статьи.

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

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

Шаг 5. Учения: план, который ни разу не проверяли, не работает

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

Частоту проверок привяжите к уровню критичности из шага 1:

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

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

Шаблон: план выхода на двух страницах

Регламент на 80 страниц не нужен. Нужен документ, который дежурный администратор откроет в три часа ночи и поймёт, что делать. Вот его структура:

1. Шапка: версия, дата последних учений, ответственный и заместитель.
2. Триггеры: когда запускаем план (например, зона или провайдер недоступны больше N часов, провайдер объявил, что восстановление займёт дни, юридические причины) и кто принимает решение. Телефоны - не из корпоративной почты.
3. Системы по приоритету: таблица «система - владелец - допустимое время простоя - допустимая потеря данных - где внешний бэкап - куда восстанавливаем».
4. Где что лежит: внешние бэкапы и доступ к ним, репозиторий и его зеркало, резервная копия секретов, доступы к DNS и регистратору, как переключить записи.
5. Порядок восстановления: по шагам для каждой системы или ссылка на инструкцию.
6. Коммуникации: кого уведомляем внутри компании и в каком порядке, шаблон сообщения для клиентов.
7. Возврат: при каких условиях возвращаемся к основному провайдеру и как синхронизируем данные обратно.

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

Когда план выхода избыточен

Не каждой компании нужен полный план с IaC и квартальными учениями. Он избыточен, если:

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

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

Если времени совсем нет: пять дел на эту неделю

Полный план выхода - работа на месяц-два. Вот что можно сделать за ближайшие дни и закрыть самые болезненные риски:

1. Выгрузите критичные базы наружу. Хотя бы pg_dump по расписанию в хранилище другого провайдера или на свой сервер.
2. Проверьте DNS и регистратора домена. Если они у того же провайдера, что и рабочие системы, перенесите их или хотя бы заведите вторичный DNS у другого.
3. Заведите локальную копию офисных папок. Минимальная файловая хранилка (NAS или простой сервер) с синхронизацией: если внешнее облако упало, люди переключаются на локальную папку, и работа не встаёт.
4. Скопируйте документацию, пароли и контакты туда, где они доступны без корпоративной почты и облака провайдера.
5. Попробуйте развернуть хотя бы один бэкап на тестовой виртуалке. Если не получится, вы узнаете об этом сейчас, у себя в офисе, без горящих сроков.

Частые вопросы

Что такое vendor lock-in простыми словами?

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

Можно ли считать резервом две зоны доступности одного провайдера?

От отказа одной зоны - да. От потери провайдера целиком, блокировки аккаунта или проблем с договором - нет. Октябрь 2026 года показал, что несколько зон могут пострадать почти одновременно.

Нужно ли малому бизнесу мультиоблако?

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

Сколько стоит план выхода?

Минимальный вариант (внешний бэкап, вторичный DNS, копия доступов) - это дни работы администратора и хранилище под копии. Полный вариант с резервной площадкой и учениями зависит от объёма систем: от одного-двух серверов под бэкапы и запасной гипервизор до второго контура в colocation.

Что делать с персональными данными при переезде?

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

Вместо вывода

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

Полезные материалы: объектное хранилище S3 · colocation: размещение своих серверов в дата-центре · как выбрать оборудование для резервного копирования в небольшом офисе · резервное копирование 1С · серверы для резервного копирования и архивного хранения