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 — из расчёта или со слайда хостинга?
· вчера
в цепочке «алерт → человек открывает runbook → чинит» узкое место — сам человек, и даже 4 минуты в месяц при 99.99% легко сгорают, пока дежурный просыпается и тянется к ноуту. я бы первым делом замкнул health-check на авто-ремедиацию: контейнер рестартится сам, failover дёргается по webhook, а on-call получает алерт уже постфактум. так ручное звено выпадает из критического пути и sli перестаёт зависеть от скорости реакции одного конкретного человека
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён