[debian-edu-commits] [Debian Wiki] Update of "DebianEdu/Documentation/nb/ITIL/Delivery" by Anna Kennedy

Sat Mar 21 13:41:31 UTC 2015

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "DebianEdu/Documentation/nb/ITIL/Delivery" page has been changed by Anna Kennedy:
https://wiki.debian.org/DebianEdu/Documentation/nb/ITIL/Delivery

New page:
= Tjenesteleveranse (Service Delivery) =

<<TableOfContents(2)>>

Hovedformålet med tjenesteleveranse er å sikre proaktiv drift og at IT-tjenesten leverer passende støtte for brukerne. Hensikten med tjenesteleveranse er å fokusere på virksomhetens behov. Det er aktiv læring med bruk av IT-verktøy i de forskjellige fagene som er behovet i skolen. Dette kapitlet beskriver i rekkefølge: 

 * Tjenestenivåhåndtering
 * Økonomistyring
 * Kapasitetshåndtering
 * Kapasitetsplanlegging
 * Tilgjengelighetskontroll
 * Driftskontinuitet

== Tjenestenivåhåndtering ==
Vi har oversatt det som ofte er kjent som forkortelsen SLA (Service Level Management) til tjenestenivåhåndtering. Håndtering av tjenestenivå handler om kvaliteten på driftstjenesten. Den måles i forhold til hva som er avtalt i en kontrakt. Det er helt konkrete tall for tilgjengelighet, svartider, brukerstøtte, feilretting osv. 

Målet er å ha styring over tjenestenivået for og forbedre kvaliteten på driftstjenestene. Ved gjentakende runder fastsettes, overvåkes og rapporteres kvalitetsnivået. Hensikten er å forbedre kontakten mellom IT-ansvarlige og brukerne slik at det leveres en IT-tjeneste til avtalt kvalitet. 

Det er viktig å ha et bevist forhold til forskjellig typer SLA-er. Man kan velge mellom mange typer avtaler. Det vanlige er tre typer: 

 * Avtale pr tjeneste for alle kunder 
 * Avtale pr kunde for alle tjenester
 * Avtale pr tjeneste pr kunde

Alle SLA-ene skal administreres, rapporteres på og vedlikeholdes. Det blir fort uoversiktlig og mye arbeide som ikke gir særlig nytte. Hensikten er at man får en avtale som bidrar til å bedre kvaliteten på tjenesten. Derfor er det nyttig å tenke seg godt om når avtalen lages. Her følger en oversikt over hva som er viktig å passe på når man lager en avtale om tjenestenivåhåndtering. 

=== 2.2  Overordnet sjekkliste ===

 * Enighet mellom bruker og driftssenter om hva som faktisk måles. Dette må ses fra brukernes perspektiv og ikke IT-tjenestens perspektiv.
 * Målbarhet og utvetydighet på de måleverdiene som inngår i tjenestenivåavtalen
 * Fastsettelse av realistiske mål for tjenestenivå (det er ingen vits i å love mer enn det man kan holde)
 * Kontinuerlig fokus på kontroll av tjenestenivå - overvåking og periodisk rapportering av oppnådde resultater

=== 2.3  Planlegging ===
Det er helt avgjørende at driftssenteret har tekniske muligheter til å måle de verdiene   som inngår i tjenestenivåavtalen.  Dette må tas hensyn til helt fra begynnelsen.

Videre er det viktig å definere de tjenestene hvor man er avhengig av underleverandører og derfor ikke kan gi garantier for tjenestenivå, eller er avhengig av en tilsvarende avtale med underleverandøren. Definisjonen av avhengigheter gjør man for at det skal være klart hvem som retter opp i problemer, og for å unngå stadige forhandlinger før feil kan rettes. 

Krav til tjenestenivå kan være forskjellig for forskjellige brukergrupper eller under forskjellig perioder av skoleåret. F.eks. kan det være forskjell på lærere og elever, eller at man har høyere tjenestekvalitet under gjennomføring av eksamen.  Det er viktig å ha dialog med alle relevante brukergrupper for å sikre at det som måles er mest mulig relevant for hver enkelt brukergruppe.

=== 2.4  Implementering ===
Det må utarbeides en tjenestekatalog som inneholder alle tjenestene som inngår i tjenestenivåavtalen.  En tjeneste vil ofte være en applikasjon (program) i denne katalogen.  Det vil ofte være forskjellige krav til forskjellige tjenester, og det vil gjenspeiles i forskjellige måltall i avtalen.

Etablering og kontinuerlig justering av brukernes forventninger kan ikke overvurderes.  Ofte vil brukerne ha overdrevne forventninger til systemet og tjenestene som inngår, og det er IT-tjenestens ansvar å justere forventningene ned til realistisk nivå før tjenestenivåavtalen inngås.  Driftssenteret må også passe på at alle brukere faktisk får beskjed  om hvilket tjenestenivå som forventes gjennom avtalen.

For strukturen på selve tjenestenivåavtalen, se 2.6.

=== 2.5  Driftssituasjonen ===
Overvåkning av faktisk oppnådd tjenestenivå og rapportering tilbake til kunden er vesentlig for å bevare en god relasjon mellom driftssenteret og brukerne.  Format og detaljeringsnivå for rapportering skal være håndtert i tjenestenivåavtalen.

Det skal avholdes periodiske (f.eks. kvartalsvise eller halvårlige) møter med kunden.  Fra disse møtene bør det komme konkrete planer for neste periode og f.eks. avtalt implementering av nye tjenester.

=== 2.6  Innhold i tjenestenivåavtalen ===

==== Innledning ====

Navn og kontaktinformasjon for avtalepartene, beskrivelse av tjenestene som inngår, varighet på avtalen, ansvarsforhold mellom kunde og leverandør.

==== Tjenestetid ====

Hvilket tidsrom avtalen gjelder (f.eks. mandag-fredag 08:00 - 16:00), eventuelle spesielle krav for bestemte tidspunkter (f.eks. eksamen), rutiner for å bestille utvidelse av tjenestetiden.

==== Tilgjengelighet ====

Tilgang til tjenestene.  Måles best som den tiden en eller flere tjenester har vært utilgjengelig i en periode (f.eks. en kalendermåned).  Det kan avtales forskjellige nivåer for forskjellige tjenester (f.eks. avhengig av viktighet for brukerne). 

Viktig å presisere at dette er tilgjengelighet innenfor den avtalte tjenestetiden, ikke den total tilgjengelighet hele døgnet, hele uka og hele året (såkalt 24/7/365). F.eks. kan det være avtalt at systemet skal være tilgjengelig mellom kl. 08 til 18 på arbeidsdager, etter det og i helger er det mer usikkert om en kan bruke  datasystemet om ikke annet er avtalt.

Tilgjengelighet handler også om når man får brukerstøtte via telefon eller e-post. F.eks. kan servicekontoret nås mellom kl. 08 og 16 på dagen, eller hele døgnet. Skal man ha mulighet for brukerstøtte på ettermiddag og kvelden, eller i bestemte helger. 

==== Stabilitet ====

Måles ofte som antall ganger med nedetid i en periode eller som gjennomsnittlig tid mellom episoder med nedetid. Man kan også måle tiden det tar før systemet kommer opp igjen. 

==== Brukerstøtte ====
Måles ofte som svartid på telefon (f.eks. 1 minutt) eller e-post (f.eks. 30 minutter) ved henvendelser fra brukerne.  Når driftsoperatør får en henvendelse om brukerstøtte vil meldingen bli kategorisert etter alvorlighetsgrad sammen med tidsgaranti for svar. Det kan også være avtale om hvor fort feilretting skal starte, noe som vil avhenge av hva slags kategori henvendelsen har fått. 

Brukerstøtten handler også om når i døgnet man får tak i folk. Skal brukerstøtten være tilgjengelig i skolens åpningstid mellom kl. 08 og 16, eller skal man også ha brukerstøtte ut over kvelden eller på helgedager. Noen vil ha brukerstøtte også på bestemte helgedager. 

Perioden for når brukerstøtten er tilgjengelig står som regel i tjenestenivåavtalen. Det avtales også om hva brukerstøtten skal hjelpe til med innen for en fast pris, og hva som må løses på oppdragsbasis. Avtalen regulerer prosessen det er å behandle henvendelser, både med hva som vil fikses, og når dette vil skjer. 

==== Kapasitet ====
Kan måles som gjennomsnittlig svartid ved bestemte operasjoner i bestemte applikasjoner.  Skal måle brukeropplevelsen av systemet.

==== Endringshåndtering ====
Mål for tid til håndtering, godkjennelse og implementering av endringsforespørsler fra brukerne.

