anders lisdorf bloghoved

Ronnie Petterson RIP - Hvordan katastrofer kan gøre vores informationssystemer bedre

Hvad skete sidst jeres firma havde et “nedbrud”? Fejlen blev rettet, og alt fik lov til at fortsætte som hidtil bagefter, antager jeg? Det er en stor fejl. Firmaer i dag er alt for dårlige til at udnytte potentialet i katastrofer. Der er grund til at reflektere lidt dybere over katastrofer, og hvordan vi opfatter dem.

Monza 1978

Det var en glad og afslappet Ronnie Petterson, som var kommet til Monza banen i Italien den 10. september 1978 for at køre årets Formel 1 grand prix. Det havde han også alt mulig god grund til, da han med 51 point kun var lidt efter holdkammeraten Mario Andretti i den samlede stilling om verdensmesterskabet. Med kun fire løb tilbage i sæsonen var det ikke utænkeligt, at han ville kunne vinde med lidt held. Pole position havde hans rival Mario Andretti efterfulgt af Gilles Villeneuve, men Ronnie havde med en tid på 1 min. 38.256 sekunder kun kvalificeret sig til en 5. plads. Han havde haft problemer med bilen, som det var tilfældet i stort set hele hans karriere. Han var vidt og bredt anset, som den bedste formel 1 kører, der aldrig havde vundet et mesterskab. Han var blevet nummer to i 1971 og tre i 1973. Til næste år havde han kontrakt med McLaren, så det så ud til bare at være et spørgsmål om tid før det lykkedes.

Allerede i opvarmningen var Ronnies sorte Lotus med nummer seks forsvundet fra feltet, men man kunne lidt senere se den blonde svensker komme gående med sin hjelm i hånden tilbage til pitten. Han var kørt galt på grund af problemer med bremsen. Han gik hurtigt ind i sin trailer for at kigge på de knubs han havde fået på benene. Nogen havde lavet en fejl, og glemt at sætte en split i. Ronnie måtte derfor finde den gamle bil frem. Det var dog ikke noget stort problem. Faktisk en situation han havde været i mange gange i karrieren, for Ronnie var typen der kørte bilen helt ud til kanten, for konstant at få det ekstra ud af den. Det så ikke altid elegant ud, men det var hurtigt. Han havde sin egen stil, som gjorde ham meget populær. Han var kendt for altid at kunne få det optimale ud af selv sub-optimale biler.

Efter opvarmningsrunden holdt Andretti og Villeneuve klar i spidsen af feltet, da starteren vinkede løbet i gang. Men de bageste biler var ikke kommet til standsning endnu, og havde derfor allerede fart på. Det betød, at der opstod en trafikprop ned mod den første chikane. Ronnie havde af ukendte grunde fået en dårlig start og blev fanget i midten af dette. Han blev ramt af Hunt’s McLaren, og den sorte Lotus kørte ind i barrieren og brød i brand. Det brændende vrag blev katapulteret tilbage ud på banen, hvorefter løbet blev stoppet. Der var biler alle steder. Brambilla var bevidstløs, fordi han var blevet ramt af et dæk. James Hunt sprang ud af sin bil, og sammen med Patrick Depailler fik de hevet Ronnie ud af den brændende bil. En marshal fik tæmmet flammerne, mens Hunt efter at have kigget på Ronnies skader gik og rystede på hovedet. De omkringstående havde prøvet at få ham til ikke at kigge på sine ben, der var helt knuste.

Han blev hastet på hospitalet og de første meldinger var, at han var udenfor livsfare, men sandsynligvis på grund af at lægerne besluttede sig for ikke at operere, opstod der ud på natten en fedt embolisme, som endte med at tage livet af ham klokken 9.55 den følgende dag.

Døden som fast passager

Et af de først minder jeg har, er underligt nok, at jeg efter at have set nyheden om Ronnie Petersons død i fjernsynet løb ud til min mor i køkkenet mens jeg råbte “Ronnie Peterson er død, Ronnie Petterson er død”. Jeg kan huske, at jeg holdt med ham, hvorfor det var en traumatisk oplevelse (den næste traumatiske oplevelse, jeg kan huske fra min barndom, var i øvrigt at Abba brød op… det var jeg også ret ked af, men det er en anden historie. Jeg er kommet nogenlunde over det nu). Grunden til dette har gjort et indtryk er antageligvis, at det var den første person, hvis død betød noget for mig. Når man læser om ham, og ser film, virker han som en utrolig sympatisk, nede på jorden og dedikeret person. Hvilket gør, at selv alle disse år efter giver det et lille stik at tænke på hvordan det endte.

