2,6 milliarder kroner. Så stort et tab fik investeringsfirmaet Knight Capital, fordi programmerne, som styrede deres automatiserede børshandler, gik amok d. 1. august 2012. Årsagen var en softwarefejl, der ikke var blevet fundet, inden en ny udgave af programmet blev lagt i drift. Selvom tabet er et af de største direkte tab pga af en it-fejl, er det langt fra det eneste. For mennesker begår fejl, og it-folk er mennesker. Derfor vil der altid være fejl i it-systemer. Men meget kan – og skal – gøres for at undgå dem.

Da rumfartøjet Mariner 1 i 1962 skulle sendes ud til Venus, nåede det ikke langt. NASA var tvunget til at sprænge fartøjet i luften, da det kom ud af kurs og styrede tilbage mod jorden. Bagefter viste det sig, at årsagen var en simpel fejl i dens styringssystemer: I et af programmerne manglede der en bindestreg.

Den type af fejl er sjældne i dag: Udviklerne har værktøjer, der fanger de mest banale fejl i programmerne. Lidt på samme måde som tekstbehandlingsprogrammer kan finde stavefejl. Udviklernes værktøjer kan dog ikke opdage, hvis programmet indeholder andre typer fejl.

Det måtte NASA sande i 1999, da de havde sendt et rumfartøj af sted til Mars. Da Mars Climate Orbiter skulle i kredsløb om planeten, mistede NASA kontakten til det dyre fartøj. Fejlen var svær at opdage for de enkelte udviklere, fandt de ud af bagefter: Det ene hold udviklere havde arbejdet med engelske afstandsenheder som fod og tommer, mens det andet udviklingshold anvendte meter og centimeter som enheder.

Fejlen er slående dum – set i bagklogskabens lys. Det er de fleste fejl i programmer. Men årsagen er sjældent lav intelligens hos den enkelte udvikler. Som hovedregel er årsagen, at det er et komplekst problem, programmet skal løse. Eller at programmerne efterhånden har vokset sig så store, at det kan være svært at gennemskue alle konsekvenserne af en ændring.

Derfor er det nødvendigt at bruge mange ressourcer på at teste, at programmet gør det, det skal, og at der ikke er kommet nye fejl. Antallet af ressourcer, man bruger, afhænger oftest af, hvor kritisk programmet er.

Hos det århusianske softwarefirma Systematic, som leverer systemer til forsvaret og sundhedsvæsenet, fortæller Michael Holm, at op til 40 % af omkostningerne til et nyt produkt anvendes på at teste programmerne.

Software testes på mange niveauer: Programmørerne indsætter normalt såkaldte enhedstests, der kan afgøre om et modul virker. Eksempelvis at 100 divideret med 10 skal give 10. Dette skal suppleres med manuelle tests, hvor personer tester, at det samlede program gør det, det skal, og at der i øvrigt ikke er fejl. En krævende proces, der skal gentages hver gang, en ny version er klar. Derfor suppleres de manuelle tests nogle gange med automatiserede tests, der utrætteligt gentager de samme tests. Hos Systematic sker dette hver nat, så udviklerne hele tiden har et indtryk af, om der er opstået fejl, de skal udbedre.

Hos københavnske SimCorp, der udvikler systemer til store finansielle institutioner verden over, bruges ligeledes omkring 40% på egentlige tests, siger Anders Crillesen. Hertil kommer andre former for kvalitetssikring. Væsentlige dele af test-arbejdet er automatiseret og kan derfor genkøres uden ekstra omkostninger. Der testes både på funktionelle krav – fx om de finansielle beregninger giver korrekte resultater – og på andre faktorer, som at svartiden er i orden.

De fleste it-brugere oplever sjældent egentlige softwarefejl. I stedet er årsagerne til it-problemerne oftest, at personerne, som vedligeholder dem, har begået en eller anden fejl eller undladt at fortælle kollegaerne, hvad de har gjort. Et it-system, som ingen ”piller ved”, er som regel meget stabilt og forudsigeligt.

Software- og håndteringsfejl kan friste mange til helt at undlade at videreudvikle eller opgradere deres systemer. Men det er en stakket frist – lige som hvis man sparer på vedligeholdelsen af sin bil.

Det måtte nyhedsbureauet Reuters sande, da det i starten af august lykkedes hackere at placere en falsk historie på deres hjemmeside, som fortalte at de syriske oprørere var på retræte. Fejlen skyldtes en manglende opdatering af dele af deres tekniske platform, har Wall Street Journal afsløret.

Reuters tab var mest et image-tab. Men andre virksomheder har lidt store økonomiske tab, fordi hackere udnyttede kendte fejl i programmer, som ikke var blevet opdateret. Eksempelvis har et enkelt af de mange vellykkede hackerangreb på Sony kostet dem mere end en milliard kroner. Ifølge virksomhedens egen opgørelse.

Derfor er den eneste forsvarlige vej frem at tage højde for de mange menneskelige fejl, der påvirker vores it-systemer. Den bedste måde er at formalisere de arbejdsgange både udviklere og driftsfolk anvender. Samtidig med at der skabes en kultur, hvor medarbejderne hele tiden lærer af deres egne og andres fejl.
Der er almindelig enighed om disse metoder. Eksempelvis at ITIL (IT Infrastructure Library) er den metode, der bedst beskriver hvordan man gennemfører it-drift og -service. Eller at CMMI (Capability Maturity Model Integration) er en god måde at beskrive en it-virksomheds modenhed.

Men det tager tid at indføre dem. Eksempelvis har Systematic brugt mere end 120.000 timer på at blive certificeret på det højeste niveau i CMMI.

Det kan lyde af meget, og ikke alle behøver at bruge lige så mange ressourcer. Men alle virksomheder er nød til at tage kvaliteten af deres it-systemer alvorligt. Hvis de vil undgå dyre tab i fremtiden.

Bragt som kommentar i Morgenavisen Jyllands-Posten d. 14. august 2012