Degradare graţioasă

1) Esența abordării

Degradarea grațioasă este trecerea gestionată a unui sistem la un mod mai simplu, dar util atunci când resursele sunt limitate, dependențele eșuează sau vârfurile de încărcare. Scopul este de a păstra nucleul valorii utilizatorului și reziliența platformei prin sacrificarea capacităților secundare și a calității.

• Predictibilitate: scenarii predefinite și „scări” de degradare.
• Constrângere rază de lovire: Izolați caracteristicile și constrângerile.
• Observabilitate: măsurători, bușteni și urme „ce nivel de degradare este activ și de ce”.
• Reversibilitate: revenirea rapidă la normal.

2) Principii și limite

1. Salvați principalul lucru: principalul SLA/SLO (de ex. „cumpărare”, „conectare”, „căutare”) - prioritatea este mai mare decât secundară (avatare, recomandări, animații).

• Securitate, plăți, drepturi - eșec închis (refuz mai bun decât încălcarea).
• Conținut cache, indicii, avatare - nu reușesc-deschis cu folback.
• 3. Bugete de timp: timeout-uri de sus în jos (client
• 4. Controlul costurilor: degradarea ar trebui să reducă consumul de CPU/IO/rețea, nu doar „ascunde” erori.

3) Niveluri de degradare

3. 1 Client/UX

Schelete/înlocuitori și încărcarea „leneș” de widget-uri secundare.
UI parțială: blocurile critice sunt încărcate, blocurile secundare sunt ascunse/simplificate.
Cache-ul clientului: ultimul-cunoscut-bun (LKG) marcat „datele pot fi depășite”.
Modul offline: coadă de comandă cu repetiție mai târziu (idempotence!).

3. Gateway 2 Edge/CDN/WAF/API

stale-în timp ce-revalidat: dăm memoria cache, actualizați fundalul.
Rata de limitare și încărcare: la supraîncărcare, resetați traficul de fundal/anonim.
Rutare geofence/ponderată: traficul este deviat în cea mai apropiată regiune sănătoasă.

3. 3 Strat de service

Răspuns parțial: partea de returnare a datelor + 'avertismente'.
Mod read-only: interzice temporar mutațiile (steaguri).
Brownout: dezactivarea temporară a caracteristicilor consumatoare de resurse (recomandări, îmbogățire).
Concurență adaptivă: reduceți dinamic concurența.

3. 4 Date/Streaming

Cache ca sursă de adevăr cu TTL (temporar): „mai bine aproximativ decât nimic”.
Precizie redusă a modelelor/algoritmilor (cale rapidă vs traseu precis).
Amână/coadă - transferă sarcini grele în fundal (outbox/coadă de locuri de muncă).
Cozi prioritare: evenimente critice - într-o clasă separată.

4) Degradarea „scări” (playbooks)

• L0 (normal) → L1: ascundeți personalizarea și bannerele → L2: dezactivați sinonimele/căutarea fuzzy → L3: mărimea și timpul limită de răspuns la 300 ms → L4: dați rezultate din memoria cache 5 minute → L5: „numai citire și numai în cache” + coadă de cereri de recalculare.

• Declanșatoare: suprasarcină CPU> 85% p95> țintă, erori> prag, steag prag Kafka>, pavilion dependență.
• Acțiuni: activați steagul X, coborâți concurența la N, comutați sursa Y la memoria cache.
• Criterii de ieșire: 10 minute de măsurători verzi, sala de resurse.

5) Politici decizionale

5. 1 Buget eronat și SLO

Utilizaţi eroare-buget arde rata ca un brownout/vărsare declanşator.
Politică: „dacă rata de ardere> 4 × în termen de 15 min - porniți degradarea L2”.

5. 2 Controlul admiterii

Restricționăm RPS-urile primite pe căile critice pentru a garanta p99 și a preveni prăbușirea cozii.

5. 3 Prioritizarea

Clase: interactive> sistem> fundal.
Priorități per chiriaș (Aur/Argint/Bronz) și justiție (cotă echitabilă).

6) Modele și implementări

6. 1 Încărcare vărsare

Renunţă la cereri înainte să preia toate resursele.
Returnați „429 ”/„ 503” cu „Retry-After” și explicația politicii (pentru clienți).

Envoy (adaptive concurenţă + circuit de rupere)

yaml typed_extension_protocol_options:
envoy. filters. http. adaptive_concurrency:
"@type": type. googleapis. com/envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency gradient_controller_config:
sample_aggregate_percentile: 90 circuit_breakers:
thresholds:
- max_requests: 2000 max_pending_requests: 500 max_connections: 1000

6. 2 Brownout (simplificare temporară)

Ideea: pentru a reduce „luminozitatea” (costul) caracteristicii atunci când resursele sunt în criză.

kotlin class Brownout(val level: Int) { // 0..3 fun recommendationsEnabled() = level < 2 fun imagesQuality() = if (level >= 2) "low" else "high"
fun timeoutMs() = if (level >= 1) 150 else 300
}

6. 3 Răspuns parţial şi avertismente

