Математика SLA — что на самом деле стоит 99,9% доступность в часах простоя

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

Это математика, которую каждый разработчик должен знать перед подписанием SLA или включением цифры доступности в предложение.

Формула

Проценты доступности переводятся в простоя с помощью одной простой формулы:

Простой период = (1 – доступность) × период

Для доступности 99,9%: 1 – 0,999 = 0,001. Умножьте на количество минут в году (525 960) и получите 525,96 минут — или 8,77 часов допустимого простоя в год. Это не катастрофический сбой. Это просто среда вторника, когда деплой уходит в петлю на несколько часов, база данных переключается дольше, чем ожидалось, и обновление зависимости в полночь нарушает сервис аутентификации. Восемь часов проходят быстро.

Таблица справок

Сохраните эту таблицу. Каждое число здесь рассчитывается одинаково — (1 – доступность) × продолжительность периода в минутах, затем переводится в наиболее понятную единицу.

Доступность	Простой в день	Простой в неделю	Простой в месяц	Простой в год
99%	14,4 мин	1,68 ч	7,3 ч	87,6 ч
99.5%	7,2 мин	50,4 мин	3,65 ч	43,8 ч
99.9%	1,44 мин	10,08 мин	43,83 мин	8,77 ч
99.95%	43,2 сек	5,04 мин	21,92 мин	4,38 ч
99.99%	8,64 сек	1,01 мин	4,38 мин	52,6 мин
99,999% (пять девяток)	0,864 сек	6,05 сек	26,3 сек	5,26 мин

Повторите строку 99,999%. Допустимый простоя в год — пять минут и двадцать шесть секунд. Всё. Включая запланированное техническое обслуживание, сбои проверок здоровья и 30 секунд, которые ваш балансировщик тратит на обнаружение умершего узла. Вы можете посчитать, насколько это реалистично для большинства команд.

Требования, которые предъявляются к пяти девяткам

Пять девяток (99,999%) — это не просто «хорошая инфраструктура». Это другая область инженерии. Чтобы достичь этого нужно:

• Полная резервная система на каждом уровне — отсутствие единичных точек отказа в любой части стека, включая DNS, CDN, базу данных и приложение
• Автоматическое переключение с подсекундным обнаружением — люди не могут реагировать быстро достаточно; мониторинг и переключение должны работать без вмешательства
• Деплой без простоя — с использованием синхронного или канарийского подхода, с автоматическим откатом. Любое развертывание, требующее перезапуска, уменьшает ваш бюджет в 5 минут
• Многоуровневые активные активные конфигурации — отказ одного региона не должен взять с собой всю систему
• Запланированное техническое обслуживание вне окон SLA — большинство SLA 99,9% явно исключают запланированное техническое обслуживание, но SLA 99,999% часто не оставляют места для этого

Компании, которые действительно достигают 99,999% — AWS S3, Google Cloud Storage — имеют специализированные команды по надежности, годы данных по хаос-инженерии и расходы на инфраструктуру, которые бы заставили большинство основателей SaaS потерять сознание. Это достижимо, но не случайно и не дешево.

Вы можете использовать Калькулятор доступности / SLA для выполнения этих расчетов для любого процента доступности и любого временного интервала, с которым вы работаете.

Проблема кредитов SLA

Вот часть, которая удивляет людей: кредиты SLA от облачных провайдеров не компенсируют вас за реальные потери. Они компенсируют лишь часть вашей платы за хостинг.

AWS, GCP и Azure обычно предлагают 10–30% от вашей ежемесячной платы за услуги в случае нарушения SLA. Если вы платите $500 в месяц за EC2 и у вас произошёл сбой на два часа, нарушающий SLA, вы можете получить кредит в размере $50–150. В то же время вы можете потерять тысячи в доходах, потратить инженерские часы на реагирование на инцидент и нанести ущерб доверию клиентов.

Когда вы пишете SLA с вашими клиентами, понимайте, что это стандартная модель — кредиты — это добрые жесты, связанные с платой за услуги, а не полная компенсация. Тщательно прочитайте пункт о компенсациях. Многие корпоративные клиенты будут пытаться включить в договор реальные убытки; это другое обсуждение, в котором участвуют юристы, а не SRE.

Ежемесячные и годовые окна имеют значение

SLA измеряется в определённом интервале, и это значение имеет большее значение, чем большинство людей думают. Годовой SLA 99,9% даёт вам 8,77 часов простоя, распределённых по 12 месяцам. Ежемесячный SLA 99,9% даёт только 43,83 минуты в месяц — но это сбрасывается каждый месяц.

Клиенты почти всегда хотят ежемесячное измерение — это звучит строже, и даёт им рычаг, если у вас один плохой месяц. То, что они не всегда понимают, — ежемесячное измерение может фактически давать меньше общего запаса: 43,83 минуты × 12 месяцев = 525,96 минут в год, что идентично расчёту по годовому периоду. Разница в том, что при ежемесячных SLA один плохой месяц может вызвать нарушение, даже если остальная часть года была идеальной.

При переговорах, стремитесь к годовым периодам измерения. Если клиенты настаивают на месячных, убедитесь, что ваша инфраструктура может достичь 99,9% каждый месяц — а не просто в среднем по году.

Что реально можно обещать

Вот практическое руководство:

Личные проекты и ранние продукты

99,% — честно и приемлемо. Девять часов простоя в месяц — реалистично для небольшой команды без специализированной операционной поддержки. Не обещайте больше, чем можете постоянно обеспечивать — репутационные потери от пропущенных SLA хуже, чем установка более низких ожиданий на начальном этапе.

B2B SaaS на стандартной облачной инфраструктуре

99,9% — правильная цель. С правильным мониторингом, автоматическим масштабированием, управляемыми базами данных и CI/CD-процессом, не требующим простоя при развертывании, это реально достижимо на AWS, GCP или Azure без героических усилий. Бюджет в 43 минуты в месяц — тесный, но достижимый, если у вас есть автоматизация развертывания.

99,99% и выше

Это требует реальных вложений: балансировщики в нескольких доступных зонах, мульти-региональные активные активные конфигурации, репликация баз данных с автоматическим переходом и кто-то, кто считает надежность своей основной задачей. Если клиент просит 99,99%, а у вас пока нет такой инфраструктуры, честный ответ — переговорить о 99,9% и построить путь к 99,99% как элемент дорожной карты — с соответствующим увеличением расходов на инфраструктуру, отражённым в цене.

99,999% — это зона Amazon и Google. Если вы не работаете с финансовыми инфраструктурами, системами здравоохранения или телеком-услугами с командой SRE, это не реалистичная обязательность.

Выполните расчёты для вашей ситуации

Эта математика масштабируется на любой временной рамку и любую цель доступности. Если вы работаете с нестандартным периодом SLA — 90-дневным скользящим окном, финансовым кварталом, или любым другим периодом измерения — формула остаётся той же: умножьте процент простоя на количество минут в вашем периоде.

The Расчёт доступности / SLA на IO Tools обрабатывает всё это — введите любой процент доступности и период времени, чтобы получить точный бюджет простоя, что полезно при составлении текста SLA или при ответе на запрос клиента о доступности с реалистичным предложением.

Итог: 99,9% — практический предел для большинства команд без инвестиций в надежность. Любое значение выше требует реальных затрат и реформ процессов. Знайте, что вы обещаете, до подписания контракта.

Вам также может понравиться