Failsafe systemen: hoe ICT kan leren van vliegtuigbouwkunde

Als een systeem faalveilig of failsafe is ontworpen, valt het bij een storing of gebrek altijd in een veilige toestand. Een goed voorbeeld is de dodemansknop in de cabine van de machinist, als hij of zij deze niet (bijna) constant ingedrukt houdt, wordt de trein automatisch tot stilstand gebracht. Door een systeem failsafe te ontwerpen, wordt het risico op onveilige situaties en ongelukken enorm verkleind.

Spoilers
Een ander voorbeeld, uit de vliegtuigbouw: de spoilers op de vleugel, die na de landing alle ‘lift’ van de vleugel elimineren waardoor het volle gewicht op de wielen komt en optimaal op de wielen kan worden geremd. Het is begrijpelijk dat deze spoilers in de lucht nooit omhoog mogen gaan, omdat het vliegtuig dan direct zou vallen. De failsafe-oplossing hiervoor is om de spoiler met grote veerkracht ingetrokken te houden en deze bijvoorbeeld elektrisch of hydraulisch omhoog te duwen bij. De benodigde energie daarvoor wordt gegenereerd door een kleine dynamo in de wielen. Als het vliegtuig op de grond komt, gaan de wielen draaien en pas dán levert de dynamo de energie om de spoilers desgewenst omhoog te brengen. Zonder contact met de grond, blijven de spoilers dus altijd in de veilige stand staan.

Vooraf in kaart
In heel veel transportsystemen zijn failsafe technieken normale uitgangspunten voor een ontwerp. De uitdaging voor ontwerpers is al tijdens het ontwerp alle mogelijke zaken die mis kunnen gaan, vooraf in kaart te brengen en daarop het ontwerp in te richten. Als een straalmotor naast de cabine van een vliegtuig hangt en de kans bestaat dat een schoep uit de rotor zou kunnen schieten richting cabine, dan vraagt dat in het ontwerp voorbereidingen om de impact daarvan te minimaliseren.

In normaal bedrijf moet de motoromhulling dit gevaar kunnen weerstaan. Of ter plekke op de cabine een impact beschermende laag. Maar elke (extra) versteviging kost gewicht en dat is kostbaar bij elk vliegtuig. Bij volle toeren, zoals bij de start, kun je de stoelconfiguratie zo ontwerpen dat ondanks materiele schade eventuele brokstukken geen mensen kunnen raken. En tijdens start en landing zit iedereen verplicht in zijn stoel waardoor er geen lopende personen in het gangpad zullen zijn. En er is nog geen druk in de cabine opgebouwd. Dit soort redeneringen horen bij failsafe ontwerpen.

Luchtwaardig
Uitgangspunt bij zeer kritische systemen is dat de overheid meestal strenge eisen heeft gesteld voor dit soort producten en er zoals in de luchtvaart een certificatie en luchtwaardigheidsbewijs nodig is om het vliegtuig te mogen laten vliegen. Zodra er ook maar enige twijfel ontstaat over de vliegveiligheid tijdens de levenscyclus, wordt het vliegtuig aan de grond gehouden tot wederom de luchtwaardigheid is aangetoond.

Dit strikte failsafe-proces zou bij informatiesystemen ook gangbaar moeten zijn. De impact van cybercriminaliteit wordt steeds groter en onze systemen moeten hun werk doen in een als het ware continu onveilige oorlogssituatie. Juist omdat we niet elk risico kúnnen vermijden, kan een failsafe ontwerp bijdragen aan de inherente veiligheid van het systeem.

Anomalie
Natuurlijk zijn er al systemen ontwikkeld die abnormale situaties kunnen herkennen tussen alle normale processen en informatiestromen. Maar de tegenstanders worden ook steeds slimmer en weten hun activiteiten steeds vaker te maskeren en creëren zo een ‘schijnbaar’ normale situatie. Daarom blijft het zaak, na het ontwerp en in gebruik nemen van een systeem, de failsafe-gedachte continu te blijven herhalen gebaseerd op het groeiende inzicht van mogelijke nieuwe en andere gevaren.

Hier kan AI (artificial intelligence) ons enorm gaan helpen. Algoritmen die ons helpen steeds nauwkeuriger en gedetailleerder anomalieën en abnormaliteiten te herkennen en in kaart te brengen. Zelflerende systemen die elke dag wijzer worden en daardoor de veiligheid van het bestaande systeem kunnen borgen in de tijd. Een ook hier weer geldt, bij twijfel liever het systeem down c.q. op de grond brengen, voordat er schade en ongelukken ontstaan, dan de het risico nemen om ‘door te vliegen’.

Chaos Monkey
Afgelopen jaren heb ik veel gesprekken met klanten gehad over het testen van de veiligheid van hun infrastructuur. Ook over het ‘durven’ testen van de realtime wereld door op geplande momenten het systeem ‘gewoon’ af te schakelen, een storing te veroorzaken en dan kijken of dat afschakelen gecontroleerd gebeurd. Of de back-up te frustreren en te kijken hoe het systeem reageert. Gewoon allerlei zaken ‘expres’ verkeerd uit voeren om te leren of het systeem veilig blijft.

De angst is vaak dat hierdoor het productiesysteem écht een keer down kan gaan en het productiviteit kost of andere externe schade met zich meebrengt. Maar het ‘niet’ weten kan op termijn wel eens veel ernstiger schade met zich mee brengen. Het was Netflix die in 2011 de zogenaamde ‘Chaos Monkey’ uitvond om het herstellingsvermogen van zijn infrastructuur continu te testen. Het is een programma dat random systemen en onderdelen van systemen kiest, die onverwacht tijdens productie uitzet en vervolgens registreert wat er gebeurt.

Simian Army
De Chaos Monkey is nu een onderdeel van de ‘Simian Army’ dat door Netflix ontworpen is om reacties van verschillende productie- en edge-systemen te simuleren voor allerhande soorten storingen. Het is een verzameling van open source cloud test-gereedschappen om de betrouwbaarheid, veiligheid, de veerkracht en het herstellingsvermogen van clouddiensten te testen. Hiermee heeft Netflix werelwijd een enorm redundante infrastructuur kunnen ontwikkelen die zo goed als failsafe is geworden. Sinds 2017 gebruikt ook Google dit om zijn cloud services-platform beter te beveiligen en robuuster te maken.

Naast de chaos monkey, die willekeurig her en der VM’s afschakelt, bestaat de latency monkey, die degradatie van services simuleert en de upstream reacties controleert. Daarnaast bestaat de conformity monkey die instances die niet goed zijn gecodeerd uitzet en hen de kans geeft op een juiste manier te herstarten, naast de security monkey die veiligheidszwakheden opspoort in instances of (bijna) verlopen certificaten. Tenslotte kan de doctor monkey health checks uitvoeren en zoekt de janitor monkey naar niet gebruikte resources.

Dit zijn stuk voor stuk prachtige voorbeelden die laten zien hoe we ook in de informatiewereld naar meer failsafe systemen en processen kunnen groeien. Failsafe denken betekent ook geen angst hebben om opzettelijk fouten te genereren, want van fouten leer je. Zelfs als je denkt intussen alle fouten wel te kennen . . .

About the Author: Hans Timmerman

Hans Timmerman (1953) is als CTO binnen Dell EMC Nederland verantwoordelijk voor de ontwikkeling en verdieping van zowel Dell EMC's lokale business en technology development als voor de bestaande strategische allianties en partnerships. Een groot deel van zijn carrière was Hans werkzaam in de Nederlandse vliegtuigindustrie. Daarna bekleedde hij bij verschillende IT-bedrijven management- en directiefuncties.