Відстеження аптайма

1) Навіщо моніторити аптайм

Аптайм - частка часу, коли сервіс доступний користувачеві. Це «перша лінія» спостережуваності: миттєво помічати недоступність, деградацію по мережі, збій DNS/TLS, проблеми маршрутизації або CDN. Для високонавантажених і регульованих систем (фінтех, iGaming) аптайм безпосередньо впливає на виручку, виконання SLA і штрафні ризики.

2) Терміни та формули

SLI доступності: 'SLI = (успішні перевірки/всі перевірки) × 100%'.
SLO: цільова доступність за вікно (зазвичай 28-30 днів), наприклад 99. 9%.
SLA: зовнішнє зобов'язання; завжди ≤ внутрішнього SLO.
MTBF / MTTR: середній час між збоями/середній час відновлення.

99. 0% → ~ 432 хв недоступності

99. 9% → ~ 43 хв

99. 99% → ~4. 3 хв

99. 999% → ~ 26 сек

3) Які перевірки потрібні (чорний ящик)

Запускаються із зовнішніх точок (різні регіони/провайдери), щоб бачити сервіс «очима клієнта».

1. ICMP (ping) - базова мережевуха/доступність вузла. Швидка, але не відображає бізнес-успіх.
2. TCP connect - порт слухає? Корисно для брокерів/БД/SMTP.
3. HTTP/HTTPS - статус-код, заголовки, розмір, редиректи, час до першого байта.
4. TLS/сертифікати - термін дії, ланцюжок, алгоритми, SNI, протоколи.
5. DNS - A/AAAA/CNAME, NS-здоров'я, поширення, DNSSEC.
6. gRPC - статус виклику, deadline, метадані.
7. WebSocket/SSE - рукостискання, підтримка з'єднання, повідомлення-відлуння.
8. Проксі/маршрутизація/CDN - різні PoP, хеш-проба кешу, гео-варіанти.
9. Транзакційні синтетичні сценарії (кліки/форми): «логін → пошук → депозит (пісочниця)».
10. Heartbeat/cron-моніторинг - сервіс зобов'язаний «пульсувати» (хук раз на N хвилин); немає сигналу - тривога.

• Ставте таймаути ближче до реального UX (наприклад, TTFB ≤ 300 мс, total ≤ 2 с).
• Перевіряйте контент-асерт (ключове слово/JSON-поле), щоб «200 ОК» з помилкою не вважався успіхом.
• Дублюйте перевірки через незалежних провайдерів і мережі (мульти-хоп, різні ASN).

4) Білий ящик і здоров'я сервісу

Liveness/Readiness проби для оркестратора (процеси живі? готові приймати трафік?).
Здоров'я залежностей: БД, кеш, брокер подій, зовнішні API (платежі/KYC/AML).
Фіча-прапори/деградація: при проблемах м'яко відключаємо не-критичні шляхи.

Білі проби не замінюють зовнішні перевірки: сервіс може бути «здоровий всередині», але недоступний користувачеві через DNS/TLS/маршруту.

5) Географія і багаторегіональність

Запускайте синтетику з ключових регіонів трафіку і поруч з провайдерами критичних залежностей.
Кворум: інцидент фіксуємо, якщо провал в ≥ N регіонах (наприклад, 2 з 3), щоб відсікти локальні аномалії.
Поріг по когортах: окремі SLI/SLO для важливих сегментів (країни, VIP, оператори зв'язку).

6) Політика алертів (мінімум шуму)

Мульти-регіон + мульти-проба: пейджер тільки при узгодженому провалі (наприклад, HTTP і TLS одночасно, ≥ 2 регіони).
Дебаунс: N послідовних невдач або вікно 2-3 хвилини перед пейджем.

• L1: on-call (продакшен-сервіси).
• L2: мережа/платформа/безпека в залежності від сигнатури збою.
• Авто-закриття: після стабільних M успішних перевірок.
• Тихий годинник/поступки: для не-критичних внутрішніх сервісів - тільки тікети, без пейджера.

7) Статус-сторінка і комунікація

Публічна (клієнтська) і приватна (внутрішня) статус-сторінки.
Автоматичні інциденти від синтетики + ручні анотації.
Шаблони повідомлень: виявлено - ідентифіковано - вплив - обхідний шлях - ETA - вирішено - пост-мордем.
Планові вікна: заздалегідь оголошувати, винятки враховувати окремо від SLO.