Formel 1 sporten står som et symbol på, hvor langt menneske/maskine udviklingen kan tages med henblik på fart. Formel 1 maskinen booster vores evne til at transportere os fra et sted til et andet. Det er her, hvor de største ressourcer er sat ind på at udvikle biler, der kan køre hurtigt og præcist. Ronnie Peterson var en af de kørere, som havde ry for at have det ekstra, som kunne trække selv en middelmådig maskine op på et højere niveau. Men ulykken illustrerer også meget godt at menneskelige fejl og tilfældigheder altid vil spille en stor rolle i vores omgang med teknologi, for var det ikke for en fejl fra starteren, ville den sekvens af uheld, der ledte til Ronnies død, ikke være sat i gang.

Det var en fejl at løbet blev sat i gang før alle biler holdt stille. Det skabte en harmonika effekt, der ledte til at flere biler end, der var plads til blev presset sammen. Det var en fejl at lægerne ikke opererede med det samme osv. Ulykker er oftest resultat af en kæde af fejl eller tilfældigheder, som ingen kan forudse. Alle maskiner kan fungere som designet, hvilket var tilfældet i denne historie, men stadig resultere i en systemisk fejl på grund af omstændigheder, som ingen designer har tænkt over.

Dette synes at have været et gennemgående træk ved formel 1 i de tidlige år. Patrick Depailler, som var med til at rede ham ud af flammerne, døde selv i en ulykke 2 år senere. Gilles Villeneuve, som havde kæmpet med Andretti i front den søndag i September på Monza, døde yderligere 2 år efter i det belgiske grand prix. Hvis vi kigger statisk på det, tegner der sig også et klart billede: 15 dødsfald i 50’erne, 13 i 60’erne, 12 i 70’erne, men kun 9 efter Ronnie’s død på Monza banen til i dag. Der er tilsyneladende sket noget med sikkerheden i de efterfølgende årtier.

Antifragility

Ifølge filosoffen, investoren og forfatteren Nicholas Nassim Taleb findes en specifik egenskab, der kendetegner den udvikling, som industrier, som formel 1 og luftfarten har gennemgået for at minimere deres ulykker. Det handler om, hvordan man responderer på ulykker. Her er det smart først at kigge på, hvordan det adskiller sig fra “resilience”. Hvis et system er resilient kan det modstå de fleste shock, men forbliver det samme. Et antifragile system derimod bliver bedre, når det udsættes for shock. Det er nok klarest illustreret ved luftfartsindustrien, hvor det har været praksis de seneste årtier at ethvert flystyrt undersøges, indtil man ved hvad der forårsagede det. Derefter tages der stilling til hvilke tiltag, der skal tages for at denne type ulykke ikke gentages.

Efter Ronnie Petersons død synes Formel 1 sporten at have taget en sådan drejning. Det betyder at en hvilken som helt industri, eller system kan vælge at tackle katastrofer på samme måde. En hvilken som helst industri som er plaget af ulykker, ville kunne tage Nicholas Nassim Talebs ide om Anti-fragility og applicere det for at minimere disse ulykker.

Trusler fra teknologien

Informationsteknologi er en sådan industri, som efterhånden er viklet ind i alle andre industrier. Her er der på samme måde som formel 1 i 70’erne alt for mange katastrofer, der kunne være undgået. Men til forskel fra formel 1 er der ingen opmærksomhed på det, nærmest tværtimod. Derfor sker der meget sjældent noget med systemet når ulykker sker. Når vi har et nedbrud i et firma, bliver det sjældent offentlig gjort. Alt for ofte er det også kun en reaktiv respons der gives. I stedet for at undersøge i detaljer, hvordan fejlen kunne være opstået og ændre procedurerne udbedres fejlen, og man er ikke bedre stillet næste gang samme situation opstår.

Årsagen er at i et firma er “operations” ofte meget separeret fra udvikling og anvendelse af IT ressourcerne. Dvs. dem som behandler og undersøger ulykkerne er nærmest klinisk separeret fra dem, som bygger systemerne der fejler. Det er i operations, at arbejderne sidder, og fikser tingene med gaffa tape og WD-40. Der er stort set aldrig nogen form for feedback til udviklingsafdelingen omkring, hvad der skaber problemerne ude i virkeligheden. Det betyder at root cause ikke forsvinder. Udviklerne lærer intet af de fejl der opstår af deres software.

Der er brug for at tænke på samme måde som i formel 1 omkring system nedbrud. Hvis vi i stedet opfattede hver et nedbrud eller kritisk fejl på samme måde som Ronnie Petersons død, ville vi automatisk blive tvunget til at tænke anderledes. Vi ville ikke længere blot ånde lettet op og glæde os over at vores task force proces endnu en gang var effektiv. Det er en del af det, som Taleb kalder "resilience", altså en situation hvor systemet efterlades uændret og ligeså sårbart, som det var før shocket. Hvis vi tænker på et nedbrud, som noget, der havde kostet liv, ville vi uundgåeligt tænke anderledes om det, og handle anderledes.

