Каждая девятка дороже предыдущей: экономика уровней доступности

MAATRIX

Вы посчитали, во что обходится второй узел, и согласились, что переход от 99% к 99,9% доступности того стоит. А теперь на столе лежит требование «пять девяток» — то ли от инвестора, то ли от отдела продаж, который прочитал эту цифру в чужом SLA и решил, что она универсальна. Прежде чем подписываться под ней, стоит понять один принцип, который редко проговаривают вслух: каждая следующая девятка в проценте доступности стоит не «немного больше» предыдущей, а на порядок больше. И если этот скачок не посчитать заранее, бюджет на инфраструктуру рискует обогнать бюджет на сам продукт.

Что скрывается за процентом доступности

Проценты вроде 99,9% и 99,99% выглядят почти одинаково на глаз, но за сотыми долями скрывается совсем разный запас времени на простой. Если перевести проценты в абсолютные часы и минуты в год, разница становится наглядной:

Обратите внимание на шаг: от 99% к 99,9% допустимый простой сокращается в десять раз — с почти четырёх суток до девяти часов. От 99,9% к 99,99% — снова в десять раз, с девяти часов до 52 минут. От 99,99% к 99,999% — опять в десять раз, до пяти минут в год. Каждая девятка не добавляет немного надёжности, она на порядок ужесточает допуск на ошибку. А ужесточение допуска на порядок обычно требует не «немного лучше делать то же самое», а качественно другого набора инструментов и процессов.

Именно поэтому нельзя просто взять смету перехода от 99% к 99,9% (второй узел, резервирование, базовый мониторинг) и умножить её на два, ожидая получить 99,99%. Так экономика уровней доступности не работает.

Почему рост доступности не линеен

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

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

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

Что покупает каждый шаг по лестнице

Полезно разложить, какой именно набор мер покупает каждый переход — не в рублях (это индивидуально для каждого проекта), а по категориям усилий.

От 99% к 99,9%. Это уровень «один сервер плюс дисциплина»: мониторинг с алертами, автоматические перезапуски сервисов, регулярные бэкапы, базовый план восстановления. Дальше добавляется резервирование — второй узел, который может принять нагрузку при отказе первого. Здесь решения ещё локальные: один провайдер, одна площадка, ручное или полуавтоматическое переключение.

От 99,9% к 99,99%. Здесь разовое резервирование внутри одной площадки перестаёт быть достаточным, потому что account сбоя самой площадки (авария в дата-центре, проблема на уровне провайдера, сетевой инцидент у аплинка) остаётся неприкрытым. Появляется геораспределённое резервирование — узлы в разных дата-центрах или даже локациях, автоматический failover вместо ручного переключения, более сложный мониторинг с проверкой не только «жив ли процесс», но и «отвечает ли сервис корректно с точки зрения пользователя». Разница с предыдущим уровнем не в «ещё одном сервере», а в целой прослойке автоматизации и мониторинга, которую нужно построить, протестировать и поддерживать.

От 99,99% к 99,999%. Здесь ручной или полуавтоматический failover уже недостаточно быстр — секунды простоя на переключение начинают съедать весь годовой бюджет допустимого времени простоя. Нужна active-active архитектура в нескольких регионах одновременно, регулярное тестирование отказов на живой системе (то, что называют chaos engineering), выделенная команда дежурных инженеров с чёткими регламентами, договорённости с несколькими провайдерами связи и электропитания. Это уже не техническая задача одного администратора, а организационная — со своим штатом, регламентами и культурой эксплуатации.

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

Где прячутся непропорциональные расходы

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

• Сложность мониторинга. На 99,9% достаточно знать, что сервер отвечает на пинг. На 99,99% нужно отслеживать корректность ответов, задержки, состояние очередей, здоровье каждого узла кластера — и настроить алерты так, чтобы они не заваливали дежурного ложными срабатываниями.
• Гео-маршрутизация трафика. Автоматическое переключение между площадками в разных регионах требует гео-DNS или аналогичного механизма маршрутизации, а это отдельный слой настройки, тестирования и последующей поддержки.
• Согласованность данных между площадками. Как только у вас две активные площадки вместо одной с холодным резервом, встаёт вопрос репликации данных в реальном времени и что делать при расхождении — это архитектурная задача, а не просто «включить синхронизацию».
• Тестирование отказов. Резервный контур, который никогда не тестировали, с высокой вероятностью не сработает в момент реального отказа. Регулярные учения — это время инженеров, которое нужно закладывать заранее, а не разово.
• Человеческий фактор и дежурства. Чем жёстче требование ко времени восстановления, тем ближе к круглосуточному дежурству нужно держать компетентных людей — это уже не разовая покупка, а постоянная статья расходов.
• Координация между командами. На высоких уровнях доступности отказоустойчивость перестаёт быть заботой одного администратора и становится процессом, в который вовлечены разработка, эксплуатация и иногда служба поддержки.

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

Как честно посчитать нужный вам уровень доступности

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

1. Оцените стоимость часа простоя. Прямые потери от недоступности сервиса (упущенные продажи, невыполненные транзакции), договорные штрафы по SLA, если они есть, и косвенные издержки — отток пользователей, репутационный урон. Даже грубая оценка лучше, чем её отсутствие.
2. Оцените вероятную частоту и длительность инцидентов на вашем текущем уровне. Не по паспортным цифрам провайдера, а по вашей реальной истории — сколько раз за год у вас были простои и сколько они длились.
3. Сопоставьте цену часа простоя с ценой перехода на следующую ступень. Если цена часа простоя для вашего бизнеса измеряется тысячами рублей, а не миллионами, инвестиция в геораспределённую отказоустойчивость может окупаться годами — или не окупаться вовсе.
4. Учтите не только среднее, но и пиковые сценарии. Для интернет-магазина простой в обычный день и простой в день распродажи — экономически разные события; иногда для этого достаточно временно поднять мощности, а не держать постоянную избыточную инфраструктуру.
5. Проверьте, не решает ли задачу более дешёвый уровень. Часто бизнес на самом деле не нуждается в автоматическом failover за секунды — ему достаточно, чтобы восстановление укладывалось в 15–30 минут при ручном вмешательстве дежурного. Это совсем другой, гораздо более скромный бюджет.

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

Типичные ошибки при выборе целевого уровня

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

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

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

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

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

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

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