==== Sikkerhet ====
Kan måles som antall fastslåtte sikkerhetshendelser i en periode.  Det er svært viktig å være tydelig på hver enkelt brukers ansvar for at garantier skal gjelde.

==== Fakturering ====
Priser, tidspunkt for fakturering og oppgjørsbestemmelser.

==== Rapportering og oppfølging ====
Beskrivelse av regler og perioder for rapportering av målt tjenestenivå.  Det anbefales regelmessige møter (f.eks. kvartalsvis) for å gå gjennom rapporten og planlegge fremover.

==== Straffereaksjoner og eventuelle incentiver ====

Regler for reduksjon i pris hvis avtalt tjenestenivå ikke er oppfylt.  Eskaleringsrutiner og regler for heving av avtale ved kontinuerlig brudd på garantert tjenestenivå.  Eventuelle incentiver ved oppnåelse eller bedre enn forventet tjenestenivå.

Se appendiks A for tjenestenivåavtale. 

== Økonomisk styring (Financial Management) ==
Organisasjoner har sjelden full oversikt over IT-kostnadene sine. En undersøkelse av norske kommuner i 2001 viste at bare 1 av 8 kommuner hadde et IT-budsjett. Sannsynligvis står det ikke bedre til i skolen. Å få på plass et IT-budsjett er viktig. Ofte synes brukerne at de betaler for mye for en tjeneste de ikke er fornøyde med.  Dette skaper mange ganger konflikter mellom brukere og IT-avdelingen.

Det er svært nyttig både for driftssenteret og brukerne å få dokumentert de reelle IT-kostnadene.  Uten dette blir det vanskelig å budsjettere riktig. Ikke minst blir det vanskelig å gjøre en kost/nytte-vurdering av eksisterende IT-løsninger. Rektor bør kjenne IT-budsjettet like godt som hun kjenner lønnsbudsjettet, eller budsjettet over læremidler. 

Det er tre viktige prosesser knyttet til økonomisk styring av IT-tjenestene:

 1. Budsjettering
 1. Regnskapsføring
 1. Fakturering

=== 3.2  Budsjettering ===
Målet med budsjettet er å lage et realistisk anslag over forventede IT-kostnader. Budsjetteringen inneholder som regel forskjellige alternative løsninger. Det gjelder både i forhold til utstyr og programvare, og nivået man vil legge seg på. Budsjettet er utgangspunkt for senere budsjettforhandlinger med skolesjefen og/eller politikerne. 

Budsjettet skal inneholde både personal- og utstyrskostnader. En del virksomheter regner bare på hva det koster å kjøpe utstyr. Da utelater man så mye som 60-70% er personalkostnader ved drift av en IT-løsning. Man må også få med alt av utstyr. 

Det er eksempler på kommuner som har glemt å regne med kostnader til strømkontakter og datanettverk på skolene. Da har man glemt ca. 2000 kroner pr. klientmaskin. Skal man få på plass 70 nye datamaskiner snakker vi fort om 140.000 kroner til datanettverk og strøm. 

Alternative løsninger er også viktig å få med i budsjettet. Det gjelder både i forhold til drift og utstyr. I dag er det flere leverandører som har spesialisert seg på drift av datautstyr på skolene med varierende priser og kvalitet. Antall samtidige brukere og type maskiner og programvare som skal vedlikeholdes betyr også en hel del. 

Skal man ha bærbar PC til alle lærere og elever vil man fort få 5-6 ganger høyere driftskostnader enn om man har stasjonære PC-er med tre elever for hver klientmaskiner. 

=== Regnskap ===
Regnskapet vil i all hovedsak bestå av fakturaene for innkjøpt av utstyr, kabling, reparasjoner, drift og ekstra tjenester. Når regnskapsperioden er over er det viktig å gå gjennom tallene og sammenligne dette med budsjettet. 

=== Planlegging av regnskap og fakturering ===
Ikke alle kommuner har regnskapssystem som viser IT-kostnadene brutt ned på hver skole. Det kan være praktiske grunner til dette som for eksempel rabattordninger og lignende som kommunen får sentralt. Derfor er det viktig å gjøre litt planlegging slik at man får oversikt over hva kostnadene har vært med drift og anskaffelser når regnskapet skal vurderes opp mot budsjettet. 

En del organisasjoner kan ha tungvinte og kostbare regnskapsrutiner. Man får fort ekstra kostnader med å betale regninger ved forsinkelser, eller om man har mange som skal godkjenne en utbetaling. Så det er viktig å bli enig om gode faktureringsrutiner ved anskaffelse og drift slik at man både har kontroll, men også håndterer betaling i tide uten lange beslutningsveier. 

=== Implementering ===
Betalingsmåte er regulert av tjenestenivåavtalen. Når det gjelder regnskapssystemet må man bli enig med økonomiavdelingen om en praktisk måte å få rapporter på, slik at man får den ønskede regnskapsoversikten over IT-kostnadene uten at det tar lang tid å få ut oversikten. 

=== Daglig drift ===
Når det gjelder driftsavtaler vil man vanligvis ha en fast månedlig fakturering som består av et fast beløp og eventuelle ekstra tjenester. Fakturering gjøres fra regnskapskontoret ut fra de driftsavtalene man har, og de ekstra tjenestene som er utført. Det er viktig med god og hyppig kontakt med regnskapstjenesten ut fra de oppdrag som er utført for kunden. 

== Kapasitetsplanlegging (Capacity Management) ==
Kapasitetsplanlegging brukes for å sikre at alle deler av IT-løsningen har tilstrekkelig kapasitet til å ivareta brukernes krav.  Dette omfatter:

 * Overvåkning av ytelsen til IKT-tjenestene med tilhørende infrastruktur
 * Konfigurasjon av systemene for å sikre at de utnyttes optimalt i forhold til det brukerne faktisk gjør
 * Forståelse av brukernes behov og planlegging av eventuelle endringer på systemene for å ivareta fremtidige behov
 * Ressursplanlegging i samarbeid med budsjettansvarlig
 * Utarbeidelse av en kapasitetsplan for å sikre leveranse av driftstjenester i samsvar med avtalt tjenestenivå
Kapasitetsplanlegging handler om å balansere:

 * Kostnader mot kapasitet.  Budsjettet setter grenser for hva slags løsninger som er mulig å implementere
 * Tilbud og etterspørsel.  Systemene må ha kapasitet til å kunne håndtere de krav som stilles av brukerne
Målet med kapasitetsplanleggingen er å unngå overraskelser.

=== Overvåkning ===
Det er avgjørende for god kapasitetsplanlegging at systemene overvåkes kontinuerlig for å fremskaffe det nødvendige datagrunnlaget.

Typiske data som overvåkes er:

 * Prosessorutnyttelse
 * Minneutnyttelse
 * Prosessorbruk pr oppgave
 * Svartider for brukerne pr oppgave
 * Skriverstyring - antall utskrifter, kølengder, utskriftstid
 * Lagringskapasitet
 * Antall klienter
 * Antall pålogginger
 * Antall samtidige brukere
I Skolelinux er det Nagios som brukes som overvåkningsverktøy.

=== Analyse ===
På bakgrunn av innsamlede data fra overvåkningsrutinene forsøker man å avdekke eventuelle flaskehalser i systemene.  Eksempler:

 * Dårlig eller ujevn utnyttelse av maskinvaren
 * Dårlig designet programvare
 * Dårlig utnyttelse av minnekapasitet
 * Flaskehalser på datalagring, minne eller prosessor
 * Flaskehalser i nettverket

=== Konfigurering ===
Hvis dataanalysen avdekker flaskehalser, må man forsøke å konfigurere systemet slik at det bedre ivaretar brukernes behov.

Her er en liste over hvilke flaskehalser man typisk møter og hva man kan gjøre for å bli kvitt dem:

||'''Flaskehalser'''||'''Tiltak'''||
||Mangler lyd, støtte for USB-penn og DVD på tynnklienter.||Installer halvtykke klienter (> 800 Mhz prosessor, > 256 MB minne)||
||Har 60 tynnklienter koblet til tjenermaskinen og ønsker flere PC-er.||Sats på halvtykke klienter, eller installer enda en tynnklient-tjener||
||Tynnklienter går tregt etter vi utvidet med 20 stykker uten å skaffe ny tjenermaskin||Installer 2 GB mer minne på tjenermaskin||
||Tynnklienter med 32 MB minne starter ikke etter oppgradering til Skolelinux 2.0||Skru på mellomlager (swap) på tynnklientene, eller nedgrader til LTSP 4.2 som er satt opp med swap.||
||Flash animasjoner gjør at tynnklientene går tregt når 50 elever er logget inn på samme tjenermaskin||Installer halvtykke klienter||

