Degrado della grazia

1) L'essenza dell'approccio

Il degrado della grazia è un passaggio gestito al sistema in modalità più semplice ma utile quando le risorse sono ridotte, le dipendenze fallite o i picchi di carico. Lo scopo è quello di preservare il valore core per l'utente e la sostenibilità della piattaforma, sacrificando funzionalità e qualità secondarie.

• Prevedibilità: scenari predefiniti e «scale» di degrado.
• Limitazione del raggio di impatto: isolamento di fich e dipendenze.
• Osservabilità: metriche, fogli e tracciabilità «quale livello di degrado è attivo e perché».
• Reversibilità: ritorno rapido alla normalità.

2) Principi e limiti

1. Salva l'essenziale: SLA/SLO principale (ad esempio, acquisto, login, ricerca) è la priorità superiore a quella secondaria (avatar, raccomandazioni, animazioni).

• Sicurezza, pagamenti, diritti - fail-closed (migliore rifiuto che violazione).
• Contenuti, suggerimenti, avatar - fail-open con folback.
• 3. Budget provvisorio: timeout dall'alto verso il basso (client
• 4. Controllo dei costi: il degrado dovrebbe ridurre il consumo di CPU/IO/rete, non semplicemente nascondere gli errori.

3) Livelli di degrado

3. 1 Client/UX

Skeletons/playsholder e un caricamento «pigro» di widget secondari.
Partial UI: i blocchi critici vengono caricati, quelli secondari vengono nascosti/semplificati.
La cache del client è last-known-good (LKG) con il segno «i dati potrebbero essere obsoleti».
Modalità off-line: coda di comandi con ripetizione in seguito (idempotenza!).

3. 2 gateway Edge/CDN/WAF/API

stale-while-revalidate - Restituisci la cassetta, aggiorniamo lo sfondo.
Rate limiting & load shedding: durante il sovraccarico, ripristiniamo il traffico di sfondo/anonimato.
Geofence/routing ponderato - il traffico viene portato verso la regione sana più vicina.

3. 3 Livello di servizio

Partial response: restituisce parte dei dati + 'warnings'.
Modalità read-only - Disattiva temporaneamente le mutazioni (flag).
Brownout - Disattivazione temporanea di FIC (raccomandazioni, arricchimento).
Adattative concertency riduce dinamicamente il parallelismo.

3. 4 Dati/streaming

Cache come fonte di verità con TTL (temporaneamente): «Meglio approssimativamente che mai».
Ridotta precisione dei modelli/algoritmi (fast path vs accurate path).
Defer/queue - Consente di spostare le operazioni più pesanti in sfondo (outbox/job queue).
Code prioritarie: eventi critici in una classe separata.

4) «Scale» di degrado (playbooks)

• L0 (norma) L1 - Nascondi la personalizzazione e i banner di L2: disattivare i sinonimi/fassi-ricerca di L3: limitare le dimensioni della risposta e il timeout a 300 ms di L4: restituire i risultati dal cassetto 5 min di L5: «read-only & cache only» + coda di richieste di ricalcolo.

• Trigger: sovraccarico CPU> 85% p95> target, errori> soglia, Kafka> soglia, flap delle dipendenze.
• Azioni: attiva il flag X, riduce la concurrency a N, sposta la sorgente Y alla cache.
• I criteri di uscita sono 10 minuti di metriche verdi, una scorta di risorse.

5) Politiche decisionali

5. 1 Budget errato e SLO

Usa l'errore-budget burn rate come trigger brownout/shedding.
Criterio: «Se il burn-rate> 4 x entro 15 minuti - includere L2 degrado».

5. 2 Admission control

Limitiamo l'RPS in entrata ai percorsi critici per garantire il p99 e evitare che le code collassino.

5. 3 Priorità

Classi attive> system> background.
Priorità per il tenante (Gold/Silver/Bronze) e giustizia (fair share).

6) Pattern e implementazioni

6. 1 Load shedding (server)

Annullare le richieste prima che si occupino di tutte le risorse.
Restituire «429 »/« 503» con «Retry-After» e spiegare le regole (per i clienti).

Envoy (adaptive concurrency + circuit breaking)

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 (semplificazione temporanea)

