SLA на сеть: какие цифры хостера что-то значат, а какие написаны для красоты

MAATRIX

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

Что вообще означает процент в заголовке

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

Механика перевода процента в часы простая: берёте длину периода, умножаете на (100% минус обещанный процент). Например, если период — календарный месяц из примерно 30 дней (720 часов), а провайдер обещает доступность X%, то допустимый простой за месяц — это 720 часов, умноженные на (100−X)/100. Чем ближе X к 100, тем меньше допустимых часов простоя, и на верхних значениях (99,9% и выше) счёт идёт уже не на часы, а на минуты.

Здесь важна не сама цифра, а то, что происходит с ней на практике:

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

Разница на бумаге между 99,9% и 99,95% выглядит как незначительная десятая доля процента, но в пересчёте на допустимые часы простоя за год это уже разница в разы — конкретные цифры всегда смотрите в договоре провайдера, а не полагайтесь на общие ориентиры. Здесь мы сосредоточимся именно на сетевой части SLA — что в ней измеряется и на что реально можно опереться.

Доступность порта — не то же самое, что доступность сервиса

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

Сетевой SLA хостера типично покрывает то, что под его прямым контролем:

• физический порт коммутатора, к которому подключена ваша виртуалка или сервер;
• магистральные каналы (аплинки) дата-центра до точек обмена трафиком;
• маршрутизацию внутри собственной сети провайдера.

Он почти никогда не покрывает:

• вашу операционную систему, которая зависла или ушла в своп;
• ваше приложение, которое упало из-за утечки памяти или бага в коде;
• вашу базу данных, забившую диск логами;
• сторонние сервисы, от которых зависит ваш стек (DNS, CDN, платёжный шлюз, внешний API).

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

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

Отдельно стоит спросить у провайдера прямым текстом, письменно: что именно считается инцидентом для целей SLA — недоступность порта, недоступность IP по ping, потеря пакетов выше определённого процента? Расплывчатый ответ — сигнал, что при споре трактовка будет в пользу того, кто пишет решение.

Общий канал против выделенного — разная цена одного и того же процента

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

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

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

Компенсация: реальные деньги или символический жест

Здесь начинается самая практичная часть — то, что превращает SLA из красивого числа в реальный (или нереальный) инструмент.

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

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

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

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

Практический чек-лист, что спросить у провайдера или найти в договоре до того, как что-то случится:

1. В какой форме выплачивается компенсация — деньги, кредит на баланс, скидка на будущий период?
2. Есть ли срок действия у кредита/скидки?
3. Кто и в какой срок должен подать заявку на компенсацию?
4. Какие доказательства провайдер принимает — свой внутренний мониторинг, ваш внешний мониторинг, независимые сервисы вроде публичных чекеров доступности?
5. Есть ли верхний предел компенсации за период (часто — не более 100% стоимости услуги за месяц, независимо от того, насколько длительным был простой)?

Исключения: то, что SLA чаще всего не покрывает

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

• Плановые технические работы. Провайдер заранее уведомляет о работах (обычно по email или в личном кабинете, за какое-то время до начала) — и простой во время них не считается нарушением SLA, сколько бы он ни длился. Если уведомление о плановых работах приходит на почту, которую никто не читает, для вас это всё равно будет «неожиданной» аварией — а по SLA это не так.
• Форс-мажор. Стихийные бедствия, отключение электричества по вине сторонних энергокомпаний, действия государственных органов, массовые атаки на инфраструктуру вышестоящих провайдеров — весь этот блок обычно сформулирован широко и трактуется в пользу провайдера.
• DDoS-атаки. Многие SLA прямо исключают простой, вызванный DDoS-атакой, из зоны ответственности провайдера — даже если атака была направлена не на вас, а на соседа по инфраструктуре, и ваш трафик пострадал как побочный эффект.
• Проблемы на стороне апстрим-провайдеров. Если авария произошла не в сети самого хостера, а у оператора, через которого он покупает транзит трафика на определённом участке маршрута, ответственность может перекладываться дальше по цепочке — а для вас разницы никакой, сайт всё равно недоступен.
• Действия клиента. Неправильная настройка firewall, DDoS-атака, спровоцированная действиями клиента (например, рассылкой спама с его IP), превышение лимитов — всё это исключается по определению.
• Проблемы клиентского оборудования вне сети провайдера. Если проблема на маршруте между вашим офисом и дата-центром — это не входит в SLA хостера в принципе.

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

Маркетинговые формулировки без измеримого веса

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

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

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

Здесь стоит различать два документа: маркетинговую страницу тарифа, где такие формулировки нормальны (это реклама), и текст самого SLA или договора-оферты, где расплывчатая формулировка — уже тревожный звонок, потому что именно этот документ используется при споре. Если на странице тарифа написано «премиальная связность», а в договоре — конкретный процент и порядок компенсации, это нормально: маркетинг и юридический текст выполняют разные функции. Хуже, если конкретики нет нигде, включая договор, — тогда красивые слова на тарифной странице ничего не гарантируют.

Как читать сетевой SLA перед тем, как выбрать хостера

Собрав всё вместе, практический порядок действий выглядит так:

1. Найдите не маркетинговую страницу, а текст самого SLA или пункт договора-оферты, где сеть описана отдельно от остальных гарантий (питание, аппаратное обеспечение, поддержка).
2. Определите предмет обязательства — порт, IP-адрес, магистральный канал дата-центра. Если формулировка не отвечает на это прямо — задайте вопрос в поддержку письменно и сохраните ответ.
3. Проверьте формулу расчёта простоя: расчётный период, минимальный учитываемый инцидент, способ округления.
4. Оцените блок исключений — насколько часто перечисленные там сценарии (DDoS, форс-мажор, проблемы апстрима) реально случаются в вашей отрасли, а не на глаз.
5. Выясните форму и порядок получения компенсации: деньги или кредит, кто подаёт заявку, какие доказательства принимаются, есть ли срок давности.
6. Сравните эту конкретику, а не заголовочный процент, с альтернативными провайдерами.

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

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