Risposta.

Nella storia dello sviluppo dei sistemi IT distribuiti, le questioni relative alla gestione degli errori e agli scenari di fallimento sono state a lungo messe in secondo piano, a favore della logica di business. Tuttavia, la crescita delle dimensioni e la complessità dell'infrastruttura hanno dimostrato nel tempo che scenari di gestione degli errori poco sviluppati portano a guasti su larga scala e perdita di dati.

Il problema è che sistemi complessi subiscono diversi tipi di guasti: dall'inaccessibilità di singoli servizi all'incoerenza dei dati o ai guasti parziali delle connessioni. Spesso i clienti interpretano i "guasti" come solo ovvi fallimenti (per esempio, server non disponibile), ignorando le catene di errori inter-servizio o la degradazione dell'esperienza utente.

Una soluzione efficace si basa su un approccio sistemico:

Identificazione di tutti i possibili punti di guasto.
Sviluppo di scenari esaustivi per la loro insorgenza in collaborazione con architetti, QA, progettisti e ingegneri operativi.
Coordinamento del comportamento del sistema con il business (per esempio, se è possibile ritardare gli ordini o è necessario memorizzare le operazioni).
Documentazione chiara di tutti i tipi di messaggi di errore e percorsi di gestione.

Caratteristiche principali:

Gestione non solo di fallimenti fatali, ma anche di fallimenti morbidi/fluttuanti (per esempio, indisponibilità temporanea di un servizio esterno).
Inclusione di scenari di degradazione dell'interfaccia utente e della funzionalità.
Distinzione tra errori di business e guasti tecnici in tutte le fasi di sviluppo dei requisiti.

Domande insidiose.

Qual è la differenza tra un'eccezione a livello di applicazione e un'eccezione a livello di infrastruttura?

Spesso i candidati confondono gli errori di business (per esempio, "utente non trovato") con guasti reali (per esempio, "database non disponibile"). L'applicazione deve sempre distinguere chiaramente tra i due tipi di eccezioni e garantire diverse strategie di gestione (rollback, notifiche, allerta).

Quali scenari di guasto dovrebbero essere modellati per un’API interna, se non è pubblica?

Gli scenari di guasto sono rilevanti per qualsiasi API: anche se l'API è interna, i guasti possono sempre verificarsi (anche all'interno di un'unica contesto di automazione), e devono essere modellati chiaramente, per lavorare correttamente con dati non affidabili/assenza di dati.

Il sistema dovrebbe nascondere tutti gli errori all'utente per massimizzare l'UX?

No, la totale occultazione degli errori porta a disinformare l'utente. È importante trovare un equilibrio tra informatività (in modo che l'utente capisca cosa fare dopo) e sicurezza (senza svelare i dettagli di implementazione).

Errori tipici e anti-pattern

Gestione dei guasti non formalizzata (catch lasciati "per impostazione predefinita").
Mancanza di scenari di degradazione in caso di guasti parziali (ad esempio, un carrello non funzionante blocca completamente l'evasione di un ordine).
Ignorare l'accumulo di guasti "silenziosi" (nessun allerta/monitoraggio per situazioni eccezionali).

Esempio dalla vita reale

Caso negativo: In un grande progetto di e-commerce, un analista di sistema ha lasciato la gestione di tutti gli errori di rete a carico dell'architettura. Durante aggiornamenti di emergenza e guasti del servizio di posta, il sistema non inviava notifiche sugli ordini e gli utenti non capivano se i loro ordini erano stati creati.

Pro:

Semplificazione della descrizione dei requisiti.

Contro:

Perdita di dati (impossibilità di dimostrare la creazione di un ordine).
Aumento dei costi di supporto dopo il lancio del prodotto.

Caso positivo: L'analista di sistema insieme all'architetto ha modellato scenari separati per ciascun servizio critico: assenza della coda di messaggi, malfunzionamenti dei gateway di pagamento, degradazione del servizio di ricerca. Sono stati scritti messaggi user-friendly per i clienti.