När koden havererar: Lärdomar från historiens fem dyraste buggar

När ett litet tecken sänker en hel koncern

Ett mjukvaruhaveri börjar ofta med något som ser löjligt litet ut: ett saknat streck, en felaktig datatyp, en gammal kodrad eller en server som inte fick den nya versionen. Sedan händer det stora. En raket förstörs, ett handelssystem köper aktier för hundratals miljoner dollar eller ett helt nätverk faller över ända. Det är just därför historiska buggar är så lärorika. De visar att ekonomisk skada sällan står i proportion till felets storlek.

Den farliga kombinationen är inte bara komplex kod. Det är komplex kod plus antaganden som aldrig ifrågasätts, otydliga ansvar och en kultur där system förväntas starta och sedan fungera utan motstånd. För den som vill förstå komplex mjukvaruarkitektur och defensiva processer är historien ett praktiskt facit. Målet är inte att hitta en ensam syndabock efteråt, utan att bygga flera oberoende skydd som gör att ett litet fel förblir litet.

Ariane 5 och det ödesdigra antagandet i rymden

Den 4 juni 1996 exploderade Ariane 5 ungefär 39 sekunder efter uppskjutningen. Ombord fanns fyra vetenskapliga Cluster-satelliter, och hela uppskjutningen gick förlorad. Den direkta orsaken var ett så kallat heltalsspill, eller integer overflow. Ett värde lagrades först som ett 64-bitars flyttal men skulle omvandlas till ett 16-bitars heltal. Värdet var större än vad den mindre datatypen kunde representera.

Felet fanns i programvara som hade återanvänts från Ariane 4. Det var inte orimligt att återanvända beprövad kod, men den nya raketen hade en annan flygbana. Den horisontella hastigheten under den tidiga delen av färden var mer än fem gånger högre än i Ariane 4. Därmed bröts ett antagande som hade varit osynligt i den gamla driftmiljön. Oberoende haveriutredningar beskrev hur båda de redundanta tröghetsreferenssystemen drabbades av samma fel, vilket gjorde att redundansen inte längre skyddade raketen. Händelseförloppet finns också pedagogiskt sammanfattat i en teknisk genomgång av Ariane 5:s integer overflow.

Det mest olyckliga var att beräkningen egentligen inte längre behövdes efter start. Modulen var avsedd för justering före uppskjutningen, men fortsatte att köras i ungefär 50 sekunder. När processorn fick felet skickades diagnostisk information vidare som om den vore aktuell flygdata. Datorn stängde sedan ner processorn, och den felaktiga informationen fick styrsystemet att tolka situationen som en fysisk kursavvikelse. Raketen hamnade i en farlig vinkel, boosterarna separerade och den automatiska förstöringsfunktionen aktiverades.

• Återanvänd kod måste valideras mot den nya driftmiljön, inte bara mot den gamla historiken.
• Redundans hjälper inte om två identiska system kan falla på samma sätt samtidigt.
• Funktioner som inte längre behövs bör stängas av, inte fortsätta köras av gammal vana.
• Felhantering måste skilja på diagnostik och giltig styrdata.

Knight Capital och mardrömsminuterna på Wall Street

Den 1 augusti 2012 fick Knight Capital Group ett fel som utvecklades på minuter i stället för dagar. Företaget uppdaterade sitt handelssystem, men driftsättningen blev inte komplett. En av åtta servrar hade kvar gammal Power Peg-kod. Funktionen var tänkt för en äldre handelslogik och skulle inte längre vara aktiv, men en återanvänd flagga råkade väcka den till liv när systemet uppdaterades för ett nytt likviditetsprogram.

Konsekvensen blev att SMARS, Knights orderhanteringssystem, började skapa och skicka oavsiktliga köp- och säljorder. Systemet betedde sig dessutom olika beroende på vilken server som tog emot en order. Under ungefär 45 minuter genomfördes mer än fyra miljoner affärer i omkring 150 till 154 aktier, med hundratals miljoner aktier inblandade. Företagets förlust uppgick till cirka 440 miljoner dollar, enligt New York Times rapportering. Beloppet översteg företagets kvartalsintäkter och slog sönder kapitalbasen.

Det tekniska felet var bara en del av problemet. Det fanns varningar före börsöppningen, men de ledde inte till ett effektivt stopp. Driftsättningen saknade en kontroll som bekräftade att samtliga servrar faktiskt körde samma version. Tester för den gamla funktionen hade dessutom tagits bort efter en ombyggnad, samtidigt som själva kodresterna levde kvar. När teamet försökte återställa systemet rullade det först tillbaka till en version som fortfarande innehöll problemet, vilket förvärrade läget.

• Det som strulade: manuell driftsättning, tyst misslyckande i ett skript, kvarvarande äldre kod och otillräckliga tester.
• Det som saknades: en global versionskontroll, pre-trade-kontroller, positionsgränser och en automatisk circuit breaker.
• Det som fungerar bättre: automatiserad driftsättning med verifiering, små stegvisa lanseringar och feature flags som kan stängas av centralt.
• Det viktigaste skyddet: systemet måste kunna stoppa sig självt när ordermönster, volym eller risk avviker kraftigt från det normala.

