Urmărirea uptime

1) De ce să monitorizați timpul de funcționare

Uptime - cota de timp atunci când serviciul este disponibil pentru utilizator. Aceasta este „prima linie” de observabilitate: observați instantaneu inaccesibilitatea, degradarea prin rețea, eșecul DNS/TLS, problemele de rutare sau CDN. Pentru sistemele cu sarcină mare și reglementate (fintech, iGaming), uptime-ul afectează direct veniturile, performanța SLA și riscurile de penalizare.

2) Termeni și formule

Disponibilitate SLI: 'SLI = (verificări de succes/toate verificările) × 100%'.
SLO: disponibilitatea țintă pe fereastră (de obicei 28-30 de zile), de exemplu 99. 9%.
SLA: obligație externă; întotdeauna ≤ SLO intern.
MTBF/MTTR: timpul mediu între eșecuri/timpul mediu de recuperare.

99. 0% → ~ 432 min indisponibil

99. 9% → ~ 43 min

99. 99% → ~4. 3 min

99. 999% → ~ 26 sec

3) Ce verificări sunt necesare (cutie neagră)

Lansat din puncte externe (diferite regiuni/furnizori) pentru a vedea serviciul „prin ochii clientului”.

1. ICMP (ping) - disponibilitatea rețelei/nodului de bază. Rapid, dar nu reflectă succesul afacerii.
2. Conectare TCP - ascultare port? Utile pentru brokeri/DB/SMTP.
3. HTTP/HTTPS - cod de stare, antete, dimensiune, redirecționări, timp până la primul octet.
4. TLS/certificate - perioada de valabilitate, lanț, algoritmi, SNI, protocoale.
5. DNS - A/AAAA/CNAME, NS-sănătate, distribuție, DNSSEC.
6. gRPC - stare apel, termen limită, metadate.
7. WebSocket/SSE - strângere de mână, întreținere conexiune, mesaj ecou.
8. Proxy/routing/CDN - diferite PoPs, hash cache, geo-variante.
9. Scenarii sintetice tranzactionale (clicuri/formulare): „login → search → deposit (sandbox)”.
10. Monitorizarea bătăilor inimii/cron - serviciul trebuie să „impulsioneze” (cârlig o dată la fiecare N minute); nici un semnal - alarmă.

• Setați timpii mai aproape de UX real (de exemplu, TTFB ≤ 300 ms, total ≤ 2 s).
• Verificați activul de conținut (cuvânt cheie/câmp JSON), astfel încât „200 OK” cu o eroare nu este considerat un succes.
• Verificări duplicate prin furnizori și rețele independente (multi-hop, diferite ASN-uri).

4) Cutie albă și servicii de sănătate

Teste de viață/pregătire pentru orchestrator (procesele sunt vii? gata să primească trafic?).
Sănătate dependență: DB, cache, broker de evenimente, API-uri externe (plăți/KYC/AML).
Caracteristică steaguri/degradare: în caz de probleme, dezactivați ușor căile non-critice.

Probele albe nu înlocuiesc verificările externe: serviciul poate fi „sănătos în interior”, dar nu este disponibil pentru utilizator din cauza DNS/TLS/traseu.

5) Geografie și multi-regionalitate

Rulați sintetice din regiuni cheie de trafic și din apropierea furnizorilor de dependență critică.
Cvorum: un incident este înregistrat în cazul în care un eșec în regiunile ≥ N (de exemplu, 2 din 3) pentru a tăia anomaliile locale.
Prag pe cohortă: SLI/SLO separate pentru segmente importante (țări, VIP-uri, transportatori).

6) Politica de alertă (minim de zgomot)

Multi-regiune + multi-sondă: pager numai în cazul unei defecțiuni consistente (de exemplu, HTTP și TLS simultan, ≥ 2 regiuni).
Debowns: N eșecuri consecutive sau fereastră de 2-3 minute înainte de paginare.

• L1: servicii de gardă (servicii de producție).
• L2 rețea/platformă/securitate bazată pe semnătura defectuoasă.
• Auto-închidere: după verificări de succes M stabile.
• Ore liniștite/concesiuni: pentru servicii interne non-critice - numai bilete, fără pager.

7) Pagina de stare și comunicare

Pagini de stare publice (client) și private (interne).
Incidente automate din sintetice + adnotări manuale.
Șabloane de mesaje: Detectate - Identificate - Impact - Workaround - ETA - Rezolvate - Post-Mordem.
Ferestre planificate: anunțați în avans, luați în considerare excepțiile separat de SLO.

