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

Сначала цена часа простоя — потом число девяток в договоре
Таблица «девяток»: сколько это простоя
Ответ: разница между 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 и чеклист пикового сезона.
Рамка для директора: пять вопросов
- Сколько стоит час простоя этого сервиса в ₽? (выручка + штрафы + репутация)
- Есть ли в договоре штраф за SLA? Если да — SLA должен быть измерим и подписан IT.
- Какой путь критичен? Одна цифра на весь «сайт» — ошибка; отдельно checkout, API, ЛК.
- Кто дежурит и за сколько поднимает? Без ответа 99.99% на бумаге = 99.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.
Статьи по теме
Как мы готовим проект к HighLoad: взгляд на систему до пика
Метод NineLab: как смотрим на проект перед HighLoad — цель нагрузки, модель пика, карта узких мест, порядок правок и проверка стресс-тестом до рекламы.
Читать статьюЛК клиента B2B: MVP из 7 экранов, которые реально открывают
Личный кабинет клиента B2B: какие 7 экранов нужны в MVP, что отложить на v2, ориентир сроков и бюджета и чеклист приёмки для дилерского / партнёрского портала.
Читать статьюКак мы сделали поиск организаций для asknayda.ru: лексика, ИИ и пилот
Как устроен поиск компаний в Найде (asknayda.ru): OpenSearch, модель bge-m3, когда включается семантический слой, RRF-гибрид и стадия пилота продукта.
Читать статьюSEO больше не хватит: магазину нужны API под ИИ-агентов
SEO находит клиента, API даёт ИИ-агенту купить. OpenAPI для e-commerce и МСБ: чеклист контура, риски в ₽ и рамка «когда пора».
Читать статью