Отслеживание аптайма

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/порт без HTTP/контента — “зеленый” при фактической недоступности.
Одна точка мониторинга — ложно положительные/отрицательные выводы.
Отсутствие контроля TLS/DNS — внезапные простои из-за просрочки/мисконфига.
Лишний шум: алерты по одиночным провалам из одного региона/типа проверки.
Нет связи с изменениями — отсутствуют аннотации релизов и флагов в дашбордах.
Неучтенные зависимости — платежный провайдер упал, а общий статус “зеленый”.

15) Итог

Отслеживание аптайма — это не только “пикать URL”. Это система синтетических проверок из реальных регионов, разумные алерты без шума, прозрачная коммуникация через статус-страницы, учет внешних зависимостей и строгая отчетность. Правильно выстроенный мониторинг аптайма уменьшает MTTR, защищает SLA и сохраняет предсказуемость пользовательского опыта.