KPI-uri de infrastructură și timpul de funcționare

De ce ai nevoie de ea?

KPI-urile de infrastructură transformă „sentimentele” privind stabilitatea în obiective măsurabile, gestionează riscul și concentrarea muncii. Valorile corecte leagă SLI-urile tehnice de rezultatele afacerii (conversie, Time-to-Wallet, LTV) și vă permit să planificați dezvoltarea, încărcarea și cota de inovație vs fiabilitate.

Concepte de bază: SLI, SLO, SLA și bugetul de eroare

SLI (Service Level Indicator) - indicator de calitate măsurat: proporția de solicitări de succes, p95 latență, uptime pe interval.
SLO (Service Level Obiectiv) - obiectiv SLI (de exemplu, "succes ≥ 99. 9% în 30 de zile").
SLA (Acord) - promisiune externă cu penalități/credite. Întotdeauna derivat din, dar nu egal cu, SLO.
Eroare la buget = '1 − SLO'. Aceasta este rata maximă permisă de eșec pe fereastră de măsurare. Folosit pentru a lua decizii cu privire la eliberări riscante și experimente.

• Disponibilitate SLO 99. 95% în 30 de zile → buget de eroare 0. 05% ≈ 21. 6 minute de „eşec” într-o lună calendaristică.

Patru semnale de aur și suplimentare

1. Latență (p50/p90/p95/p99, coada este mai importantă decât media).
2. Erori (erori 5xx/timeout/business).
3. Trafic/debit (RPS/QPS, MBps).
4. Saturație (CPU/RAM/IO/FD/conexiuni/GC/cote).
Suplimentar: pornire la rece, cozi/restanțe, timp de implementare, conformitate SLO.

Model SLI pentru diferite tipuri de servicii

HTTP/API

Disponibilitate: '(succes 2xx/3xx − erori logice )/( toate cererile)'

Latență: „p95” pentru interogări de succes; ţintă pe rute fierbinţi.
Calitate: proporția cererilor cu „audiență/domeniu” corectă (fără erori authZ).

Cozi/asincrone

Timpul de procesare a mesajelor: p95 de la un capăt la altul ≤ N secunde

Restanţe: mediană <X, coada p99 <Y.
Eroare de livrare: ≤ Z ppm.

DB/Cache

Latența operațiunii: p95 obține/pune/comite.
Saturație: utilizare piscină conexiune, cache hit-raport.
Erori: timeout, blocaje, furtuni de evacuare.

CDN/Static

Hit Ratio: nivelul țintă ≥; degradarea → creșterea încărcăturii la origine.
Disponibilitate POP: Anycast, eșecurile sunt compensate de vecini.

Plăți (Business SLI)

Timp-la-Wallet p95, depozit/succes de ieșire%, rata de eșec PSP.

Calcularea disponibilității și a timpului de funcționare

Disponibilitatea serviciului = 'cereri de succes/toate cererile' (preferabil nu 'minute de uptime').
O alternativă pentru nodurile de infrastructură este „timpul verde/timpul de fereastră”.
Fereastra calendarului: 28-31 zile, fereastra glisanta: ultimele 30/90 zile.
Ore de lucru/ferestre critice: pentru backoffice poate fi considerat uptime în conformitate cu programul (de exemplu, 08: 00-22: 00 ora locală).

• „Disponibilitate (A) ≈ Av (B) × Av (C) × Av (A 'B, C)” - este important să se stabilească SLO-uri la limitele.

Exemplu kit SLO (eșantion)

Gateway API: ≥ 99 disponibil. 95 %/30d; p95 latență ≤ 120 ms; eroare ≤ 0. 2%.
Checkout/Plăți: succes depozit ≥ 98. 5 %/30d; Time-to-Wallet p95 ≤ 90 с; PSP-timeout ≤ 0. 3%.
Baza de date: p95 citit ≤ 10 ms; p95 scrie ≤ 25ms; replica lag p95 ≤ 150 мс.
Cache: raportul lovit ≥ 85%; furtuni de evacuare = 0/30д.
Plăți: procesare p95 ≤ 5 min; fraud-falls-pozitiv ≤ 0. 3%.

Bugetul de eroare și gestionarea schimbărilor

Dacă bugetul de eroare este epuizat cu 50% + înainte de mijlocul ferestrei, se introduce o „înghețare” a caracteristicilor/eliberărilor, accentul se pune pe stabilizare.
Dacă bugetul este cheltuit încet, puteți accelera experimentele/canarii.
Conectați consumul bugetar la versiuni/incidente specifice prin intermediul 'release _ id'.

Alertă: cum să nu „suni noaptea” în zadar

Alerte numai pentru degradarea SLO și simptome vitale, nu pentru fiecare metrică.
Rată multi-fereastră, multi-burn: fereastră scurtă (5-15 min) + fereastră lungă (1-6 h).
Exemplu: „Rata de ardere 14 × în 5 minute ȘI 6 × într-o oră” → pagina de apel.
Ore liniștite pentru semnale non-P1; rutare de proprietate.

Tablouri de bord și practici de vizualizare

Panoul SLO: conformitatea serviciului, bugetul rămas, hărțile de dependență.
Panou latență: p50/p90/p95/p99, descompunere pe rute/chiriași/țări/ASN.
Panoul de erori: coduri/motive, corelație cu versiuni/steaguri de caracteristici.
Panou de capacitate: CPU/RAM/IO/rețea/FD/conexiuni, tendințe și previziuni.
Panoul de afaceri: Conversie, Timp-la-portofel, Depozite/Retrageri, Impactul protecțiilor (WAF/Anti-Bots).

Incidente, MTTR și post-mortem

• MTTD (detectare), MTTA (acceptare), MTTR/MTTC (recuperare/izolare),% incidente fără RCA la timp.
• Playbooks: cine escaladează, cum să activați steaguri/blocuri de caracteristici, cum să rulați înapoi eliberarea, comunicarea cu afacerea.
• Postmortem (fără vină): fapte, linie de timp, cauze profunde (acele/procese), acțiuni: imediate/pe termen lung, teste de regresie, efect asupra SLO.

Performanță, saturație și degradare

Headroom: resursa țintă headroom (de ex. CPU <70% p95, RAM <75% p95).
Căi fierbinți: profilarea rutelor critice; „p99” este mai important decât media.
Moduri de degradare: cache-only, read-only, drop-slefuire a cererilor neimportante, „limita ratei „/cota.

Formule și exemple de calcule

1) Disponibilitate la cerere

