Antwoord.

In de geschiedenis van de ontwikkeling van gedistribueerde IT-systemen zijn vragen over foutafhandeling en uitvalscenario's lange tijd op de tweede plaats gekomen, ten koste van de bedrijfslogica. Echter, de groei en complicatie van de infrastructuur heeft in de loop der tijd aangetoond dat onvolledige foutafhandelingsscenario's leiden tot grootschalige storingen en dataverlies.

Het probleem is dat complexe systemen vele soorten storingen ervaren: van de onbeschikbaarheid van afzonderlijke services tot inconsistentie van gegevens of gedeeltelijke uitval van communicatiekanalen. Vaak begrijpen klanten onder "storingen" alleen de evidente uitval (bijvoorbeeld, de server is niet beschikbaar), waardoor ze chains van interservicefouten of degradatie van de gebruikerservaring negeren.

Een effectieve oplossing is gebaseerd op een systematische aanpak:

Detectie van alle mogelijke uitvalpunten.
Ontwikkeling van uitputtende scenario's voor hun optreden in samenwerking met architecten, QA, ontwerpers en exploitatie-ingenieurs.
Afstemming van het gedrag van het systeem met het bedrijfsleven (bijvoorbeeld, mag een bestelling worden uitgesteld of moet er worden gecached?).
Duidelijke documentatie van alle soorten foutmeldingen en verwerkingsroutes.

Belangrijke kenmerken:

Afhandeling van niet alleen fatale, maar ook zachte/drijvende storingen (bijvoorbeeld, tijdelijke onbeschikbaarheid van een externe service).
Inclusie van scenario's voor degradatie van de UI en functionaliteit.
Scheiding van bedrijfseigen fouten en technische storingen in alle fasen van de vereistenontwikkeling.

Misleidende vragen.

Wat is het verschil tussen een uitzondering op applicatieniveau en op infrastructuurniveau?

Kandidaten verwarren vaak bedrijfseigen fouten (bijvoorbeeld, "gebruiker niet gevonden") met echte storingen (bijvoorbeeld, "database niet beschikbaar"). De applicatie moet altijd duidelijk onderscheid maken tussen de twee soorten uitzonderingen en verschillende verwerkingsstrategieën waarborgen (rollback, meldingen, alerting).

Welke uitvalscenario's moeten worden gemodelleerd voor een interne API, als deze niet openbaar is?

Uitvalscenario's zijn relevant voor elke API: zelfs als de API intern is, kunnen storingen altijd optreden (zelfs binnen één automatiseringscontour), en ze moeten expliciet worden gemodelleerd om effectief te kunnen werken met onbetrouwbare/ontbrekende gegevens.

Moet het systeem alle fouten verbergen voor de gebruiker voor de maximale UX?

Nee, absolute verberging van fouten leidt tot verkeerde informatie voor de gebruiker. Het is belangrijk om een balans te vinden tussen informativiteit (zodat de gebruiker begrijpt wat hij/zij verder moet doen) en veiligheid (zonder details van de implementatie prijs te geven).

Typische fouten en antipatterns

Informele foutafhandeling (alleen "op standaard" catch-blokken).
Gebrek aan degradatiescenario's bij gedeeltelijke storingen (bijvoorbeeld, een niet-functionerende winkelwagentje blokkeert volledig de bestelling in microservices).
Negeren van de accumulatie van "stille" storingen (geen alerting/monitoring voor uitzonderlijke situaties).

Voorbeeld uit het leven

Negatief geval: In een groot e-commerce project heeft de systeemanalist de behandeling van alle netwerkfouten aan de architectuur overgelaten. Bij noodupdates en storingen van de e-mailservice verzond het systeem geen meldingen over bestellingen, en de gebruikers begrepen niet of hun bestellingen waren gemaakt.

Voordelen:

Vereenvoudiging van de beschrijving van vereisten.

Nadelen:

Gegevensverlies (het is onmogelijk te bewijzen dat een bestelling is gemaakt).
Ondersteuningskosten stegen na de lancering van het product.

Positief geval: De systeemanalist heeft samen met de architect afzonderlijke scenario's gemodelleerd voor elke kritieke service: onbeschikbaarheid van de emails, uitschakeling van betalingsgateways, degradatie van de zoekservice. Gebruiksvriendelijke berichten voor klanten werden in detail uitgewerkt.