Tre andra kodhaverier som förändrade ingenjörskonsten

Historien innehåller fler exempel på hur triviala avvikelser kan få en enorm räckvidd. Mariner 1, som skulle skickas mot Venus 1962, förlorades efter ett fel i överföringen av en matematisk formel. Ett streck, närmare bestämt en felaktigt återgiven markering i ekvationen, saknades i programmet. Styrsystemet beräknade därför felaktiga korrigeringar, och uppskjutningen avbröts. Kostnaden brukar anges till omkring 18,5 miljoner dollar. Händelsen blev ett tidigt argument för oberoende kodgranskning och noggrann kontroll mellan specifikation, formel och implementation.

1988 spreds Morris-masken över det tidiga internet. Programmet var inte utformat som ett destruktivt vapen, men en brist i logiken gjorde att infekterade datorer kunde infekteras igen och igen. Belastningen blev så hög att omkring 6 000 datorer uppskattas ha påverkats, en mycket stor andel av dåtidens internet. Senare exempel visar andra varianter av samma mönster. Intels Pentium-bugg i flyttalsdivision ledde till ersättningar och kostnader på cirka 475 miljoner dollar, medan Y2K-problemet blev dyrt att förebygga eftersom årtal lagrats med två siffror. Den katastrof som många fruktade uteblev till stor del tack vare omfattande förberedelser, men kostnadsuppskattningarna för arbetet varierar kraftigt.

Det som strular gentemot det som faktiskt fungerar

Den gemensamma nämnaren är ofta en start-and-run-attityd. Koden byggs, testas i en begränsad miljö och släpps sedan med förhoppningen att produktionen ska bete sig likadant. Det fungerar tills en hastighet förändras, en server missar en uppdatering, en datatyp får ett oväntat värde eller en gammal flagga återanvänds. Då blir systemets osynliga antaganden plötsligt operativa risker.

Defensiv programmering betyder inte att all kod ska bli långsam eller överlastad med kontroller. Det betyder att systemet ska reagera säkert när verkligheten avviker. Ett felaktigt värde ska avvisas eller isoleras. En ovanligt stor ordervolym ska utlösa stopp. En driftsättning ska vägra gå vidare om en enda instans kör fel version. Sådana spärrar är särskilt viktiga i system där sekunder räcker för att skapa stora skador.

Projektforskning pekar också på organisatoriska risker. Enligt Försvarshögskolans analys av megaprojekt kan orealistiska visioner, maktkamp och en kultur av ständig förändring göra att kritiska invändningar tystnar. Tekniken blir då inte den enda svaga länken. Beslutsprocessen runt tekniken kan vara minst lika sårbar.

1. Gör antaganden synliga. Dokumentera intervall, enheter, hastigheter, datatyper, tidsgränser och beroenden. Ett antagande som inte står någonstans är svårt att testa.
2. Testa den riktiga driftmiljön. Använd realistiska volymer, hastigheter, felmoder och konfigurationer. Testa också vad som händer när bara en del av klustret är uppdaterad.
3. Automatisera sanity checks. Kontrollera att versioner, konfigurationer, datatyper och nyckelvärden ligger inom förväntade gränser innan systemet får börja arbeta.
4. Bygg manuella och automatiska circuit breakers. En människa ska kunna stoppa flödet snabbt, men systemet ska också kunna stoppa sig självt när risknivån passerar en definierad gräns.
5. Hantera teknisk skuld stegvis. Börja med de komponenter som har högst påverkan och lägst observerbarhet. Kartlägg beroenden, lägg till mätvärden, kapsla in äldre kod och ta bort den först när ersättningen är verifierad.
6. Öva på haveriet. Incidentövningar visar om larm, ansvar, rollback och kommunikation fungerar innan en verklig incident tvingar fram svaren.

Bygg en sund säkerhetskultur utan teknisk blindhet

De dyraste buggarna är påminnelser om att ödmjukhet är ett ingenjörsverktyg. Ariane 5 misslyckades inte för att matematiken var för avancerad, och Knight Capital förlorade inte hundratals miljoner dollar för att en okänd naturlag slog till. I båda fallen fanns små, begripliga fel som fick rörelsefrihet i ett system utan tillräckliga spärrar.

En sund säkerhetskultur gör det legitimt att ställa obekväma frågor: Vad händer om bara sju av åtta servrar uppdateras? Vad händer om värdet blir större än väntat? Vilken signal är data, och vilken är bara diagnostik? När får systemet inte starta? Öppna granskningar, oberoende testning och tydliga stoppkriterier gör dessa frågor till en del av arbetet, inte till efterklok kritik.

• Prioritera verifierad robusthet framför förhastad leverans.
• Belöna den som upptäcker en risk innan den blir en incident.
• Gör versionsskillnader och osäkra beroenden synliga i drift.
• Se varje kritiskt system som en kedja av skydd, inte som en ensam kodbas.

Från fail till fix handlar därför mindre om att skriva perfekt kod och mer om att bygga system som tål att koden, miljön och människorna ibland gör fel. När antaganden granskas, larm tas på allvar och stoppknappar faktiskt fungerar kan ett litet tecken förbli just ett litet tecken.