L'idea è quella di ridurre la luminosità quando le risorse sono finite.

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 Partial response e avvisi

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

6. 4 Stale-while-revalidate sul bordo (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 Interruttore read-only (Kubernets + flag)

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 e classi di coda

Passare ai consumatori heavy in «max» più piccoli. poll. record', limitate la produzione di batch-e.
Separare «critici» e «bulk» per top/quote.

6. 7 UI: graceful fallback

Nascondete i widget «pesanti», mostrate kash/skeleton e etichettate chiaramente i dati obsoleti.

7) Esempi di configurazione

7. 1 Istio: outlier + pool di priorità

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

7. 2 Nginx: traffico di sfondo sotto il coltello primo

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 Feature flags / kill-switches

Memorizzare in configurazione dinamica (ConfigMap/Consul) e aggiornare senza rilascio.
Separare per Fic e le bandiere globali e regolare le attivazioni.

8) Osservabilità

8. 1 Metriche

«degradation _ level {service}» è il livello corrente.
'shed _ sollests _ total {route, reason}' - quanto è stato cancellato e perché.
«stale _ responses _ total» - Quanto è stato rilasciato.
`read_only_mode_seconds_total`.
`brownout_activations_total{feature}`.
Bilancio errato: burn-rate, percentuale di violazioni SLO.

8. 2 Tracing

Attributi span: 'degraded = true', 'level = 2', 'reason = upstream _ timeout'.
Link tra retrai/richieste hedged per vedere il contributo alle code.

8. 3 Logi/alert

Eventi di alterazione dei livelli di degrado con cause e proprietario della modifica.
Alert di livello «gonfio» (la degradazione dura troppo a lungo).

9) Gestione dei rischi e della sicurezza

Non degradare l'autenticazione, l'autorizzazione e l'integrità dei dati.
La maschera PII viene salvata in qualsiasi modalità.
Finanze/pagamenti: solo operazioni idipotenti, timeout e rimborsi rigorosi; in caso di dubbio - read-only/hold.

10) Anti-pattern

Degrado silenzioso senza suggerimenti all'utente e senza telemetria.
Tempeste retrae invece di load shedding e brevi timeout.
I tagliandi globali senza segmentazione sono un enorme blast radius.
Mescolare i percorsi prod e quelli leggeri in una sola cache/coda.
Il degrado eterno è brownout come «nuova normalità», criteri di uscita dimenticati.
State-write - Tentativi di scrittura basati su dati obsoleti.

11) Assegno-foglio di implementazione

• Identificati il kernel di valore e gli script critici dell'utente.
• Sono state create scale di degrado per servizi/case con inneschi e uscite.
• Timeout/vincoli e server-side load shedding.
• Sono stati configurati rate limits e classi di traffico prioritarie.
• Implementati partial response, read-only, stale-while-revalidate.
• Le feature flags/kill-switches sono integrate.
• Metriche/tracking/alert per livelli di degrado e cause.
• Esercitazioni regolare game day con simulazione di sovraccarico/guasto.
• Sono stati documentati il SLO e la policy error-budget per la degradazione.

12) FAQ

Q: Quando scegliere brownout e quando scegliere shedding?
A: Se l'obiettivo è di ridurre i costi delle richieste senza guasti - brownout. Se l'obiettivo è proteggere il sistema quando anche la semplificazione non aiuta - shedding access.

Segnalare all'utente il degrado?
A: Per gli script critici, sì. La trasparenza riduce il supporto e l'insoddisfazione.

La cache può essere la fonte della verità?
A: Temporaneamente, sì, con SLA evidenti e etichette di obsolescenza. È proibito per le mutazioni.

Come si fa a non essere rotti?
A: Brevi timeout, backoff esponenziale con jitter, idipotenza e limite di tentativi; ritrae solo operazioni sicure.

13) Riepilogo

Il degrado della grazia è un contratto architettonico e una serie di modalità di funzionamento gestite, incluse da metriche e budget errato. Scale correttamente progettate, timeout rigoroso e shedding, cash folback e brownout, oltre ad una forte osservabilità - e la piattaforma rimane utile e economico anche durante la tempesta.