SLA 99,9% означает, что за выбранный расчётный период сервис может быть недоступен 0,1% времени и формально остаться в пределах обещания. Для 30 дней это 43 минуты 12 секунд. Однако сама цифра ещё не отвечает, какие сбои считаются простоем, откуда производится измерение и что получит клиент при нарушении.
Практический вывод: сравнивать нужно не только процент SLA, но и полный документ с методом расчёта, исключениями и компенсацией. Публичные 99,9% с понятными условиями полезнее рекламных 99,99%, которые ни к чему не обязывают.
Сколько простоя допускают разные проценты
Расчёт строится по формуле допустимый простой = длительность периода × (1 − доступность). Значения ниже предполагают 30-дневный месяц и 365-дневный год. Реальный договор может использовать календарный месяц, квартал или собственное окно.
| Доступность | Простой за 30 дней | Простой за год |
|---|---|---|
| 99% | 7 ч 12 мин | 3 дня 15 ч 36 мин |
| 99,5% | 3 ч 36 мин | 1 день 19 ч 48 мин |
| 99,9% | 43 мин 12 с | 8 ч 45 мин 36 с |
| 99,95% | 21 мин 36 с | 4 ч 22 мин 48 с |
| 99,99% | 4 мин 19 с | 52 мин 34 с |
Переход от 99,9% к 99,99% уменьшает допустимый простой в десять раз. Но это не означает автоматического десятикратного роста фактической надёжности: процент описывает целевой уровень и последствия отклонения в рамках конкретных правил.
SLA, SLO и фактический аптайм — не одно и то же
SLI — измеряемый показатель уровня сервиса: например, доля успешных запросов или доступность по времени. SLO — целевое значение этого показателя. SLA — соглашение с пользователем, в котором обычно описаны обязательства и последствия их нарушения.
Удобная проверка: если показатель не выполнен, что именно происходит дальше? Если документ не предусматривает последствия, перед вами может быть техническая цель или маркетинговое заявление, но не полноценное соглашение об уровне сервиса.
Фактический аптайм — историческое наблюдение. Он может быть выше или ниже SLA в отдельном месяце. Один хороший период не отменяет условия договора, а высокий SLA не заменяет историю инцидентов.
| Понятие | На какой вопрос отвечает | Где искать |
|---|---|---|
| SLI | что и как измеряют | методика мониторинга |
| SLO | к какому уровню стремятся | техническая документация |
| SLA | что обещано клиенту и с какими последствиями | договор или публичная оферта |
| аптайм | что наблюдалось фактически | независимый мониторинг и статус-страница |
Семь условий, которые важнее красивого процента
1. Расчётный период
99,9% за месяц и 99,9% за год допускают одинаковую долю, но по-разному распределяют риск. При годовом окне один многочасовой инцидент может ещё не нарушить цель, хотя конкретный месяц для клиента был провальным. Для операционной оценки удобнее видеть месячные значения и долгую историю.
2. Объект гарантии
Документ должен объяснять, что считается доступным: гипервизор, сеть дата-центра, виртуальная машина, панель управления или отдельный API. Работа панели не доказывает доступность VPS, а доступность узла не гарантирует успешность приложения пользователя.
3. Точка измерения
Измерение внутри сети провайдера и проверка с внешних точек дают разные результаты. Сбой маршрута между клиентом и площадкой может быть виден пользователю, но не внутреннему мониторингу. Сильная методика описывает точки наблюдения, интервалы и порог фиксации сбоя.
4. Определение недоступности
Считается ли единичная потеря пакета? Сколько неудачных проверок подряд образуют инцидент? Учитывается ли частичная деградация? Для API полезнее доля успешных запросов, а для одиночного VPS часто применяют доступность по времени. Google SRE отдельно отмечает, что для распределённых сервисов доля успешных операций может быть информативнее простого времени «включено/выключено».
5. Исключения
Плановые работы, атаки, проблемы внешних операторов, действия клиента и форс-мажор часто исключаются. Это может быть разумно, но длинный список превращает высокий процент в слабое обязательство. Проверяйте также требования к уведомлению о работах и максимально допустимую длительность обслуживания.
6. Компенсация
Обычно компенсация выдаётся сервисным кредитом, а не возвратом денег. Важно узнать размер, верхний предел и срок действия кредита. Компенсация части месячной платы не возмещает убытки от остановки бизнеса, поэтому критичному проекту всё равно нужна собственная отказоустойчивая архитектура.
7. Процедура обращения
Некоторые SLA требуют открыть заявку в короткий срок и приложить журналы. Автоматическая компенсация встречается реже. Если процедура слишком сложная или срок пропущен, формально подтверждённый сбой может не привести к выплате.
Пример: нарушены ли 99,9%
Представим один непрерывный сбой продолжительностью 45 минут в 30-дневном месяце. Бюджет простоя для 99,9% равен 43 минутам 12 секундам, поэтому математически цель не выполнена примерно на 1 минуту 48 секунд.
Но юридический результат зависит от условий:
- входил ли затронутый компонент в SLA;
- не относился ли инцидент к исключениям;
- совпадает ли длительность по системе провайдера и внешнему мониторингу;
- подал ли клиент заявку вовремя;
- предусмотрен ли кредит именно для такого отклонения.
Поэтому HostMetrics не превращает найденный процент в безусловное обещание. Мы фиксируем источник, дату, числовое значение и наличие публичного документа, а историю подтверждённых инцидентов показываем отдельно.
Какой SLA нужен проекту
Для тестовой среды последствия часа простоя могут быть минимальны. Для магазина, платёжного сервиса или корпоративной системы даже 99,9% одного узла может быть недостаточно. Требуемый уровень начинается не с количества девяток, а с ответа на вопрос: сколько минут простоя выдерживает бизнес и сколько стоит этот простой.
Если допустимое время восстановления меньше гарантии одного VPS, проблему нельзя решить только выбором более красивого SLA. Понадобятся резервные копии, мониторинг, автоматический перезапуск, несколько узлов или площадок, проверенная процедура восстановления и независимые зависимости.
Это связано с понятием error budget — допустимым бюджетом ошибок. Цель 99,9% означает бюджет 0,1%. Его можно измерять по времени или по доле неуспешных запросов и использовать для решений: продолжать изменения или сначала повышать надёжность.
Чек-лист перед покупкой VPS
Процент в договоре не говорит, как быстро сервер справляется с нагрузкой. В сравнении тестов VPS Beget, JustHost, Selectel и Timeweb можно отдельно посмотреть результаты процессора и диска, их разброс и параметры проверенных машин. Эти измерения не заменяют SLA и не доказывают годовой аптайм.
- Найдите полный документ SLA, а не только процент в тарифе.
- Проверьте расчётный период и формулу доступности.
- Уточните компоненты и локации, на которые действует гарантия.
- Прочитайте определения простоя и частичной деградации.
- Оцените исключения и плановые работы.
- Найдите таблицу компенсаций и максимальный размер кредита.
- Проверьте срок и способ подачи требования.
- Сопоставьте обещание с публичной статус-страницей и историей инцидентов.
- Организуйте собственный внешний мониторинг после запуска.
Частые вопросы
99,9% — это хороший SLA для VPS?
Для некритичного проекта он может быть достаточным. Для бизнеса важнее допустимый ущерб, архитектура приложения и конкретные условия документа. Один процент без контекста не даёт ответа.
Плановые работы входят в простой?
Зависит от договора. Часто заранее объявленные работы исключаются полностью или частично. Нужно читать определение исключений, а не предполагать.
Компенсацию выплатят автоматически?
Не всегда. Во многих соглашениях клиент должен подать заявку в установленный срок. Порядок обращения и подтверждения нужно сохранить заранее.
SLA гарантирует сохранность данных?
Нет. Доступность и долговечность данных — разные показатели. Даже высокий SLA не отменяет резервные копии и проверку восстановления.
Чем независимый мониторинг лучше статус-страницы?
Он показывает доступность с точки зрения внешнего наблюдателя и сохраняет собственную историю. Статус-страница остаётся важным официальным источником причин и подтверждения инцидента; полезно использовать оба канала.