Observabilitate și controlul stării

1) Obiective și principii

Scopul: Să înțelegem „ce se întâmplă” și „de ce” în timp real pentru a preveni incidentele și a recupera rapid fără a încălca SLO sau a umfla OPEX.
Principii: SLO-primul, „semnale de aur” (latență, trafic, erori, saturație), un singur standard de telemetrie (OpenTelemetry), detalii minim suficiente, explicabilitate, observabilitate cost-conștient.

2) Straturi de observabilitate

1. Valori: agregate pentru SLI/SLO, capacitate și tendințe (modele RED/USE).
2. Urme: lanțuri cauzale de cereri, plăți și tranzacții de joc.
3. Jurnale/evenimente: context detaliat și audit al acțiunilor operatorului/serviciului.
4. Sintetice (black-box): verificări externe API/web cale, PSP/KYC sănătate pings.
5. RUM (utilizator real): valori din prima linie (TTFB, LCP, JS erori), felii geo/dispozitiv.
6. Telemetrie de nivel scăzut: profilare eBPF/CPU/IO/allocare, întârzieri ale percentilei de rețea.

3) set SLI și semnale de aur

Latență: p50/p95/p99 pe căi critice (autentificare, depunere, rată, retragere).
Erori: cota de 5xx/timeout/declin (normalizată de către furnizori/bănci).

Trafic/Transfer: RPS/TPS, sesiuni active, evenimente/sec

Saturație: încărcare CPU/RAM/IO, adâncime de coadă, utilizare în piscină, decalaj de replicare.
SLI de afaceri: depozite de succes/% rate pe fereastră, abateri de conversie KYC/PSP, cota de chargeback.

4) Arhitectura de telemetrie

Injectie standardizata: OpenTelemetry SDK/colector → normalizare, prelevare de probe, filtre de confidentialitate → stocare (TSDB, urme, busteni).
Corelație: trace-id/span-id în bușteni și metrici (exemplare); id-ul unic de corelare pentru plăți/evenimente de jocuri de noroc.
Topologie: grafic de servicii, furnizori externi dependenți cu SLI-uri live.
Managementul costurilor: niveluri de retenție, agregări, eșantionare dinamică, clase de stocare "la cald'/" la rece".

5) Metrica: Design și cardinalitate

Reguli: un număr mic de etichete, o interdicție asupra cardinalității ridicate (userId, sessionId) în seria de timp; astfel de detalii - numai în rute/jurnale.
RED/UTILIZARE: Requests-Errors-Duration для API; Erori de utilizare-saturație pentru infrastructură.
Exemplare: legarea percentilelor înalte de exemple specifice de urme.
Valori de afaceri: $/RPS, PSP bank/GEO de conversie, furnizor de reziliență.

6) Urmărirea: adâncime și eșantionare

Context: aruncăm contextul urmelor prin intermediul brokerilor → → API din față → procesoare → baze de date/PSP.
Eșantionare: de bază 1-10%, cu anomalii - creștere dinamică în conformitate cu regulile (pe bază de coadă).
Focus: fluxul de plată (init → auth → capture/settle), tranzacțiile de joc (pariu → decontare), KYC (init → verify).
Adnotări: codul PSP de răspuns, banca-BIN/emitent-categorie, regiune, rata de risc.

7) Jurnale și audituri

Jurnale structurate: JSON, nivel cu profil (INFO pe prod, DEBUG în depanare).
Filtre de confidențialitate: mascare PII, interzicerea documentelor KYC brute în jurnale.
Evenimente de audit: cine/ce/unde/când/de ce, ID-ul biletului, valori pre/post pentru tranzacții cu risc ridicat (bonusuri, limite, rutare PSP).
Ineligibilitate: WORM/imuabil, semnătură, păstrare prin politică.

8) Controlul stării (sănătate)

Liveness/Readiness/Startup: eșantioane corecte (nu verificați dependențele externe în viață).
Mod degradat: steaguri explicite de degradare a serviciilor, astfel încât alertele și pagina de stare să fie consecvente.
Sănătate bugetară: buget de eroare cu rată de ardere (fereastră rapidă/lentă), spațiu de trecere prin resurse și cozi.

9) Alertare și avertizare timpurie

Alerte SLO: în funcție de bugetul de eroare (4 ore și 1 oră ferestre) în loc de „brut” p95.
Anomalii: detectoare STL/IQR/online pentru explozii 5xx, autorizații PSP scad într-un anumit GEO/bancă.
Rădăcină-cauza indicii: asociem alerte cu cele mai recente versiuni/phicheflags/planificate de lucru.
Runbooks: fiecare alertă are legături către un playbook, grafice, „verificări rapide”.

