Categorieën
Agile Planning Testen

Het rijdt als een trein

Niet dus. Begin april faalde een cruciaal NS-systeem. Alle treinverkeer werd stopgezet.

NS: “Niet alleen de borden en app van NS waren uitgevallen, het complete planningsysteem voor materieel en personeel lag plat. Normaal gesproken kan men dan op een back-up terugvallen, maar dat lukte niet.”

Het is niet te bevatten. Een cruciaal systeem kan zomaar uitvallen, en plotseling rijdt geen enkele trein. Tienduizenden reizigers zitten vast op stations. NS zet geen bussen in, reizigers moeten maar zien hoe ze thuiskomen.

De gigantische storing werd veroorzaakt door een systeem dat doorlopend planningen voor de dag maakt. Dat werkte niet meer en dat had grote impact. Het backup-systeem faalde ook. De oorzaak is nooit publiekelijk bekend geworden – na enkele dagen ebde de aandacht weg.

Dit keer was het volgens NS geen hack – zoals tegenwoordig vaak voorkomt.
Eigenlijk is dat heel, heel erg: een hack is iets dat je kunt proberen te voorkomen, wat algemeen bekend lastig is. Dit was een “gewoon” technisch falen en dat hoor je bij een bedrijfskritisch, cruciaal systeem door je ontwerp absoluut te voorkomen.

Hoewel ik open sta voor scrum-ontwikkeling en agile, moet me toch van het hart dat daarbij minder aandacht is voor betrouwbaarheid en voor beschikbaarheid. Dat is logisch, en niet als verwijt bedoeld. Een betrouwbaar systeem opzetten vereist nu eenmaal vooral veel inspanning bij het overall systeemontwerp, nog voor er één regel code is geproduceerd. Juist die stap gebeurt bij agile aanpak niet grondig.

Hoe anders ligt dat bij de SE (System Engineering) aanpak!

Een FMECA (Failure Mode and Effect Analysis) is de start van het SE traject, gericht op optimale betrouwbaarheid. Een specialistisch team gaat na hoe en waardoor het systeem kan falen, en wat van elke faalmodus de gevolgen kunnen zijn. Vanuit de FMECA volgen de te nemen maatregelen. Voor de hoogst haalbare betrouwbaarheid is een hot-standby of 2-out-of-3 benadering aangewezen, waarbij het ontwerp garant moet staan voor de onmerkbare overgang bij falen van één systeem. Als de faalkans dan nog te groot is, moeten fall-back maatregelen genomen worden.

Het blijft niet bij het maken van een doorwrochte FMECA, een razend goed ontwerp, een fantastische implementatie en perfect onderhoud.

Regelmatig checken dat alles inderdaad zo werkt en blijft werken als ontworpen is noodzakelijk. Mijn indruk is (zeker weten doe ik het niet), dat dat niet is gebeurd bij NS. Want als men dat wel gedaan had, dan had men tijdig moeten merken dat het back-up systeem de activiteiten niet overneemt op het moment dat het actieve systeem faalt. En of de fall-back voldoet.

Zulke checks zijn natuurlijk kostbaar, en je loopt het risico dat er een fout ontdekt wordt. Makkelijker is het om ze te “vergeten”. Het gevolg: als het dan misgaat kun je niets meer. Het treinverkeer gaat plat, je primaire bedrijfsvoering valt stil. Is dat die “besparing” echt waard?

Wat maakt toch dat er altijd tijd en geld is om iets te herstellen maar niet om iets gewoon goed te doen?

It’s Jaap kan u ondersteunen bij het bereiken van een wél betrouwbaar systeem, en het inrichten van een regelmatige check of alles nog zo functioneert als bedoeld.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *