NineLabNineLab.ru
КейсыЦены
Контакты
24 августа 2026Евгений · Senior Systems Engineer

SLA 99.9% vs 99.99%: когда переплата за «девятки» не нужна


На презентации хостинга — 99.99% аптайма. В договоре с клиентом — штраф за каждый час простоя. Внутри компании — «если что, перезагрузим». Три разных уровня обещаний, и только один из них связан с реальными деньгами.

Главное. Каждая «девятка» в SLA — это не маркетинг, а бюджет: резервирование, мониторинг, дежурства, тесты. Для большинства сервисов достаточно честных 99.9% на критичном пути — если вы их измеряете, а не копируете со слайда вендора.

SLA и доступность: 99.9% vs 99.99% — простой в минутах и стоимость для бизнеса

Сначала цена часа простоя — потом число девяток в договоре

Таблица «девяток»: сколько это простоя

Ответ: разница между 99.9% и 99.99% — не «ещё 0.09%», а порядок по времени недоступности.

  • 99.9% — ~8 ч 45 мин в год, ~43 мин в месяц
  • 99.95% — ~4 ч 23 мин в год, ~22 мин в месяц
  • 99.99% — ~52 мин в год, ~4 мин в месяц
  • 99.999% — ~5 мин в год

Для CEO достаточно запомнить: 99.9% ≈ один рабочий день простоя в год, 99.99% ≈ один час. Переход между уровнями стоит не линейно, а кратно — см. SRE для бизнеса.

SLA, SLO и «галочка в панели хостинга»

Ответ: не путайте три вещи.

  • SLI — что меряем (доля успешных запросов, p95, «оплата прошла»).
  • SLO — цель для команды (99.9% успешных на checkout за месяц).
  • SLA — обещание клиенту + последствия (скидка, штраф, расторжение).

«Uptime 99.9%» у провайдера часто считается по ping главной страницы, а не по вашему пути денег. Хостинг может быть зелёным, пока корзина и оплата лежат.

Когда 99.9% — нормальная цель

Ответ: когда простой неприятен, но не разрушает бизнес за час и нет жёсткого штрафа в B2B-договоре.

  • Маркетинговый сайт без оплаты на том же домене
  • Внутренний портал, HR-формы, некритичные отчёты «к утру понедельника»
  • B2B-кабинет, где партнёры терпят короткий сбой, если нет SLA с неустойкой
  • Staging и песочницы для интеграций

Здесь разумно: мониторинг на 3–4 сигнала, бэкапы по схеме 3-2-1, runbook «кто поднимает и за сколько», без круглосуточного on-call.

Когда переплата за 99.99% оправдана

Ответ: когда стоимость минуты простоя выше стоимости инфраструктуры «лишней девятки».

  • Checkout, эквайринг, API заказов в пик (акция, отчётный период)
  • Договор с enterprise-клиентом: SLA + штрафы
  • Тендер, где «99.99%» — формальный фильтр (тогда нужен план, как это доказать)
  • Единая точка входа для сети дилеров / франчайзи без offline-обхода

Цена часа простоя — в статье про стоимость простоя. Если час = 100–200 тыс. ₽, одна сорванная акция перекрывает год «экономии» на мониторинге.

Что покупает каждая «девятка» (упрощённо)

Ответ: не «магия хостинга», а набор решений.

99.9%Один ЦОД или облако, алерты в рабочее время, ручной деплой с откатом, бэкапы с редким restore-тестом
99.95–99.99%Резерв БД, health-checks, автоматический failover или быстрый runbook, дежурный on-call, нагрузочный прогон перед пиком
99.999%Multi-AZ/регион, chaos-практики, SRE-процессы, error budget — уровень, который большинству МСБ не нужен на старте

Подготовка к пику — отдельная история: даже при 99.9% «в среднем» вы можете лечь в четверг акции. См. подготовку к HighLoad и чеклист пикового сезона.

Рамка для директора: пять вопросов

  1. Сколько стоит час простоя этого сервиса в ₽? (выручка + штрафы + репутация)
  2. Есть ли в договоре штраф за SLA? Если да — SLA должен быть измерим и подписан IT.
  3. Какой путь критичен? Одна цифра на весь «сайт» — ошибка; отдельно checkout, API, ЛК.
  4. Кто дежурит и за сколько поднимает? Без ответа 99.99% на бумаге = 99.5% в реальности.
  5. Когда последний раз проверяли восстановление? Бэкап и failover на словах не считаются.

Если на вопросы 1–2 ответ «не знаем / не критично» — не покупайте 99.99% у хостера. Сначала измерьте и зафиксируйте SLO 99.9% на одном сервисе.

Типичные ошибки

  • SLA из маркетинга в договор с клиентом без расчёта — IT подписывает невыполнимое.
  • Один SLA на всё — главная 99.99%, API 99.5%, все довольны средним.
  • Покупка multi-AZ до карты узких мест — дорого, пик всё равно упрётся в БД.
  • Нет error budget — либо вечный code freeze, либо вечные пожары без релизов.

Итог

99.9% vs 99.99% — не «хуже / лучше», а разный класс затрат. Для большинства B2B-кабинетов, порталов и витрин вне пика достаточно честных 99.9% на критичном пути плюс подготовка к всплескам. 99.99% имеет смысл, когда простой измерим в деньгах и зафиксирован в договоре.

Если нужно согласовать SLO под ваш контракт или проверить, выдержит ли система акцию — начните с аудита производительности или нагрузочного тестирования: за 1–2 недели зафиксируем цель, метрики и приоритеты без лишних «девяток».

Вопросы про SLA и доступность

Около 8 час 45 минут в год (≈43 минуты в месяц). 99.99% — около 52 минут в год (≈4 минуты в месяц). Разница не в «чуть лучше», а в другом классе инфраструктуры и процессов.

SLO — внутренняя цель надёжности (например, 99.9% успешных запросов). SLA — обещание клиенту в договоре со штрафами или компенсацией. SLO обычно строже SLA, чтобы был запас. Подробнее про SLO и error budget — в статье про SRE для бизнеса.

Для внутренних систем, некритичных отчётов, маркетинговых страниц без прямой оплаты, B2B-кабинетов без жёстких штрафов в договоре. Критично не цифра на слайде, а измерение на пути денег: корзина, оплата, API для партнёров.

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

Один критичный сервис, три метрики (ошибки, p95, путь оплаты/отчёта), письменный SLO на квартал, учебный разбор одного инцидента. Не покупать «лишнюю девятку» до того, как посчитали цену часа простоя в ₽.

Хотите применить это на практике?

Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.

Все материалы: High-Load

High-Load17 августа 2026 г.
Как мы готовим проект к HighLoad: взгляд на систему до пика

Метод NineLab: как смотрим на проект перед HighLoad — цель нагрузки, модель пика, карта узких мест, порядок правок и проверка стресс-тестом до рекламы.

Читать статью
High-Load13 августа 2026 г.
ЛК клиента B2B: MVP из 7 экранов, которые реально открывают

Личный кабинет клиента B2B: какие 7 экранов нужны в MVP, что отложить на v2, ориентир сроков и бюджета и чеклист приёмки для дилерского / партнёрского портала.

Читать статью
High-Load12 августа 2026 г.
Как мы сделали поиск организаций для asknayda.ru: лексика, ИИ и пилот

Как устроен поиск компаний в Найде (asknayda.ru): OpenSearch, модель bge-m3, когда включается семантический слой, RRF-гибрид и стадия пилота продукта.

Читать статью
High-Load6 августа 2026 г.
SEO больше не хватит: магазину нужны API под ИИ-агентов

SEO находит клиента, API даёт ИИ-агенту купить. OpenAPI для e-commerce и МСБ: чеклист контура, риски в ₽ и рамка «когда пора».

Читать статью