Några ord från Agical

Upptid och nedtid

Ola Ellnestam

Det var en gång …

I en datorhall någonstans på söder, på 90-talet, stod en så kallad stordator och surrade. Datorn i fråga användes för att köra ett kassasystem för öppenvården i Södra Stockholms Läns Landsting. Dess användare visste inte om det, dess driftansvarige hade ingen aning och datorn själv var lika ovetande, men snart skulle kassasystemet inte längre fungera som tänkt.

Klipp till: Ett kontorslandskap. Två IT-tekniker samtalar med varandra. En lång och en lite kortare.

– Jag går in och byter backup-band på filservern …

– Ja … bra, jag hade helt glömt det

Den kortare personen reser sig från sin stol och går mot en kraftig ståldörr. Dörren verkar leda till en datorhall. Teknikern stannar framför dörren och knappar in koden på dosan till höger. *Blipp* säger dosan och teknikern öppnar den tunga brandsäkra dörren och kliver därefter vant över den höga tröskeln in i den svala datorhallen. Luften svalkar skönt på den här ovanligt varma sensommardagen.

Väl inne blickar teknikern mot filserverns bandstation. Ingen av status-lamporna lyser. “Skönt, allt har nog gått bra“ tänker teknikern. En snabb blick på backup-bandet i högerhanden, följt av en snabb blick tillbaka på bandstationen. Teknikern stannar upp och en viss tvekan infinner sig. IT-teknikern ser något i ögonvrån. Vad är det där? På golvet till höger ligger ett grenuttag som letat sig oroväckande långt ut i den trånga passagen mellan alla datorer. “Här går ju folk hela tiden” tänker teknikern “… och grenuttaget har glidit långt ut från sin position under stordatorerna. Vem som helst kan ju snubbla på sladden när som helst” tänker teknikern vidare.

IT-teknikern petar ledigt tillbaka grenuttaget med foten och går sedan och byter backupband i servern som tänkt. Bytet av band går fort. IT-teknikern hinner till och med kolla att nattens backup har gått bra. Allt detta under en minut. Nöjd med sig själv kliver vår hjälte tillbaka ut i den klibbiga kontorsluften igen och sätter sig för att fortsätta med dagens arbete.

Vi snabbspolar framåt 3 minuter.

Längre in i lokalen reser sig en påtagligt stressad IT-tekniker som ser något äldre ut än backup-bands-hjälten. Med raska kliv tar sig personen in i serverhallen. 7 minuter senare kommer han ut. Svettig, irriterad och hållandes i ett grenuttag.

– Vem faan tryckte på grenuttagets brytare …

Upptid & nedtid

Dom flesta i vår bransch behöver förr eller senare förhålla sig till System i drift. Antingen som ansvariga för själva driften eller som utvecklare av sagda system. I vissa fall både och. Ett IT-systems naturliga tillstånd är “i drift”, då syftet med våra ansträngningar i alla fall borde vara automatiserade steg i en (affärs-)process som hjälper oss och andra i det dagliga arbetet.

System i drift har dock en baksida. En sida som vi ogärna ser.

Driftsatta system har en förmåga att pocka på vår uppmärksamhet. Det uppstår obönhörligen fel, de är långsamma och dom är svåra att förstå. Ni har säkert hört tirader av svordomar som “Vilket jävla skitsystem, det är så sjukt slött … kan någon fixa den här skiten …”.

Problem med system är omöjliga att undvika, för i vårt arbete begås det ständigt nya misstag och behov förändras över tid. Som en direkt följd av dessa omständigheter behöver vi hantera konsekvenserna. I exemplet ovan såg vi hur kassasystemets driftansvarige skyndade in i serverhallen och såg till att få igång kassasystemet igen. Det misstaget var lätt att återhämta sig från och med facit i hand lätt att undvika framgent. “Vi borde valt en grendosa utan strömbrytare, men nu valde vi fel och olyckan var framme. Vi byter dosa.”.

