В онлайні «доступність» — це не абстрактна метрика, а жорсткий дашборд прибутку та репутації. Uptime показує, який відсоток часу сайт або сервіс дійсно працював і був доступний відвідувачам. Чим ближче до 100 %, тим рідше клієнти стикаються з помилками, кошики не «падають», платіжні сторінки відкриваються швидко, а техпідтримка не «горить» щовечора. Коли в пропозиції провайдера ви бачите «99 %», це звучить переконливо, однак на практиці означає майже 7 годин простою на місяць — і бізнес-ефект від цих годин може бути відчутним навіть для невеликих проєктів.

Що таке uptime і як його рахують

Uptime — це співвідношення часу безвідмовної роботи до загального часу за період:
Uptime = (Час роботи ÷ Загальний час) × 100 %.
На практиці враховують різні статуси: повний простій, часткову деградацію (наприклад, API недоступний, але сайт відкривається), планові роботи та форс-мажори. Важливо розуміти методику підрахунку: в одних провайдерів плановий даунтайм виключається з розрахунку, в інших — входить; деякі починають таймер простою лише після N хвилин безперервної недоступності. Це тонкощі, які ховаються в SLA і впливають на реальний відсоток.

Математика SLA: чому «99 %» — це багато простою

Переведемо відсотки в зрозумілі хвилини та години в рамках 30-денного місяця:

  • 99 % ≈ 7 год 18 хв простою на місяць і ≈ 3 доби 15 год на рік;
  • 99,9 % ≈ 43 хв на місяць і ≈ 8 год 45 хв на рік;
  • 99,99 % ≈ 4–5 хв на місяць і ≈ 52 хв на рік.

Різниця між 99 % і 99,9 % — це прірва у втрачених можливостях. Для інтернет-магазину із середньою виручкою 5 000 грн/год 7 годин простою — мінус ~35 000 грн прямих доходів плюс непрямі втрати через збої оформлення замовлень, скасування та зниження довіри.

Вплив на бізнес, SEO та репутацію

Доступність — компонент користувацького досвіду, а значить, і конверсії. Якщо форма оплати «крутиться» без відповіді, клієнт йде. Пошукові системи враховують стабільність: коли краулер кілька разів поспіль отримує помилки, сторінки втрачають позиції, а відновлення потребує часу і бюджету на рекламу. Партнери та інтеграції (ERP, CRM, платіжні шлюзи) також очікують передбачуваності; кожне «вікно» веде до збоїв у звітності та SLA-штрафів вже з вашого боку.

Не тільки відсотки: MTTR, MTBF і SLO

Навіть ідеальні відсотки не врятують, якщо MTTR (Mean Time To Repair) — середній час відновлення — великий. Два провайдери з однаковими 99,9 % можуть бути різними у відчуттях: в одного аварії короткі та швидко закриваються, в іншого — рідкі, але багатогодинні. MTBF (середній час між відмовами) і SLO (цільовий рівень послуги всередині компанії) допомагають планувати надійність і доступність так, щоб цифри не були косметикою.

Типові причини простоїв (і як їх запобігати)

  • Живлення та охолодження: відсутність N+1/2N резервування, відмова ІБЖ, перегрів стійки.
  • Мережа: аварії операторів, насичення каналів, «петлі» в L2, помилка маршрутизації.
  • Сховище: деградація RAID, «повільна смерть» SSD, вузькі місця в SAN/NAS.
  • ПЗ та оновлення: невдалий патч, несумісність бібліотек, конфлікт модулів.
  • Людський фактор: невірний playbook, «гарячі» правки в проді.
  • DDoS та зловмисники: перевантаження L7, виснаження ресурсів, блокування.

Профілактика — в архітектурі: резервні лінії, ізоляція відмов, staging-оновлення, WAF/Rate-Limit, регулярні DR-тренування.

Архітектури високої доступності: як реально підвищити uptime

  • Георозподіленість: active-active або active-passive між майданчиками, реплікація БД, автоматичний failover.
  • Балансування та самовідновлення: health-checks, вилучення «хворих» інстансів, автоскейлінг.
  • CDN та edge-кешування: зниження навантаження на origin і локальні timeouts замість тотального падіння.
  • Декомпозиція: ізоляція критичних сервісів, щоб локальна деградація не «роняла» все.
  • Зберігання секретів і TLS: централізована ротація ключів, HSTS, OCSP-stapling, своєчасне продовження SSL-сертифікатів, щоб не «уронити» сайт простроченим сертифікатом.
  • Автономність від одного провайдера/оператора зв’язку: резервні uplink’и, BGP-мультихомінг (для великих).

Міні-калькулятор збитків та пріоритети інвестицій

Проста оцінка: Збиток = Простій (години) × Середня виручка/год + штрафи SLA + репутаційні втрати.
Порівняйте: здорожчання інфраструктури на 10–20 % часто дешевше, ніж один-два серйозних збої в пікові години. У проєктному плані закладіть бюджет на резервування критичних вузлів і регулярні DR-тренування — вони окупаються.

План на 30 днів: як швидко підняти фактичний uptime

  • Тиждень 1. Аудит SLA, інвентаризація залежностей, включення зовнішнього моніторингу, перевірка строків TLS.
  • Тиждень 2. Налаштування алертів і ескалацій, прискорення кешування, включення CDN для статики.
  • Тиждень 3. Репліка БД і резервний бекенд (хоча б у пасиві), тест-фейловер на стейджі.
  • Тиждень 4. DR-тренування, фіксація RPO/RTO, оновлення runbook’ів, коригування on-call.

Паралельно — домовленості з провайдером по вікнах обслуговування та каналах екстреного зв’язку. Якщо обороти ростуть — розгляньте перехід на більш потужний тариф VPS або георозподілене розміщення сервера в межах кількох стійок.

Висновок

Цифра «99 %» виглядає солідно до тих пір, поки не перевести її в реальні години простою. Для економії на інфраструктурі компанії нерідко переплачують втраченими замовленнями, впалим SEO і втомленими клієнтами. Зосередьтесь на трьох китах: архітектура відмовостійкості, операційна готовність (MTTR, моніторинг, on-call) і прозорий SLA із зрозумілими компенсаціями. Тоді рекламні відсотки перетворяться на передбачувану доступність, а доступність — на стабільну виручку і зростання.