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

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

Три обещания. Одно связано с деньгами — и часто это не то, что на слайде вендора. 99.9% vs 99.99% — не «чуть лучше / чуть хуже». Это разный класс затрат: резервирование, мониторинг, on-call, failover. Каждая «девятка» — строка в бюджете, а не маркетинг.

Сколько простоя в цифрах → 99.9% ≈ 8 ч 45 мин в год (~43 мин/мес) — примерно один рабочий день → 99.99% ≈ 52 мин в год (~4 мин/мес) — примерно один час → разница — порядок, не «0.09%»

Три ловушки 1. Копировать uptime хостинга в договор с клиентом — IT подписывает невыполнимое 2. Одна цифра на весь «сайт» — главная зелёная, checkout лежит 3. Покупать multi-AZ до расчёта цены часа простоя в ₽

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

Когда хватит 99.9% → маркетинг без checkout на домене → внутренний портал, некритичные отчёты → B2B-кабинет без неустойки в договоре

Достаточно: 3–4 метрики, бэкапы 3-2-1, runbook — без 24/7 on-call.

Когда 99.99% оправдан → checkout/API в пик (акция, отчётный период) → enterprise-договор со штрафами → тендер с формальным фильтром «99.99%»

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

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

Даже при 99.9% «в среднем» можно лечь в день акции. SLA и HighLoad — смежные темы: одно про обещание в договоре, другое про выдержать конкретный всплеск.

Типичные ошибки → SLA из маркетинга в договор без расчёта → один SLA на всё — среднее, которым все недовольны → multi-AZ до карты узких мест — пик упрётся в БД → restore-тест «никогда не делали» — бэкап на словах

С чего начать, если SLA «на словах» Один критичный сервис. Три метрики: ошибки, p95, путь оплаты. Письменный SLO на квартал. Один разбор инцидента.

Пять вопросов CEO 1. Сколько стоит час простоя в ₽? 2. Есть штраф за SLA в договоре? 3. Какой путь критичен — checkout, API, ЛК отдельно? 4. Кто дежурит и за сколько поднимает? 5. Когда последний restore-тест?

Если на 1–2 «не знаем» — не покупайте лишнюю девятку. Сначала SLO 99.9% на одном сервисе.

Полный разбор — статья на сайте «SLA 99.9% vs 99.99%: когда переплата за «девятки» не нужна»: https://ninelab.ru/blog/sla-availability-cost-smb?utm_source=setka&utm_medium=social&utm_campaign=ninelab_setka_sla_availability_cost_smb

А в вашем договоре SLA — из расчёта или со слайда хостинга?

#SLA #highload #CTO

SLA 99.9% vs 99.99%: когда лишняя «девятка» — переплата | Сетка — социальная сеть от hh.ru