SLA в договоре: как читать проценты и компенсации

MAATRIX

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

Как на самом деле измеряется простой

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

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

Отсюда вытекает практический вывод, а не теоретический: вести собственный независимый мониторинг обязательно, если вы всерьёз рассчитываете на SLA как на инструмент, а не просто украшение договора. Свой мониторинг — это не про недоверие к провайдеру, а про то, что у вас должны быть свои данные с точными таймстампами на случай спора. Настроить его можно за вечер — например, разобраться, как установить и настроить Uptime Kuma на VPS, и завести отдельные проверки из нескольких точек, а не полагаться на дашборд провайдера.

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

• Полная недоступность — сервер не отвечает на ping/HTTP вообще, сервис не открывается ни для кого. Это самый строгий и самый частый критерий в SLA бюджетных и средних тарифов.
• Деградация производительности — сервер отвечает, но с задержками в разы выше нормы, часть запросов падает по таймауту, база данных подвисает под нагрузкой. Формально сайт «работает», но пользоваться им нельзя.

Большинство типовых SLA хостинга считают простоем только первый случай. Ситуация «сайт открывается 40 секунд вместо 2» или «каждый пятый запрос падает с ошибкой 504» под определение простоя обычно не попадает вовсе, если в договоре явно не прописан порог по времени отклика или проценту ошибок. Если для вашего бизнеса деградация так же болезненна, как полный отказ (высоконагруженный интернет-магазин, платёжный шлюз, API для клиентов), проверьте, есть ли в SLA отдельный порог по латентности или error rate — если нет, для вас реальная защита SLA слабее, чем кажется на первый взгляд.

Что заранее исключено из расчёта — и почему это законно

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

Плановые технические работы. Если провайдер уведомил вас заранее (обычно за 24–72 часа, конкретный срок смотрите в самом договоре) о плановом окне обслуживания — обновление гипервизора, миграция на новое оборудование, замена сетевого оборудования — и недоступность произошла в это окно, это не простой в смысле SLA. Здесь важны две детали: способ уведомления (email на указанный в договоре адрес обычно достаточен — проверка спам-папки на вашей стороне) и длительность объявленного окна. Если провайдер заявил окно в 2 часа, а работы заняли 6, превышение сверх заявленного окна обычно уже считается простоем — но это стоит явно найти в тексте, а не предполагать по умолчанию.

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

Есть и менее очевидные исключения, которые встречаются реже, но тоже стоит поискать по тексту: проблемы на стороне вашего собственного оборудования или ПО (неправильная конфигурация, которую вы сами внесли), нарушение вами условий использования (DDoS-атака, спровоцированная вашим же трафиком), действия третьих сторон вне периметра провайдера (upstream-провайдер интернета, DNS-регистратор, CDN, если это отдельные поставщики).

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

Как именно выплачивается компенсация

Здесь чаще всего расходятся ожидания и реальность. Клиент, читая слово «компенсация», представляет деньги на счёт или возврат части оплаты живыми средствами. На практике подавляющее большинство SLA в хостинге и облаке предусматривают компенсацию кредитом на будущие услуги того же провайдера — service credit, а не денежный возврат (refund).

Это принципиально меняет ценность компенсации в зависимости от вашей ситуации:

Второй практический нюанс — компенсация почти никогда не начисляется автоматически. В подавляющем большинстве договоров клиент обязан сам обратиться с заявлением о нарушении SLA в определённый срок после инцидента — часто это 7–30 дней, конкретное число ищите в тексте раздела. Если вы просто пережили простой и не написали официальный тикет/заявление с указанием времени начала и конца недоступности, обосновывающими данными (те самые логи вашего независимого мониторинга) — с высокой вероятностью компенсация просто не будет начислена, потому что провайдер не обязан отслеживать нарушения за вас и напоминать вам о праве на компенсацию.

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

Почему компенсация почти всегда меньше реального ущерба

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

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

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

На что ещё смотреть в тексте SLA

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

• Период расчёта. SLA считается за календарный месяц или за скользящие 30 дней? От этого зависит, как быстро «сгорает» право на компенсацию за конкретный инцидент.
• Потолок компенсации. Почти всегда есть верхняя граница — например, не более 100% от месячной стоимости услуги, независимо от того, сколько реально длился простой. Даже месяц полного простоя не даст компенсацию больше одного месячного счёта.
• Что именно покрывает гарантия. Отдельный SLA на сеть (доступность порта), отдельный на аппаратную часть (железо VPS/сервера), иногда отдельный на конкретный managed-сервис (база данных, панель управления). Гарантия 99,9% на «сеть» не означает автоматически такую же гарантию на приложение внутри вашего сервера — это вообще не входит в зону ответственности хостера.
• Порядок разрешения споров. Что происходит, если провайдер отклонил ваше заявление о компенсации — есть ли эскалация, апелляция, независимая экспертиза, или решение провайдера окончательное.
• Право провайдера менять SLA. Некоторые договоры позволяют провайдеру изменить условия SLA с уведомлением за определённый срок — стоит понимать, что гарантия, под которую вы подписывались, не обязательно неизменна на весь срок сотрудничества.

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

Короткий чек-лист перед подписанием

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

1. Чей мониторинг является источником истины для расчёта простоя — провайдера или можно предоставить собственные данные как доказательство?
2. Считается ли деградация производительности простоем, или только полная недоступность?
3. Какой список исключений (плановые работы, форс-мажор, действия третьих сторон) — и какое уведомление о плановых работах считается достаточным?
4. Компенсация — деньгами или кредитом на будущие услуги? Переносится ли кредит при смене тарифа?
5. Нужно ли самостоятельно подавать заявление, и в какой срок после инцидента?
6. Какой потолок компенсации за расчётный период?
7. К какой именно части инфраструктуры относится гарантия — сеть, железо, конкретный сервис?

Эти семь вопросов занимают десять минут внимательного чтения, но именно они определяют, получите ли вы реальную защиту или просто красивую цифру в маркетинговом разделе сайта.

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