Миф: 99,9% аптайма — это почти всегда

MAATRIX

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

Откуда берётся ощущение «почти идеально»

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

Ошибка в том, что доступность считается не в процентах пространства, а в процентах времени, а время — штука с очень большим абсолютным объёмом. Год — это 8760 часов. Даже сотая доля процента от такого числа — не пренебрежимо малая величина, а несколько часов реального простоя. Проценты, близкие к 100, обманчивы именно потому, что маленькая на вид разница умножается на огромную базу.

Точная арифметика: что означает 99,9% в часах и минутах

Возьмём год без високосных нюансов — 365 дней, то есть 8760 часов. Допустимый простой при уровне доступности X% считается по формуле:

допустимый простой (часы) = 8760 × (1 − X/100)

Для 99,9% (0,1% недоступности, или 0,001 в долях):

8760 × 0,001 = 8,76 часа ≈ 8 часов 45-46 минут в год

Это не абстрактная погрешность — это почти рабочий день полной недоступности сервиса, разрешённый контрактом. В пересчёте на месяц (условно 30 дней, 720 часов) картина следующая:

720 × 0,001 = 0,72 часа ≈ 43 минуты в месяц

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

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

Таблица «девяток»: каждая дополнительная девятка — на порядок дороже

Разница между уровнями доступности выглядит малозаметной в процентах, но становится наглядной, если пересчитать её в часы и минуты допустимого простоя. Вот точный пересчёт для распространённых уровней SLA (год — 365 дней/8760 часов, месяц — условно 30 дней/720 часов):

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

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

Почему простой редко «размазан» — чаще это один крупный инцидент

Ключевая ошибка в восприятии 99,9% — считать, что эти 8 часов 45 минут в год равномерно распределены микросекундными заминками, незаметными пользователю. На практике простой почти никогда не выглядит так. Гораздо типичнее сценарий, когда весь годовой лимит (или большая его часть) сгорает за одну аварию: отказал диск и восстановление из бэкапа заняло полдня, датацентр потерял электропитание на несколько часов, произошла ошибка при обновлении и сервис не поднимался, пока инженер не разобрался вручную ночью.

Разница принципиальна для бизнеса. 8 часов 45 минут, распределённые по 500 миллисекунд в течение года, — это то, чего пользователь физически не замечает: TCP-соединение переустановится, запрос повторится, никто не напишет в поддержку. А 8 часов недоступности одним куском — это полный рабочий день, в течение которого магазин не принимает заказы, SaaS-сервис недоступен для всех клиентов одновременно, а телефон поддержки разрывается от звонков. Именно поэтому «в среднем 99,9% за год» — плохой ориентир для планирования: важно не среднее, а распределение простоя во времени и максимальная длина одного инцидента, которую способна выдержать конкретно ваша инфраструктура и ваш бизнес.

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

SLA провайдера — юридическое обязательство, а не гарантия отсутствия сбоев

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

Ключевая деталь, которую часто упускают: компенсация за нарушение SLA почти всегда скромная и рассчитывается не от вашего реального ущерба, а от стоимости самой услуги. Типичная формула — частичный возврат абонентской платы за период, в котором зафиксировано нарушение, иногда с прогрессивной шкалой (чем больше простой сверх нормы, тем больше процент возврата). Условно: сервер стоит несколько тысяч рублей в месяц, и в худшем случае вы получите обратно часть этой суммы. Но если за время простоя магазин не принял заказы на сотни тысяч рублей, а SaaS потерял клиентов из-за срыва их собственных процессов — этот реальный ущерб компенсацией провайдера не покрывается вообще, потому что она физически привязана к цене аренды, а не к последствиям для вашего бизнеса.

Отсюда практический вывод: SLA — полезный ориентир при выборе провайдера и инструмент дисциплины (провайдер, который рискует компенсацией, мотивирован держать инфраструктуру в порядке), но не основание перестать думать о собственной отказоустойчивости. Бизнес несёт полные реальные потери от простоя независимо от того, что написано в договоре с хостером — SLA защищает провайдера юридически (устанавливая предел его ответственности), а не ваш бизнес финансово. Точный расчёт того, во что обходится час или минута недоступности именно вашему проекту, помогает понять, оправдан ли переход на более высокий (и более дорогой) уровень резервирования, или заявленных 99,9% с обычным мониторингом действительно достаточно.

Как выбрать реальный уровень доступности под свою задачу

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

• Личный блог, тестовый стенд, внутренний инструмент без клиентов снаружи. 99% или даже отсутствие формального SLA — рабочий вариант. Простой на несколько часов раз в год неприятен, но не критичен финансово.
• Небольшой интернет-магазин, лендинг с рекламным трафиком, корпоративный сайт. 99,9% — разумный базовый уровень. Важнее не сам SLA, а собственный мониторинг (алерт в течение минуты, а не обнаружение проблемы через несколько часов) и регулярно проверяемые бэкапы, чтобы сократить длину именно единичного инцидента.
• Сервис с прямой зависимостью выручки от доступности каждую минуту (платежи, критичный SaaS, высоконагруженный e-commerce в пиковые часы). Здесь имеет смысл считать экономику резервирования до 99,95-99,99%: резервный сервер, распределение нагрузки, автоматическое переключение при отказе основного узла.
• В любом случае — не полагаться только на цифру SLA от провайдера. Собственный внешний мониторинг с независимой точки проверки (не на том же сервере, где крутится сайт) — единственный способ узнать о простое раньше, чем о нём напишут в комментариях под постом в соцсетях. Как настроить такую систему пошагово — в статье про настройку Uptime Kuma для сайта и сервера.

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

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