=== Implementering ===
Implementering av eventuelle endringer av systemkonfigurasjonen må gjøres i samsvar med de retningslinjer som er satt for endringer av systemet.  En godt planlagt test av funksjon og ytelse må også gjøres før endringene kan gjøres i produksjonssystemet. Testingen gjøres for å unngå driftsforstyrrelser når endringene settes i produksjon. 

=== Utarbeidelse av kapasitetsplanen ===
En kapasitetsplan er i utgangspunktet en investeringsplan for IKT-systemet basert på kjennskap til brukernes nåværende behov og fremtidige planer.

Kapasitetsplanen bør oppdateres og behandles en gang i året, normalt i forbindelse med budsjettprosessen.  Planen bør inneholde følgende områder:

 * Innledning
 * Forutsetninger
 * Sammendrag
 * Nåværende og fremtidige brukerbehov
 * Tjenestesammendrag
 * Ressurssammendrag
 * Forbedringsområder
 * Kostnadsmodell
 * Anbefaling

== Tilgjengelighetsstyring ==

God og stabil tilgjengelighet av IKT-tjenestene er selvsagt helt avgjørende for brukerne. 

Tilgjengelighet sett fra brukerperspektiv avhenger av følgende forutsetninger:

 * Tilgjengelighet av tekniske komponenter
 * Feiltoleranse
 * Kvalitet på vedlikehold og brukerstøtte
 * Prosedyrer og rutiner for håndtering av driftstjenestene
 * Sikkerhet, integritet og tilgjengelighet av data

Tilgjengelighet kan måles på flere måter. Men før vi viser eksempler peker vi på hva som kan være vanskelig med måltall. Om det skal jobbes systematisk med tilgjengeligheten må man avklare hva de forskjellige tingene betyr. Hva betyr f.eks. et prosenttall for tilgjengelighet. 

La oss si at det er en «datamaskin med dataprogram» er en tjeneste. Om dataprogrammet ikke fungerer en dag, er da tjenesten utilgjengelig når alle de andre programmene fungerer helt greit. Hva om dataprogrammet er utilgjengelig for et klasserom, men tilgjengelig på resten av skolen (på grunn av en underliggende tjeneste). Dette er vanskelig materie å avklare, og jobbe med i praksis. 

=== Måltall for tilgjengelighet ===
Tilgjengelighet kan måles på flere måter.  Her er noen eksempler:

||'''Måleverdi'''||'''Betydning'''||
||% tilgjengelig||Verdien kan være tilgjengelighet mellom kl 08:00 til 18:00. Er systemet nede 1 time i løpet av en dag, er systemet tilgjengelig i 90% av den avtalte tiden. Måles tilgjengelighet over en måned med 20 arbeidsdager, så er systemet tilgjengelig i 95% av tiden.||
||% utilgjengelig||Er systemet nede 1 time i løpet av en avtalt driftstid på f.eks. 10 timer om dagen, er systemet utilgjengelig i 10% av tiden. Måles dette over 20 arbeidsdager snakker vi om at systemet har vært utilgjengelig i 5% av tiden.||
||Antall timer utilgjengelig||Man kan avtale antall ganger man godtar at systemet er utilgjengelig i løpet av f.eks. en måned (20 arbeidsdager). Det kan være maksimalt 1 time utilgjengelighet i den perioden, og mellom 08:00 til 18:00.||
||Feilhyppighet||Også feilhyppighet kan måles pr dag eller hver måned. 3 feil i måneden for at systemet er nede mellom 08:00 til 18:00 er et eksempel.||
||Konsekvenser av feil||Måleverdiene er et vanlig utgangspunkt for å bedømme om en feil skal få konsekvenser ut over vanlig feilretting. Kunden eller skolen kan f.eks. be om å betale mindre for driftsavtalen for aktuell måned.||

Det viktigste er at det man måler beskriver brukeropplevelsen på en best mulig måte.  Derfor bør man måle det som er viktig for brukeren.

Tilbakemeldingen fra skolene er at det er skrivere som gir mest problemer. Det gjelder alt fra at skriverkøen har stoppet opp, til at papir eller toner mangler. Enkelte har også opplevd noe ustabilitet med nettleseren, og at kontorprogrammet OpenOffice.org blir hengende. Det kan skje når bredbåndsforbindelsen er ustabil og man har linker i dokumenter som går ut på Internett. 

