99,9% vs 99,99% vs 99,999% доступности:
что эти числа означают на самом деле
Проценты доступности SLA — одни из наиболее стабильно неправильно читаемых чисел в облачных закупках. Разрыв между 99,9% и 99,999% кажется маленьким — 0,099 процентного пункта. Но в переводе на допустимое время простоя в год разница составляет 8 часов 40 минут против 5 минут. Выбор неправильного уровня SLA для системы, генерирующей выручку, — решение, которое рано или поздно станет очень заметным.
Числа в переводе
99,9% доступности допускают 8 часов 45 минут простоя в год — около 43 минут в месяц. Это одно расширенное окно обслуживания в квартал или три-четыре коротких инцидента в год. Для внутренних инструментов и сред разработки это, как правило, приемлемо.
99,99% доступности допускают 52 минуты 34 секунды в год — около 4 минут 22 секунд в месяц. Это базовый уровень для производственных систем, генерирующих выручку. Его достижение требует избыточности N+1 на всех компонентах, автоматического переключения при сбое без ручных шагов и отсутствия единых точек отказа. Это достижимо без героизма — стандартная цель архитектуры для любой правильно спроектированной облачной инфраструктуры.
99,999% допускают 5 минут 15 секунд в год — 26 секунд в месяц. Этот уровень требует резервирования 2N по питанию и охлаждению, активно-активной мультизонной архитектуры, практики развёртывания без простоя для каждого изменения ПО и зрелого реагирования на инциденты (среднее время восстановления в секундах, а не минутах). Это дорого строить и эксплуатировать, и подходит только для систем уровня 1.
Допустимое время простоя в год
- • 99,9% — 8 часов 45 минут
- • 99,99% — 52 минуты 34 секунды
- • 99,999% — 5 минут 15 секунд
Типичные варианты применения
- • 99,9% — Внутренние инструменты, dev/staging-среды
- • 99,99% — Производственные веб-приложения, клиентские API
- • 99,999% — Обработка платежей, банковские ядровые системы
Как выбрать правильный уровень для системы
Рассчитайте стоимость одного часа простоя рассматриваемой системы. Включите: потерянную выручку, стоимость поддержки (тикеты и звонки резко растут при сбоях), штрафы SLA перед вашими клиентами и репутационные издержки. Сравните это число с ежемесячной разницей стоимости между уровнями SLA. Если один час простоя стоит $10 000, а уровень 99,99% дороже 99,9% на $200/мес — ответ очевиден.
Условия кредитов: читайте мелкий шрифт
Процентные показатели SLA — лишь часть оценки. Условия кредитов важны не меньше, чем заголовочный процент. Провайдер с SLA 99,99%, предлагающий 10% от ежемесячного счёта как кредит при несоблюдении, обеспечивает значимую финансовую защиту только если 10% кредита значимо компенсируют ваши потери от простоя.
Что часто исключают документы SLA
-
Запланированные окна обслуживания — Многие провайдеры исключают плановое обслуживание из расчётов SLA. Провайдер с ежемесячными 4-часовыми окнами обслуживания фактически обеспечивает меньшую доступность, чем подразумевает число SLA.
-
Оговорки о форс-мажоре — Широкие оговорки о форс-мажоре могут исключать предсказуемые события (перебои в электросети, сбои интернет-обменников). Провайдер с хорошей резервируемостью не должен ссылаться на форс-мажор при предсказуемых сбоях.
-
Сбои вышестоящего интернета — Если сбой вызван вышестоящим интернет-провайдером, а не инфраструктурой облачного провайдера, многие SLA не применяются. Это обоснованно, если провайдер имеет многопутевое подключение.
-
Процедура подачи заявки на кредит — Некоторые провайдеры требуют подачи заявки в течение определённого периода (например, 30 дней) для получения кредитов. Кредиты, требующие ручного оформления, на практике редко получают.
Подход Hyper App
Hyper App предлагает SLA 99,999% на производственной инфраструктуре — 5 минут 15 секунд допустимого простоя в год. Кредиты автоматически применяются к следующему счёту при обнаружении нарушения SLA — подавать заявку не нужно. Плановое обслуживание объявляется за 72 часа и исключается из расчётов SLA только если клиент заранее подтвердил окно обслуживания. Неподтверждённое обслуживание, вызвавшее простой, засчитывается в SLA. Эта политика отражает, как выглядит настоящее сервисное обязательство: операционная команда несёт нагрузку по планированию обслуживания с учётом подтверждения клиента, а не наоборот.