Что означает «availability» (доступность)

Availability — это степень готовности сервиса обрабатывать запросы и отдавать требуемую функциональность пользователю. Проще: это доля времени (или доля успешных запросов), когда сервис «работает» по заданному критерию успеха.

Формулы

1. Временной подход (time-based availability)
   Availability=Общее время−Время простояОбщее время\text{Availability} = \frac{\text{Общее время} - \text{Время простоя}}{\text{Общее время}}
   где «Время простоя» — суммарное время, когда сервис считается недоступным по определённым правилам (health-checks, ошибки, таймауты и т.д.).

2. Подход по запросам (request-based availability)
   Availability=Число успешных запросовОбщее число запросов\text{Availability} = \frac{\text{Число успешных запросов}}{\text{Общее число запросов}}
   «Успешный запрос» — это заранее определённое условие (например, HTTP-коды 2xx, p95 latency < X и т.п.).

Пример вычисления (цифра за цифрой)

Возьмём SLO = 99.9% за 30-дневный период и посчитаем допустимое время простоя:

• 30 дней = 30 × 24 = 720 часов.

• 720 часов × 3600 = 2 592 000 секунд.

• Ненадёжность = 1 − 0.999 = 0.001.

• Допустимое простое время в секундах = 2 592 000 × 0.001 = 2 592 сек.

• 2 592 сек = 2 592 ÷ 60 = 43.2 мин → 43 мин и 0.2×60 = 12 сек → 43 мин 12 сек.

Часто используемые уровни доступности — время простоя

(дано в человеко-понятном виде)

• 90% → год: ~36 дн 12 ч; месяц(30д): ~3 дн; день: ~2 ч 24 мин.

• 99% → год: ~3 дн 15 ч 36 мин; месяц: ~7 ч 12 мин; день: ~14 мин 24 сек.

• 99.9% → год: ~8 ч 45 мин 36 сек; месяц: ~43 мин 12 сек; день: ~1 мин 26 сек.

• 99.95% → год: ~4 ч 22 мин 48 сек; месяц: ~21 мин 36 сек; день: ~43 сек.

• 99.99% → год: ~52 мин 34 сек; месяц: ~4 мин 19 сек; день: ~9 сек.

• 99.999% → год: ~5 мин 15 сек; месяц: ~26 сек; день: ~1 сек.

Как измеряют на практике

• Синтетические проверки (active / probes): регулярные HTTP-запросы монитора к URL/эндпойнту (ping, healthcheck). Позволяют быстро обнаружить доступность, но могут не отражать реальный пользовательский опыт.

• Реальные запросы (RUM / passive): измерение успешных/проваленных реальных пользовательских транзакций. Лучший индикатор UX, но может быть подвержен шуму и нерегулярному трафику.

• Логи и метрики сервера: подсчёт ошибок 5xx/availability по сервисам, контролируемым компонентам.

• Трейсинг и APM: использование распределённых трейсингов для определения точек отказа и влияния на availability.

На каком уровне считать

• Уровень сервиса (API, сайт), компонент (база данных, кэш), регион/зона и edge/CDN — важно указывать уровень, на котором измеряется availability, иначе цифры будут вводить в заблуждение.

Что считается «успехом»

Нужно заранее определить: HTTP 2xx? 2xx+3xx? Включать ли повторные попытки (retries)? Что делать с частично деградировавшей функциональностью (например, поисковая функция работает медленно — считать доступной или нет)? Эти правила должны быть документированы.

Особенности и подводные камни

• Окна учета: скользящее окно (rolling) и календарный месяц дают разные результаты.

• Искажения из-за ретраев и CDN: клиентские ретраи могут скрывать реальные сбои.

• Синхронизация времени: ошибки в часовых метках могут исказить подсчёт.

• Зависимости: доступность комплексного сервиса = функция доступности зависимостей; простая агрегация может неверно оценивать UX.

• Плановое обслуживание: обычно исключается из SLA, но это должно быть явно согласовано.

• Разная метрика для разных пользователей: internal admin UI и публичный API могут иметь разные SLO/SLA.

Лучшие практики измерения

• Формализовать критерий «успеха» и методику подсчёта SLI.

• Собирать и хранить сырые метрики запросов и health-check событий для верификации.

• Сочетать синтетические проверки и RUM для полноты картины.

• Мониторить скорость «сжигания» error budget, а не только факт нарушения SLO.

• Учитывать границы — региональные сбои, сетевые partition’ы и плановые окна.