I bästa fall går misstag att förutspå och åtgärda innan dom ställer till stor oreda, men här börjar det råda delade meningar om tillvägagångssätt.

Ska vi

  1. Se till att minimera risken att problem uppstår

eller

  1. Se till att vara snabba att åtgärda problem när de uppstår

För att bringa lite klarhet kan vi använda något av följande mått på driftsäkerhet.

Snittid mellan stopp och Snittid för återställande

Snittider mellan stopp

Snittiden mellan stopp beräknas genom att dividera tiden ett system är uppe med antalet stopp för detsamma.

Produktionstid / antal stopp

Det kan till exempel användas för att jämföra system eller komponenter. Är du ansvarig för driften av ett system är du förmodligen mest intresserad av trenden för ditt system.

Snittid för återställande

Snittiden för att återställa ett system är lika lätta att räkna på. Såhär gör du då.

Total nedtid / antalet stopp

Samma sak här. Det går att jämföra system med varandra. Ju fler likheter dom har desto rimligare är det att jämföra dom. Återigen är du förmodligen mest intresserad av trenden för systemet du är ansvarig för.

Det finns alltså olika sätt att angripa driftsäkerhet. Du kan försöka minska antalet stopp. Då behöver du “spå in i framtiden”. Eller så kan du korta nedtiden. Då behöver du bli snabb på att återställa system.

Tillbaka till Kassasystemet

I ett fikarum någonstans på Söder, nära en datorhall, för över 20 år sedan.

– Ge idioten sparken, sånt här får bara inte hända …

– Ta det lite lugnt nu …

– Vaddå ta det lite lugnt, hade det inte varit för den där karate-sparkande-pc-sprätten så hade det här aldrig hänt …

– Jo, men har du tänkt på att det kanske var en klantskalle som valde ett grenuttag med en vipp-brytare …

– Jo, men i så fall så kanske någon skulle sett till att det fanns ett ordentligt antal RIKTIGA STRÖMUTTAG. Då hade inte ett grenuttag behövts …

Trots dieselaggregat, skalskydd, dubbla hårddiskar, en massa andra åtgärder och goda avsikter sköts kassasystemet i sank. Vår backup-bands-hjälte, driftansvarig för kassasystemet, personalen på Vårdcentralerna och en och annan chef andra lärde sig nog del den där olycksaliga dagen för över 20 år sedan.

Så, vems fel var det?

Nja, det kanske inte är så lätt som att hitta den svagaste länken i ett system? Vi behöver nog göra något annat.

Byt fokus

Att hitta en kedjas svaga länk är mycket lättare i efterhand. Att hitta någon att skylla på är också lättare i efterhand. Fast det leder inte till lika stora förbättringar som att bli snabb på att återställa system. Om du i stället för att skälla på folk och leta fel och brister byter fokus till att bli oerhört snabb och effektiv på att återställa system. Då har du i ett slag undvikit fällan att begränsa dina medmänniskor till att försvara sig, samtidigt som du skapar förutsättningar för stora förbättringar.

Att återställa system tillsammans är dessutom en mycket mer tillfredsställande och kreativ process än att tvingas försvara sina misstag.

Ola Ellnestam

Ola Ellnestam fascineras av kombinationen datorer och människor. Det har han gjort ända sedan han spelade River Raid på sin kompis C64. I början trodde han att programmering av datorspel var hans kall här i livet, men insåg snart att det fanns något än mer intressant. Dynamiken kring hur datorprogram uppstår.

I sin iver att bli bättre på att underhålla IT-system upptäckte han en sätt att hantera krångliga kodbaser. Det sättet finns beskrivet i boken “The Mikado Method”. Numera försöker han lista ut hur vi kan ha kul tillsammans, samtidigt som vi programmerar.

Vill du lära dig mer om Olas syn på IT-system. Hur de blir till, hur de ska hållas i gott skick eller kanske till och med hur de ska pensioneras med värdighet. Sätt en gul nejlika i kavajslaget Kontakta honom med frasen “En Appedemi verkar vara i antågande”.