En trevegg som ikke vedlikeholdes, vil råtne. Det er de fleste klar over. Ikke like mange vet at “råte” kan ramme dataprogrammer også – og tvinge dem i kne eller få dem til å regne feil.
“Digital råte” er feil som programutviklere kommer i skade for å skrive inn. Enten i selve programmet. Eller i såkalte “eksterne systembibliotek”, som drivere – tilleggsutstyr dataprogrammer må ha for å virke.
“Råten” oppstår gjerne under oppdateringer.
Feil i all programvare
I en viss forstand inneholder all programvare feil. Oppdages de mens programkoden skrives, kan de rettes raskt. Men har programmet ligget brakk og er skrevet av folk som ikke er tilgjengelige lenger, kan feilretting bli umulig.
Heldigvis finnes en liste med “forebyggende tiltak” som programutviklere kan bruke for å sikre at feil kan rettes selv i slike tilfeller.
Men denne ligger ikke forrest i pannebrasken hos alle utviklere. Det burde den gjøre. For om listen fravikes, kan følgen bli at et helt nytt dataprogram må lages. Og det koster flesk.
Sløsing med ressurser
I sin tid kostet det over fem millioner kroner å utvikle programvaren vi gjenopplivet. Trass i litt plunder med oppvekkingen, kostet det ikke mer enn 100 000 kroner å få programmet til å fungere igjen på moderne systemer (hovedsakelig tidsforbruk for å tilpasse koden til nye versjoner av eksterne bibliotek).
Om trekonstruksjoner råtner, mister de bæreevne. Også digital råte er skadelig.
Fenomenet kan få regneprogram til å spytte ut gale svar. Siden slike program brukes til å dimensjonere alt fra strømforsyningssystemer til bildeler, kan regnefeil gi sløsing med energi og materialer – i verste fall gå på sikkerheten løs.
Telekluss i Canada
I tillegg kan digital råte få dataprogrammer til å gå ned. En av Canadas største leverandører av internett og mobile tjenester erfarte dette i fjor: Et dyrt mareritt i form av en mange timer lang blackout som rammet nødsamband, transport og banker.
Som fagfolk i prosesskjemi oppdaget vi fenomenet ved en tilfeldighet, i et forskningsprosjekt der vi trengte å blåse nytt liv i et ti år gammelt regneprogram som lå i dvale.
Etter fire uker fikk vi programmet opp i stående. Så kom den avgjørende testen. Ville en gitt beregning gi samme resultat som før? Nei, oppdaget vi.
Liten tue veltet stort lass
I alle beregningsprogram er regnefeil selvsagt uønsket. Ille vil det også være om eksempelvis et system for utbetaling av lønn slutter å fungere dagen før feriepenger skal utbetales.
Feilen i vårt eget program skyldtes en endring av én enkelt bit (binary digit). Altså ikke en forandring av et tall eller en bokstav, men av en liten byggekloss som datamaskiner lager bokstaver og tall av. Feilen oppsto trolig ved oppdatering av et eksternt “systembibliotek”.
Kalddusjen gjorde oss bevisst på hvordan digital råte kan forebygges.
- Brukerne må etterse programmene ved å teste dem.
- I tillegg må programutviklerne lage programmene slik at de lar seg reparere hvis “råten” først har trengt inn.
Som å dra “jorden rundt på 80 dager”
Programvare er som en reiseplan for en tur a la “Jorden rundt på 80 dager”. Da trengs en lang liste med detaljerte instruksjoner om hvordan reisen skal foregå.
Også dataprogram er en serie instruksjoner, som utviklere skriver inn linje for linje. Vår femdelte resept mot digital råte har mange fellestrekk med suksessresepten for en global “80-dagerstur”:
- Brukerne må følge testprosedyrer når et dataprogram endres. Det er like viktig som å teste kjøleanlegget i SUV’en før du krysser Sahara.
- Har programmet “bærebjelker” andre rår over – altså eksterne “bibliotek – må du som bruker være sikret at du kan koble deg over på alternativt “tilleggsutstyr”. Ellers er det som om luftrommet stenges på reisen din, og du ikke har båt- eller togbillett i bakhånd.
- Er programmet skrevet i et standardisert språk, gjelder standarden alltid. Nettsider som en stund kun virket i Internet Explorer, var resultatet av en synd mot denne regelen. Skrives “reisebestillingen” i et ikke-standardisert språk, gjelder spesielle regler.
- Like viktig som testing, er dokumentasjon som forklarer hvordan programmet er tenkt å virke, ikke hva koden gjør i detalj.
- Hold orden når programvare endres over lang tid. Publisert forskning fra SINTEF viser at kjappe løsninger («tape og ståltråd») over tid kan skape så mye rot at systemet slutter å fungere som tenkt. Botemiddel: såkalt “refactoring” – vedlikeholdsarbeid og opprydding i koden.
En mer sirkulær økonomi er en av reseptene på økt bærekraft i de fleste bransjer. Fempunktslista du akkurat har lest er nøkkelen til en ressursbesparende sirkulærøkonomi også på programvarefeltet.
Artikkelen ble første gang publisert på digi.no og gjengis her med nettstedets tillatelse.
