ICT van levensbelang: kantoorautomatisering is geen leidraad
Gisteren verscheen het rapport “Patiëntveiligheid bij ICT-uitval in ziekenhuizen” van de Onderzoeksraad voor veiligheid.
Omdat ik een bescheiden bijdrage heb geleverd aan dit rapport voel ik me geroepen een stukje te schrijven over wat in het rapport het “ICT-fundament” wordt genoemd.
Voor de volledige duidelijkheid, wat ik hier schrijf heeft niets te maken met de Onderzoeksraad en ook niet specifiek met de inhoud van het rapport. Zie het als een overdenking over bedrijfskritische ICT.
Mijn eigen achtergrond is dat de software van mijn bedrijf 24 uur per dag verantwoordelijk is voor de internettoegang van honderden miljoenen mensen, inclusief (naar hoge waarschijnlijkheid) uw internetverbinding thuis, op kantoor of via mobiel.
Heel in het kort betoogt dit artikeltje dat zeer hoge bedrijfszekerheid in ICT alleen gerealiseerd kan worden met eenvoudige systemen voorzien van een onafhankelijke noodoplossing. Het nastreven van de hoogste betrouwbaarheid door systemen complexer te maken met grote hoeveelheden redundantie levert uiteindelijk omvangrijkere en langere storingen op. Wat gangbaar is in kantoor-ICT is niet geschikt voor echte “leven of dood” ICT. En aanvullend, zelfs de beste SLA garandeert in de praktijk weinig.
Bedrijfskritische ICT
We willen graag dat onze computersystemen altijd werken. Maar voor veel toepassingen is een storing ook weer niet zo heel erg. Het is vervelend als de kwartaalcijfers een dag later verschijnen maar het levert geen lichamelijk letsel op.
Andere systemen zijn wel van letterlijk levensbelang. Ik heb persoonlijk meegemaakt op een spoedeisende hulp dat het dossier van mijn vader niet toegankelijk was terwijl we met hartklachten arriveerden. Het is best spannend als een arts jou vraagt naar details over het medisch dossier van je vader.
ICT-ontwerpen die geschikt zijn voor op kantoor zijn gemaakt voor andere niveaus van beschikbaarheid en betrouwbaarheid dan nodig voor systemen die verantwoordelijk zijn voor de (tijdige) behandeling van patiënten.
Theoretische betrouwbaarheid
Alles kan uitvallen, van mensen tot kabels. De gedachte bij hoogbetrouwbare systemen is dat losse storingen opgevangen kunnen worden zonder dat “het hele systeem” in elkaar stort.
In het klein is dit vrij eenvoudig. Als een printer bedrijfskritisch is, regel een tweede printer. Als er 6 ambulances nodig zijn voor afdoende capaciteit, koop er 7. De kans dat twee printers of twee ambulances tegelijk uitvallen is miniem en deze maatregelen zijn daardoor vrijwel 100% effectief.
Voor grotere en complexere systemen zou het mooi zijn als we op eenzelfde manier hogere betrouwbaarheid konden realiseren. In plaats van een enkele harde schijf, neem er twee. Vul de stroom aan met een noodstroomgenerator. Verbind netwerken niet met een maar met twee kabels. In plaats van een enkele database, repliceer alle gegevens naar een tweede “multi-master” systeem.
Helaas blijkt dat de betrouwbaarheid door dit soort maatregelen vaak helemaal niet toeneemt. Hoewel er nu meer mogelijkheden zijn om systemen draaiend te houden gaat het juist door de toegenomen complexiteit vaak mis.
Een harde schijf gaat bijvoorbeeld zelden in 1 klap kapot - in plaats daarvan blokkeert hij eerst en vertraagt de verwerking gigantisch. Noodstroomoplossingen zijn zelf notoir in het veroorzaken van storingen. En die tweede netwerkverbinding veroorzaakt regelmatig problemen, bijvoorbeeld door het “rondzingen” van packets, of het (onterecht) detecteren van storingen en vervolgens minutenlang automatisch herconfigureren (zonder netwerkverkeer).
En specifiek als uitdaging, de multi-master database die na een storing niet meer weet wie de master is, en beide helften bevatten inmiddels conflicterende gegevens.
Kortom - dubbel uitvoeren heeft tot bepaalde hoogte zeker zin, maar door de inherente complexiteit leidt het niet tot onfeilbare systemen.
Klassieke moderne ICT
Voor zover ICT nog niet verhuisd is naar de cloud ziet de typische “stack” er nu zo uit:
- Werkplek PC geeft toegang tot een
- Applicatie die draait op een
- Virtual machine die wordt gehost door
- Een grote server die
- Via een netwerk
- Data opslaat op een storageoplossing die
- Net als alle onderdelen, wordt voorzien van stroom
Er zijn variaties op dit thema (vaak is er ook nog “middleware” of een belangrijke database in het spel) maar de kern is constant: een grote keten afhankelijkheden. Als onderaan de storageoplossing blokkeert, of als het netwerk hapert en de storageoplossing onbereikbaar wordt, dan komt werkelijk alles tot stilstand.
Dit is op zich geen nieuws en om dit te voorkomen wordt gepoogd alle onderdelen individueel zo betrouwbaar mogelijk te maken. Storage is voorzien van veel overtollige harde schijven, netwerkverbindingen zijn dubbel, virtual machines kunnen gemigreerd worden naar andere servers etc.
Een typische storing
Een laptop wordt, tijdens een test, dubbel ingeplugd op het netwerk. Hierdoor ontstaat, onbedoeld, een “rondzinger” die na enige tijd door de netwerkapparatuur ontdekt wordt. Het netwerk maakt gebruik van het “spanning tree protocol”, en poogt om de netwerkstoring heen te werken. Dit is mogelijk want er zijn extra kabels in het netwerk aanwezig.
Helaas kost dit automatische proces minuten en gedurende die tijd is de storageomgeving onbereikbaar. Hierdoor komen alle virtual machines tot stilstand, op een zeer onprettige manier. Na enige tijd worden deze VMs uitgeschakeld tot het probleem opgelost is.
Als na geruime tijd bekend is waar de storing door kwam blijkt dat de diverse virtual machines niet zomaar herstart meer kunnen worden daar onduidelijk is in welke toestand deze zich bevinden.
En vervolgens is alles dagenlang ontredderd.
Eenvoudigere ICT
Het bovenstaande scenario klinkt pijnlijk, maar de beschreven architectuur is op dit moment ‘best practice’. Afwijken van deze norm vergt veel moeite. Vrijwel alle betrokkenen zullen twijfels hebben want “iedereen doet het zo”. Centrale storage levert, zegt men, grote kostenbesparingen op. Virtual machines maken veel efficiënter gebruik van hardware, dus het is vrijwel verplicht deze te gebruiken inmiddels.
Maar vergelijk een bovenstaand systeem met een individuele computer voorzien van eigen opslag en een kopie van relevante data. Deze heeft, behoudens stroom, niets nodig om in de lucht te blijven. Indien uitgevoerd als laptop kan er zelfs geruime tijd zonder stroom gewerkt worden.
En, vergelijkbaar met de “tweede printer” of “zevende ambulance” uit het begin van dit artikel, is het uitstekend mogelijk meerdere van dit soort standalone systemen te hebben.
En natuurlijk kent dit nadelen, maar in andere landen hebben ziekenhuizen wel dit soort oplossingen om door te kunnen gaan bij grote storingen. Ook enkele ziekenhuizen in Nederland blijken een “nood electronisch patiëntendossier” te hebben.
Hoewel we pogen “99.999%” bedrijfszekerheid uit onze ICT te halen is het realistischer om te accepteren dat het soms misgaat en dan een onafhankelijk “Plan B” te hebben, want “Plan A” valt gegarandeerd een keer uit.
Complexiteit
Complexiteit ligt overal op de loer - iets wat begon als een eenvoudig netwerk wordt in de loop der tijd uitgebouwd, met de beste bedoelingen, tot een heel circus.
Systemen die eerder onafhankelijk waren worden, onder druk van bezuinigingen, samengevoegd op grotere en complexere computers.
En waar eerder systeembeheerders in staat waren om een toepassing over te zetten op een backupsysteem kiest men er voor om een veel complexer ‘multi-master’ systeem neer te zetten dat dit automatisch zou kunnen doen, want we hebben geen capabele systeembeheerders meer in dienst.
Complexiteit is de vijand van hoge beschikbaarheid.
Service Level Agreements
Hier knettert het. Ik heb bovenstaand gemeld dat het altijd een keer fout gaat, en dat het niet haalbaar is zeer hoge betrouwbaarheid te krijgen met complexe systemen. Maar, hoe kan dit, want met alle leveranciers en partners zijn strenge Service Level Agreements (SLA’s) afgesproken. Het kan toch niet dat die allemaal liegen?
Nou wil ik daar niet al te veel over zeggen, maar wel over iets anders - bekijk een contract eens op wat er nou precies gebeurt als een SLA niet gehaald wordt. Dat valt vaak nog niet mee want ervaren leveranciers tuigen een heel circus van definities op waardoor het niet eenvoudig is om te bepalen of een SLA nou wel of niet gehaald is. Recentelijk wist een reputabele partij een storing van twee weken te presenteren als ‘SLA gehaald’, om een voorbeeld te noemen. Kwestie van handige definities. Veel SLA’s garanderen overigens alleen een responsetijd (‘inzet’), en niet daadwerkelijk een oplossing.
En zelfs als bepaald is dat de leverancier niet aan de eisen voldaan heeft blijken de gevolgen vaak minimaal - korting op de volgende bestelling bijvoorbeeld.
Met andere woorden, een dienst die afhankelijk is van meerdere “99.99%” SLA’s tegelijk zou in werkelijkheid deze betrouwbaarheid mogelijk helemaal niet kunnen halen, en dat vaak zonder (ernstige) gevolgen voor leveranciers.
(terloops, zelfs als er stevige boetebedingen afgesproken zijn, dan maken die de downtime bij “ICT van levensbelang” nooit goed).
Afsluitend
Voor echte hoge beschikbaarheid is het niet voldoende om ‘best practices’ uit de kantoorautomatisering toe te passen. De ketenafhankelijkheid van netwerken, databases, servers, storageoplossingen en stroom is zo groot dat de “99.9%” niet langdurig waargemaakt kan worden.
Kies in plaats daarvan waar mogelijk voor systemen die eenvoudiger zijn en meer op zichzelf staan. Geloof minder in onfeilbare netwerken en perfecte storage, en meer in “niet alle eieren in één onvernietigbaar mandje”.
Ter inspiratie kan ik iedereen bijlage D en bijlage F van het rapport van de Onderzoeksraad aanraden.
En afsluitend, realiseer dat ondanks beste bedoelingen “plan A” toch een keer in zal storten en dat er dan een echt onafhankelijke oplossing moet bestaan om verder te kunnen.