json
{
"items": [...],
"degradation": {
"level": 2,
"applied": ["cache_only", "no_personalization"],
"expiresAt": "2025-10-31T14:20:00Z"
}
}

6. 4 Stale-în timp ce-revalidat pe margine (Nginx)

nginx proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout http_500 http_502 http_504 updating;
proxy_cache_background_update on;

6. 5 Comutator numai pentru citire (Kubernetes + pavilion)

yaml apiVersion: v1 kind: ConfigMap data:
MODE: "read_only"

The code should check MODE and block mutations with a friendly message.

6. 6 Kafka: backpressure și clase de coadă

Comuta heavy-consumatori la mai mici 'max. sondaj. înregistrări ", limita lot de producție și.
Separați evenimentele „critice” și „în vrac” după subiect/cotă.

6. 7 UI: rezervă grațioasă

Ascundeți widget-uri „grele”, afișați memoria cache/schelet și etichetați clar datele depășite.

7) Exemple de configurare

7. 1 Istio outlier + piscine prioritare

yaml outlierDetection:
consecutive5xx: 5 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 50

7. 2 Nginx: Traficul de fundal sub cuțit mai întâi

nginx map $http_x_priority $bucket { default low; high high; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
limit_req_status 429;

server {
location /api/critical/ { limit_req zone=perip burst=40 nodelay; }
location /api/background/ {
limit_req zone = perip burst = 5 nodelay; # stricter
}
}

7. 3 Caracteristici steaguri/kill-switch-uri

Stocați în configurație dinamică (ConfigMap/Consul), actualizați fără lansare.
Separați fiecare caracteristică și steaguri globale, activări de jurnal.

8) Observabilitate

8. 1 Măsurători

'degradation _ level {service}' este nivelul actual.
'shed _ requests _ total {route, reason}' - cât de mult este resetat și de ce.
'stale _ responses _ total' - câtă memorie cache a fost emisă.
'read _ only _ mode _ seconds _ total'.
'brownout _ activations _ total {feature}'.
Buget eronat: rata de ardere, proporția încălcărilor SLO.

8. 2 Vectorizare

Atribute ale intervalelor: 'degraded = true', 'level = 2', 'reason = upstream _ timeout'.
Legături între retroys/interogări acoperite pentru a vedea contribuția la cozi.

8. 3 Jurnale/Alerte

Nivelul de degradare comută evenimentele cu cauze de schimbare și proprietar.
Alerte pentru nivelul de „lipire” (degradarea durează prea mult).

9) Managementul și securitatea riscurilor

Nu degrada autentificarea/autorizarea/integritatea datelor: un eșec mai bun.
Mascarea PII este păstrată în orice mod.
Finanțe/plăți: numai tranzacții idempotente, timeout-uri stricte și rollback-uri; în dubiu - read-only/hold.

10) Anti-modele

Degradare silențioasă fără a solicita utilizatorului și fără telemetrie.
Retrage furtuni în loc de vărsare de sarcină și scurte intervale de timp.
Global „switch-uri” fără segmentare - o rază mare explozie.
Se amestecă căile prod și ușoare în aceeași memorie cache/coadă.
Degradarea eternă: maroniu ca „nou normal”, criterii de ieșire uitate.
Stale-write: încercări de a scrie pe baza datelor vechi.

11) Lista de verificare a implementării

• Valoarea de bază și scenariile critice ale utilizatorilor definite.
• Scări de degradare de serviciu/domaine cu declanșatoare și ieșiri sunt compilate.
• Timeouts/restricții și de încărcare server-side sunt introduse.
• Limitele ratei și clasele de trafic prioritare sunt configurate.
• Implementat răspuns parțial, read-only, stale-în timp ce-revalidate.
• Steaguri de caracteristici integrate/kill-switch-uri cu audit.
• Metrica/urmărire/alerte pentru niveluri de degradare și cauze.
• Exerciții regulate de zi de joc cu supraîncărcare/eșecuri simulate.
• SLO documentate și eroare-buget → politica de degradare.

12) ÎNTREBĂRI FRECVENTE

Î: Când să alegeți brownout și când să vărsați?
R: Dacă scopul este de a reduce costul cererilor fără eșecuri - brownout. În cazul în care scopul este de a proteja sistemul atunci când chiar și simplificarea nu ajută, vărsare autentificare.

Î: Raportez degradarea utilizatorului?
R: Pentru scenarii critice - da (insigna „mod limitat”). Transparența reduce sprijinul și nemulțumirea.

Î: Poate fi făcută o memorie cache o sursă de adevăr?
R: Temporar - da, cu SLA-uri explicite și etichete de îmbătrânire. Pentru mutații - interzise.

Î: Cum să nu faci retrai "rupt'?
R: Intervale scurte de timp, backoff exponențial cu jitter, idempotență și limită de încercare; retrait numai operațiuni sigure.

13) Totaluri

Degradarea grațioasă este un contract arhitectural și un set de moduri de operare controlate, pornite de semnalele de metrică și buget eronat. Scări proiectate corespunzător, termene stricte și vărsare, cashback și brownout, plus observabilitate puternică - iar platforma rămâne utilă și economică chiar și într-o furtună.