Katastrofala misstag. Vad kan vi lära oss av det? Del 1

Jag samlar på exempel där det gått åt skogen för projekt och jag har ganska många. Jag tänker nu publicera ett axplock av dem i en serie här på bloggen.  Det är mestadels stora och allvarliga problem men det betyder inte att du inte har något att lära, tvärtom.

Man kan ibland förundras över hur det har kunnat gå så fel och få så stora konsekvenser. Personligen så försöker jag tänka ett steg till. Var gick det fel? Varför orsaken till felet inte hittats tidigare? Utan den reflektionen så lär vi oss inte så mycket av andras fel.

Jag kommer att ta upp saker som:

• Varför blir det fel fast vi gjort det förut?
• Varför slutar en programvara som vi och kunderna var så nöjda med att fungera bra?
• Har tid någon inverkan och hur testar vi i så fall det?
• Vad skall hända om det trots allt blir fel? Kan man bestämma det?
• Osv.

Jag tar jättegärna emot fler exempel. Helst med en länk men gärna i text också. Berätta varför du tycker att det är ett intressant exempel.

Ariane 5

”Vi gör det igen”

Ariane 5 exploderade på sin jungfrufärd vilket orsakades av ett dåligt datorsystem. Det finns många lärdomar man kan dra av det här men jag kommer att fokusera på två. Ariane 5 föregicks av Ariane 4 som var en mycket framgångsrik kommersiell raket. Ariane 5 var väsentligt kraftigare och skulle därför kunna ta avsevärt högre last.

Man installerade samma programvara och 37 sekunder efter att den lyfte så förlorades kontrollen. Felaktiga kommandon skickades till styrraketerna och raketen började vobbla. Det gjorde att raketen utsattes för mer krafter än vad den klarade av och den började brytas isär. Men varför kraschade inte Ariane4 som hade samma mjukvara? Pga av att den hade en svagare motor så användes inte alla delar av programvaran vilket gjorde att man inte råkade ut för något fel.

De hade även ett backuppsystem som skulle ta över om det primära fick problem. Problemet var dock att det var exakt samma programvara, med exakt samma fel.

Vad kan vi dra för lärdom av det här?

Du kanske bygger webbsidor för små föreningar och har kanske gjort det 100 gånger förut. Vad kan du dra för lärdom av en 20 år gammal raketexplosion? Flera stycken skulle jag vilja säga men jag tänker fokusera på två.

Men först måste vi fråga oss om det verkligen var ett fel i programvaran för Ariane4. Det som hände Ariane5 kanske omöjligt kunde hända Ariane 4 pga andra begränsningar. Programvaran de använde i Ariane 4 var kanske helt felfri. Det är lite som att förlita sig på best practice, för det brukar ju fungera.

Vi kan omöjligen ha kontroll på allt.

På sätt och vis så hade utvecklarna av raketen det mycket enklare än oss som jobbar med internetuppkopplade produkter. De hade fullständig kontroll på vilken hårdvara och mjukvara som skulle användas. De behövde inte ta hänsyn till att systemet och kontrollklienterna skulle kunna installeras på många olika hårdvaror. De behövde inte ta hänsyn till att andra mjukvaror skulle kunna komma att installeras på samma klient. Ändå gjorde de en sådan generalblunder till en kostnad av ca 370 miljoner amerikanska dollar.

När vi installerar ett nytt system som påminner om ett tidigare så kan vi sällan ha kontroll på varenda liten detalj. De små detaljerna som skiljer kan dessutom vara helt utanför vår kontroll. Vi kan chansa och hoppas på att det fungerar ändå men någon form av test måste vi utföra för att vara säker. Hur mycket resurser vi lägger på det bygger förhoppningsvis på riskerna om vi inte testar. Värre är det om vi inte har råd eller kompetens att testa. Det kan bli vårt livs dyraste besparing.

Vad skall hända när det går fel?

Man måste fundera på vad som skall hända om något blir fel, ett väldigt vanligt sätt när vi pratar om webb är ju att skapa en informativ 404 sida dit besökaren skickas när hen försöker besöka en sida som inte finns. Så behöver man tänka för mycket fler saker. Vad händer om webbsidan överlastas? Skall vi låta den krasha eller har vi ett alternativ? Tex  kan vi göra en sk gracefull degredation och ge besökarna mindre innehåll vilket gör att den klarar avsevärt fler besökare.

Något som är ännu viktigare är att testa vad som inte får hända. En tjänst som attackeras eller används oavsiktligt fel får inte äventyra säkerheten för tjänsten. Ej heller får den ge fel uppgifter. Säkerhetsluckor eller felaktig information kan ofta ha värre konsekvenser än om sajten överbelastas.

UK air traffic control wiped out

”Om något fungerar bra behöver inte betyda att det är bra”

12 December 2014 så lamslogs trafiken från och till Londons flygplatser samt de flyg som passerade detta område. Trafiken stod stilla i en dryg timma och man har räknat ut att det sammanlagda förseningen var 14863 minuter utslaget på 353 flyg. Egentligen inte mer förseningar än vad som händer när det är dåligt väder.

Det som gör den här historien så intressant är att felet som snabbt hittades genom att analysera loggarna fanns i kod som skrevs på 1990-talet. Just det här felet hade alltså funnits i systemet i minst 15 år utan att någonsin ge ett felsymptom.

Vad kan vi dra för lärdom av det här?

Om du inte testar ditt system systematiskt och på ett kompetent sätt så kan det hända att du har en vacker kuliss som du och kunden är jättenöjd med. Men du kommer troligtvis att stöta på allt fler problem ju längre du kommer i programvarucykeln. Du kan få plötsliga systemkrasher, säkerhetsproblem etc och troligtvis då du har som mest last i systemet vilket är precis då du inte vill ha problem. Det kan vara såväl svårt som kostsamt att lokalisera felet och åtgärda det.