Det er et slidt eksempel, men Danske Bank overlevede rent faktisk at være nede i primetime i flere dage.
Og alle overlevede det store strømsvigt på Sjælland for et par år tilbage, mens flere og flere overlever nedetid i telefonsystemerne (det fandtes ikke, før IP kom til).
De meget få, der vitterligt ikke kan leve med nedetid, må anskaffe diverse dimser til at sikre høj oppetid ved hjælp af disaster recovery-sites, realistiske testsystemer, clustre, koderedundans, og hvad ved jeg.
Invester store beløb
Frem for alt skal de investere rigtigt store beløb i opfostring og vedligeholdelse af mennesker, der kan holde systemet i luften, justere det løbende og holde sig i form med øvelser, kurser og brug af realistiske testsystemer.
Resten bør ikke anskaffe disse high availability-dimser til at sikre driftsikkerheden, da de alligevel ikke har pengene, tiden og dermed viljen til at vedligeholde systemet (og menneskene).
Det gør mange bare alligevel, godt hjulpet af sælgere fra leverandørerne.
Og så får de problemer. Ikke på grund af de enkelte komponenter, men snarere det komplicerede samspil mellem dimserne i teknologistakken.
I efteråret var jeg ordstyrer på et stort møde i England, hvor brugere af noget bestemt oppe-hele-tiden-udstyr diskuterede stabilitet.
Ni måneder om at stabilisere
I gennemsnit havde de været ni måneder om at stabilisere systemet.
Nogle af de helt store bikse havde valgt at bruge de ni måneder, før de satte systemet i produktion, mens andre brugte nogle af de ni måneder, efter at systemet var sat i produktion.
Det er også mere spændende.
Det ironiske ved hele sagen er, at en virksomhed ender med at have et meget mere stabilt system, fordi en masse “moving parts” er fjernet fra systemet, hvis virksomheden indser, at den ikke har råd til ægte oppetid og sagtens kan være nede i nogle timer, uden at alt og alle går henholdsvis bankerot og i hundene.
Hvorfor har vi ikke to motorer?
Hvorfor kører vi ikke rundt med to motorer i vore biler?
Når bilen pludselig standser på vejen mellem Ubbehage og Langmod kan vi bare slå over på standbymotoren.
Og trods den øgede vindmodstand var det måske en ide at have fire ekstra dæk på taget.
Eller endnu bedre: Vi kører aktiv-aktiv motor-konfiguration i motor-clustret, og skulle den ene motor sætte ud, så kører vi bare videre på den anden.
I stedet satser vi dagligt på, at motoren og resten af bilen bare virker.
Vi lever med den indbyggede risiko, at den kan brænde sammen på vej til fødsler, begravelser, et SAS-fly, der går til tiden (ha!) eller bare en jobsamtale.
Hvis vi en dag står med en bil, hvor motoren sætter ud hele tiden, vil vi nok ikke anskaffe en reservebil til at køre bagefter os eller en reservemotor til at have på traileren.
Find problemet og fiks det
Det normale vil være at finde ud af problemet og fikse det og så køre videre på én motor.
Det andet er for rallykørere, der skal tværs over Afrika i et let støvet landskab.
Kompleksitet er tilgængelighedens værste fjende og simplicitet dens største ven.
Af Mogens Nørgaard, administrerende direktør, Miracle.
Computerworlds klummer er ikke nødvendigvis udtryk for Computerworlds holdninger, men er alene udtryk for skribentens holdninger.
