Процент доступности — это только первая строка SLA, а понять, как читать SLA хостинг‑провайдера, можно лишь вместе с окном измерения, источником данных и исключениями. SLA хостинга и аптайм связывают метрику с конкретным сервисом, окном измерения, источником данных, исключениями и процедурой обращения. Термины и формулы у провайдеров разные, поэтому любой разбор привязан к конкретной датированной редакции договора.
Сколько простоя допускает SLA 99,9%?
SLA 99,9% допускает около 43 минут 12 секунд учитываемого простоя за 30 дней. За 365 дней это 8 часов 45 минут 36 секунд. Реальный предел зависит от окна измерения, округления и исключённых событий, поэтому процент пересчитывают по формуле из выбранного договора.
Уточнить, какой сервис и какая граница покрыты
Сначала нужно определить, что именно перестало работать: виртуальная машина, сеть, хранилище, панель управления и поддержка могут иметь разные гарантии. Доступность VM не значит доступность приложения с базой данных на другом ресурсе.
SLA должен задавать техническую границу сервиса и точку, из которой ведётся замер. Для VM это может быть соединение с гостевой ОС через сеть провайдера, для object storage — доступность операций чтения и записи через API, для поддержки — время до первого ответа по обращению заданной категории. Без такой точки стороны определят место отказа по‑разному.
Выбранный SLA хостинга и аптайм должен соответствовать тарифу, региону и зависимостям, поскольку редакция для выделенных серверов может не распространяться на VPS, а гарантия одного ЦОД может не покрывать межрегиональный канал.
Пересчитать процент в допустимый простой окна
Базовая формула выглядит так: uptime = (W — D) / W × 100%, где W обозначает учитываемое время окна, а D только тот простой, который договор признаёт нарушением. Для 30 дней W равен 43 200 минут. При 99,95% остаётся 21 минута 36 секунд, при 99,99% всего 4 минуты 19,2 секунды.
Календарный месяц, скользящие 30 дней и год дают разные результаты. Одни договоры вычитают согласованное обслуживание из знаменателя, другие относят его к исключениям. Округление каждой минуты тоже может изменить ступень компенсации.
Медиана против p95 в SLA — это про задержку и время ответа, а не про аптайм. Сервис может отвечать на каждый запрос и формально оставаться доступным, хотя часть операций длится десятки секунд. Поэтому доступность, задержку и ошибки проверяют по отдельным определениям.
Сравнить типичный случай и медленный хвост
Медиана делит отсортированную выборку пополам, а p95 показывает значение, не превышенное примерно в 95% наблюдений. Точный результат зависит от метода расчёта процентиля. p95 не равен максимуму, и самые медленные 5% могут быть заметно хуже.
Возьмём 20 замеров задержки: восемнадцать значений идут подряд от 80 до 97 мс с шагом в миллисекунду, последние два равны 900 и 1300 мс. Медиана равна 89,5 мс. По методу nearest rank p95 попадает на девятнадцатую позицию и составляет 900 мс. Центр распределения выглядит хорошо, а хвост уходит почти на секунду.
Почему медиана скрывает плохой p95?
Медиана делит выборку пополам, поэтому небольшая доля очень медленных операций её почти не сдвигает. p95 показывает границу, ниже которой укладываются 95% запросов, и попадает уже в начало хвоста. Значение p95 зависит от окна, источника данных и метода расчёта, так что сравнивать провайдеров можно только при одинаковых endpoint, нагрузке и правилах.
Провайдеры могут измерять серверное время, полный запрос у внешнего зонда или только успешные обращения, поэтому без единой методики ряды несопоставимы. Карточка метрики содержит endpoint, границы таймера, размер выборки, окно, источник и правило обработки ошибок.
Расчёт сервисной компенсации по задержке имеет смысл только тогда, когда SLA связывает порог p95 с нарушением и назначает способ выплаты. Сам график не создаёт права на компенсацию, так как договор должен определить метрику, размер компенсации и процедуру её получения.
Из чего складываются часы инцидента
Один инцидент даёт несколько временных отметок, и их лучше не путать. Обнаружение наступает в момент, когда выбранный источник зафиксировал отказ. Время первого ответа отмечает первое содержательное сообщение поддержки, а автоматическое уведомление о приёме обращения обычно за него не считается. Частичное восстановление возвращает сервису работоспособность не полностью, а полное определяется по критерию из договора.
У каждого таймера должна быть начальная отметка: сигнал мониторинга, создание тикета или назначение категории инженером. Разница в десять минут меняет результат, поэтому журнал хранит временные метки в одном часовом поясе и исходные уведомления.
Остановка таймера тоже требует правила. Если поддержка запросила лог и ждала клиента, SLA иногда исключает этот промежуток. Такой пункт входит в исключения в SLA провайдера и должен быть виден рядом с целевым временем. Срок первого ответа нельзя выдавать за срок восстановления, ведь сообщение «инцидент принят» не возвращает сервис в работу.
Найти условия, при которых нарушение не засчитывается
Исключения обычно делятся на четыре группы: плановое обслуживание, форс‑мажор, действия клиента и внешние зависимости. За названием группы должны стоять проверяемые условия. Для планового обслуживания это срок уведомления, максимальная длительность работ, затронутые сервисы и способ публикации сообщения.
Отдельная группа исключений касается границы ответственности. Ошибка firewall внутри VM отличается от недоступности виртуального коммутатора. DDoS‑защита, DNS стороннего регистратора и канал клиента могут находиться вне SLA. Для пользователя результат выглядит одинаково, поэтому источник измерения должен локализовать отказ.
SLA времени ответа поддержки часто зависит от категории инцидента, тарифа, канала и рабочих часов, а письмо на общий email может не запускать таймер аварийного портала. До инцидента стоит проверить допустимые каналы, обязательные поля обращения и срок подачи заявки на компенсацию.
Каждый вывод должен опираться на конкретный пункт актуальной редакции, поэтому рядом с ним ставьте ссылку на раздел. Соберите в рабочую папку датированную копию SLA, определения метрик и категорий, окно и источник измерения, исключения, порядок подачи заявки и таблицу service credits.
Посчитать service credit, потолок и область применения
Базу компенсации задаёт договор: это может быть месячная плата за затронутую VM, стоимость недоступного сервиса за период или, реже, весь счёт. Разница существенная. Если ресурс стоит 10 000 рублей, service credit в размере 10% даст 1000 рублей, даже когда общий счёт организации намного выше.
Таблица ниже показывает, как устроена шкала компенсаций. Числа в ней условные, у вашего провайдера ступени и проценты будут свои:
99,9% и выше — 0% credit от платы ресурса, SLA выполнен
99,0% ≤ аптайм < 99,9%, 10% credit, первая ступень
95,0% ≤ аптайм < 99,0%, 25% credit, вторая ступень
Ниже 95,0% — 50% credit, предел шкалы
Договор может ограничивать сумму всех сервисных компенсаций за месяц — например, половиной платы за затронутый ресурс. После расчёта остаётся проверить срок подачи заявки, формат доказательств и способ зачёта. Компенсация обычно уменьшает будущий счёт, а упущенную прибыль возмещают только при прямом условии договора.
Какие инциденты обычно не компенсируются?
Плановое обслуживание, заранее объявленное по правилам SLA.
Сбой в конфигурации клиента или неподдерживаемой внешней зависимости.
Инцидент без своевременной заявки и требуемых договором доказательств.
SLA должен называть источник, который подтверждает доступность инфраструктуры. Если клиентский мониторинг расходится с серверными логами, обращение должно содержать оба ряда и идентификатор ресурса.
Прогнать короткий и тяжёлый инцидент по тексту договора
Два учебных сценария используют 30-дневное окно, плату 10 000 рублей и шкалу выше. Условный SLA исключает только заранее объявленное обслуживание, а реальный договор может задавать другое окно, формулу, потолок и базу.
Сценарий A. VM была недоступна 70 минут, из них 10 минут пришлись на согласованное обслуживание. Учитываемый простой равен 60 минутам, аптайм составляет (43 200 — 60) / 43 200 × 100% = 99,8611%. Нарушение попадает в ступень 10%, поэтому возможная компенсация равна 1000 рублей.
Сценарий B. Сервис не работал восемь часов, а исключаемое обслуживание заняло 30 минут. Договор учитывает 450 минут, аптайм снижается до 98,9583%. Ступень 25% даёт 2500 рублей. Даже тяжёлый инцидент даёт только service credit, а бизнес‑убыток остаётся на вас.
Карточка обоих сценариев отмечает severity level, время обнаружения, первого ответа, частичного и полного восстановления. От точки отсчёта зависит результат: если таймер идёт от создания тикета, ответ через 22 минуты уже нарушает лимит в 15 минут. Спорные определения лучше запросить письменно до миграции.
Собрать единую карточку SLA для выбора хостинга
Сравнение начинается с названия сервиса и границы ответственности. Дальше идут окно измерения, допустимый простой, источник данных, процентиль задержки, категория инцидента, исключения, ступени компенсации, потолок и срок заявки. Каждой строке нужны дата и ссылка на редакцию.
Response and resolution time стоит смотреть только раздельно: первый показатель отсчитывает начало работы поддержки, второй её договорное завершение. Если поставщик публикует лишь response time, карточка не должна приписывать ему срок восстановления.
Собранную карточку остаётся сравнить с тем, что вы обещаете своим пользователям. Если ваш SLO 99,99%, а провайдер гарантирует 99,9%, разрыв составит примерно 39 минут за 30 дней. Эти минуты компенсация не вернёт, поэтому закрывать их придётся резервированием, мониторингом и планом восстановления.
Договор стоит ровно столько, сколько в нём можно проверить самостоятельно. Процент без окна измерения, источника данных и списка исключений не говорит ничего о том, чем закончится ваша заявка на компенсацию. Практический ответ на вопрос, как читать SLA хостинг‑провайдера, начинается с формулы простоя и заканчивается прогоном собственного сценария по тексту договора. Пока этого не сделано, вы не знаете предела ответственности поставщика.