8) Luarea în considerare a dependențelor externe

Pentru fiecare furnizor (plăți, KYC, corespondență, CDN, nori) - propriile controale din mai multe regiuni.
Rute failover: comutare automată la un furnizor alternativ folosind un semnal sintetic.
SLO-uri separate la nivelul furnizorului și e2e-SLO integrate.
Convin asupra SLA cu furnizorii (webhook-uri de stare, prioritate de sprijin).

9) Tablouri de bord și widget-uri cheie

Harta lumii cu starea verificărilor (după tipul: HTTP, DNS, TLS).
Cronologia incidentelor cu adnotări de lansare/pavilion.
P50/P95/P99 TTFB/TTL/latență pe regiuni.
Disponibilitatea prin cohortă (țară/furnizor/dispozitiv).
MTTR/MTBF, „minute inactive” și „arderea” tendințelor bugetului de disponibilitate pentru luna.
Top motive pentru eșecuri (TLS-expirare, DNS-rezolvare, 5xx, timeout).

10) Procesul de incidente (scenariu tranzitoriu)

1. Se declanșează alertă multi-regiune/multi-tip.
2. Ofițerul de serviciu confirmă, pornește înghețarea eliberărilor, anunță proprietarii.
3. Diagnosticare rapidă: starea DNS/TLS/CDN, cele mai recente versiuni, programul de eroare.
4. Bypass: schimbare de traseu, conținut folback/furnizor, permițând modul de degradare.
5. Recuperare: verificați dacă sintetica/traficul real este verde.
6. Comunicare pe pagina de stare; închiderea incidentului.
7. Elemente RCA și de acțiune: remedieri, teste, alerte, cărți de redare.

11) SLA/SLO Raportare

Rapoarte lunare: uptime pe service/regiune, minute de nefuncționare, MTTR, motive.
Comparație cu SLA: credite/compensații, dacă este cazul.
Recenzii trimestriale: actualizarea pragurilor, distribuția de sintetice, lista de dependențe.

12) Șabloane de inspecție (exemplu)

• Metodă: „GET/healthz/public” (fără secrete).
• Timeout: 2 s, reîncercare: 1.
• Succes: '2xx', antetul' X-App-Version' prezent, câmpul JSON '„stare”:” ok”'.

• Termen> 14 zile, lanț valabil, protocoale "TLS 1. 2 + ', SNI corect.

• Timpul de răspuns ≤ 100 ms, înregistrările A/AAAA sunt conform planului, fără SERVFAIL/REFUZAT.

• Webhook '/beat/{ service} 'la fiecare 5 minute; absența a 2 semnale la rând - alertă L2 (sarcini de fundal/ETL).

13) Lista de verificare a implementării

• Verificări externe multiregionale (HTTP/TCP/DNS/TLS/deep scripts).
• Mostre de pregătire/viață albă pentru orchestrator.
• Separarea căilor critice/non-critice, steaguri de degradare.
• Cvorum și debit în alerte, escaladare și auto-închidere.
• Pagini de stare publice și interne, șabloane de mesaje.
• Verificări separate și SLO pentru furnizorii externi + failover automat.
• Tablouri de bord: hartă, cronologie, percentile, minute inactive, MTTR/MTBF.
• Rapoarte regulate SLA/SLO și RCA post-incident.

14) Erori frecvente

Numai ping/port fără HTTP/conținut este verde atunci când nu este de fapt disponibil.
Un punct de monitorizare - concluzii fals pozitive/negative.
Fără control TLS/DNS - întreruperi bruște din cauza întârzierii/configurării greșite.
Zgomot suplimentar: alerte pentru defecțiuni unice din aceeași regiune/tip de verificare.
Nici o legătură cu modificările - nu există adnotări de versiuni și steaguri în tablouri de bord.
Dependențe neînregistrate - furnizorul de plăți a scăzut, iar statutul general este „verde”.

15) Linia de jos

Urmărirea uptime nu este doar despre "URL-uri de vârf. "Acesta este un sistem de controale sintetice din regiunile reale, alerte rezonabile fără zgomot, comunicare transparentă prin paginile de stare, contabilizarea dependențelor externe și raportarea strictă. Monitorizarea uptime construită corespunzător reduce MTTR, protejează SLA-urile și păstrează predictibilitatea experienței utilizatorului.