Доступність сервісів (Uptime): формула й «дев’ятки»
Uptime / Доступність — частка часу, коли сервіс працює в межах узгоджених показників якості (SLO): успішність запитів, затримка, помилки. Це базовий SLI для продуктів і платформ, що напряму впливає на виконання SLA, досвід користувача й доходи.
Що вимірює показник
Частку «здорового» часу сервісу за вибраним критерієм: успішні відповіді (2xx/3xx), помилки (5xx), латентність (≤ ціль), відсоток валідних подій. Окремо вимірюйте критичні залежності (БД, кеш, платіжний шлюз, CDN) і регіони/зони доступності.
Розрахунок
- Uptime, % = (Загальний час − Downtime) / Загальний час × 100
- Downtime, хв = Σ Інциденти (фактичний недоступний інтервал)
- Availability SLI = Успішні запити / Усі запити × 100 (з фільтром на SLO-латентність)
- SLO — ціль доступності (напр., 99.9% за 30 днів)
- Error Budget = 100% − SLO; Burn Rate = Витрачено бюджету / Час
- MTTR = Середній час відновлення; MTBF = Середній час між збоями
Зафіксуйте правила: вікно вимірювання (напр., ковзні 30 днів), бізнес- vs календарний час, планові вікна (maintenance), часткові відмови (вага за трафіком/користувачами), часові пояси.
Приклад розрахунку
У місяці 30 днів = 43 200 хвилин, сервіс був недоступний 54 хвилини. Доступність = (43 200 − 54) / 43 200 × 100 = 99,875 %. Для SLA 99,9 % допустимо лише 43 хвилини простою на місяць, тож зобов’язання порушено.
Джерела даних
Моніторинг/APM (запити, помилки, латентність), синтетичні перевірки (HTTP/DNS/SSL), RUM/телеметрія клієнта, алерти інфраструктури (VM/K8s/DB/queue), логи інцидентів/онколлів, статус-сторінка.
Інтерпретація
- Uptime↓ або високий burn rate — ризик невиконання SLO/SLA; потрібні стабілізаційні зміни й change freeze
- MTTR↑ — слабкий алертинг/діагностика/ескалації; MTBF↓ — технічний борг, «гарячі деплоя»
- Регіональні/часткові відмови маскуються середнім — використовуйте вагу за реальним трафіком
Корисні розрізи
- Сервіс/ендпоінт; критичність (P0–P3); середовище (prod/stage)
- Регіон/зона; ISP/CDN; клієнтський тип (web/iOS/Android/API)
- Тип інциденту (інфра/деплой/залежність/DDoS/конфіг)
- Латентність P50/P95/P99; частка 5xx/4xx; saturation ресурсів
Візуалізації на дашборді
- Тренд Uptime% і SLO compliance за 7/30 днів
- Error Budget burn-down і миттєвий burn rate (1 год / 6 год)
- Таймлайн інцидентів із причинами/анотаціями деплоїв
- Heatmap доступності за регіонами/ендпоінтами
- Кореляції Uptime ↔ конверсія/доход/CSAT
Як ставити цілі
Визначте SLO за критичністю (напр., ядро — 99.95–99.99%, допоміжні — 99.5–99.9%), правила бюджету помилок і давнвейти на регіони/ендпоінти. Налаштуйте чіткі SLA для клієнтів, ескалації P0/P1, auto-rollback, канарні релізи та postmortem-практики з діями (CAPA).
Типові помилки
- Рахувати «пінг живий» як доступність бізнес-функції; ігнор латентності
- Не враховувати часткові/регіональні збої або залежності (БД, платежі, CDN)
- Змішувати планові роботи з даунтаймом без політики maintenance
- Немає ковзного вікна 30 днів і контролю error budget
- Відсутність чітких алертів/рунбуків/ескалацій
Запитання для обговорення
- Які залежності найчастіше «ламають» доступність і як їх ізолювати?
- Чи достатні наші бюджети помилок і політика change management?
- Де скоротити MTTR: сповіщення, observability, рунабучні скрипти?
- Який вплив канарних/blue-green релізів на Uptime і ризики?