Резервный сервер: сколько стоит спокойствие в месяц

MAATRIX

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

Три степени готовности — и почему они стоят по-разному

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

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

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

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

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

Формула: во что вам обходится час простоя

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

Грубая методика расчёта складывается из нескольких составляющих:

1. Прямая упущенная выручка. Средний доход в час (или за пиковый час, если нагрузка неравномерна), который сервис не получит, будучи недоступным. Для интернет-магазина это выручка за час деления на количество часов работы; для SaaS — сумма подписок, пропорциональная простою, плюс возможные компенсации по SLA.
2. Штрафы по контракту. Если у вас есть SLA перед клиентами или партнёрами, в договоре обычно прописана конкретная неустойка за превышение допустимого времени простоя — это не оценка, а точная цифра, которую нужно просто достать из договора.
3. Стоимость команды при инциденте. Час работы дежурного администратора или всей команды разработки, которая переключается на тушение пожара вместо плановых задач, тоже деньги — обычно недооценённые, потому что не выставляются отдельным счётом.
4. Репутационный ущерб. Самая сложная для количественной оценки часть — потерянные из-за инцидента клиенты, негативные отзывы, недоверие к сервису. Точную цифру тут не получить, но для критичных сервисов (платежи, медицина, финтех) стоит закладывать её как множитель к прямой выручке, а не игнорировать.

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

Как сопоставить цену резерва с ценой простоя

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

Ожидаемые потери считаются как произведение трёх величин:

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

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

Практическое правило, которое из этого следует:

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

Таблица компромисса: цена в месяц против времени восстановления

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

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

Практический пример расчёта (с условными цифрами)

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

Допустим, магазин зарабатывает в среднем условную сумму N рублей в час в рабочее время. По истории за последний год было два серьёзных инцидента, суммарно приведших к простою около 5 часов при отсутствии резерва (только бэкапы и ручное восстановление). Грубая оценка вероятности — примерно один инцидент в полгода, со средним простоем 2–3 часа без резерва.

Тогда ожидаемые потери в месяц:

(1 инцидент / 6 месяцев) × 2.5 часа × N руб/час ≈ 0.42 × N руб в месяц

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

• если 0.42 × N заметно больше M — тёплый резерв окупает себя с запасом, даже с учётом того, что расчёт грубый;
• если 0.42 × N близко к M или меньше — прямой финансовой выгоды от тёплого резерва нет, и решение переходит в плоскость «готовы ли вы вообще терпеть часы простоя раз в полгода» — вопрос уже не про деньги, а про риск-аппетит.

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

Что дополнительно снижает реальную цену спокойствия

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

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

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

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