Tehnologie și infrastructură → Cloud Architecture și SLA
Arhitectura cloud și SLA
1) De ce SLA și cum să le gestionați
SLA (Service Level Agreement) - o promisiune externă către afaceri/parteneri cu privire la disponibilitatea, viteza și corectitudinea serviciului.
SLO (Service Level Obiectiv) - niveluri țintă interne pentru comenzi.
SLI (Service Level Indicator) - valori măsurabile pe baza cărora este evaluat SLO.
iGaming/fintech se caracterizează prin ferestre de vârf rigide (turnee, pariuri live, perioade de raportare, zile „salariale”), dependență puternică de furnizorii PSP/KYC și geografie. SLA-urile ar trebui să ia în considerare acest comportament, iar arhitectura ar trebui să ofere garanții nu numai medii, ci și percentile.
2) Terminologia de bază
Disponibilitate - Procentul de solicitări de succes pe interval.
Latență - P50/P95/P99 pentru operațiuni cheie.
Eroare - determinați exact (5xx, timeout, eroare de afaceri?).
RTO (Recovery Time Obiectiv) - cât timp este permis pentru recuperare.
Recovery Point Obiectiv (RPO) - cât de multe date pot fi pierdute într-un dezastru.
Eroare buget - 1 − SLO, „rezervă” pentru modificări și incidente.
3) Cadrul arhitecturii cloud pentru SLA
3. 1 Zonă multifuncţională (Multi-AZ)
Replicați starea (DB, cache, cozi) la cel puțin 2-3 AZ.
Standbys rece/cald, failover automat.
Echilibriști locali (L4/L7) cu controale de sănătate per-AZ.
3. 2 Multiregion
Active la activ: RTO/RPO scăzut, coerență și costuri mai dificile.
Activ-răspundere (cald/cald): mai ieftin, RTO mai mult, dar mai ușor de control al datelor.
Rutare geografică (GeoDNS/Anycast), izolare „rază de explozie”.
3. 3 Stocare și date
Baze de date tranzacționale: replicare sincronă în regiune, interregională asincronă.
Cache: replici transregionale, modul "citiri locale + încălzire async'.
Stocarea obiectelor: versioning, cicluri de viață, replicare transregională.
Cozi/Streaming: Clustere oglindă/Fluxuri multi-regiune.
3. 4 Izolație buclă
Separarea serviciilor critice (plăți/portofel) și sarcini analitice „grele”.
Rate-limite/cote între contururi, astfel încât rapoartele să nu „mănânce” prod.
4) modele de înaltă disponibilitate
Izolarea pereților etanși și a piscinei - Izolați conexiunea și bazinele de resurse.
Întrerupător de circuit + Timeouts - protecție împotriva înghețării integrărilor externe.
Idempotency - cereri repetate fără scrieri duble.
Degradarea grațioasă - atunci când degradat, dezactivați caracteristici non-fundamentale (avatare, filtre avansate).
Backpressure - controlați fluxul de intrare, nu permiteți cozi „la orizont”.
Haos/Injecție eșuată - planificate „eșecuri” pentru a testa ipoteze de fiabilitate.
5) DR (Dezastru de recuperare) Strategii
Alegere: plăți/portofel - minim Hot Standby; conținut/director - Warm; Rapoarte - Backup & Restaurare cu ferestre clare.
6) Despre SLI/SLO: cum se măsoară corect
6. 1 SLI în funcție de nivel
SLI client: end-to-end (inclusiv gateway și furnizori externi).
Service SLI: latență/erori de serviciu „pure”.
Business SLI: CR (registratsiya→depozit), T2W (time-to-wallet), rata PSP-declin.
6. 2 exemple SLO
Disponibilitate API de bază: ≥ 99. 95% în 30 de zile.
Latența plății: P95 ≤ 350 ms, P99 ≤ 700 ms.
Livrarea cârligelor web PSP: ≥ 99. 9% pentru 60 sec (cu retras).
Rapoarte de prospețime a datelor: ≤ 10 min lag în 95% din timp.
6. 3 Politica bugetară de eroare
50% din buget - pentru modificari (lansari/experimente), 50% - pentru incidente.
Buget de ardere → friza caracteristică, numai stabilizare.
7) Performanță și scalare
HPA/VPA cu semnale orientate spre SLO (nu numai CPU, ci și cozi/latență).
Scalare predictivă bazată pe programe și vârfuri istorice.
Piscine calde/conexiuni de preîncălzire la DB/PSP înainte de turnee.
Caching și edge - reduceți RTT, în special pentru cataloagele de jocuri și activele statice.
8) Nivelul rețelei și traficul global
Anycast/GeoDNS pentru a minimiza latența și localiza accidentele.
Politici de eșec: teste de sănătate ale regiunii, praguri, „lipiciozitate” cu TTL.
mTLS/WAF/Limită de rată la margine, protecție împotriva traficului bot.
Control de ieșire la PSP/KYC prin lista de permise și retrageri conștiente de SLA.
9) Date și consecvență
Selectați nivelul de consistență: strict (plăți) vs eventual (catalog/rating).
CQRS pentru descărcarea citirii și a verticalelor comenzilor critice.
Outbox/Inbox pentru „exact o dată” eveniment de livrare.
Migrări fără întreruperi: extindere-migrare-contract, intrare dublă în timpul schimbărilor MAJORE.
10) Observabilitate sub SLA
Urme prin gateway: corelarea 'trace _ id' cu versiunea partener/regiune/API.
Tablouri de bord SLO cu burn-rate, „vreme” pe regiuni și furnizor.
Alerte prin simptome, nu prin simptome proxy (nu CPU, ci P99/erori).
Sintetice: controale externe din țările țintă (TR, BR, EU...).
Audit și raportare: export SLI/SLO către portalul partenerilor.
11) Siguranță și conformitate
Segmentarea reţelei şi gestionarea secretă (KMS/Vault).
Criptare în timpul zborului/odihnei, tokenizare PAN/PII.
Politici de acces la rol pentru administratori/operatori.
Busteni imuabili (WORM) si retentie pentru audit.
Reglementare: stocarea în regiune, rapoarte, probabilitatea executării SLA.
12) FinOps: SLA ca driver de cost
Puneți prețurile pe deviațiile SLO: cât este + 0. 01% disponibilitate?
Profil ferestre de vârf, nu umfla puterea constantă.
Dimensionarea corectă și „la fața locului unde puteți” pentru sarcini de fundal.
Cotele și bugetele pentru contururi, nu permit degradarea „liberă”.
13) Testarea fiabilității
Sesiuni GameDay/Chaos: oprirea AZ/PSP, întârzieri la cozi, pauze BGP.
DR-drili: antrenament regulat de comutare regiuni cu obiective pentru RTO.
Încărcați și înmuiați: rulează lungi cu profiluri reale de pariuri/turnee.
Incidente replay: o bibliotecă de fișiere celebre și scripturi de redare.
14) Partea de proces SLA
Director SLO: proprietar, formulă, valori, surse, alerte.
Modificări prin RFC/ADR: evaluarea impactului asupra bugetului de eroare.
Post-mortems: îmbunătățirea arhitecturii și ranbooks, ajustarea SLO.
Comunicări cu partenerii: corespondență, pagină de stare, întreținere planificată.
15) Exemple SLI/SLO/Raport
15. 1 Formule
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 Core API SLO Set Exemplu
Disponibilitate (30 zile): 99. 95%
Punctul final P95 '/v2/payouts/create ': ≤ 350ms
Erori 5xx (rulare 1 oră): <0. 3%
Livrare prin broșură web ≤ 60 сек (P99): ≥ 99. 9%
RPO pentru portofel: ≤ 60 sec, RTO ≤ 5 min
15. 3 raport SLA (stoarcere)
Finalizat: 99. 97% (SLO 99. 95%) +
Încălcări: 2 episoade pe regiune BR din cauza temporizărilor PSP (cumulativ 8 minute).
Măsuri: a fost adăugată rutarea inteligentă prin coduri de eșec, creșterea rezervei calde de conexiuni la PSP-B.
16) Lista de verificare a implementării
1. Sunt definite căile critice ale utilizatorilor și SLI-urile corespunzătoare.
2. SLO pentru 30/90 zile + politica bugetului de eroare.
3. Multi-zonare și planul DR cu obiective RTO/RPO, exerciții regulate.
4. Sintetică din geo-țintă, tablouri de bord pe regiune/per-PSP.
5. Modele de stabilitate: întrerupător de circuit, backpressure, idempotency.
6. Politica de degradare și steaguri caracteristică pentru caracteristici cu handicap.
7. FinOps: bugete de contur, prognoza de vârf, piscine calde.
8. Securitate: segmentare, criptare, audit.
9. Documentație SLA pentru parteneri, proces de comunicare.
10. Retrospective și revizuiri SLO la fiecare 1-2 trimestre.
17) Anti-modele
Promite SLA fără SLI-uri măsurabile și tehnici de numărare transparente.
Contorizați disponibilitatea „la intrarea în serviciu”, ignorând gateway-ul/furnizorii.
Bazați-vă doar pe latența medie, ignorând cozile P99.
DR „pe hârtie”, lipsă de pregătire reală.
Resurse „eterne”, fără limite: un raport aduce în jos prod.
Se amestecă alimente și analize grele într-un singur cluster/bază de date.
18) Linia de jos
Arhitectura cloud pentru SLA este o combinație de modele tehnice (multi-AZ/regiune, izolare, date tolerante la erori), procese (SLO, buget de erori, DR-burghiu) și economie (FinOps). Dați-vă dreptul la eșecuri prezise: testați toleranța defectelor, măsurați prin percentile, limitați „raza explozivă” și comunicați deschis. Promisiunile SLA vor deveni apoi nu marketing, ci practică de inginerie gestionată.