Почему 99,9% аптайма означает 8 часов простоя в год: расшифровываем мелкий шрифт SLA

SLA на аптайм (SLA, Service Level Agreement — пункт договора, определяющий гарантированный провайдером уровень доступности) в 99,9% допускает 8,76 часа простоя в год, а вовсе не ровные 8 часов, которые постоянно фигурируют в блогах о хостинге. В этой статье разберём, как считается эта цифра, какие именно пункты SLA аптайма определяют, сколько реального простоя провайдера засчитывается против процента доступности, и как сравнивать уровни SLA перед подписанием договора на хостинг. Технические термины — SLA, MTTR, RTO, RPO, HTTP — расшифровываются при первом упоминании ниже. К концу статьи читатель сможет за минуту рассчитать реальный допустимый простой за любым заявленным процентом аптайма.

Что на самом деле гарантирует SLA аптайма

SLA аптайма гарантирует, что сервер будет доступен и работоспособен в течение заявленного процента от установленного расчётного периода — и по определению допускает его недоступность в оставшееся время. SLA измеряет процент времени, а не обещает непрерывную доступность, поэтому недоступный процент — это не запас на погрешность, а прямо заявленная квота, которую провайдер может использовать по любой причине: аппаратный сбой, неудачное обновление ПО или плановые технические работы списываются с одной и той же квоты. SLA аптайма 99,9% с помесячным измерением допускает 43,8 минуты простоя; провайдер, недоступный 40 минут в течение одного расчётного месяца, не нарушает договор — при условии, что остальное время месяца сервис был полностью доступен.

Распространённая ошибка практиков — считать, что процент аптайма описывает работу приложения, а не доступность сервера. Большинство SLA аптайма измеряют доступность только на сетевом уровне — отвечает ли сервер на запрос подключения, — а не то, корректно ли работают для посетителей сайт, база данных или почтовый сервис на этом сервере. Это принципиальное различие: сервер может проходить каждую проверку аптайма, при этом отдавая реальным посетителям ошибки HTTP (Hypertext Transfer Protocol — протокол, по которому браузеры запрашивают страницы с сервера) 500, поскольку мониторинговая проверка и реальный пользовательский запрос тестируют совершенно разные вещи.

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

Аптайм 99,9% допускает 8,76 часа простоя в год. Формула расчёта фиксированная: количество минут в расчётном периоде умножается на (1 − % аптайма), применительно к 525 600 минутам стандартного невисокосного года.

• 525 600 минут/год × (1 − 0,999) = 525,6 минуты = 8,76 часа (8 ч 45,6 мин)

• 43 833,6 минуты/месяц × (1 − 0,999) = 43,8 минуты/месяц

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

Где в мелком шрифте SLA аптайма прячется реальный риск

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

Исключения плановых технических работ — провайдеры полностью исключают из расчёта простоя заранее анонсированные технические окна, обычно предупреждая за 24–48 часов, а некоторые договоры вообще не ограничивают их продолжительность.

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

Пороги минимальной длительности — некоторые договоры засчитывают простой только сверх установленной длительности, например 5 минут, поэтому десять отдельных 4-минутных отключений за день могут официально зафиксироваться как 100% аптайма.

Определение частичного отказа — многие провайдеры измеряют аптайм строго на сетевом уровне, поэтому сервер, отвечающий на ICMP-пинг (Internet Control Message Protocol — базовый сетевой запрос для проверки доступности хоста), считается «работающим», даже если база данных или веб-приложение на нём полностью отказали.

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

Советы, которые пишут везде (и почему они неполные)