=== Infrastruktur ===
Skal man ha et stabilt datasystem er man avhengig av en god nok teknisk kvalitet på datanettet. Flere skoler har erfart ustabilitet fordi det fysiske datanettet er provisorisk og av dårlig kvalitet. 

Mange satser i dag på trådløse nett. Gjør man det må man også være klar over at trådløse nett har betydelige svakheter. Trådløse nett har begrenset kapasitet. Det gjør at det kan bli ganske hakkete om 30 elever skal se en filmsnutt fra Internett samtidig. Trådløse nett har også skygger. Det betyr at det er områder som ikke dekkes, noe som gjør at enkelte havner i blindsoner. Da får man dårlig eller ingen nettoppkobling i det hele tatt. 

Skal man stille krav til tilgjengelighet til vanligvis driftsselskap og IT-tjenester stille krav om god kvalitet på datanettet på skolen. 

=== «Single points of failure» ===
Det er som regel deler i en dataløsning som bare må virke. Svikter f.eks. en brannmur og slutter å virke, så stopper det all trafikk til Internett. Man kan ha problemer med stabiliteten til system for tildeling av nett-adresser med DHCP (Dynamic Host Configuration Protocol). 

Driftsavdelingen har som ansvar og kjenne til de delene som kan stoppe hele dataløsningen. Det er viktig å finne disse punktene, og fjerne feilene en etter en, om dette er noe man har råd til. Hvis man ikke har råd til å fjerne feilkilder som kan stoppe f.eks. hele datanettet må man leve med risikoen om at noe plutselig ikke virker. 

Feilkilder som gjør at alt stopper kan også være logiske fremfor fysiske. Dette gjelder spesielt for datanett og databaser. Så det er viktig å ha et bredere perspektiv når det kommer til slike feilkilder. 

=== Risikostyring ===
Man må vurdere hva man aksepterer av risiko i datanettet. Er det akseptabelt at brukere mister personlige filer og data når en harddisk går i stykker? Hvor raskt skal man få på plass utstyr som har gått i stykker? Det er skoler som har erfart at det tar flere dager å få opp tjenermaskinen etter virusangrep. Kommunen har ikke ressurser å avsette til feilretting. 

Mye av arbeidet med drift går på å opprettholde tjenestenivået som er avtalt. Det handler om å unngå og miste tillit og brukertilfredshet. Risikostyring handler om å sette av passende ressurser til å holde hele datasystemet på lufta, og ha ressurser klar om noe skulle gå galt og må fikses. 

=== Testing ===
Det er stor forskjell på å installere utstyr og programvare på en enkelt PC og hundrevis, kanskje tusenvis av datamaskiner. Har man ansvar for hundrevis av maskiner vil en liten feil som man kan leve med på en PC bety mye ustabilitet og misnøye om feilen rammer hundrevis av brukere. 

For å unngå at man gjør feil ved installasjon, og bidrar til stabilitet, er det helt avgjørende å teste utstyr og programvare som skal brukes. Det handler om å følge opp den forventede kvaliteten. Skal man ha stabil drift må man ofte velge nest siste utgave av utstyr og programvare. 

Man bør unngå å ta i bruk programvare som som slutter med en null. F.eks. OpenOffice.org 2.0 bør man unngå. Man bør ta i bruk kontorprogrammet når versjon 2.0.2 har kommet eller nyere. Da har programpakken blitt fikset for flere feil. Det samme gjelder maskinvare. 

Når man ser på tjenermaskiner har de gjerne litt eldre utgave av prosessorer, og mer robust minne, og harddisker. Dette er fordi mange bruker denne maskinvaren samtidig. En liten feil som ikke ville bety noe for en bruker, kan gi driftsstans om 30 brukere er logget inn på maskinen. 

Så testing handler om å ta i bruk utstyr som er velprøvd og utgaver av programvaren som har fått et halvår eller et år på baken. Testing handler også om å prøve ut de forskjellige delene i en mindre men realistisk sammenheng, for å forsikre seg om at alt virker. Å  ta i bruk siste versjon, eller til og med beta-utgaver av programvare eller helt nyeste maskinvaren fører som regel til mye trøbbel og ekstra arbeide med vedlikehold. Å sette systemer i produksjon uten en mindre test i realistiske omgivelser fører som regel til betydelig brannslukking og misfornøyde brukere. 

