Antwoord.

Geschiedenis van de vraag

Met de overstap naar microservices-architecturen en gedistribueerde systemen is de kans op fouten, die optreden bij de interactie tussen services, dramatisch gestegen, evenals de complexiteit van de afhandeling ervan. Vroege benaderingen hielden vaak geen rekening met de instabiliteit van netwerkcommunicatie, wat leidde tot grootschalige incidenten in productie.

Probleem

Het belangrijkste probleem is dat complexe uitvalszenario's, degradatie van services en integratiefouten niet voldoende zijn geformaliseerd in de vereisten. Hierdoor zijn ontwikkelaars gedwongen zelfstandig beslissingen te nemen over foutafhandeling, wat leidt tot heterogene cases en moeilijkheden bij het testen ervan.

Oplossing

Een effectieve beschrijving van foutafhandeling moet bevatten:

• Identificatie van foutentypen (netwerkstoringen, time-outs, uitval van derden, fouten in de business logica, inconsistentie in data).
• Beschrijving van reactiemogelijkheden voor elk fouttype: herhalingspogingen, terugdraaien van transacties, degradatie van functionaliteit, alerts, gebruikersberichten.
• Invoering van duidelijke scenario's voor falenstest (fail-over, graceful degradation), inclusief niet-specifieke en ketenincidenten.
• Documentatie van contracten en foutformaten (bijvoorbeeld een standaard JSON-contract voor foutantwoorden).

Belangrijke kenmerken:

• Standaardisering van foutafhandelingssjablonen tussen services.
• Validatie van degradatiescenario's en afstemming met het bedrijfsleven.
• Zorg voor fouttracering en logging voor latere analyse van incidenten.

Vragen met een addertje onder het gras.

Is het verplicht om technische foutafhandeling in de vereisten te beschrijven — is dat niet de taak van de ontwikkelaar?

Dat is verplicht. Een onverwerkte foutafhandelingspolitiek leidt vaak tot fouten in de werking en misinterpretaties. De systeemanalist moet het gedrag bij fouten bespreken.

Moet je gevallen beschrijven die uiterst zeldzaam voorkomen (bijvoorbeeld gedeeltelijk verlies van verbinding tussen services)?

Ja, omdat zelden voorkomende fouten leiden tot de meest complexe incidenten. De gevolgen ervan kunnen kritiek zijn voor het bedrijf.

Moet je de berichten die aan gebruikers worden getoond bij fouten afstemmen met het bedrijfsleven?

Ja. Correcte, informatieve, maar niet overbodige of angstaanjagende berichten moeten met het bedrijfsleven worden afgestemd, anders lijdt de gebruikerservaring en loyaliteit.

Typische fouten en anti-patronen

• Alleen de happy path beschrijven, en uitvalszenario's negeren.
• De degradatie van het systeem niet in overweging nemen (back-up scenario's zijn niet beschreven).
• Niet afgestemde of technisch complexe foutmeldingen voor gebruikers.

Voorbeeld uit het leven

Negatief geval: In het project waren de scenario's voor handelingswijze bij time-outs tussen services niet beschreven. Hierdoor "bevroren" de services zonder antwoord door een instabiel netwerk. Pluspunten: Snelle uitvoering van de hoofdscenario's. Minpunten: Massale storingen in de productie, negatieve feedback van klanten, "handmatig" sluiten van incidenten.

Positief geval: De analist beschreef de degradatie- en herstartscenario's, herhalingspogingen en correcte berichten. Pluspunten: Hoge stabiliteit van de service bij storingen, vermindering van het aantal incidenten. Minpunten: Meer tijd voor de uitwerking van de architectuur van de scenario's.