8) Облік зовнішніх залежностей

Для кожного провайдера (платежі, KYC, розсилки, CDN, хмари) - свої перевірки з декількох регіонів.
Failover-маршрути: авто-перемикання на альтернативного провайдера за сигналом синтетики.
Окремі SLO на рівні провайдера і інтегральний e2e-SLO.
Домовитися про SLA з провайдерами (статус-вебхуки, пріоритет підтримки).

9) Дашборди та ключові віджети

Карта світу зі станом перевірок (за типами: HTTP, DNS, TLS).
Таймлайн інцидентів з анотаціями релізів/прапорів.
P50/P95/P99 TTFB/TTL/latency по регіонах.
Доступність по когортах (країна/провайдер/пристрій).
MTTR/MTBF, тренди «хвилин простою» і «burn-down» бюджету доступності за місяць.
Топ-причини провалів (TLS-expiry, DNS-resolving, 5xx, timeouts).

10) Процес інциденту (швидкоплинний сценарій)

1. Спрацьовує мульти-регіон/мульти-тип алерт.
2. Черговий підтверджує, включає заморожування релізів, сповіщає власників.
3. Швидка діагностика: статус DNS/TLS/CDN, останні релізи, графік помилок.
4. Обхід: зміна маршруту, фолбек-контент/провайдер, включення режиму деградації.
5. Відновлення: перевірка, що синтетика/реальний трафік зелені.
6. Комунікація на статус-сторінці; закриття інциденту.
7. RCA и action items: виправлення, тести, алерти, плейбуки.

11) Звітність по SLA/SLO

Щомісячні звіти: аптайм по сервісах/регіонах, хвилини простою, MTTR, причини.
Порівняння з SLA: кредити/компенсації, якщо застосовується.
Квартальні рев'ю: актуалізація порогів, розподіл синтетики, перелік залежностей.

12) Шаблони перевірок (приклад)

• Метод: 'GET/healthz/public'( без секретів).
• Таймаут: 2 с, retry: 1.
• Успіх: '2xx', заголовок'X-App-Version'присутній, JSON-поле'« status »:"ok"`.

• Термін> 14 днів, валідний ланцюжок, протоколи'TLS 1. 2 +', коректний SNI.

• Час відповіді ≤ 100 мс, записи A/AAAA відповідають плану, немає SERVFAIL/REFUSED.

• Вебхук '/beat/{ service}'раз в 5 хв; відсутність 2 сигналів поспіль - алерт L2 (фонові задачі/ETL).

13) Чек-лист впровадження

• Мульти-регіональні зовнішні перевірки (HTTP/TCP/DNS/TLS/глибокі сценарії).
• Білі проби readiness/liveness для оркестратора.
• Розділення критичних/некритичних шляхів, фіча-прапори деградації.
• Кворум і дебаунс в алертах, ескалації та авто-закриття.
• Публічна і внутрішня статус-сторінки, шаблони повідомлень.
• Окремі перевірки та SLO для зовнішніх провайдерів + автоматичний failover.
• Дашборди: карта, таймлайн, перцентілі, хвилини простою, MTTR/MTBF.
• Регулярні звіти по SLA/SLO і пост-інцидентні RCA.

14) Часті помилки

Тільки ping/порт без НТТР/контенту - «зелений» при фактичній недоступності.
Одна точка моніторингу - хибно позитивні/негативні висновки.
Відсутність контролю TLS/DNS - раптові простої через прострочення/місконфіга.
Зайвий шум: алерти по одиночних провалах з одного регіону/типу перевірки.
Немає зв'язку зі змінами - відсутні анотації релізів і прапорів в дашбордах.
Невраховані залежності - платіжний провайдер впав, а загальний статус «зелений».

15) Підсумок

Відстеження аптайма - це не тільки «пікати URL». Це система синтетичних перевірок з реальних регіонів, розумні алерти без шуму, прозора комунікація через статус-сторінки, облік зовнішніх залежностей і сувора звітність. Правильно вибудуваний моніторинг аптайма зменшує MTTR, захищає SLA і зберігає передбачуваність користувацького досвіду.