10) Tablouri de bord (cine vede ce)

: uptime/SLO, burn-rate, depozite/rate de succes, starea furnizorului, prognoza de capacitate și $/RPS.
SRE/platform: RED/USE by service, cozi/lag, pool-usage, replicare lag, CDN/WAF, profile eBPF.
Plăți/Risc: succesul autorizațiilor PSP/bank/GEO, scăderi soft/hard, timp KYC, semnale timpurii de încărcare.
Suport/CS: panoul de stare a incidentului, SLA-urile de răspuns, macrocomenzile de întrebări frecvente.

11) FinOps-Observabilitate

Retenție: 7-14 zile pentru piese „brute”, unități mai lungi; selectiv - servicii calde.
Eșantionare/agregare: eșantionare dinamică prin anomalie, subeșantionare a seriei vechi.
Politici de ingerare: tăiați zgomotul (ping-uri de sănătate, bușteni redundanți), cote pentru metrici de înaltă cardinalitate.
Costul KPI: $/GB ingera, $/trace, $/SLI tablou de bord; recenzii periodice ale consumatorilor de top.

12) Confidențialitate și conformitate

PII/Finante: mascare, tokenizare, minimizare date in telemetrie.
Geo-localizare: depozitare și prelucrare în funcție de jurisdicție; export jurnal - numai prin fluxul de lucru aprobat cu criptare și TTL.
Audit acces la telemetrie: RBAC/ABAC, SoD pentru încărcări, cerere jurnal.

13) Integrarea cu gestionarea incidentelor și eliberări

Pagina de stare: actualizare automată a fluxului de pe cardul incident.
Poarta de lansare: analiză canar SLI, eliberare automată la arde-rate> prag.
Post-mortem: cronologie din trasee/jurnale, SLI-uri reale și ferestre de încălcare.

14) Practica de implementare (8-12 săptămâni)

Ned. 1-2: inventarul căilor critice și SLI; selecție stivă (OTel, TSDB, busteni, urme); hartă dependență.
Ned. 3-4: Implementarea OTel în 3-5 servicii cheie (autentificare/depunere/rată), RED/UTILIZARE de bază, contextul urmelor în jurnale.
Ned. 5-6: alerte SLO și burn-rate; sintetice în conformitate cu PSP/KYC; primele cărți de alergare; ROM către web/mobil.
Ned. 7-8: eșantionare dinamică, exemplare, harta serviciilor; Tablouri de bord /SRE/Plăți.
Ned. 9-10: eBPF/profilare la cald; filtre de confidențialitate; cote/retenții.
Ned. 11-12: porți de lansare și auto-rollback prin SLI; Integrarea cu pagina de stare a învățăturilor tabletop.

15) Modele artefact

SLO-card al serviciului: SLI, goluri, ferestre, bugetul de eroare, alerte, proprietari.
Specificații de alertă: metric/stare, praguri, deadup/silence, destinatari, runbook.
Specificații tablou de bord: audiență, întrebări, 6-8 widget-uri, sursă de date, rata de reîmprospătare.
Politica de telemetrie: ce domenii sunt permise/interzise, retenție, mascare, export.
Cost Review Pack: Top Series/Jurnal Streams, Oferta de eșantionare/TTL, Economii așteptate.

16) Funcția de observabilitate KPI

MTTA/MTTR (îmbunătățire după implementarea alertării SLO).
% din incidentele detectate de sintetice/SLI înainte de reclamațiile utilizatorilor.
Proporția de eliberări care au trecut poarta prin SLI fără intervenție manuală.
Scăderea $/SPR per telemetrie menținând în același timp diagnosticarea.
Acoperirea traseelor critice (> 90%).
Acuratețea corelației „actualizare de stare ↔ SLI-uri reale”.

17) Antipattern

„Log totul” → o explozie de costuri și zgomot.
Alerte privind valorile „brute” în loc de SLO/burn-rate → pager-oboseală.
Cardinalitate ridicată a metricii (userId) → furtuni TSDB.
Traseele fără context de afaceri (PSP/bank/GEO) nu → o perspectivă.
Nici o asociere de observabilitate cu eliberări/incidente → telemetrie trăiește separat.

Total

Controlul observabilității și al condițiilor nu este un set de instrumente, ci un sistem gestionat: corectă SLI/SLO → telemetrie standardizată și corelație → alertă SLO și runbooks → integrare cu versiuni și comunicare de stare → operare conștientă de costuri și confidențialitate. O astfel de buclă oferă semnale timpurii, RCA rapid și reziliență de afaceri chiar și în vârfuri extreme de trafic.