I høst kjøres fordypningsemnet i drift TDT43, der vi skal gå igjennom ITIL v3 - det er ikke det samme som driftsfaget, som går på våren. Det er strengt tatt bare for femteklassinger i datateknikk, og det er bare meg og én student. Vi kommer til å kjøre det som en seminarserie, og dersom det er noen med nysgjerrighet, litt driftserfaring og deltakervilje som ønsker å kaste seg med, så kontakt meg. Da blir vi litt flere og diskusjonen går glattere og vi får flere vinklinger. Vi legger nivået på kurset i henhold til den formelle studenten, men det er sikkert noen rundt om som er på tilsvarende nivå, og som derfor kunne ha glede av å delta.

Vi bruker boka Foundation of IT Service Management Based on ITIL V3, og kommer til å ta ca ett kapittel pr uke, muligens med litt ekstra støttelitteratur som deles ut etter behov. Undervisningsformen er to timer pr uke. Hver dobbelttime starter med en kort presentasjon av kapittelet og deretter diskusjon. Alle som deltar forventes å ha lest kapittelet og på forhånd ha formulert en håndfull innspill til diskusjonen: problemstillinger, uklarheter, synspunkter, erfaringer, mangler, styrker, snubletråder osv.

Første dobbelttime er fredag 5. september kl 13.15-15.00 på Gløshaugen, rom IT-Syd 236. De resterende dobbelttimene blir på en annen ukedag, men tidpunkt er ikke bestemt, og evt deltakere kan komme med innspill. Tema for første dobbelttime er kapittel 1 og 2 i boka.

Dersom du er interessert i å delta, så send meg mail til anders@idi.ntnu.no. Det er fullt mulig å delta uten å ta eksamen - faktisk er det sannsynligvis ikke mulig å ta eksamen for andre enn de som formelt har kurset på timeplanen :-) Det er også fullt mulig å delta på bare noen av seminarene, ja til og med bare ha ambisjoner om det. I det høyst usannsynlige tilfellet at det flommer over med ønsker om å være med, så kommer jeg til å sette et tak på antall deltakelse.

Rune Andersen på IME ble nettopp tildelt tilgjengelighetsprisen for 2008 fra en eller annen instans ved NTNU med venner - jeg fikk ikke helt med meg hva eller hvem.

Når det deles ut slike priser, så tenker jeg umiddelbart: jaja, det er aldri noen jeg kjenner som får dem, og sjeldent for noe jeg synes er viktig. Men ikke slik denne gang!

Rune fikk prisen for å lage maler og gjøre websidene ved NTNU mer tilgjengelige. Han skal ikke lastes for mange av teknologivalgene ved NTNU, for hans banehalvdel er stort sett IME, samt der han har klart å komme i inngripen med NTNU sentralt. På IME har han latt være å bruke de store, interne, endringstunge, database(mis)brukende, dyre CMS-ene som ingen liker, og i stedet implementert alle websidene i en Wiki. Det er slikt man ikke alltid blir populær av, men hver gang noen har påpekt at noe ikke kunne gjøres i Runes system, så har han svart «vent litt» og så har funksjonaliteten vært der.

Rune har jobbet hardt for å følge standarder, lage maler som er renslige, ryddige, modulære, utvidbare og alle de andre tingene som vi ikke alltid finner på websider. For ham er det ikke tilstrekkelig at det fjongt og fancy ut i ens egen webbrowser, men det skal være riktig etter en standard, det skal være portabelt mellom ulike browserimplementasjoner, og koden skal være ryddig, selv om knappest noen kommer til noensinne å se på den.

Gratulerer, Rune!! Og gratulerer NTNU for at man også har satt søkelyset på at konstruksjon av websider ikke bare er en lekegrind for «webdesignere», men et område der man må tenke tilgjengelighet, skalering, standarder og slikt!

Sukk. Akkurat nå har jeg 50% oppetid på nettverket hjemme, fordi nettverksmodemet fra Bluecom fungerer annethvert halvminutt. Ja, du leste rett. Dersom jeg pinger, så kommer ca 30 pingpakker gjennom, så det ca 30 som ikke kommer igjennom, så kommer ca 30 igjennom ... og det hele repeterer seg ad neuseam. Eller rettere sagt, slik hangler det en periode på rundt en halvtime, så er nettet ok en halvtime, så og så repeterer dén rytmen seg over en periode på rundt seks timer. Vanligvis går det noen dager mellom hver gang vi har en slik periode.

