Śledzenie uptime

1) Dlaczego monitorować czas uptime

Uptime - udział czasu, kiedy usługa jest dostępna dla użytkownika. Jest to „pierwsza linia” obserwowalności: błyskawicznie zauważyć niedostępność, degradację w sieci, awarię DNS/TLS, problemy z routingiem lub CDN. W przypadku systemów o wysokim obciążeniu i regulowanych (fintech, iGaming) czas pracy bezpośrednio wpływa na przychody, wydajność SLA i ryzyko kary.

2) Terminy i wzory

Dostępność SLI: „SLI = (udane kontrole/wszystkie kontrole) × 100%”.
SLO: dostępność docelowa na okno (zwykle 28-30 dni), na przykład 99. 9%.
SLA: zobowiązania zewnętrzne; zawsze ≤ wewnętrzne SLO.
MTBF/MTTR: średni czas pomiędzy awariami/średnim czasem odzysku.

99. 0% → ~ 432 min niedostępny

99. 9% → ~ 43 min

99. 99% → ~4. 3 min

99. 999% → ~ 26 sec

3) Jakie kontrole są potrzebne (czarne pudełko)

Uruchomiony z zewnętrznych punktów (różne regiony/dostawcy), aby zobaczyć usługę „oczami klienta”.

1. ICMP (ping) - podstawowa dostępność sieci/węzłów. Szybki, ale nie odzwierciedlający sukcesu biznesowego.
2. TCP connect - słuchanie portów? Przydatne dla brokerów/DB/SMTP.
3. HTTP/HTTPS - kod stanu, nagłówki, rozmiar, przekierowania, czas do pierwszego bajtu.
4. TLS/certyfikaty - okres ważności, łańcuch, algorytmy, SNI, protokoły.
5. DNS - A/AAAA/CNAME, NS-health, dystrybucja, DNSSEC.
6. gRPC - status połączenia, termin, metadane.
7. WebSocket/SSE - uścisk dłoni, konserwacja połączenia, wiadomość echo.
8. Proxy/routing/CDN - różne PoP, hash pamięci podręcznej, warianty geo.
9. Scenariusze syntetyczne transakcji (kliknięcia/formularze): „login → search → deposit (piaskownica)”.
10. Monitorowanie bicia serca/kronu - usługa musi „pulsować” (hak raz na N minut); brak sygnału - alarm.

• Ustawić terminy bliżej rzeczywistego UX (na przykład TTFB ≤ 300 ms, łącznie ≤ 2 s).
• Sprawdź aktywa treści (słowo kluczowe/pole JSON), aby „200 OK” z błędem nie było uważane za sukces.
• Duplikat kontroli za pośrednictwem niezależnych dostawców i sieci (multi-hop, różne ASN).

4) Białe pudełko i służba zdrowia

Livity/Testy gotowości dla orkiestry (procesy są żywe? gotowy do odbioru ruchu?).
Zdrowie uzależnienia: DB, pamięć podręczna, broker wydarzeń, zewnętrzne interfejsy API (płatności/KYC/AML).
Flagi funkcyjne/degradacja: w przypadku problemów delikatnie wyłączyć ścieżki niekrytyczne.

Białe próbki nie zastępują kontroli zewnętrznych: usługa może być „zdrowa wewnątrz”, ale niedostępna dla użytkownika ze względu na DNS/TLS/trasę.

5) Geografia i wieloregionalność

Uruchomić syntetykę z kluczowych regionów ruchu i w pobliżu krytycznych dostawców zależności.
Kworum: zdarzenie jest rejestrowane, jeśli w regionach ≥ N (na przykład 2 na 3) nie można odciąć lokalnej anomalii.
Próg według kohorty: oddzielne SLI/SLO dla ważnych segmentów (krajów, VIP, przewoźników).

6) Polityka ostrzegania (minimum hałasu)

Multi-region + multi-sonda: pager tylko w przypadku konsekwentnej awarii (na przykład HTTP i TLS jednocześnie, ≥ 2 regiony).
Debowns: N kolejne awarie lub 2-3 minutowe okno przed przywołaniem.

• L1: dyżur (usługi produkcyjne).
• L2 sieć/platforma/bezpieczeństwo na podstawie podpisu awaryjnego.
• Automatyczne zamykanie: po stabilnych kontrolach M.
• Ciche godziny/koncesje: dla usług wewnętrznych innych niż krytyczne - tylko bilety, bez pagera.

7) Strona statusu i komunikacja

Strony o statusie publicznym (klient) i prywatnym (wewnętrznym).
Automatyczne incydenty z syntetyki + ręczne adnotacje.
Szablony wiadomości: Wykryte - Zidentyfikowane - Wpływ - Działanie - ETA - Rozwiązane - Post-Mordem.
Planowane okna: ogłosić z wyprzedzeniem, rozważyć wyjątki oddzielnie od SLO.

