Operațiuni și → Management Audit Metrics și SLAs

Măsurători de audit și SLAs

1) De ce aveți nevoie de ea

Dacă valorile sunt greșite - deciziile vor fi greșite, SLA-urile vor fi încălcate „pe hârtie” sau invers pentru a ascunde problemele. Măsurătorile de audit și SLA-urile asigură faptul că promisiunile făcute utilizatorilor și partenerilor sunt comparabile, fiabile și sigure din punct de vedere juridic.

• Furnizați o singură „sursă de adevăr” (SSOT) și calcule reproductibile.
• Reduceți discrepanțele dintre tablouri de bord/rapoarte/facturare.
• Asigurați-SLA bazate pe dovezi.
• Detectați degradarea în măsurători încă din timpul serviciilor.

2) Concepte de bază și limitele responsabilității

Metric: cantitate măsurată (SPR, p95, CR, GGR, Rata de succes).
KPI/OKR: ținte la care sunt legate valorile.
SLO: target quality of service (de exemplu, "p99 ≤ 400 ms 99. 9% din timp").
SLA: promisiune externă; semnificativă din punct de vedere juridic, bazată pe SLO.
OLA: acord intern între echipe/furnizori, sprijină SLA.
SSOT: sistem/stocare ale cărui date sunt considerate o referință pentru raportare.

3) Taxonomia metricii (straturi)

1. Infrastructură: CPU/Memory/IO/Net, păstăi/noduri, HPA/VPA.
2. Platforma: cozi/fluxuri (lag, throughput), DB/caches (conexiuni, lovit), API (p95/p99, 5xx).
3. Fluxuri de afaceri: depozite/retrageri, pariuri, lansări de jocuri, autorizații, KYC.
4. Produs/marketing: conversii, ARPPU/LTV, campanii.
5. Calitatea proceselor: MTTA/MTTR, modificarea ratei de eșec, verificarea acoperirii listei.

Regulă: Fiecare metrică trebuie să aibă un strat, proprietar și formulă.

4) Surse de date și „adevărat”

Telemetrie online: Prometheus/OTel, busteni (ELK/ClickHouse), urme.
Evenimente și contabilitate: Kafka/Outbox, DWH/marte de date (BigQuery/ClickHouse).
Artefacte manuale: post-mortem, bilete, registre incidente.
Registre externe: rapoarte furnizor (PSP/KYC/studios), facturare.

Soluționarea conflictelor: în cazul discrepanțelor „online vs DWH”, se aplică regulamentul prioritar (de exemplu, pentru SLA - agregate din DWH cu trasabilitatea sursei).

5) Procesul de audit metric (bucla de control)

1. Inventar: catalog metrici/SLO/SLA (nume, proprietar, strat, formulă, sursă, frecvență de calcul).
2. Verificarea formulei: reconcilierea interogărilor SQL/promo cu definiția (testele unitare de calcule).
3. Eșantionare și reverificare: eveniment de eșantionare/linii de jurnal și reconciliere manuală.
4. Cartografierea conturului: compararea tablourilor de bord online și a rapoartelor DWH.
5. Controlul schimbării: revizuire formulă pentru scheme/versiuni logice.
6. Audit SLA: verificarea corectitudinii ansamblurilor și a excepțiilor (întreținere planificată, forță majoră).
7. Raport și îmbunătățiri: o listă de discrepanțe detectate și remedieri cu termene limită.

6) Definiții și formule (eșantioane)

• 'succes = cereri - (5xx + timeout + circuit_open)'
• 'success _ rate = succes/requests'

• SSOT înregistrează o singură definiție a ferestrei (rulare 5m/1h) și agregare (HDR/TDiest).

• 'SLO _ availability _ month = (uptime - admisibil _ exceptions )/total _ time'

• 'SLA _ month = 99. 90% uptime prin fereastra UTC, cu excepția ferestrelor planificate (notificare T-48), accidente dovedibile la operatorii de tranzit (documente) "

7) Calitatea datelor: verificări și alerte

• Полнота (exhaustivitate): 'received _ events/ expected_events ≥ 0. 99`.
• Actualitatea: lag de încărcare ≤ N minute.
• Unicitate: fără chei duplicat (idempotency-key).
• consistență-Sume/valută/caractere.
• Liniaritate - Contoarele nu sunt „laminate înapoi”.

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Audit SLA/OLA: Metodologie

1. Colectați un calendar de excepții: ferestre planificate, degradarea convenită, acte de vânzători.
2. Calculul timpului de funcționare: în funcție de un singur fus orar, bazat pe SSOT.
3. Reconcilierea cu incidentele: cronologie, bilete, post-mortems.
4. Atribuire: defecțiuni proprii, furnizor, tranzit, DDoS, întreținere de rutină.
5. Perimetrul SLA: experiența utilizatorului (E2E) vs un API specific.
6. Raportare: raport lunar/trimestrial: efectiv, abateri, compensații (dacă este cazul), măsuri corective.

9) Verificarea reproductibilității calculului

Formula versioning: Git depozit cu specificații SQL/PromQL/dock.
Teste unitare de măsurare: pe date sintetice (cazuri de margine: lacune, duplicate, limite de dată).
Linia de date: de la tabloul de bord înapoi la tabelele sursă și evenimente.
Instantanee: înghețarea datelor pentru tăiere, astfel încât re-calculele să fie comparabile.