Det er nærmest som tortur å regne. Når jeg har tid til å feilsøke, så er alt ok, mens når jeg har det travelt, går den inn i sykler på halvminutter oppe og nede. Derfor jeg har aldri fått feilsøkt det skikkelig. Og med litt planlegging, så overlever jeg det alltid. Jeg har utviklet en teknikk med auditable pings og multitasking, så når det plopper i høyttaleren så kontekstsvitsjer jeg over til den oppgaven som trenger nett - i 30 sekunder. Det er en overdrivelse å si at det er en behagelig måte å jobbe på: ikke er det effektivt å kontekstsvitsje oppgaver to ganger per minutt, og heller ikke er det behagelig å sitte å lytte til plingingen, men det går ...

Tidvist har det fungert å boote ADSL-modemet, men det fungerer visst ikke lengre. Jeg tror det er noe som går i metning eller krasjer eller noe slikt, og så tar det ca 30 sekunder å resette. Det er heller ikke slik hele tiden. Grafene under viser hvordan det går i perioder, for siste halvannen dag og siste halvannen uke. De måler tiden frem til først og siste overførte byte i en wget fra en webside på NTNU.

Men nå er snart tålmodigheten slutt - hvilket betyr at nettet kommer til å virke prikkfritt i et par dager. Jeg kjenner blodtrykket stige bare ved tanken på å skulle kontakte en telefonkundeservicesenterhelpdesk for å forsøke å forklare dette feilmoduset. Det har virket som om det er en tendens til at det er verst på natta, enten frem mot midnatt eller like etter - så det er ikke helpdeskserviceåpningstidsvennlig. Som allerede nevnt er det heller ikke repeterbart på kommando, så det er et feilsøkingsmareritt.

Det er et feilmønster som ikke kunne vært mer frustrerende om det var ondsinnet designet av mine verste fiender. Det enkleste er vel å innse at Bluecom var et dårlig teknisk valg, og skifte til ny leverandør. Arrrrrgh!

Limoncelli og Hogan har - sammen med Strata Chalup som ny medforfatter - kommet med ny utgave av «The Practice of System and Network Administration», og dermed har jeg et valg foran neste års TDT4285-fag. Skal jeg bruke den nye boka, eller skal jeg velge en annen bok.

Den nye utgaven har vært annonsert lenge. De siste 2-3 årene har den kontinuerlig lagt omkring seks måneder frem i tid ... vanligvis et dårlig tegn. En kjapp blading i den viser at det er noen nye kapitler, og endel tillegg her og der, men generelt sett er det ikke de store fundamentale endringene. Prisen er også stiv, på 536,- men det er likevel billigere enn den forrige utgaven.

Alternativet er å bruke «IT Service Management based on ITIL - an introduction», som er på overkommelige 240 sider og rundt 330,- på Amazon, og full av presise definisjoner og TLA-er. På mange måter er den diametralt motsatt av Limoncelli-boka, for der Limoncelli formidler at det viktige er å gi deg som systemansvarlig en forståelse som du kan tilpasse og bruke i fremtidige situasjoner, så er ITIL-boka tilsynelatende et presist kart for hvordan en driftsenhet bør fungere. På et overordnet nivå er de egentlig ikke så forskjellige i filosofi, men i presentasjon og fremtoning er de ekstremt forskjellige.

Jaja ... livet er fullt av valg. Er det noen gamle studenter som leser denne bloggen og kan komme med råd og forslag til hvilken bok som er mest hensiktsmessig?

Det er mangt og mye man opplever. I lunsjen idag fortalte en av lunsjkameratene mine om en fyr hos seg som kom med en dyr, halvannet år gammel bærbar. Den hadde svart skjerm ... hvilket ikke er helt uvanlig. Etterhvert kom det frem hva som hadde skjedd. Familiens katte hadde pisset i den bærbare PC'en.

Hva gjør så denne personen (som er fast vitenskaplig ansatt på et institutt som har elektronikk som fokusområde)? Jo, han vil tørke PC'en, og den beste måten er å skru på strømmen, så det blir varme i elektronikken slik at kattepisset tørker opp, og en vifte som kan blåse det ut ... tenkte han. Etter lunsj skal de forsøke å ta ut harddisken og se om de i det minste kan få ut dataene.

Og sånn går dagene.

Man kan se på automatisering som en løk med flere skall, eller med flere lag eller nivåer. Innerst inne er kjerneaktiviteten i automatisering, men uten de ytre lagene blir det pislete og stakkarlige greier. La meg forklare:

• Innerst inne ligger funksjonaliteten. Dersom ikke en automatisert oppgave faktisk løser oppgaven som er målet, så er og blir den dysfunksjonell samme hvordan du snur og vender på det. Dette er gjennomføringen, og de som tror dette er alt det er ved automatisering, har misforstått noe fundamentalt.

• Neste nivå er stabilitet, som er et systems evne til å fortsette å virke over tid. Det motsatte - et ustabilt system - er noe som mer eller mindre faller sammen av seg selv. Stabilitet er viktig i en automatisert oppgave fordi den skal fortsette å kjøre gang på gang i overskuelig fremtid, men det tar tid og testing å sikre at den automatiserte oppgaven er stabilt spesifisert og programmert.

• Tredje nivå er robusthet, som er beslektet med stabilitet, men allikevel fundamentalt forskjellig. Med robusthet menes et systems evne til forsatt å virke selv om omgivelsene rundt det endrer seg. Et stabilt korthus fortsetter å stå av seg selv, mens et robust korthus i tillegg takler at du puster på det og rugger litt i bordet. Stabilitet er viktig for en automatisert oppgave fordi miljøet det skal kjøre innen, garantert kommer til å endre seg over tid - du har kanskje ikke planlagt endringene ennå, men de kommer!

• Det fjerde og siste nivået er elegant feiling. Det betyr at når systemet tross funksjonalitet, stabilitet og robusthet allikevel ikke kan fullføre oppgaven sin, så sier det ifra på en grei og informativ måte. Ting som den ikke har blitt programmert til å takle, skal den heller ikke forsøke å ordne.

Jeg misliker automatiserte jobber når de inntrengende, repeterende og pågående forteller meg om alt som er normalt. Jeg har allerede nok avbrytelser og oppmerksomhetsavledninger i arbeidsdagen til at jeg trenger noe som støyer bare for å fortelle meg at alt er i orden. Nettopp derfor er det viktig at en automatisert jobb holder kjeft sålenge alt er i orden, og kun skriker opp dersom noe er galt. Enkle, hyppige og lettolklige feil bør den settes opp til å håndtere selv, mens de øvrige bør videresendes til en systemadministrator i mest mulig ordrett kopi og med best mulig bakgrunnsinfo. Manuell, inkrementell tilpassing av den automatiserte oppgaven over tid er den enkleste måten å gjøre den stabil og robust på.

Dette betyr ikke at jeg har noe imot statistikkrapportering og logging av at alt er greitt. Det må imidlertid skilles skarpt mellom to ting som har hvert sitt bruksområde: På den ene siden er det som er tilstandslogging som en systemadministrator kan oppsøke for rapportgenerering eller post-mortem debugging. På den andre siden er det som varsler om at noe er galt, og som systemadministrator bør få som avbruddshåndtering.

Ikke misforstå meg dithen at jeg har noe i mot proaktivtitet, tvert imot! Men jeg observerer at proaktivitet er noe som 'alle' skryter av men 'ingen' gjør. Med proaktivitet mener jeg i forbindelse med problemer å handle før de negative konsekvensene har sprunget ut og rammet brukerne. Proaktivitet er hva som ligger bak ordspråket 'bedre føre var enn etter snar'.

Det vanligste er det motsatte av proaktivitet: nemlig reaktivitet. Man fikser ikke doseringene i en sving på E6 før man har fått dødsulykker der, man trekker ikke et produkt fra markedet før man har sett at det er utrygt, man skifter ikke strømforsyningen før man merker at den ikke lengre virker.

Årsaken til dette er kanskje at det er så ufattelig mange ulike feil som kan oppstå, at man av ren matthet ignoreres de fleste. Oftest går det jo allikevel bra, og alternativet er vanligvis å bruke mye ressurser på noe man i ettertid 'ikke fikk bruk for'. Derfor satser man på at det er billigere å rydde opp reaktivt for de relativt få crashene som faktisk kommer.

Så er vi ved sakens kjerne:

• Jeg skulle ønske at flere hadde en bevisst holdning til proaktivitet, reaktivitet og balansen mellom dem, og at det er basert på kostnader, ressursbruk, sannsynlighet og konsekvenser.
• Jeg skulle ønske at flere i forkant var bevisste på hva de håndterte proaktivt og hva de planla å ta reaktivt dersom det skulle bli nødvendig.
• Og jeg skulle ønske at flere i etterkant var ærlige nok til å innrømme at dette krasjet fordi man vurderte at det totalt sett var billigere å rydde i ettertid enn på forhånd å fikse dette og tallrike tilsvarende problemer.

Og mekanismen er enkel: jo større skadekonsekvenser, jo større sannsynlighet og jo lavere proaktive kostnader; jo lavere er terskel for å bruke proaktivitet helt eller delvis for å unngå eller begrense skaden.

Det finnes noe tankegods som sier at større er bedre: dvs at om man er stor så er det lettere å håndtere ulike mer eller mindre uforutsette situasjoner ferie, sykdom, ansatte som slutter osv. Jeg kunne tenke meg til å erklære meg delvis uenig i dette, og la meg forklare hvorfor.

For det første, det er ikke konseptet om stordriftsfordeler jeg misliker. Stordriftsfordeler er ekte og reelle. Det er ideen om at om man er stor, så er man mange personer, og derfor har man lettere for å absorbere uforutsette ting. Jeg tror det er en logisk feilslutning av typen pose-og-sekk. Den går vanligvis slik:

1. Jo større du er, jo flere personer har du ansatt. Joda, jeg er enig i den, ikke fordi det nødvendigvis er en universell sannhet, men mer fordi det er en tommelfingerregel som er beskrivende for hva vi stort sett kan observere.

2. Når du har mange ansatte, så kan du la de ansatte kunne gå i dybden, slik at de kan bli eksperter som kan tingene godt i stedet for at de kan litt om alt, men ingenting skikkelig. Jepp, jeg er enig i det også, ikke minst fordi du har et større bruksvolum dersom du er stor, så de ansatte kommer bort i flere og mer varierte utfordringer. Dessuten er det mange kostnader som skalerer sublinært med bruksvolum, så som opplæring.

3. Når du har mange ansatte, så vil frafall av en person gjennom sykdom, ulykke, oppsigelse eller annet gi en mindre innvirkning på virksomheten. Tja, isolert sett er jeg jo enig i det, for det virker innlysende at om du mister en av hundre, så gir det mindre konsekvenser enn om du mister en av to.

Der hvor dette brister, er mellom andre og tredje påstand, for de er ikke kompatible seg imellom. Du kan ikke både la dem fokusere i dybden på et snevert område (spisskompetanse) og samtidig flushe dem rundt etter kortsiktige behov (krever breddekompetanse). Det er bare når du har svært arbeidsintensive (i motsetning til kunnskapsintensive) oppgaver, dvs der mange gjør samme jobben, at dette vil virke. Men det er jo det motsatte av ta ut en stordriftsfordel slik som vi oppfatter det innen IT-drift. Med andre ord, Trondheim parkering kan gjør det med parkeringsvaktene, og MacDonalds kan gjøre det med ekspeditørene, men en stor IT-bedrift kan ikke gjøre det, kort og godt fordi de ikke har mange ``like'' personer med samme kompetanse og bakgrunn.

Tvert imot, det aller siste du ønsker om du er stor og mangler en person eller to i avdeling A, er å ``låne'' en person fra avdeling B. Det sprer bare problemet, uten at du er sikret at det blir løst i avdeling A. Jo dyktigere den personen du flytter er, jo større er sjansen for at problemet sprer seg. Jo mindre dyktig personen er, jo større er sjansen for at det ikke er tilstrekkelig eller bare forverrer situasjonen.

For at dette skulle kunne fungere, så må alle avdelinger ha en visst overkapasitet (eller i det minste en viss sikkerhetsmargin) som kan spises opp av andre etter behov. Men en stor del av ideen med stordrift er å skrelle bort sikkerhetsmarginene og overkapasiteten. Man skal effektivisere bort og strømlinjeforme.

Se på en vilkårlig stor bedrift - det behøver ikke å være en IT-bedrift. Generelt sett: jo større de er, jo mer stresset, oppjaget og kjemisk renset for overkapasitet og slingringsmonn er de. Det er først når du kommer i liten organisasjon at breddekompetansen gjør det mulig å flytte folk mellom oppgaver, og størrelsen gjør det mulig å ha oversikt nok til å kunne omprioritere.

Og hvorfor snakkes det bare om stordriftsfordeler? Hvorfor er det ingen som snakker om smådriftsfordeler eller stordriftsulemper?

Så kom den da, rapporten fra Sølvbergutvalget. Den er i alle fall lagt for alle ansatte og studenter ved IME, så da er den vel å regne som offentlig. Det er mye spennende i den, og kanskje jeg kommer tilbake til mer senere, men la meg først ta tak i det viktigste, hva rapporten sier om ``sentral'' og ``lokal''.

