Quando un’applicazione dipende da servizi interni o esterni, il guasto di uno di essi non dovrebbe obbligare automaticamente a fermare tutto. Tuttavia, mantenere attive tutte le funzioni come se nulla fosse può causare dati incoerenti, operazioni duplicate o decisioni basate su informazioni non aggiornate. Progettare un degrado controllato significa decidere in anticipo quali funzionalità restano disponibili, quali vengono limitate e quali devono essere bloccate quando un servizio dipendente non risponde.
La decisione deve proteggere il processo aziendale, non soltanto la disponibilità tecnica. Per ogni funzione, conviene valutare di quale servizio ha bisogno, cosa accade se quel servizio manca, per quanto tempo si può tollerare l’interruzione e come ripristinare la coerenza in seguito. In questo modo, il team può offrire un’alternativa utile senza nascondere il problema né assumersi rischi inutili.
Che cosa significa degradare in modo controllato
Un’applicazione è in degrado controllato quando, in seguito a un guasto o a una risposta insufficiente di un servizio dipendente, mantiene un insieme deliberato di funzioni entro limiti espliciti. Non è una copia completa del servizio né una promessa che tutto continuerà a funzionare. È una politica che stabilisce come comportarsi in condizioni di guasto parziale.
Si distingue da altri meccanismi correlati:
- Modalità offline: consente di usare alcune funzioni senza connettività e, in determinati casi, di sincronizzare le modifiche in un secondo momento. Il degrado controllato può applicarsi anche quando la rete funziona, ma un servizio specifico è guasto.
- Nuovi tentativi: ripetono una richiesta non riuscita, in genere con limiti e pause. Da soli, non determinano che cosa l’utente debba vedere o fare mentre il servizio continua a non essere disponibile.
- Degrado controllato: definisce l’esperienza e le regole aziendali durante il guasto, compresi quali operazioni siano consentite, con quali dati e a quali condizioni.
Per esempio, se un servizio di consigli non funziona, l’applicazione può mostrare una selezione generica e mantenere attiva la ricerca. Se invece non funziona la convalida necessaria per confermare un pagamento, consentire comunque l’addebito può comportare un rischio maggiore rispetto all’interruzione temporanea di quell’azione.
Collega ogni funzione alle sue dipendenze e al suo impatto
Inizia da una mappa delle funzionalità del prodotto, non da un inventario isolato dei servizi. Per ogni funzione visibile, annota quali dipendenze richiede e quale risultato produce. Una scheda utile comprende l’operazione, il servizio necessario, i dati letti o scritti, l’effetto per l’utente e le conseguenze di un risultato errato.
Valuta poi due aspetti: l’impatto dell’impossibilità di completare la funzione e il possibile danno nel caso in cui venga completata usando informazioni incomplete o errate. Non sono la stessa cosa. Un ritardo nel caricamento dei contenuti può essere fastidioso, mentre accettare una transazione senza verificarne lo stato può causare perdite o problemi di riconciliazione.
Come primo passo, suddividi le funzioni in tre gruppi:
- Da mantenere: funzionalità indipendenti dal servizio guasto, come consultare contenuti già disponibili localmente.
- Da limitare: azioni utili se il loro ambito viene circoscritto, per esempio mostrare dati memorizzati indicando quando sono stati aggiornati oppure consentire di salvare una bozza senza inviarla.
- Da interrompere: operazioni la cui correttezza dipende da una verifica impossibile da eseguire, come confermare un’azione irreversibile senza convalidarne le condizioni.
La classificazione deve considerare le alternative e le conseguenze per le aree coinvolte. Il team di prodotto può definire quale esperienza conservi valore; i team tecnici e operativi devono confermare quali guasti siano rilevabili e quali garanzie offrano i sistemi. Esamina anche le dipendenze indirette: una funzione può sembrare autonoma e aver comunque bisogno di una convalida successiva per completare il processo.
Scegli tra funzionalità limitata, cache e alternativa manuale
L’opzione giusta dipende da quanto possono essere datati i dati, dal fatto che l’operazione modifichi o meno lo stato e dalla possibilità di riconciliare le modifiche in un secondo momento. Non tutte le cache sono sicure per qualsiasi uso: un dato utile per orientare una ricerca può non essere adatto ad autorizzare un’operazione.
- Dati in cache: usali quando la lettura rimane utile anche se i dati non sono del tutto aggiornati. Indicane la datazione ed evita di presentarli come una conferma aggiornata. Definisci quando non sono più accettabili; se non riesci a stabilire un limite basato su criteri aziendali, non usarli per decisioni sensibili.
- Funzionalità ridotta: offri una parte della funzione, ad esempio consentendo di consultare le informazioni ma non di modificarle, oppure di preparare una richiesta senza inviarla. Spiega quale passaggio è ancora in sospeso e che cosa servirà per completarlo.
- Alternativa manuale: può essere appropriata se esistono una procedura chiara, responsabili assegnati e una registrazione successiva. Senza questi controlli, il lavoro manuale può generare duplicati e diventare una fonte parallela di dati.
- Blocco temporaneo: è preferibile quando l’operazione non può essere eseguita in sicurezza o verificata in seguito. Limita l’azione interessata, non necessariamente l’intera applicazione.
Prima di consentire scritture differite, definisci come identificare, archiviare e riprovare le operazioni; quale risposta riceverà l’utente; e come verranno risolti i conflitti. Se non esiste una regola sicura per questi casi, conservare l’intenzione come bozza è spesso meno rischioso che dichiarare completata l’azione.
Blocca le operazioni che possono rendere incoerenti i dati
La domanda fondamentale è se il sistema riesca a distinguere tra una richiesta non ricevuta, una richiesta elaborata la cui risposta è andata persa e una richiesta ancora in sospeso. Se non ci riesce, ripetere un’operazione sensibile senza controlli potrebbe eseguirla più di una volta. I nuovi tentativi devono essere limitati e adattati al tipo di richiesta; per le azioni che producono effetti, occorre progettare meccanismi per riconoscere i duplicati e verificare il risultato prima di ripetere l’operazione.
Interrompi o limita un’operazione quando:
- richiede una convalida che non è disponibile e non esiste una regola alternativa approvata;
- può produrre un effetto irreversibile o difficile da compensare;
- non è possibile stabilire se una richiesta precedente sia stata completata;
- i dati memorizzati hanno superato la soglia di aggiornamento accettabile per quella decisione.
Se esiste una procedura di compensazione, documenta chi può avviarla e come viene registrata. Non dare per scontato che un’azione compensativa equivalga ad annullare l’effetto originale: potrebbe richiedere un intervento operativo, una verifica o una comunicazione alla persona interessata. La politica deve rispecchiare questi limiti.
Comunica i limiti e ripristina il servizio in modo controllato
Il messaggio deve spiegare quale funzione è limitata, che cosa può fare l’utente nell’immediato e se dovrà ripetere qualche passaggio. Evita frasi come «l’operazione è stata completata» quando è stata soltanto salvata una richiesta in sospeso. Non promettere neppure tempi di ripristino che il team non è in grado di garantire. Comunicare chiaramente lo stato riduce i tentativi impulsivi e le richieste evitabili all’assistenza.
Quando il servizio dipendente torna disponibile, non riattivare alla cieca tutto ciò che è rimasto in sospeso. Verifica lo stato effettivo, elabora le operazioni secondo un ordine definito, individua i duplicati e registra i risultati. Se ci sono conflitti tra modifiche, applica una regola concordata — per esempio, una revisione prima di sovrascrivere — e conserva una tracciabilità sufficiente per indagare sulle discrepanze.
Il ripristino deve basarsi su condizioni osservabili. Verifica che il servizio dipendente risponda in modo stabile, che i risultati siano validi e che l’applicazione riesca a completare il flusso normale. Rimuovi poi le restrizioni in modo controllato. Se i sintomi ricompaiono, il sistema deve poter limitare di nuovo la funzione, anziché alternare continuamente tra disponibilità e guasto.
Verifica le decisioni e misura i risultati
Una politica di degrado descritta soltanto in un documento non dimostra che l’applicazione la applichi correttamente. Simula l’interruzione, la latenza elevata, gli errori parziali e le risposte tardive di ogni dipendenza importante. Verifica sia l’interfaccia sia i registri, le operazioni in sospeso e il comportamento in presenza di duplicati. Includi test di ripristino e riconciliazione, non soltanto quelli di attivazione della modalità limitata.
Esamina insieme gli indicatori tecnici e quelli aziendali. Tra i primi rientrano gli errori e i tempi di risposta del servizio dipendente, il volume dei nuovi tentativi e la durata del degrado. Tra gli indicatori aziendali figurano le operazioni bloccate, le richieste in sospeso, i conflitti rilevati e i casi che richiedono un intervento manuale. Un miglioramento della disponibilità non basta se aumenta il numero di transazioni incoerenti o il carico sull’assistenza.
Come criterio pratico, per ogni funzione rispondi a quattro domande e verifica le risposte: che cosa si mantiene, che cosa si limita, che cosa si blocca e come si conferma il ripristino. Se il team non sa rispondere, la strategia non è ancora completa. Il degrado controllato trasforma un guasto inevitabile in una decisione esplicita: mantenere il valore che resta sicuro e rimandare ciò che dipende da una garanzia temporaneamente non disponibile.