availability = (total_requests - error_requests) / total_requests

unde 'error _ requires' = 5xx + timeout + erori de afaceri (configurabil).

2) Bugetul de eroare (minute)

error_budget_minutes = window_minutes (1 - SLO)

Exemplu: 30 zile (43.200 min), SLO 99. 95% → 21. 6 min.

3) Rata de ardere

burn_rate = observed_error_ratio / (1 - SLO)

Dacă SLO 99. 9% (buget 0. 1%) și eroare 1% → burn_rate = 10 ×.

4) Disponibilitate compusă

A_total ≈ A_gw × A_auth × A_db × A_psp

Căderile mici se înmulțesc a lovit totalul A.

Politici de măsurare și excepție

Ferestre neprogramate (incidente) - luate în considerare.
ferestre de întreținere planificate - luate în considerare numai în cazul în care SLA este prescris astfel; pentru SLO-uri de multe ori nu sunt scăzute (sau marcate separat ca „planificat _ downtime”).
Sintetice vs utilizatori reali: este util să aveți ambele canale (RUM + verificări sintetice).

Exemple de artefacte

KQL/PromQL (idei)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (SLI de afaceri de plată)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Gestionați dependențele și cascadele

Contracte SLO între echipe: gateway↔auth↔wallet↔PSP.
Politici de degradare: atunci când dependența scade, serviciul intră în „mod simplificat”.
Caracteristici: dezactivarea funcțiilor non-critice, „eliberare gri” pentru a reduce cozile de latență.

Planificarea și previziunile capacității

Schomes. RPS/MBps prognozate de tendințe și evenimente (turnee, meciuri, promoții).
Testarea încărcării prin „căi de aur”, teste separate pentru PSP/plăți.
Stocul la vârf: factorul țintă 1. 3 × -2. 0 × din sarcina preconizată.

Lista de verificare a implementării SLO/KPI

1. Identificați căile critice ale utilizatorilor și negociați SLI „din perspectiva clientului”.
2. Selectați obiectivele SLO și fereastra (30/90 zile); calculează bugetul de eroare.
3. Construiți colectarea metrică în gateway-uri/servicii, normalizați codurile/motivele.
4. Configurați alerte burn-rate (fereastră scurtă + lungă), rutare și de gardă.
5. Vizualizați conformitatea SLO, asociați-vă cu versiuni/steaguri de caracteristici.
6. Crearea unui buget împotriva politicii de schimbare și a unui proces de înghețare.
7. Retrospective și RCA pe fiecare exces, teste de regresie.
8. Revizuirea SLO trimestrială pentru utilizarea reală a bugetului și obiectivele de afaceri.

Greșeli comune

Măsurați „uptime by ping”, ignorând erorile aplicației.
SLO-urile sunt stabilite „în rezervă” (99. 999%), dar de neatins și nu rezolvă nimic.
Alerte pe valori de nivel scăzut în loc de simptome de utilizator.
Nu există nici o hartă de dependență → nu este clar unde arde.
Nu există nicio legătură între SLO și versiuni → nu este clar cine a „mâncat” bugetul.
Ignorați cozile p99 → medii bune, dar utilizatori VIP UX răi.

iGaming/fintech specific

Vârfuri programate: meciuri/evenimente/promoții - creșterea capacității în avans, încălzirea memoriei cache/CDN, includ profiluri limită speciale.
Business SLI: Time-to-Wallet, succes de depunere/retragere, „viteza de plată” p95; la rădăcina tablourilor de bord.
PSP/parteneri: SLO/tablouri de bord individuale de către furnizor, comutare automată a traseului.
Antibot/antifraudă: nu ar trebui să existe buget pentru erori - „blocuri legitime” separate de „erori tehnice”.
Reglementare: stocare jurnal, reproductibilitatea calculelor SLO/SLA, rapoarte incidente.

ÎNTREBĂRI FRECVENTE

Trebuie să scad munca planificată de la SLO?
De obicei, nu: SLO reflectă experiența experimentată de utilizator. Puteți specifica excepții pentru SLA.

De ce p95, nu medie?
Cel din mijloc maschează cozile; UX definesc cozi (p95/p99).

Pot avea un SLO pentru întregul produs?
Aveți nevoie de un arbore SLO: agregați după produs și copii după căi/componente critice.

Total

Un sistem KPI puternic de infrastructură este SLI-urile personalizate, SLO-urile realiste, bugetul de eroare ca pârghie de control al schimbării, disciplina inteligentă de alertă și incidente și RCA-urile. Conectați indicatorii tehnici cu măsurătorile de afaceri, automatizați colectarea și vizualizarea - iar infrastructura va deveni previzibilă, iar timpul de funcționare va fi controlat chiar și în scenariile de vârf.