Сколько стоит держать копию бизнеса в другой стране

MAATRIX

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

Из чего складывается цена «копии в другой стране»

Прежде чем считать, стоит развести три принципиально разных статьи расходов — их часто смешивают в одну неопределённую сумму «дорого, наверное», хотя природа у них разная:

1. Технический костяк — сам резервный сервер в альтернативной локации: тариф, режим готовности (холодный/тёплый/горячий), стоимость хранения бэкапов.
2. Синхронизация данных между юрисдикциями — трафик и задержка при передаче данных между основной локацией и резервной, которые почти всегда обходятся дороже, чем синхронизация внутри одной страны или одного дата-центра.
3. Нетехнические издержки — всё, что нужно, чтобы копия могла не просто хранить данные, а реально вести бизнес во второй юрисдикции: от организационного оформления присутствия до банковских и платёжных вопросов. Это отдельная большая тема, которая выходит далеко за рамки хостинга, и ниже она разобрана только описательно — без юридических деталей конкретных стран.

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

Резервный сервер как технический костяк: во что упирается цена локации

Базовая механика здесь та же, что и у любого резервного сервера: чем быстрее должно произойти переключение, тем больше приходится платить за постоянно работающую (а не просто хранящуюся) инфраструктуру. Три степени готовности — холодный резерв (только бэкапы плюс возможность быстро развернуть сервер), тёплый резерв (сервер работает постоянно, данные подтягиваются с задержкой) и горячий резерв (полная синхронная копия, готовая принять нагрузку без простоя) — подробно разобраны в статье про горячий или холодный режим резервного сервера, а методика сравнения их цены с ценой простоя — в статье «резервный сервер: сколько стоит спокойствие». Здесь эта логика не повторяется целиком, а дополняется тем, что специфично именно для копии в ДРУГОЙ СТРАНЕ, а не просто в другом дата-центре той же локации.

Первое отличие — сама локация сервера выбирается не только по цене и производительности, а по тому, в какую регуляторную зону вы хотите вывести данные и часть инфраструктуры. Тарифы на аналогичную по характеристикам машину физически отличаются между локациями (RU/US/UK и так далее) — это не искусственная наценка, а следствие разной стоимости электричества, аренды стойки и рынка труда в конкретной стране; уточняйте актуальные тарифы в каталоге под нужную локацию, здесь принципиально важен сам факт, что цена не универсальна для всех регионов.

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

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

Синхронизация данных между юрисдикциями: почему трафик здесь дороже

Второй компонент цены — не сам сервер, а канал между основной и резервной локацией, по которому данные реплицируются или синхронизируются. Здесь работает общий принцип тарификации трафика: межрегиональный и межконтинентальный трафик почти всегда обходится дороже внутрирегионального — подробный разбор моделей тарификации (включённый пакет, оплата за объём, фиксированная полоса) есть в статье «цена одного гигабайта трафика: разбор». Применительно к межстрановой копии это означает: если провайдер закладывает трафик оптом в тариф VPS (типичная модель классического хостинга), синхронизация обходится дёшево или бесплатно в рамках пакета; если провайдер считает исходящий трафик отдельно (характерно для гиперскейлеров), трафик между странами — самая частая статья неожиданного перерасхода, потому что межрегиональные направления там нередко тарифицируются по повышенной ставке.

Второй фактор — задержка (latency) между локациями напрямую ограничивает, какой режим синхронизации вообще технически доступен. Синхронная репликация требует низкой и стабильной задержки — на трансконтинентальном канале с задержкой в десятки, а иногда и сотню с лишним миллисекунд она либо технически неприменима, либо заметно замедляет каждую запись в основной базе. На практике для межстрановой копии асинхронная репликация (с отставанием в секунды-минуты) — не компромисс от бедности, а разумный технический выбор, который прямо ограничивает достижимый RPO. Общие ориентиры по задержке между регионами — в статье «задержка между локациями: таблица ориентиров»; точная цифра для вашей пары локаций зависит от маршрута провайдера, и её стоит измерить, а не брать из таблицы буквально.

Практическая методика оценки этой статьи расходов:

1. Определите реальный объём данных, который нужно синхронизировать — не весь трафик проекта, а именно дельту изменений (записи в БД, изменённые файлы) за единицу времени. Для большинства проектов это на порядки меньше, чем весь входящий трафик пользователей.
2. Умножьте на частоту синхронизации, которую вы выбрали (непрерывная репликация, раз в несколько минут, раз в сутки) — это определяет, укладываетесь ли вы во включённый пакет или уходите в оплату за объём.
3. Уточните у конкретного провайдера, тарифицируется ли трафик между вашими двумя локациями как «межрегиональный» — у одних это повышенная ставка, у других (в том числе внутри одной сети провайдера, если он присутствует в обеих странах) трафик между собственными локациями может идти по внутренней, более дешёвой ставке.

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

Нетехнические издержки: юридическое присутствие во второй юрисдикции

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

Две вещи здесь важны для расчёта, даже без знания конкретики:

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

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

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

Методика: вероятность потери основной локации и цена такого простоя

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

• Отказ инфраструктуры дата-центра — самый предсказуемый сценарий, по нему часто есть собственная история инцидентов или как минимум статистика провайдера, на которую можно опереться.
• Регуляторное действие в отношении сервиса или отрасли (блокировка, ограничение, требование к локализации данных) — вероятность сложнее оценить точно, но можно ориентироваться на опыт похожих компаний в вашей отрасли и динамику за последние годы, а не гадать на пустом месте.
• Геополитическая нестабильность (ограничения на трансграничные платежи и переводы, санкционные риски, разрыв инфраструктурных связей между странами) — самый трудный для количественной оценки сценарий; здесь честнее заложить экспертную оценку сценария «вероятно / маловероятно / почти невероятно в горизонте планирования», чем изображать точность там, где её нет.

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

ожидаемые потери в месяц = (вероятность сценария в месяц) × (среднее время/тяжесть прерывания бизнеса без копии) × (цена единицы простоя)

«Цена единицы простоя» здесь считается так же, как и в общем случае — прямая упущенная выручка, штрафы по SLA перед вашими клиентами, стоимость команды при инциденте, поправочный коэффициент на репутационный ущерб. Но применительно к межстрановому сценарию к ней стоит добавить ещё один пункт, специфичный именно для этой темы: время до полной операционной готовности без заранее подготовленной копии — это не время разворачивания сервера (часы), а время получения организационного присутствия во второй стране с нуля, если оно не было заложено заранее. Именно этот срок — недели или месяцы, а не часы — и есть главный аргумент в пользу того, чтобы хотя бы минимальную подготовку (выбранная локация, черновой план, готовый к развёртыванию бэкап) сделать заранее, даже если полноценную копию разворачивать рано.

Как свести всё в одно решение

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

На практике удобно думать не в терминах «да/нет», а в терминах трёх уровней готовности, которые можно наращивать постепенно:

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

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