Большинство гайдов по хостингу советуют вести независимый мониторинг аптайма именно для того, чтобы подать претензию при нарушении SLA. Совет не ошибочный, но он оптимизирует не тот результат. На типичных для отрасли цифрах — нарушение 99,9% на тарифе shared-хостинга за £15/мес обычно даёт компенсацию 10% — итоговые £1,50 слишком малы, чтобы покрыть потерянные заказы во время самого простоя или оправдать административные усилия на подачу претензии. Более полезная практика — проектировать инфраструктуру вокруг MTTR провайдера (Mean Time to Recovery — среднее время восстановления сервиса после начала инцидента), а не вокруг процента аптайма, поскольку именно MTTR определяет длительность конкретного инцидента, тогда как процент аптайма лишь ограничивает суммарный простой за месяц. Для небольшого бизнес-сайта провайдер с SLA аптайма 99,5% и документированным MTTR до 20 минут для критичных инцидентов зачастую окажется удобнее, чем провайдер с рекламой 99,99% без публикуемых данных о времени восстановления, — потому что несколько коротких, быстро устранённых сбоев мешают большинству проектов меньше, чем один длинный неустранённый. Запрашивайте у провайдера историю MTTR напрямую, а не ориентируйтесь на заявленный процент аптайма как на решающий фактор.

Как провайдеры считают — и иногда искажают — цифры аптайма

Собственная статистика аптайма провайдера может показывать 100%, пока клиенты в конкретном регионе реально сталкиваются с простоем. Внутренний мониторинг проверяет сервер изнутри сети самого провайдера, а не с реальной точки клиента: зонд мониторинга, опрашивающий сервер каждые 1–5 минут из того же дата-центра, никогда не проходит по внешнему маршруту пиринга, по которому идёт запрос реального посетителя, — поэтому региональный сбой BGP (Border Gateway Protocol — протокол маршрутизации, определяющий, как трафик передаётся между сетями в интернете) или авария пиринга у вышестоящего провайдера остаётся невидимой для панели мониторинга провайдера, хотя полностью затрагивает реальную аудиторию клиента.

Проверено на Ubuntu 24.04 LTS с curl 8.5.0:

bash

# Внешняя проверка мониторинга через curl, запущенная из точки

# вне сети провайдера, проверяющая доступность и HTTP-код

# ответа — а не только ICMP.

curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com

# Пример вывода:

# 200 0.312s   -> сервер реально работает исправно

# 000 30.001s  -> недоступен с этой точки, таймаут

Для любого клиентского сайта настройте независимый внешний мониторинг — сервисы вроде UptimeRobot, Pingdom или StatusCake — с проверкой HTTP-кода ответа, а не голого ICMP-пинга, и выставьте интервал проверки в 1 минуту вместо стандартных 5. Для подачи претензии по SLA провайдеры обычно требуют именно такие независимые доказательства, а не полагаются только на слова клиента.

Компенсация по SLA: почему выплаты редко покрывают реальные убытки

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

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

Четырёхчасовой простой в пик продаж может обойтись в куда более серьёзную сумму потерянных заказов, чем покрывает компенсация в £5. Для любой нагрузки, где простой напрямую бьёт по выручке, закладывайте отдельный бюджет на резервирование: настройте вторичного DNS-провайдера (Domain Name System — служба, преобразующая доменные имена в IP-адреса серверов), например Cloudflare или NS1, параллельно с основным, держите резервный сервер наготове для приёма трафика при отказе основного, либо подключите CDN (Content Delivery Network — распределённая сеть серверов, кэширующих контент ближе к посетителям) с функцией failover на источник. Не рассчитывайте, что компенсация по SLA покроет финансовые последствия простоя.

Сравнение уровней SLA: во что реально обходится каждый

Переход с SLA аптайма 99,9% на 99,99% сокращает допустимый простой примерно в десять раз — с 43,8 минуты до 4,38 минуты в месяц. Это сокращение обходится значительно дороже в реализации, поскольку устранение ещё одного порядка простоя требует резервных линий электропитания, резервных сетевых маршрутов и балансировки нагрузки либо географически распределённой инфраструктуры — затраты растут нелинейно по мере сужения допустимого окна отказа, что и объясняет, почему SLA на уровне 99,99% провайдеры сосредотачивают в тарифах enterprise-класса.

