Disponibilitate ridicată и SLA
Disponibilitate ridicată и SLA
1) Termeni și conexiune cu afacerea
SLI (Service Level Indicator) - indicator de serviciu măsurat (de exemplu, proporția de solicitări de succes 2xx/3xx ≤ T ms).
SLO (Service Level Obiectiv) - țintă valoare SLI (ex. "99. 95% din cereri ≤ 300 ms).
SLA (Service Level Agreement) - obligația contractuală față de client (amenzi/credite în caz de încălcare).
HA (High Availability) - măsuri arhitecturale și operaționale care vă permit să efectuați SLO/SLA.
Principiu: SLA se bazează pe SLO și SLO se bazează pe SLI-urile observate. Nu poţi promite în SLA ceea ce nu măsori.
2) „Nouă” și matematica accesibilității
Disponibilitate pe perioadă = 'work _ time/total _ time'. Criterii de referință (pe an):Compoziția disponibilității
Lanț secvențial (dependențe de cale roșie): 'A _ total = Π A_i' (fiecare componentă reduce totalul).
Noduri paralele de active: 'A _ total = 1 − Π (1 − A_i)' (rezerva crește total).
3) Ce anume să măsurați (SLI corect)
Vizualizare utilizator: finalizarea cu succes a operațiunilor cheie (conectare, depozit, check-out) și latența lor p99.
Coridor de timp: agregat prin ferestre glisante (5/30/60 min) și pe regiuni.
Excepții: „ferestrele programate” sunt numărate în SLO-uri și în SLA-uri numai dacă contractul spune acest lucru.
- Disponibilitate: rata de succes ≤ T.
- Calitate: p95/p99 latență.
- Compozit: "ponderea depozitelor de succes ≤ 5 s'.
4) Bugetul de eroare și rata de ardere
Eroare Buget = '1 − SLO'. Pentru 99. 95% fereastră lunară dă 0. 05% erori/downtime.
Rata de ardere: viteza consumului bugetar (de ex. 4 × înseamnă că în 6 ore mănânci limita zilnică).
Politică: cu ardere rapidă - stop releases, se concentreze pe stabilizare, caracteristică-congela.
5) Arhitectura HA: Nod la regiune
5. 1 Nod/Service
N + 1: cel puțin o replică redundantă (Implementare ≥ 2, PDB, anti-afinitate).
Izolarea resurselor: limite CPU/RAM/IO, priorități (PriorityClass).
Închidere/scurgere grațioasă: nici o pauză de cerere la repornire.
5. 2 Zonă/Regiune
Multi-AZ: replici în diferite zone, echilibrare cross-zone, putere independentă/rețea.
Multi-regiune: active-active (mai greu: date/coerență) sau active-pasiv (mai simplu: peste RPO).
Date: CP pentru bani/comenzi (cvorum/RAFT), CE/AP pentru cache/storefronts.
5. 3 Strat de rețea și perimetru
L7-LB с controale de sănătate, încercați din nou/timeout/circuit-breaking.
GSLB/DNS/Anycast pentru trafic global, scurt TTL.
Control de ieșire și canale tolerante la erori la PSP/furnizori externi.
6) Degradarea în loc să cadă
Caracteristică kill-switch (feature flags): dezactivați non-critic, salvați „calea roșie”.
Trecerea la căi simplificate: sincron → asincron/coadă, „acceptat pentru procesare”.
Rata-limită/cote: este mai bine pentru a limita traficul decât picătură toată lumea.
Moduri vechi: oferiți date cache/statice atunci când originea nu este disponibilă.
7) Gestionarea constrângerilor
Harta serviciului: directă/tranzitivă, critică, SLO a fiecăruia.
Link-uri vulnerabile: furnizor extern fără SLA - se transformă într-un cache/coadă/duplicat.
Izolarea pereților etanși: diferite piscine de conectare/cote pentru rute lente.
Timeouts> Retries: intervale scurte de timp, maxim 1 retray pentru operațiuni idempotente.
8) Operațiuni și modificări
Managementul schimbării: lansări prin canari/albastru-verde, porți SLO, rollback automat.
Ferestre programate: standardizare - lungime, frecvență, comunicații.
Incidente: roluri (IC/Comms/Tech/DB), runbook 'și, post-mortems cu acțiuni corective.
Evenimente de securitate: dacă sunt compromise, „modul de panică” (citire/token-uri/rotație/blocare).
9) Observabilitate și alertare
Modelul RED (Rata, Erori, Durata) pentru fiecare traseu.
Tablouri de bord SLI: disponibilitate/latență pe regiuni și pe segmentul clienților.
Alerte Burn-rate: rapid (1h, 14. 4 ×), lent (6h, 2 ×) - semnal înainte de eșecul SLO.
Comutatoare exemplare de la valori la aliniamente trace_id.
Sintetice: eșantioane din puncte externe (perimetru, flux de plată).
10) Teste de toleranță la erori
Zile de joc: scenarii pentru dezactivarea AZ/regiuni, degradarea bazei de date/cache, eșecul furnizorilor externi.
Instrumente haos: folt-uri de rețea (latență/pierdere), kill-pod-uri, suprasarcină CPU/IO.
DR-burghiu: dezvoltarea RTO/RPO pentru sistemele de Tier-0 (a se vedea „Backup-uri și DR”).
11) SLA Design
Definiția „disponibilității”: ceea ce contează ca incident (5xx, timp> T, erori de domeniu).
Fereastra de calcul: luna/trimestru; includerea/excluderea activităților planificate.
Credite/penalități: scară (ex. 99. 9–99. 99% - X%, mai mic - Y%).
Responsabilități clienți: integrare, retribuții în limite rezonabile, limite.
Notificări și procedura de clymes: termeni, format, baza de probe (busteni/metrici).
Forța majoră: formulare juridică și limite.
- „Disponibilitatea API prin SLI” de succes ≤ 500 ms' este de cel puțin 99. 95% pe lună calendaristică. Ferestrele programate (până la 60 min/lună anunțate în 48 de ore) sunt excluse. La 99 de ani. 90–99. 95% - împrumut 5%; 99. 80–99. 90% — 10%; <99. 80% — 25%.»
12) Economie de nouari
Fiecare „nouă” suplimentar crește costurile nu liniar (regiuni duble, cvorumuri, duplicate ale furnizorilor, 24 × 7). Utilizați SLO pe niveluri:- Tier-0 (bani/ordine): 99. 95–99. 99%, multi-AZ, DR gata.
- Nivelul 1 (caracteristici de bază): 99. 9–99. 95%, multi-AZ.
- Tier-2 (non-critică): 99. 5–99. 9%, degradarea/oprirea este permisă pentru incidente.
13) Modele HA după strat
Perimetru: CDN/edge, multi-CDN sau GSLB, WAF, rate-limită.
Echilibrare: L7 cu outlier-ejection, timeout/retrays, lipicios/consistent-hash.
Aplicații: scară orizontală, pregătire/viață, PDB, răspândire topologică.
Date: leader + replici, cvorum pentru CP, L2 cache, idempotency, PITR.
Cozi: oglindire/multicluster, dedup, DLQ.
Secrete/configurații: GitOps, instantanee atomice, rollback.
14) Anti-modele
SLA fără instrumente de măsurare și sintetice externe.
Zonă unică/cluster ca SPOF.
Retroactive necontrolate → „auto-DDoS”.
Tranzacții lungi/mutexuri pe pista fierbinte.
Migrații/eliberări „grele” fără canari și plan rollback.
Lipsa cărții de alergare și comunicarea cu părțile interesate într-un incident.
15) Lista de verificare a implementării (0-60 zile)
0-15 zile
Definiți SLI-urile critice ale utilizatorilor, setați SLO-urile după niveluri Tier-0/1/2.
Include alerte burn-rate, tablouri de bord SLO, verificări perimetrale sintetice.
Eliminați SPOF: replici ≥2, PDB, multi-AZ pentru fronturi și baze de date critice.
16-40 zile
Introduceți lansări canare cu SLO-gating și auto-rollback.
Harta dependenței + cote/piscine/timeout/PB pentru fiecare „cale roșie”.
Reglementarea ferestrelor și comunicațiilor planificate, șabloane de mesaje incidente.
41-60 zile
Ziua jocului: deconectarea AZ, eșecul unui furnizor extern, „izbucnirea” traficului.
Recalcularea SLA-urilor și a creditelor reale, publicarea rapoartelor către clienți.
Revizuirea „costului de ↔ nouă” și re-stabilire pe galeria de fotografiere.
16) Valorile maturității
≥ 95% din rutele critice au alerte SLI/SLO și burn-rate.
Erorile SLO sunt însoțite de înghețarea automată a versiunilor (politică).
Multi-AZ acoperire Tier-0 = 100%, de succes DR-burghiu ≥ 1/trimestru.
„Detectare → atenuare” timp p50 <5 min, p95 <15 min.
Corelația "Release ↔ incidents' - menținută și redusă (rollback rate↓).
Incident public/Raport de credit - în termen de N zile lucrătoare.
17) Exemple și fragmente
Alerte Burn-rate (idee regula):- Rapid: "SLO 99. 95%, fereastra 1 h, arde ≥ 14. 4 × → pagina de gardă"
- Lent: „fereastră 6 h, arde ≥ 2 × → bilet & monitorizare”.
yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50
Canare cu analiza SLO (Argo Rollouts, idee):
yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus
Exemplu de formulare SLI:
SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region
18) Concluzie
Disponibilitatea ridicată nu este doar clustere și replici, ci un set consistent de arhitectură, procese și metrici: SLI/SLO clar, SLA realist, nouari economice, degradare în loc de scădere, disciplină timeout/cotă, eliberări canare, exerciții regulate și comunicare transparentă. Asigurați-accesibilitate măsurabilă și ușor de gestionat - și devine un avantaj competitiv, nu o loterie.