8) Uwzględnienie zależności zewnętrznych

Dla każdego dostawcy (płatności, KYC, mailingi, CDN, chmury) - własne kontrole z kilku regionów.
Trasy awaryjne: automatyczne przełączanie na alternatywnego dostawcę za pomocą sygnału syntetycznego.
Oddzielne SLO na poziomie dostawcy i zintegrowane e2e-SLO.
Uzgodnić SLA z dostawcami (status webhooks, priorytet wsparcia).

9) Deski rozdzielcze i widżety kluczy

Mapa świata ze statusem kontroli (według typu: HTTP, DNS, TLS).
Harmonogram incydentów z adnotacjami wydania/bandery.
P50/P95/P99 TTFB/TTL/opóźnienia według regionów.
Dostępność przez kohortę (kraj/dostawca/urządzenie).
MTTR/MTBF, „minuty bezczynności” i „spalić” trendy budżetu dostępności na miesiąc.
Główne przyczyny awarii (TLS-expiry, DNS-resolving, 5xx, timeouts).

10) Proces incydentu (scenariusz przejściowy)

1. Uruchamiany jest alarm wielobranżowy/wielofunkcyjny.
2. Oficer służby potwierdza, włącza zamrożenie zwolnień, powiadamia właścicieli.
3. Szybka diagnostyka: status DNS/TLS/CDN, najnowsze wydania, harmonogram błędów.
4. Obejście: zmiana trasy, zawartość folback/dostawca, włączając tryb degradacji.
5. Odzyskiwanie: sprawdź, czy syntetyka/rzeczywisty ruch jest zielony.
6. Komunikacja na stronie statusu; zamknięcie incydentu.
7. RCA i elementy akcji: poprawki, testy, alerty, playbooks.

11) Sprawozdawczość SLA/SLO

Raporty miesięczne: czas uptime według usługi/regionu, minuty przestoju, MTTR, powody.
Porównanie z SLA: kredyty/rekompensaty, w stosownych przypadkach.
Kwartalne recenzje: aktualizacja progów, dystrybucja syntetyki, lista zależności.

12) Szablony kontroli (przykład)

• Metoda: 'GET/healthz/public' (brak tajemnic).
• Czas: 2 s, ponowna próba: 1.
• Sukces: '2xx', nagłówek 'X-App-Version' obecny, pole 'status' JSON: 'ok'.

• Termin> 14 dni, ważny łańcuch, protokoły TLS 1. 2 + ', poprawny SNI.

• Czas odpowiedzi ≤ 100 ms, rekordy A/AAAA są zgodne z planem, brak SERVFAIL/ODMOWA.

• Webhook '/beat/{ service} 'co 5 minut; brak 2 sygnałów z rzędu - alert L2 (zadania tła/ETL).

13) Lista kontrolna wdrażania

• Wieloregionalne kontrole zewnętrzne (HTTP/TCP/DNS/TLS/głębokie skrypty).
• Białe próbki gotowości/umieralności dla orkiestry.
• Oddzielenie ścieżek krytycznych/innych niż krytyczne, flagi degradacyjne.
• Kworum i debet w wpisach, eskalacji i automatycznego zamykania.
• Strony o statusie publicznym i wewnętrznym, szablony wiadomości.
• Oddzielne kontrole i SLO dla zewnętrznych dostawców + automatyczna awaria.
• Deski rozdzielcze: mapa, linia czasu, percentyle, minuty bezczynności, MTTR/MTBF.
• Regularne sprawozdania SLA/SLO i RCA po incydencie.

14) Częste błędy

Tylko ping/port bez treści HTTP/jest zielony, gdy nie jest dostępny.
Jeden punkt monitorowania - fałszywe pozytywne/negatywne wnioski.
Brak sterowania TLS/DNS - nagłe przerwy spowodowane opóźnieniem/błędną konfiguracją.
Dodatkowy hałas: wpisy dotyczące pojedynczych awarii z tego samego regionu/typu kontroli.
Brak połączenia ze zmianami - nie ma adnotacji o zwolnieniach i flagach w deskach rozdzielczych.
Niezauważone zależności - dostawca płatności spadł, a ogólny status jest „zielony”.

15) Najważniejsze

Śledzenie uptime to nie tylko "szczyt adresów URL. "Jest to system syntetycznych kontroli z prawdziwych regionów, rozsądnych wpisów bez hałasu, przejrzystej komunikacji poprzez strony stanu, rozliczania zewnętrznych zależności i ścisłej sprawozdawczości. Właściwie zbudowany monitoring uptime zmniejsza MTTR, chroni SLA i zachowuje przewidywalność doświadczenia użytkownika.