10) Prelevarea de probe

Zilnic: 10-20 evenimente după fluxuri cheie (depozit/rată/CCL) - verificarea manuală a ↔ de urmărire DWH.
Săptămânal: 1% eșantion pentru a compara „online vs DWH” între agregate.
Lunar: set de incidente cu efect SLA - reconstrucție detaliată.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Auditul tablourilor de bord și al alertelor

Dicționar unificat de valori: glosar chiar pe tabloul de bord.
Adnotări ale eliberărilor/evenimentelor: pentru a vedea cauza abaterilor.
Comparație pre/post: panouri automate de regresie.
Duplicate/discrepanțe: identificarea „două p99s diferite” - formule de editare/ferestre.
Disponibilitatea panoului: drepturi, rezervă, control link/versiune.

12) Managementul schimbărilor metrice

Proces RFC - Schimbare formulă/fereastră/sursă - prin RFC cu SLA/Evaluare a impactului de raportare

Migrarea „extindeți → migrați → contract”: păstrați temporar ambele versiuni, comparați, apoi opriți-l pe cel vechi.
Comunicații: notificați produsul/afacerea în avans cu privire la schimbările de valori „în conformitate cu noua metodă”.

13) Specificul iGaming/fintech

Vârfurile cererii: valorile trebuie să reziste la sarcini explozive (agregările nu se „lipesc”).
Furnizori: SLA depinde de vânzătorii OLA → își stochează rapoartele, statusurile incidentelor și cotele.
Cost: 'cost _ per _ 1k _ calls' și' costul succesului 'sunt panouri obligatorii.
Antifraudă/risc: sensibilitate la întârzieri și „rezultate fals pozitive” ale măsurătorilor.

14) Tablouri de bord audit (set minim)

Metrics Health: integralitate/actualitate/duplicate, ingera-lag, ошибки ETL.
SLO/SLA Dovezi: SLO calculat, SLA efectiv, excepții, referințe la incidente/acte.
Online vs DWH Comparați: Rata de p95/p99/Success, abateri și tendințe.
Furnizor SLA: uptime/cote/timeout/cost de către furnizor.
Release Impact: regresia metricii după calcule/includerea caracteristicilor.

15) Lista de verificare a auditului (operațional)

• Directorul metric/SLO/SLA cu proprietari și formule este actualizat.
• SSOT este definit pentru fiecare raport/panou.
• Testele unitare ale formulelor sunt verzi, conductele de calcul sunt documentate.
• Alertele privind calitatea datelor sunt active (completitudine/cronologie/duplicate).
• Discrepanța „Online vs DWH” ≤ un prag acceptabil (de exemplu, ≤2%).
• Excepțiile agreate de SLA sunt documentate și atașate raportului.
• Au fost prelevate probe de control și au fost întocmite certificate.
• Toate modificările formulei au trecut RFC și migrare.

16) Exemple (fragmente)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-modele

Două formule metrice diferite „la fel” pe panouri diferite.
Schimbarea metricii fără migrare și notificare - „salturi” în OKR/SLA.
Raportează în Excel local ca „adevărat” (non-reproductibil).
Amestecarea fusurilor orare și a calendarelor în calculele SLA.
Excepțiile SLA nu sunt documentate.
Nu există alerte privind calitatea măsurătorilor.

18) Maturitatea măsurării KPI

Drift Rate Online↔DWH (țintă ≤2%).
Metrics Health Uptime.
Formula Time-to-Fix.
Rata litigiilor SLA.
Acoperire SLO/SLA (proporția de căi critice cu SLO/SLA descrise formal).

19) Roluri și responsabilități

Proprietarul metric/serviciu: formulă, sursă, tablou de bord, alerte.
Observabilitate/SRE: SSOT/platformă, teste cu formulă, alerte privind calitatea datelor.
Date/BI: DWH, reproducerea raportului, descendență.
Avocați/manageri parteneri: acorduri și excepții SLA.
Manager de incidente: Atribuirea și conectarea incidentelor SLA.

20) Pornire rapidă (30 zile)

Săptămâna 1: Metrica inventarului/SLO/SLA și proprietarii; atribuie un SSOT.
Săptămâna 2: Includeți alerte privind calitatea datelor și panoul „Online vs DWH”.
Săptămâna 3: efectuați probe de control, aliniați fereastra p95/p99.
Săptămâna 4: formalizați procesul RFC pentru formule, pregătiți un raport lunar SLA cu atașamente.

21) ÎNTREBĂRI FRECVENTE

Î: Ce este SSOT pentru SLA?
R: Stocare cu calcule reproductibile (DWH) și descendență completă; panouri online - pentru control operațional, nu pentru acte juridice.

Î: Cum să se ocupe de "două p99s'?
R: Fixați metoda fereastră/agregare în directorul metric, migrați panouri, adăugați alertă în derivă.

Î: Cum să luați în considerare lucrările planificate?
R: Mențineți un calendar al excepțiilor și deduceți-le automat din SLA în conformitate cu regulile contractului; stoca artefacte de confirmare.