Для сайта на WordPress или небольшого интернет-магазина с посещаемостью до 10 000 визитов в месяц выбирайте SLA аптайма 99,9% на хорошо укомплектованном VPS с компетентной техподдержкой. Если на сайте идут транзакции в реальном времени, либо намечается конкретное событие вроде плановой распродажи, из-за которого каждая минута простоя обойдётся ощутимо дороже, — на этот период стоит перейти на уровень 99,99%.

Что проверить перед подписанием договора на хостинг

Расчётный период измерения, определение отказа и порядок подачи претензии определяют реальную ценность SLA аптайма гораздо сильнее, чем заголовочный процент. Два договора с одинаковой рекламой в 99,9% могут кардинально различаться по применимости на практике: один измеряется помесячно, с определением простоя по всему стеку приложения и неограниченным сроком подачи претензий, другой — ежегодно, с определением простоя только на сетевом уровне и 15-дневным сроком подачи претензии, который большинство клиентов пропускает. Перед подписанием запросите письменные ответы на следующие вопросы:

1. Договор измеряет аптайм помесячно или ежегодно?

2. Определение отказа охватывает только сетевую доступность или весь стек приложения — веб-сервер, базу данных, почту, DNS?

3. Ограничивает ли договор плановые технические работы конкретным числом часов в месяц, или оставляет их без ограничения?

4. Требует ли договор минимальной длительности простоя, прежде чем он засчитывается в SLA?

5. Провайдер полагается только на внутренний мониторинг, или публикует независимо проверяемую страницу статуса?

6. Требует ли получение компенсации проактивной подачи заявки, и в какой срок?

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

8. Публикует ли провайдер историческую статистику аптайма, или предоставляет её только по запросу?

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

Как IWIHOST подходит к прозрачности SLA аптайма

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

Часто задаваемые вопросы

Считается ли аптайм 99,9% хорошим показателем для веб-хостинга?

99,9% — это надёжный, отраслевой стандартный уровень SLA аптайма для shared-хостинга и стандартных тарифов VPS, что соответствует 43,8 минуты допустимого простоя в месяц. Это не самый высокий доступный уровень — выше находятся 99,95% и 99,99%, — но он подходит большинству небольших бизнес-сайтов и личных проектов, не зависящих от обработки транзакций в реальном времени.

Засчитываются ли плановые технические работы против SLA аптайма провайдера?

Большинство провайдеров полностью исключают плановые технические работы из расчёта простоя при условии заблаговременного предупреждения, обычно за 24–48 часов. Действует ли на это исключение месячный лимit, зависит от конкретного договора, поэтому этот пункт стоит уточнять письменно перед подписанием.

Как проверить реальный аптайм провайдера, а не доверять его маркетинговым заявлениям?

Независимые инструменты мониторинга — UptimeRobot, Pingdom или StatusCake, настроенные на проверку HTTP-кода ответа, а не голого ICMP-пинга, — дают взгляд снаружи, отражающий реальный опыт посетителей. Интервал проверки в 1 минуту вместо стандартных 5 позволяет засечь короткие сбои, которые собственный внутренний мониторинг провайдера может исключить по порогу минимальной длительности.

В чём разница между SLA аптайма и гарантией аварийного восстановления?

SLA аптайма покрывает рутинную доступность и компенсации за стандартные простои, измеряемые как процент времени за помесячный или годовой период. Гарантии аварийного восстановления, напротив, покрывают восстановление данных после катастрофических событий, и провайдеры измеряют их через RTO (Recovery Time Objective — целевое время восстановления сервиса) и RPO (Recovery Point Objective — максимально допустимый объём потери данных, измеряемый во времени), а не через процент аптайма.

Могу ли я получить возврат денег при нарушении провайдером SLA аптайма?

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

Стоит ли переплачивать за аптайм 99,99%?

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

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