availability-numbers.js·4 scenarios
Concept page: Availability в цифрах. Девятки SLA — 99% / 99.9% / 99.99% / 99.999% — и сколько это реального downtime в год/месяц/неделю. Composition: sequential (произведение availabilities, слабейшее звено доминирует) vs parallel (1 - (1-A)^n, добавляет девяток). 4 сценария: single-9 disaster (3.65 дня/год), sequential composition (4 сервиса по 99.9% = 99.6%), parallel redundancy (2 реплики 99% = 99.99%), real MTTR/MTBF incident timeline (30-минутный outage съедает 69% месячного error budget).
Когда тебе говорят «нужно 99.99% uptime» — это надо немедленно переводить в минуты downtime в год. Без этой интуиции невозможно обсуждать SLA с заказчиком, нельзя ставить error budget, нельзя адекватно оценивать стоимость HA. И наоборот: если один сервер падает раз в неделю на 5 минут — это уже не 99.99%, а грустные 99.95%, и заказчик имеет право на штраф.
Цифры девяток обманчиво близкие: визуально 99.9% и 99.99% отличаются на «лишнюю девятку», а на практике одна стоит в 10 раз дороже другой — нужны multi-AZ, automated failover, on-call дежурство, chaos engineering, и команда инженеров, которая умеет это всё держать.
Главный навык — уметь за секунды считать в голове: composition (произведение для sequential, 1 минус произведение для parallel), error budget на месяц, сколько incident-ов сожрут весь бюджет, и где находится «слабейшее звено» цепочки.
Девятка = downtime/год переводится по таблице наизусть:
| Availability | Downtime / год | Downtime / месяц | Downtime / неделя |
|---|---|---|---|
| 99% (two nines) | 3.65 дня | 7.2 часа | 1.68 часа |
| 99.9% (three nines) | 8.76 часа | 43.2 минуты | 10.1 минуты |
| 99.99% (four nines) | 52.6 минуты | 4.32 минуты | 1.01 минуты |
| 99.999% (five nines) | 5.26 минуты | 26 секунд | 6 секунд |
| 99.9999% (six nines) | 31.5 секунды | 2.6 секунды | 0.6 секунды |
Composition — две формулы, которые надо знать:
A_total = A_1 × A_2 × ... × A_n. Каждый hop отнимает доступность. Слабейшее звено доминирует.A_total = 1 - (1 - A)^n. Каждая реплика добавляет девятки экспоненциально.Каждая следующая девятка стоит ~10x: 99% делается на одной ноде; 99.9% требует мониторинга и быстрого on-call; 99.99% требует multi-AZ и automated failover; 99.999% требует cell-based architecture, no-human-in-the-loop, chaos drills.
MTTR съедает error budget быстрее, чем кажется: при SLO 99.9% бюджет = 43.2 минуты/месяц. Один 30-минутный incident сжирает 69% месячного budget. Два таких — breach.
Диаграмма построена вокруг двух групп, иллюстрирующих обе формулы composition одновременно:
client → LB (99.99%) → API (99.9%) → Worker (99.9%) → DB (99.95%). Цепочка показывает, как произведение availability компонентов даёт меньше доступности, чем любой отдельный узел. На LB закреплён ADR-001 с правилом «каждая девятка стоит ~10x» и рекомендациями по выбору SLO для разных классов сервисов.1 - (1 - 0.99)^2 = 99.99%: две посредственные ноды дают четыре девятки, если LB умеет failover.Edges — это физические соединения: client запрашивает LB, LB балансирует на цепочку и параллельно на пару реплик. Ответы в анимации идут по тем же edges в обратном направлении (reverse animation). Никаких «shortcut» edges, обходящих LB, нет — это сознательное архитектурное решение, потому что LB — единственный proxy между клиентом и бэкендом.
single-9-disaster — Single 9 (99%) = 3.65 дня даунтаймаБазовый сценарий: одна нода, нет HA, договорились на 99%. Звучит солидно — а математика говорит, что это 3.65 дня в год или 1.68 часа в неделю. Когда DB действительно падает, нет replica для failover, нет worker queue для буфера, нет fallback — каскадная ошибка докатывается до клиента в виде 503. Урок: «99% звучит как высокая планка, но это часы downtime каждую неделю». Реальный бизнес с такими цифрами теряет клиентов.
sequential-composition — Композиция последовательной цепочкиСчитаем по шагам: 0.9999 × 0.999 × 0.999 × 0.9995 = 0.9974. Каждый компонент по отдельности выглядит «достаточно надёжным», но цепочка из 4 hops даёт 99.74% — это 22.7 часа downtime в год. Урок: «composed availability ≤ min(A_i)» — слабейшее звено доминирует, но даже хорошие звенья снижают общую цифру через умножение. Лекарство: меньше hops или parallel redundancy на каждом уровне.
parallel-redundancy — Две реплики добавляют девяткуФормула 1 - (1 - 0.99)^2 = 99.99% — две посредственные ноды дают четыре девятки. Сценарий показывает baseline (обе реплики живые, LB балансирует), затем падение X1, и failover на X2, который должен тянуть 100% нагрузки (привет, capacity headroom — если X2 утилизирован на 60%, то после падения X1 он на 120% = тоже падает). Урок: дублирование экспоненциально дёшево по девяткам, но требует (а) LB с health checks, (б) capacity headroom на оставшихся репликах, (в) data consistency между ними.
mttr-mtbf-incident — MTTR съедает error budgetРеальный 30-минутный outage по фазам: T+0 (DB CPU 100%), T+5 (Prometheus alert), T+10 (on-call просыпается, ищет runbook), T+15 (failover + restart), T+30 (восстановлено). Считаем: 30/43.2 = 69% месячного budget съедено за один incident. Два таких в месяц — SLA breach. Урок: чтобы держать 99.9%, нужно либо реже падать (MTBF — chaos engineering, capacity planning), либо быстрее восстанавливаться (MTTR — alerts с детекцией за секунды, runbooks, automation). Detection + decision time часто больше самой mitigation.
Контекст. Соблазн обещать заказчику «много девяток» велик, но каждая девятка стоит ~10x: 99% живёт на одной ноде с мониторингом; 99.9% требует health checks, быстрого on-call, runbooks, базового automation; 99.99% — multi-AZ, automated failover, chaos drills, dedicated SRE; 99.999% — cell-based architecture, blast-radius isolation, no-human-in-the-loop recovery, формальная chaos engineering программа.
Решение.
Последствия. SLA = SLO − девятка работает как защитный буфер: если у нас 1 incident в квартал, мы не нарушаем контракт. Без буфера один плохой месяц = legal exposure.
Контекст. Цепочка из 4 hops по 99.9% даёт 99.6% (≈35 часов/год). Очевидное решение — поставить parallel pair на каждом уровне, но это умножает infrastructure cost, требует state replication между парами, и каждый уровень добавляет операционную сложность.
Решение. Сначала сокращаем количество hops (объединяем сервисы, выкидываем proxy, кешируем результаты), и только потом дублируем оставшиеся узлы. Каждый убранный hop ценнее, чем дополнительная реплика.
Последствия. Архитектурный refactoring (микросервисы → modular monolith там, где это уместно) часто даёт больше availability, чем инфраструктура. Меньше moving parts = меньше точек отказа.
Контекст. Если две реплики по 99% утилизированы каждая на 70% и одна падает, оставшаяся получает 140% нагрузки. Она либо падает сразу, либо throttle/queue, и user-perceived availability рушится несмотря на «технический failover».
Решение. Каждая реплика в N-way HA-кластере несёт не больше 100% / (N-1) × 50% нагрузки. Для пары: ≤ 50% утилизации. Для тройки: ≤ 33%.
Последствия. HA-пара стоит не в 2x, а минимум 2x по compute + networking + data sync. Бизнес должен это понимать при подписании SLA.
Контекст. Если планировый maintenance не исключён из SLA, любой deployment съедает error budget, и team боится деплоить — что парадоксально снижает availability через накопление tech debt.
Решение. В SLA явно указывать: scheduled maintenance windows (например, воскресенье 02
–06 UTC, объявляется за 7 дней) не считаются downtime.Последствия. Команда деплоит без страха breach. Заказчик планирует критичные операции вне окна. Хочет 24/7/365 — это multi-region active-active и другие деньги.
Не гонитесь за лишней девяткой, если бизнес её не оплачивает. Переход с 99.9% на 99.99% — другая команда, другие deploy практики, другой бюджет. Если revenue impact от 4.3 минут downtime в месяц < $10K — пятая девятка не окупится.
Не стройте multi-region до того, как осилили multi-AZ. Multi-region даёт +1 девятку, но требует решения data consistency, replication lag, DR runbooks. Если не справляетесь с multi-AZ failover, multi-region добавит больше incident-ов.
Не указывайте SLA, если не меряете SLI. Без мониторинга success rate / error rate по user-facing endpoint-ам ваша «99.9%» — пожелание, а не контракт.
Не путайте availability с user-perceived availability. Сервис может отдавать 200 OK с p99 latency 30s — технически доступен, практически нет. SLI должен включать latency budget.
Не вкладывайтесь в девятки до capacity planning. Самая частая причина outage-ов — overload (traffic spike, bad query, runaway loop). 3 ноды по 50% утилизации дают больше availability, чем «99.99% SLA» на 2 нодах по 90%.
sli-slo-sla — формализация: SLI (что меряем), SLO (внутренняя цель), SLA (контракт с штрафами). Каноничный текст — Google SRE Book, Ch.4 «Service Level Objectives».error-budgets — как использовать оставшийся бюджет downtime как валюту между product и SRE: есть budget — деплоим быстрее; нет budget — freeze.numbers-to-know — Latency Numbers Every Programmer Should Know + reliability constants для back-of-envelope расчётов.back-of-envelope — как считать capacity, throughput, storage в голове на собеседовании.replication — master-slave, multi-master, quorum-based: какой паттерн репликации даёт какие гарантии availability.