Доступність сервісів (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), часткові відмови (вага за трафіком/користувачами), часові пояси.

Джерела даних

Моніторинг/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 і ризики?