Vi ville nedsætte en kommision der ville komme med forslag til, hvordan procedurer, standarder eller regler kunne ændres, så ulykken ville have været undgået. Vi ville sørge for at anbefalinger blev behandlet og implementeret i systemet.

Fejl og nedbrud er invitationer til at forbedre designet. Det er i virkeligheden gode kilder til produktudvikling. Man kunne f.eks. starte med at gøre følgende

  • Involver udvikling i fejl processen. Alle udviklere, som har udviklet et system skal have at vide præcist hvad der gik galt, og hvorfor som minimum. En hårdere version er at udviklerne selv skal rette fejlen og klare support sagen. Det kan virke i nogen sammenhænge. 

  • Vælge en ændring til eksisterende prakis. For hvert alvorligt nedbrud skal man vælge minimum en ændring man vil implementere for at sikre at noget lignende ikke sker igen

  • Fokuser på en systemisk tilgang, for ofte er det ikke enkelte systemer som fejler. Der kan sagtens opstå kritiske fejl, selvom alle systemer opererer som designet. Der er nogen som bliver nød til at eje det systemiske ansvar, som går på tværs af selve systemet og den måde det anvendes på samt interaktionen med andre systemer
  • Nedsæt et forensic team til at undersøge og lave en rapport over præcist hvad der skete og hvad årsagerne antages at være
  • Nedsæt et panel, ligesom National Transportation and Safety Board, der undersøger alle luftfartsulykker og kommer med anbefalinger om hvad der skal gøres. Dette panel skulle have autoritet til at implementere ændringer i alle områder af forretningen. Derfor skal det nok gerne have repræsentanter fra elle områder i sig. Det kunne mødes ad hoc.

Heldigvis er vores IT systemer meget sjældent forbundne direkte med menneskeliv. Men vi burde tænke på dem på samme måde som formel 1 racere, der potentielt kan lede til døden af en anden sympatisk fyr som ligner Ronnie Peterson. Derfor skal vi gentænke de procedurer der behandler ulykker, så de kommer til at gøre systemerne stærkere, hver gang ulykker sker.

Kilder:

Fredrik Petersens: The Viking Drivers
Nassim Nicholas Taleb: Antifragile: Things That Gain from Disorder

Kommentarer (4)
Claus Juul

Jeg kan ikke andet end enig.

Jeg fik engang til opgave at drive et system/setup, det sandede til i tide og utide. Jeg fik sat noget overvågning op som holdt øje med de punkter det sandede til (der kom flere og flere til). På den måde fik jeg dokumenteret at der var et problem og hvad problemet/symptomerne var og kunne få allokeret udvikler resurser til at kigge på nogle af problemerne.

I starten var det brugerne der opdagede fejlene først. senere når brugerne mente at der var noget galt, kunne jeg ret let afvise at der var et problem, og operation opdagede typisk fejlene før nogen andre.

Simon Mikkelsen

En forskel på de fleste systemer og racerbiler er, at sidstnævnte er kraftigt reguleret. Der er bl.a. mange, detaljerede og målbare krav til sikkerhed og hvis en bil ikke lever op til dem, får den ikke lov til at køre.

De fleste softwareprojekter er drevet af profit. Ikke nødvendigvis på en grådig måde, men kunden vil jo altid gerne betale mindst muligt og dem der udvikler vil også gerne have løn så de kan betale deres husleje.

Selv når nedetid betyder bod til kunden, kan det være svært at argumentere for at bruge væsentlige beløb på at løse designfejl korrekt, frem for at lappe og håbe den går bedre næste gang. Sådan ville det nok også være i racerbranchen hvis den var styret på denne måde.

Krav kunne være: Et eksternt system har en uendelig svartid eller er nede. Overlev med mindre funktionalitet eller give passende beskeder, men lad være med at hænge og tvinge hele systemet i knæ. Når det eksterne system er oppe, genoptag normal drift, men uden at overbelaste nogle dele.

Jesper Pedersen

Som Poul-Henning Kamp beskriver i den glimrende artikel [1] har software industrien ganske enkelt ingen encitament til at tage fejl alvorligt. Medmindre selvfølgelig at kunderne ikke længere vil betale.
Hvis dette skal ændres, er vi som samfund nødt til at stille de, som tjener penge på at levere software, til ansvar for fejl og mangler i det software de levere.

[1] The Software Industry IS the Problem - https://queue.acm.org/detail.cfm?id=2030258

Kristian Rastrup

Alle Formel 1 teams er også rene profit virksomheder. Det er derfor løbet har reguleret kraftigt for at beskytte kørerne.
Ellers ville teamsene argumentere på samme måde at der kun er tidstab og udgifter ved sikkerhed.
Vi kan gøre det samme i IT

Log ind eller Opret konto for at kommentere