Det store gjennomgående temaet ved NTNU har de siste 20-25 årene har kunne oppsummeres med ``sentralt eller lokalt''. Da jeg begynte her i 1985, så hadde IDT (en delforløper til IDI) allerede året før sparket ut Runit av grunnopplæringen innen IT (eller EDB som man sa dengang), og faset over fra Fortran på Nord-10-anlegget til Pascal på IBM-PC-maskiner. Allerede den gang kranglet man så filler og minnebrikker flagret om IT skulle være sentralt eller lokalt, og evt hva slags fordeling det skulle være mellom dem. Og for å gjøre en meget lang historie kort: det holder man fremdeles på med.

Hva sier så Sølvbergutvalget om dette? De gjør noe nytt og ganske genialt. Først formlerer de problemstillingen: ``Skal IT-tjenestene organiseres lokalt eller sentralt?'' og så kommenterer de: ``Utvalget mener det ikke finnes enkle og endelige svar på [dette] spørsmål[et].''

Verdensoppfattelsen vår består gjerne av enkle todelinger, og Sølvbergutvalgets rapport introduserer en ny todeling som en erstatter til den gamle lokalt/sentralt-todelingen. Den nye todelingen går mellom ``primærprosessene'' og ``sekundærprosessene''. Når jeg underviser i faget mitt deltar jeg i en primærprosess, mens når jeg tar backup av hjemmekataloger deltar jeg i en sekundærprosess.

Primærprosessene er det som er direkte relatert til forskning, undervisning, formidling og nyskaping - mens sekundærprosessene er det som er relatert til det som støtte opp under primærprosessene. Bjørn Østby liker å fortelle om en episode fra ``Javel, hr statsråd'' der St Andrew's Hospital hadde 2000 ansatte men hverken pasienter eller leger. Departementsråden forstod dette meget godt, for det var tross alt en kompleks og vanskelig oppgave å drive et hospital, om man ikke i tillegg skulle ha leger og pasienter å bale med. Det er et ekstremt eksempel på en organisasjon med bare sekundærprosesser og ingen primærprosesser.

I innstillingen fra Sølvbergutvalget tenker man altså ikke lengre på om man jobber sentralt eller lokalt (altså hvor på organisasjonskartet), men om man jobber med primærprosesser eller sekundærprosesser. I det ligger også at man kan jobbe med begge deler. Da har man ulike roller i ulike prosesser. Jeg har det når jeg underviser og når jeg tar backup. Det er viktige at, primær- og sekundærprosesser må ikke mistolkes som et synonym til viktige og mindre viktige oppgaver, men bare som en referanse til hvor nært en står NTNUs hovedformål, eller som de sier på engelsk: ``where the rubber meets the road.''

Og så kommer vi til det hvor Sølvbergutvalget vil endre på ting: det skal bli primærprosessene som skal legge premissene for sekundærprosessene. Med andre ord, IT er noe som en IT-ansvarlig implementerer, men ikke bestemmer mål og rammer for. Det er noe der proffer og studenter stiller kravene, og der IT-ansvarlig oppfyller dem.

Det er også en annen endring her, for hvor vi før har vært enten lokale eller sentrale, så er vi nå alle sammen deltakere i sekundærprosessene - enten vi jobber på instituttnivået, fakultetsnivået etter på NTNU-nivået. Kanskje er det forskjeller i antall indireksjonsnivåer til primærprosessene, men vi er allikevel alle sammen i sekundærprosessene.

Det kan kanskje være like så bra med denne begrepsendringen. Jeg har alltid mislikt merkelappene ``sentralt'' og ``lokalt''. Ord har alltid konnotasjoner, og satt på spissen kan man oppfatte ``lokalt'' som noe smått, noe tuslete, noe dilletantisk, noe hjemmesnekret, noe enkelt, noe billig, noe perifert, noe uvesentlig, noe irrelevant og noe som er uvesentlig i det store bildet. Mens ``sentralt'' har konnotasjoner til noe som er stort, noe viktig, noe komplekst, noe fjernt, noe dyrt, noe som er i samhandling med alt og alle, noen kompetansekrevende, noe omfattende.

Dette er den store, fundamentale endringen i Sølvbergutvalgets rapport. Alt det andre er enten bare opprettholdelse av status quo eller endringer for å implementere dette ene, store endringsgrepet.