Når man gjør testing i mindre skala på utstyr som er i produksjon, er det helt avgjørende å avtale dette med de berørte. I tillegg må man velge tidspunkt for test. Man skal ikke test ut nye ting samtidig som det pågår f.eks. eksamensavvikling med bruk av IT-verktøy. 

=== Designforbedringer ===
En driftsavdeling vil være tjent med å utbedre systemer som gir mye driftsmeldinger. Det kan være at brukerne får mye søppelpost. Da kan det være greit å installere filer for søppelpost. Det kan være mye ekstra arbeide med elever som stadig glemmer passordet sitt, og lærere som sender henvendelsen til den sentrale drifsstaben. For å unngå ekstra e-posting og dobbeltarbeide så kan læreren selv gi eleven nytt passord. 

Dette var et par eksempler på designforbedringer som letter arbeidet med drift, og gjør at brukerne blir mer fornøyd. En godt drevet driftsavdeling har en liste med prioriterte designforbedringer som gjør at driften blir enklere. Prioriteringene gjøres som regel ut fra en vurdering av henvendelsen til servicekontoret som man har lagret i meldingsloggen, og en vurdering av arbeidet som må gjøres for å behandle henvendelsene. 

=== Planlegging for tilgjengelighet ===
Det betyr at man har realistiske forventninger til IT-tjenesten ut fra hva driften koster. Planlegg hva som er forventet tilgjengelighet. F.eks. krever skolene at man skal være på lufta på under 1 time etter serverkræsj, så må man ha stående en ferdig installert maskin i reserve, hvor denne kan kobles inn som erstatning for den defekte maskinen. Det som gjøres i løpet av en time er å legge over sikkerhetskopierte filer til reservemaskinen. 

Går en halvtykk eller tynn klient i stykker har man liggende et lite lager med maskiner og skjermer på skolen. Skolens IT-kontakt kan hente og installere en erstatningsmaskin. Dette kan gjøres enkelt og greit uten å vente i dagevis på utstyr som må bestilles. 

=== Planlegging for gjenoppretting ===
Som eksemplet med utstyr som står klar til å erstatte defekt utstyr, så er det også forventet å kunne hente fram filer og data som har gått tapt. Derfor er det helt avgjørende å ha sikkerhetskopi av brukerdata og en kopi av oppsettfiler. Man må også ha arkitekturtegninger, og beskrivelser av systemet som gjør at IT-staben raskt kan få på plass systemene når noe går galt. 

Det er helt avgjørende å planlegge sikkerhetskopiering av brukerdata og oppsett.  Man må planlegge slik at man har riktig utstyr og passende tjenester. Det må også planlegges hvilke rutiner som skal følges når bestemte feilsituasjoner har skjedd, og systemene må gjenopprettes. 

== Driftskontinuitet (Service Continuity) ==
Driftskontinuitet eller kontinuitetshåndtering er ofte det mest kostbare prosessen å jobbe med. Høye krav til driftskontinuitet vil kreve store investeringer, noe som avtales i arbeidet med SLA-en. F.eks. kan det avtales at det ikke er noen katastrofeplan for enkelte tjenester. Har man en katastrofeplan så er verdien svært lav om den ikke prøves en gang i blant. Som regle er dette dyrt. Det er eksempler der kunden og ledelsen har sperret maskinrommet og tatt strømmen for å teste beredskapen til IT-avdelingen. 

Driftskontinuitet kan være aktuelt i bestemte perioder som ved eksamen. Da kan det stilles ekstra krav til å ha utstyr med backup klart i tilfelle en harddisk på tjenermaskinen skulle svikte. Men også dette vil kreve betydelig ekstraarbeide for driftsstaben. 

En IT-koordinator fortalte oss at det kan være like greit å utsette eksamen en dag om noe gikk galt med dataanlegget. Dette kostet mye mindre enn å ha et dobbelt antall med tjenermaskiner på hver skole. Det er eksempler på at skoler har hatt vannlekkasje. Da er det vanlige å utsette eksamen en dag eller to til skaden er utbedret. Man kan tenke på samme måte når det kommer til skolens dataløsning. Har man backup av hjemmekatalogene til elever og lærere har man tid til å områ seg uten å doble systemer på skolen. Da holder det med en eller to tjenermaskiner plassert på kommunehuset i reserve, som raskt kan kjøres ut og kobles opp på skolen om noe skulle gå galt. 