[debian-edu-commits] [Debian Wiki] Update of "DebianEdu/Documentation/nb/ITIL/Support" by Anna Kennedy
Debian Wiki
debian-www at lists.debian.org
Sat Mar 21 13:40:47 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/Support" page has been changed by Anna Kennedy:
https://wiki.debian.org/DebianEdu/Documentation/nb/ITIL/Support
New page:
= Service støtte =
<<TableOfContents(2)>>
Som nevnt i innledningen er det anbefalt å starte med etablering av et skikkelig servicekontor ved sentralisert drift. Dette gjør man for å få styring på driftsmeldingene. Gevinstene kommer både raskt og blir fort synlige, noe som er viktig for kunde- og brukertilfredshet.
Etter at kontoret er oppe å går med en fornuftig håndtering av hendelser (henvendelser og feilsituasjoner) går man til det som er den største utfordringen for organisasjonen. Som regel er dette enten endringshåndtering eller problemhåndtering. Organisasjonene som har det vi kaller «cowboy-drifting», der driftsoperatører finner på lure ting, og implementerer dem uten særlig testing, går ofte for endringshåndtering først. Andre som opplever av driften plages med stadig driftsstans går først for problemhåndtering.
Uansett hva man velger å starte med, så tvinger det seg fram en viss bruk av konfigurasjonshåndtering. Håndtering av konfigurasjoner er avgjørende for å levere riktige programmer og tjenester for brukerne. Programmene må virke som forventet. Skal man gjøre endringer på en god måte, må man vite oppsettet til de forskjellige programmene.
For å håndtere endringer i konfigurasjoner kan man bruke en database (Configuration Management Data Base (CMDB)). De færreste tar i bruk en database for konfigurasjoner fullt ut. Man trenger heller ikke å legge alle konfigurasjoner i en eneste database. Det går like greit å plassere konfigurasjonene i flere mindre, og tildels uavhengige lagre. Flere tar f.eks. vare på konfigurasjoner og oppsett i et system for versjonskontroll. Men selv om man har forskjellige lagre, så kan nytten bli større om man kobler sammen informasjon fra de forskjellige prosessene.
For brukere av Skolelinux ligger de aller fleste konfigurasjoner av tjenester i katalogen i en bestemt katalog (/etc). Disse kan med fordel samles og lagres i en sentral versjonshåndtert katalog. Dette gjør det enklere å få på plass tjenester som har falt ut, eller oppsett av maskiner om de er installert på nytt. Dette gjelder både tjenermaskiner og bestemte klientmaskiner som bærbare eller arbeidsstasjoner. Det hører med at backup-systemet i Skolelinux tar sikkerhetskopi av oppsett-katalogen /etc. Men backup-systemet er noe annet enn en database eller en versjonshåndtert katalog med for konfigurasjoner.
== Servicekontor (Service Desk) ==
Servicekontoret er der brukere henvender seg med spørsmål eller feil. På skolen er det gjerne IKT-kontakten som videreformidler driftshendelser til servicekontoret. Det kan også være forespørsler som å sette opp en ny PC, eller installere et program.
På skolen er det IKT-kontakten som er bindeleddet med servicekontoret. IKT-kontakten svarer selv på de mest vanlige spørsmålene. Noe spørsmål blir for vanskelige å håndtere på skolen. De må videreformidles servicekontoret. Da er det viktig med et godt samarbeidet mellom skolens IKT-kontakt og servicekontorets driftsoperatører. Oppgaver som er for omfattende eller for vanskelige å ordne lokalt videreformidles servicekontoret.
Det kan også hende at brukerne får direkte svar fra en driftsoperatør på servicekontoret. Alle driftshenvendelser går til servicekontoret. Henvendelsene får et saksnummer. Den som har meldt saken får en e-post som bekrefter at henvendelsen er mottatt. Under behandling av saken kan de som jobber med den på servicekontoret sende oppdatert status til brukeren.
På den måten får brukerne en plass å forholde seg til, og driftsoperatører på servicekontoret får oversikt over alle sakene. Driftstjenesten kan løse problemene effektivt i alle deler av organisasjonen. Med jevne mellomrom går ledelsen gjennom alle henvendelser og løsninger på problemer for å prioritere feilretting. Ut fra det kan man sette inn tiltak for å unngå at feil ikke dukker opp på ny. På den måten får skolene et mer stabilt driftsmiljø.
Hendelser kan komme over telefon, fax, epost eller nettskjema. Hendelser som haster blir prioritert. Hendelser som må løses raskt komme gjerne på telefon. Mindre viktige hendelser kommer via f.eks epost. Personene i brukerstøtten må kunne sette seg inn i brukeren sitt problem, og stille spørsmål for å finne mest mulig ut om problemet.
Husk å vær en aktiv lytter, ikke passiv.
Alle henvendelser skal logges. Man skal også gi e-posttilbakemelding på at man har mottatt en sak. Det er viktig for at kunden skal føle seg trygg, og for å få gode opplysninger om hva som kan være problemet. Når henvendelsen kommer vil servicekontoret loggføre en kort beskrivelse av hendelsen eller en forespørsel. Henvendelsen kan være fra IKT-kontakten på skolen, eller noen av de andre som har avtale om å bruke servicekontoret. Loggføringen skal skje så fort som mulig, og det vil følge med et saksnummer. Den som har kommet med henvendelsen vil få e-post-kopi om at saken er mottatt med passende saksnummer.
I tidligere tider ble henvendelser ført i papirbaserte logger. I dag brukes datasystem til å loggføre henvendelser. På engelsk heter dette «Request Tracker». Det er avgjørende for driften å logge henvendelsene. Dette er utgangspunktet for feilhåndtering, ønsker fra brukerne, og prioritering av de forskjellige driftshendelsene. Loggføringene er viktig for å hindre gjentakende feil. Fordi man med jevne mellomrom går igjennom driftshendelsene får man også gjort en vurdering om feilrettingen er god, og om man har prioritert oppgavene riktig. Det gir også grunnlag for å forbedre servicen ved å feilrette problemtjenester og programmer ut fra hva brukere opplever som problematisk. .
Altså er logg over henvendelser et grunnleggene nødvendig verktøy for brukerne og servicekontoret. Det er flere fritt tilgjengelige systemer for logging av henvendelser med god dokumentasjon<<FootNote(RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html)>>. Driftsorganisasjonen Skolelinux Drift bruker RT<<FootNote(RT: Request Tracker: http://www.bestpractical.com/)>> for håndtering av henvendelser.
En viktig ting når man starter opp brukerstøtte er å ikke få for tøff start. Ikke prøv å få til alt på en gang. Sats heller på «raske gevinster» som å holde brukeren informert og korte responstider. Det er også viktig å avklare hvem servicekontoret skal videresende hendelser til om de ikke finner ut av henvendelsen selv. Brukerstøtten må også enkelt kunne se om det er driftsforstyrrelser ute hos brukeren. Dette gjør det raskt og enkelt å gi tilbakemelding.
For brukerne er det viktig at hendelsen blir håndtert. For servicekontoret er det viktig at hendelsene blir håndtert riktig i forhold til tjenestenivåavtalen, og at arbeid som ønskes utført ut over avtalen avklares på ledernivå mellom skole og driftsorganisasjon.
=== Arbeidsoppgaver og roller ===
Vi anbefaler å avtale hva IKT-kontakten på skolen har i oppgaver og hva som er ansvaret for de som jobber på servicekontoret. Skolene har ofte små ressurser sammenlignet med hva som er vanlig i kommuneadministrasjonene eller private bedrifter. Samtidig har man vanligvis mange flere brukere og ofte flere klientmaskiner enn hva som er i bruk i resten av kommunen.
For å fordele arbeidsoppgaver må man ha på plass roller. Ved å ha klarlagte roller er det enklere å fordele oppgaver, og arbeidskapasiteten som er nødvendig for å løse driftsoppgavene på en god måte.Ut fra erfaringer i kommuner og profesjonelle driftsorganisasjoner viser det seg at følgende roller er vanlig.
* IKT-kontakt på hver skole. Dette er gjerne en lærer som også har IKT-pedagogisk og/eller teknisk begrunn.
* Driftsoperatør(er) som jobber i den sentrale IT-tjenesten. Dette er en fagperson på drift.
* IKT-koordinator som organiserer den pedagogiske IT-bruken, og bidrar til å lage planer for utbygging, drift og pedagogisk bruk. Ofte er dette en lærer.
* IKT-ansvarlig. Dette er vanligvis rektor som er ansvarlig for IT-virksomheten.
Her følger en oversikt over de forskjellige arbeidsoppgavene som er vanlige, og som enkelte kommuner har kontraktfestet med de som gjør jobben.
IKT-kontakten(e)s arbeidsoppgaver på hver skole:
* Ha oppsyn med skolens maskinpark.
* Være skolens kontaktperson mot kommunen - rapportere om feil og mangler.
* Utføre enkelt vedlikehold eks. bytte mus, tastatur, tynnklient og enkel patching.
* Være skolens superbruker - kunne veilede kollega med tanke på: brukergrensesnitt, e-post, videokanon og enkelte programmer.
* Delta på IKT-samlinger.
* Opprette og administrere lokale brukere.
* Utføre enkelt vedlikehold av skrivere.
* Opprette og administrere e-postkontoer.
* Kunne utføre enkle kommandoer og operasjoner under veiledning av IKT-veileder.
* Legge til rette for bruk av IKT i undervisningen.
Driftsoperatørens arbeidsoppgaver:
* Ta imot hendelser (incidents) og forespørsler (service requests)
* Veilede IKT-kontaktene på telefon og e-post.
* Om det er avtalt, oppsøke skolen for utbedring av mangler og feil på datamaskiner, skrivere og server.
* Sikkerhetskopiering (eng.: backup).
* Sikkerhetsoppdatering av programvare på skolens maskiner (tjenermaskiner og klientmaskiner).
IKT-koordinators oppgaver:
* Bistå skoleledelsen og IKT-kontakter i utarbeidelse av tekniske og pedagogiske IKT-planer
* Sørge for at servicekontoret og ledelsen får forespørsler om valg av programvare ol.
* Bidra til at skolene har riktige IT-verktøy til undervisningen, og at datamaskiner og nettverk er riktig dimensjonert for bruk i skolefagene.
* Gir råd og veiledning til driftstjenesten om hva som er det tekniske og pedagogiske IT-kravene i skolen.
IT-ansvarliges arbeidsoppgaver (rektor, skoleleder, leder av driftstjenesten):
* Gjøre felles innkjøp av datautstyr og inngå fellesavtaler osv.
* Utarbeide kompetanseplaner.
* Tilby skolene kurs i pedagogisk bruk av data.
* Driftskurs.
* Forhandle fram driftsavtaler.
* Sørge for at IT-kontakten og IT-tjenesten har nødvendige ressurser.
Fordelen med å avtalefeste disse arbeidsoppgavene er at man både vet hva som forventes av den enkelte, og at man har et godt grunnlag for å planlegge og styre IT-tjenestene. Vanligvis gjøres disse IT-oppgavene som kun en del av jobben til en lærer som også har undervisningsoppgaver.
I en bedrift ville man fort hatt to ansatte på full tid for å drifte 100 standard klientmaskiner med 100 brukere. I skolen har man kanskje en 30% stilling totalt fordelt på flere personer som drifter 100 klientmaskiner som brukes av 320 elever og lærere.
Når man i skolen har så få ressurser til driften så er det avgjørende å ha god styring på ressursene. Ved å avtalefeste oppgavene kan man enklere gjøre vurderinger knyttet til om man trenger ekstra ressurser, eller må redusere forventningene til IT-satsingen i skolen ut fra budsjettmessige hensyn. Ved å ha god oversikt over hva IT-oppgavene er vil skolens IT-ansvarlige enklere kunne be om økning i ressursene om dette er nødvendig. Det kan være behov for økte ressurser til gjennomføring av IKT-basert eksamen eller behov for nytt utstyr som digital tavle som hjelpemiddel i undervisningen.
=== Forventet tidsbruk ===
Vi har laget en tabell som viser tiden som brukes på drift og vedlikehold. Tabellen bygger på erfaringer fra kommuner som sentraldrifter Skolelinux på 9-10 skoler med 250-500 klientmaskiner. Det er flere ting som ikke er med i tabellen. Derfor må man sette opp ekstra tid til prosjekter hvor skolene utbygger ut IT-løsningene med nettverk og mer utstyr.
|| '''''Rolle''''' || '''''Driftsansvar''''' || '''''Tidsbruk pr skole pr uke''''' || '''''Total tidsbruk alle skoler''''' ||
||Driftsoperatør sentralt||Overvåking, feilretting og drift av 500 maskiner på f.eks. 10 skoler med 3200 elever og lærere.|| 2-3 t<<BR>> (50 klienter)|| ½ stilling<<BR>> (500 klienter)||
||IKT-kontakt på hver skole||Oppsyn over utstyr, enkelt vedlikehold, og rapportering av hendelser og forespørsler|| 3-4 t<<BR>> (50 klienter)|| 1 stilling<<BR>> (10 skoler / 500 klienter)||
||IKT-koordinator sentralt||Bistå planlegging og gjennomføring av pedagogiske og tekniske IT-arbeidet i skolen.|| 1-2 t|| ½ stilling||
||IT-ansvarlig (rektor)||Gjøre felles innkjøp, og passe på at tjenestenivåavtalen overholdes. Planlegge oppdateringer, eller utbygning av løsningene|| 1 t|| ¼ stilling||
||'''Totalt for skole'''||'''50 klient-maskiner (samtidige brukere)'''|| '''6 - 10 t '''|| ||
||'''Totalt for alle skoler'''||'''10 skoler, 500 klient-maskiner (samtidige brukere)'''|| || '''2 ¼ stilling'''||
Erfaringer viser at arbeidsomfanget til IKT-kontakten blir påvirket av antall samtidige brukere. Uttrykket «samtidige brukere» er nytt for mange. For å illustrere med et eksempel. En skole kan ha 250 elever men ikke mer enn 50 datamaskiner. Da er det maksimalt 50 elever som kan bruke datamaskiner på samme tid. Dette er mye mindre enn de tilsammen 250 brukerne som har konto på systemet. Det er disse 50 innloggede brukerne som gir arbeide for IT-tjenesten. De andre 200 personene som ikke er logget inn gir lite ekstra arbeide.
Derfor er det vanlige å beregne IT-kostnader ut fra maksimalt antall samtidige brukere. Andre beregningsmåter er også mulig, f.eks. når man betaler for produsenteid programvare. Men siden Skolelinux ikke har lisenskostnader, så er det antall samtidige brukere som er det mest avgjørende for driftskostnadene. Å regne driftskostnader ut fra brukerkonti gir liten eller ingen mening i skolen.
For brukere av Skolelinux er det nesten ingen kostnadsforskjell å forvalte 100 eller 250 brukerkonti. Det er et par unntak. Sannsynligvis er det flere elever som stadig glemmer passordet sitt med 250 elever sammenlignet med 100. Derfor er det lurt å la læreren med ansvar for klassen være den som gir elever som glemmer nytt passord.
Har skolen 50 klientmaskiner trenger IKT-kontakten mindre tid på sine driftsoppgaver enn om skolen har 150 klientmaskiner. Med flere klientmaskiner øker den samlede tiden som brukes på drift. Men driftstiden fordelt pr klientmaskin går noe ned.
Flere kommuner har satt av 3-4 timer i uka til IKT-kontaktens oppgaver på hver skole om det er installert 30-70 klientmaskiner. Utdanningsetaten i Oslo har satt av halvannen ukedag, eller 30% stilling til å følge opp 150 klientmaskiner. Erfaringer fra andre kommuner tyder på at en 20% stilling er nok for å løse arbeidsoppgavene til en lokal IKT-kontakt om skolen har 160 tynne eller halvtykke klienter med Skolelinux.
I tillegg kommer kostnadene med sentralisert drift, IT-ledelse, og oppføringen av den pedagogisk bruken av IT-verktøy i skolefagene. Sannsynligvis er det nok med en stilling til drift av 1000 klientmaskiner. Når det gjelder pedagogisk støtte er det flere rektorer som har en 50-100% stilling på skolen til dette arbeidet. Det kan være en 10-20% stilling som IKT-kontakt og en 40-80% stilling som pedagogisk støtte for læreren. Mange lærere oppfatter IT-verktøy i skolen som noe nytt. En del rektorer ønsker å satse ekstra på den pedagogiske siden ved å gjøre lærerne trygge på bruk av IT-verktøy i skolefagene.
=== Sjekkliste ===
Vi har satt opp en huskeliste over oppgaver som må løses om man skal få på plass et ordentlig servicekontor.
* Få på plass personer i det forskjellige rollene som IT-ansvarlig, IKT-kontakt på skolene, driftsoperatør(er) sentralt, og IT-koordinator for alle skolene. Det er viktig å gjøre et skille mellom hva som er teknisk drift og vedlikehold, og det faglig-pedagogiske arbeidet.
* Etabler servicekontoret der hver skole har en serviceavtale som regulerer hva som er standard driftsaktiviteter, og hva som er ekstra. Det er avgjørende at IT-ansvarlig rektorer et med i denne prosessen hele veien.
* Få på plass system for meldingslogging (request tracker). Alle henvendelser på e-post får et saksnummer. Nesten alle henvendelser som brukere eller IT-kontakter på skolene ringer inn får også et saksnummer.
* Sørg for at IT-budsjettet gjenspeiler den arbeidsinnsatsen som er nødvendig for å sikre forsvarlig drift av skolens datautstyr og nettverk. Kravet i dag er at IT-systemene skal brukes til nasjonale og lokale prøver med bruk av IT-verktøy med eller uten Internett.
* Bruk i utgangspunktet standard utgave av Skolelinux med samme versjon på alle skolene. Ut fra dette gjøres endringene man ønsker. Disse endringene må man ta vare på i en konfigurasjonsdatabase med dokumentasjon av de endringene som er gjort. Man kan bruke et system for versjonshåndtering for å lagre endringene og dokumentasjonen.
== Hendelseshåndtering (Incident Management) ==
Hensikten med IT-tjenesten er å hindre forstyrrelser som driftsstans eller redusert kvalitet ved bruk av dataprogrammene. Brukerne vil oppleve få problemer med IT-systemet om IT-tjenesten har nok ressurser til drift, utstyr og henvendelser til servicekontoret. Allikevel skjer små eller store feil som gir forstyrrelser for brukerne. Da trenger man god håndtering av hendelser.
I fallskjermmiljøet kaller man nestenulykker for «hendelser». Det er kanskje ikke helt det samme i datadrift når noe ikke virker. Hensikten med å håndtere hendelser er og gjenopprette tjenesten så raskt som mulig slik at alt virker på vanlig måte. Går noe galt skal dette ha minst mulig å si for brukerne. Hva som er en normal tjeneste er avtalt gjennom en driftsavtale som beskriver tjenestenivå.
Statistikk over hendelser er viktig. Spesielt om flere jobber med driften. Når flere jobber sammen mister man fort oversikten over alle sakene. Statistikk vil kunne påvise problemområder som må håndteres mer grundig enn en rask løsning fra servicekontoret. F.eks. kan det være mange henvendelser om å bytte passord til elever som har glemt dette. Da kan det være lurt å la læreren til klassen bytte elevens passord.
En driftsforstyrrelse er definert som:
en hendelse som ikke er en del av den normale driften som forårsaker, eller kan forårsake et avbrudd, eller reduksjon i kvaliteten på tjenesten.
Eksempler på driftforstyrrelser kan være:
* Programmer
* kontorprogrammet (!OpenOffice.org) starter ikke
* nettleseren (Firefox) kræsjer
* disklageret er fullt
* Maskinvare
* tjenermaskinen er nede
* får ikke skrevet ut
* får ikke logget inn
* Henvendelser
* spørsmål om informasjon, råd eller dokumentasjon
* glemt passord
Eksemplene viser noen av de vanligste driftsforstyrrelsene. Dette er problemer som gjør at brukere henvender seg til IKT-kontakten på skolen eller servicekontoret. IT-tjenesten må prioritere hva som skal behandles med en gang, og hvilke problemer som trenger mer tid for å løses. For å prioritere hvilke problemer som trenger mer omfattende feilretting er det viktig å logge alle henvendelser om driftsforstyrrelser. Når man har oversikt over hvilke driftsforstyrrelser det er mest av, kan man sette inn tiltak på de områdene der det er mest problemer.
=== Sjekkliste ===
Vi har laget en kort huskeliste for å sikre at man har på plass rutiner og systemer for god hendelseshåndtering
* Driftsoperatør som gjør feilretting er den som melder status tilbake til IT-kontakt på skolen og/eller bruker
* Systemet for logging av hendelser må være på plass slik at det virker både teknisk og funksjonelt for de som jobber med hendelseshåndtering på skolene og på servicekontoret
* Systemet for hendelseslogging må brukes for så og si alle driftshendelser
* Ved jevne mellomrom lages statistikk av loggen over hendelser. Statistikken brukes for å sette inn tiltak som fjerner problemer som går igjen, og irriterer brukerne.
=== Planlegging og implementasjon ===
Å sette opp et brukbart system for logging av hendelser krever er noe mer enn å installere systemet. Alle i driftsavdelingen må bruke systemet. De som melder feil må også få tilbakemelding på e-post med saksnummer. Slike ting krever betydelig med konfigurering av systemet for hendelseslogging. I tillegg må man sørge for enkel brukeropplæring av de som tar imot henvendelsene.
Man trenger ikke store og omfattende planer for å få på plass skikkelig hendelseshåndtering. Å håndtere hendelser er en helt standard oppgave for de som jobber på servicekontoret og IT-kontaktene på hver skole. Å sette opp et dataverktøy for logging av hendelser krever fort en par uker slik at det er konfigurert riktig, og brukere også kan rapportere hendelser via e-post i tillegg til telefon.
Selve brukergrensesnittet til loggsystemet er relativt selvforklarende. Så det tar ikke mange timene å ta i bruk. I løpet av den daglige bruken av systemet vil man bli mer og mer komfortabel med hva som bør stå i meldingene som logges. Det er avgjørende at alle i driftsavdelingen bruker systemet for logging av driftsmeldinger.
=== Aktiviteter ved driftsforstyrrelser ===
For å få en idé om hvilke aktiviteter som gjøres ved en melding av en hendelse, bruker vi et eksempel.
En bruker kontakter servicekontoret med et problem. Utskriften virker ikke, er meldingen fra brukeren på telefon. Driftsoperatør logger hendelsen rett etter samtalen er avsluttet. Problemet med utskriften blir en sak med et saksnummer (som gis automatisk).
Driftsoperatør på servicekontoret gjør en rask analyse. Er det utskriftskøen som har stoppet igjen, eller er det noe annet? Det kan hende det mangler papir eller toner? Ved å undersøke utskriftskøen ser driftsoperatøren at den er fylt opp. Hun sletter køen, og ser om neste utskrift blir skrevet ut.
Denne gangen fylte skriverkøen seg opp igjen. Driftsoperatør kontakter skolens IT-kontakt, og ber om å sjekk om papir er på plass. Dette noteres i hendelsesloggen. IT-kontakten melder tilbake at papir er fylt på, og at utskriften går som normalt. Saken er avsluttet noe som også noteres i systemet for hendelseslogging.
Om skriveren ikke hadde startet igjen kunne det vært toner som manglet, eller at skriveren hadde en feil. Var det en feil måtte driftsoperatør skalert problemet. Med skalering menes at andre enn driftsoperatør og IKT-kontakten løser problemet. I dette eksemplet måtte man fått hjelp av en servicetekniker som kan fikse skrivere.
Dette eksemplet viser at det settes igang et helt apparat for å få igang en skriver som har stanset opp. Virker ikke skriveren selv om man har lagt inn mer papir i en i en tom skriver, så må man først undersøke om det er toner som mangler. Om alt ser ut til å være på plass, men ting fortsatt ikke virker, må man skalere problemet. Driftsavdelingen kaller inn en ekspert på et bestemt område for å fikse feilen. Denne gangen var det en servicetekniker for skrivere.
Hva som var feilårsak og den reparasjonen som ble gjort noteres i systemet for hendelseslogging.
=== Roller ===
Det er en rekke roller involvert når IT-tjenesten behandler meldinger om at noe ikke virker. I eksemplet over samarbeider skolens IT-kontakt og driftsoperatøren om å løse problemet med utskrift. Hadde problemet vært større måtte man ha innkalt en servicetekniker. Får man ikke fikset skriveren å må kjøpe ny. Må skolen skaffe ny skriver kan det hende man må involvere IT-ansvarlige for å få penger. Mange steder er det rektor som har siste ordet.
Kort sagt blir det fort mange som blir involvert når noe ikke virker. Man skal i utgangspunktet løse problemer der og da. Da unngår man å involvere mange som ikke kan bidra til å løse problemet. Skalerer man problemer som kan løses lokalt så blir det fort mer kostbart. Også fordi mange henvendelser bør være enkelt å håndtere der og da. Andre henvendelser dreier seg om mer sammensatte problemer. Da må man involvere flere personer. Er man avhengig av ekstra eller ekstern hjelp for å løse problemet så må dette som hovedregel avklares med driftsleder. Det viktige er å være bevisst ved håndtering av driftshendelser, og bruke ressursene på en god måte.
=== Nøkkelpunkter ===
Vi har satt opp en del nøkkelpunkter ved håndtering av hendelser. Punktene skal være til hjelp for å vurdere om man gjør en god jobb ut fra målbare og vel definerte krav. Slike målepunkter er:
* Totalt antall driftsforstyrrelser
* Gjennomsnittlig tid fra man har fått en henvendelse til at problemet er løst, brutt ned på koder (en godt organisert driftsavdeling har koder for hendelser og feiltyper).
* Prosentvis av hendelser håndtert innen avtalt svartid (avtalt i avtalen om tjenestenivå)
* Gjennomsnittlig kostnad for hver hendelse
* Prosentvis av hendelsene løst av hjelpetjenesten uten å gå videre til neste nivå med driftsstøtte
* Hendelser pr klientmaskin (arbeidsplass)
* Antall og prosenter av hendelser som løses fra driftsenteret uten behov for besøk på skolen
=== Verktøy ===
Det er en rekke verktøy som kan gjøre det enklere å håndtere driftsforstyrrelser.
* Automatisk logging
* Automatisk dirigering av hendelser til riktige personer
* Automatisk uthenting av data fra databasen for konfigurasjonsstyring
* Telefonen og e-post virker enkelt sammen med verktøy for registrering av henvendelser og hendelser.
== Problemhåndtering (Problem Management) ==
Problemhåndtering er en «undersøkende» prosess. Kjente feil blir oftest håndtert direkte av servicekontoret. Dette er den mest vanlige formen for hendelseshåndtering. Ved ukjente feil må man undersøke nærmere hva som er galt. Denne form for feilsøking krever både sunn fornuft og teft. Gode driftsfolk bruker teften til å gå rett til problemet, finner løsningen, og gjenopprette tjenesten så raskt som mulig slik at alt virker på vanlig måte.
'''Problemhåndtering er;'''
* Problemkontroll
* Feilkontroll
* Proaktiv kontroll for å hindre problemer
* Identifisere feilmønstre ved å bruke informasjon fra f.eks. hendelseshåndteringen
'''Problem kontroll '''
* Identifisere problemer
* Klassifisere problemer
* Etterforske/Undersøke problemer
'''Feil kontroll'''
* Identifisere og registrere kjente feil
* Finne midlertidige løsninger om mulig
* Kontakte de med ansvar for endringsledelse for å få fjernet feilen permanent
'''Proaktiv kontroll'''
* Identifisere og løse problemer og feil før hendelsen blir rapportert av brukere.
* Bruke logger, informasjon fra hendelseshåndteringen for å se hvor problemer kan oppstå
=== Prosedyrer for problemhåndtering ===
Vi har lagt ved en omfattende samling av problemløsninger og oppskrifter for konfigurering. I løpet av sommeren 2006 vil dette også være lagt ut på Internett. Vedlikeholdet av oppskriftene vil skje av profesjonelle driftsoperatører på skoler, kommunale IT-tjenester og private driftsoperatører. For å gjøre det enkelt å gjøre forbedringer i dokumentasjonen er det hele lagt ut i en wiki som ligger på en Skolelinux-tjener.
Wiki-teknologien har vist seg å være en stor suksess for å vedlikeholde katalogisert informasjon på Internett. Det er enkelt å bidra og alle endringer loggføres. Det er også mulig å importere !OpenOffice.org dokumenter, og eksportere oppskrifter som pdf.
== Konfigurasjonsstyring (Configuration Management) ==
Ressursene som brukes på IT-systemene i skolen må håndteres på en økonomisk forsvarlig måte. Da må man ha styring på tjenestene som brukes og utstyret eller infrastrukturen som det ofte kalles. Utstyret, programvaren og tjenestene har en hel rekke med innstillinger. Dette er konfigurasjoner, eller en logisk modell av hvordan infrastruktur og tjenester er satt opp.
For å kunne styre konfigurasjonene må de kunne identifiseres, lagres og vedlikeholdes. Man må også kunne holde orden på forskjellige utgaver av konfigurasjonene. Vi kaller hver del av et oppsett for en «konfigurasjonsdel» (eng.: Configuration Item CI). En konfigurasjonsfil kan f.eks. sørger for at bestemte brukere får adgang til noen få skrivere i datanettet. En annen kan sørge for at man får mellomlager på halvtykke klienter.
En oppdatert database for konfigurasjonsstyring er avgjørende for å sikre rask og kontrollert behandling av driftsforstyrrelser, eller ønske om endringer i oppsettet av maskiner, programmer eller tjenester.
=== Planlegging ===
Det krever planlegging for å få på plass en database for konfigurasjons styring. Man må bestemme seg for områdene systemet skal brukes, målsetningen, politikken og prosessene for lagring og vedlikehold av konfigurasjonene.
* Identifiser og velg en struktur på konfigurasjonene på de viktige delene av IT-infrastrukturen. Det gjelder også eiere av konfigurasjonen, navnelapper (attributter), avhengigheter, og relasjoner mellom konfigurasjoner.
* Styringen med konfigurasjonene slik at bare de som er godkjente blir tatt vare på i databasen gjennom levetiden til systemet. Styring over tilgang til konfigurasjonene kan gjøres med gruppetillatelser. Dette kan gjøres gjennom prosessen for endringshåndtering (Change Mangagement).
* Statuslogging - holder orden på tilstanden og status til de forskjellige delsystemer. Dette gjelder hele levetid til tjenesten, programvaren eller maskinvaren. Det kan være en konfigurasjon er i produksjon, er frakoblet eller avviklet.
* Sjekking og revisjon. Hver konfigurasjon må sjekkes for å bekrefte at riktig informasjon er lagret i databasen for konfigurasjoner (CMDB). Dette følges opp med periodiske gjennomganger for å sikre at databasen hele tiden er oppdatert.
Som vi ser må man planlegge en hel del om man vil ha en god forvaltning av konfigurasjonene til IT-systemet. Hensikten ved å planlegge dette som en del av IT-driften er å sikre at systemer som går ned raskt kan komme på lufta. Har man god orden på konfigurasjonene er det lett å bytte ut en defekt maskin, og erstatte denne med en ny. Konfigurasjonene kan raskt overføres til den nye maskinen, og IT-systemet oppleves som like godt som før det gikk galt med den gamle maskinen.
=== Styring av delekonfigurasjonene ===
En konfigurasjonsdel (CI Configuration Item) er en del av infrastrukturen. Det er som regel et oppsett av en tjeneste eller et program. Av og til ønsker brukerne og endre litt på hvordan en tjeneste virker. Man må ha styring på konfigurasjonene om det skal gjøres justeringer.
For å få dette ned på jorda så kan vi tenke oss konfigurasjonen til utskriftstjeneren. Man ønsker å legge til en ny skriver i datanettet, og vil legger til denne i utskriftssystemet CUPS. Da endrer man i konfigurasjonen gjennom en nett-applikasjon eller via oppsettet i KDE. Konfig-fila til CUPS vil endres, og man må starte utskriftstjeneren på nytt. Dette kan gjøres i KDE-verktøyet eller via nett-applikasjonen. Den endrede oppsettfilen kopieres til en filkatalog der fila kan håndteres av et versjonsystem.
Av mange forskjellige valg er det noe som går igjen. Dette er om en tjeneste skal: kjøre, stenges, avsluttes, startes, avbrytes eller tas ut.
Man bør være varsom med å endre konfigurasjonene uten en skikkelig plan. Det er lett å glemme hva man har gjort på en tjenermaskin eller en PC. Derfor er det viktig med dokumentasjon av endringene som er gjort i en endringslogg.
=== Planlegging og installasjon ===
Konfigurasjonen av datanettet henger sammen med arkitekturen. Mye av planleggingen er gjort med Skolelinux. Dette skyldes at det fort tar både 3 og 4 uker å sette opp tjenermaskiner med tilsvarende tjenestenivå med Windows server eller RedHat og andre GNU/Linux-distribusjoner. Med Skolelinux tar dette 1-2 timer. Skal man ha fast IP-adresse på nettverket bruker en fagperson ½ time ekstra på dette. Det skyldes at nett-tjenestene er satt opp med gjenbrukbare navn.
Det som da må planlegges er hvilke ekstra brukerprogram som skal opp, og hvilke delsystemer som skal samvirke med Skolelinux. Det kan f.eks. være at skolen har elektronisk tusjtavle (eng. Whiteboard).
=== Huskeliste ===
Vi har laget en liste med aktiviteter og løsninger som må på plass skal man ha god styring på konfigurasjoner.
* Etabler en versjonshåndtert område for lagring av konfigurasjoner til alle tjenermaskiner og utvalgte arbeidsstasjoner og bærbare. Man kan bruke versjonsystemet subversion til dette. Husk å ta daglig backup av område, og sørg for å lagre alle endringer i konfigurasjonene.
* Bruk et elektronisk system for å ta vare på oppskrifter som forklarer konfigurasjonene til forskjellig type maskiner, nettverket og tjenester. Slike oppskrifter bidrar til at andre som hjelper eller overtar driften kan lese seg opp på hva som er gjort. En wiki kan være passende til dette.
* Bruk en bestemt utgave av operativsystem og programvare på alle maskiner. Dette for å unngå å vedlikeholde mange forskjellige utgaver av programvaren. Sørg for at programvaren er godt testet. Derfor kan det være lurt å vente i 6-12 måneder før man tar i bruk nyeste utgave av et program.
=== Relasjoner til andre prosesser ===
Styring av konfigurasjoner henger nøye sammen med håndtering av problemer og om systemene er tilgjengelige. Opplever man stadig vekk at utskriften stopper, så kan det hende det hende en endring av konfigurasjonen løser problemet. Det kan f.eks. være å få på plass en rutine for sletting av utskriftskøen og starte utskriftstjenesten på ny.
Målsetningen med endringene man gjør i konfigurasjonene er som regel å øke tilgjengeligheten til tjenester eller programmer. Det kan også være for å begrense tilgangen til enkelte programmer eller tjenester til bestemte tidspunkt. For å få dette til må man endre oppsettet til tjenesten. I tillegg kan det koste penger ut over det som er avtalt om tjenestenivå, eller kapasiteten til systemet.
Eksemplene viser at håndtering av konfigurasjoner griper inn i en rekke andre områder. Derfor er det mye å tjene på å få på plass gode arbeidsrutiner for håndtering av endringene som gjøres i konfigurasjonene. Også automatisering er lurt om man ønsker økt stabilitet, eller tilgang til bestemte tjenester i bestemte perioder.
=== Verktøy til konfigurasjonsstyring ===
Som nevnt under huskelisten kan man bruke:
* Lagring av konfigurasjonsfiler i et system for versjonskontroll, f.eks. subversion
* Wiki for lagring av dokumentasjon av oppsett og veivisere
* Bruk av felles katalog for driftsdokumentasjon på Internett vedlikeholdt av de som sentraldrifter Skolelinux på mange skoler
== Endringsledelse (Change Management) ==
Mange IT-tjenester er lite flinke til å håndtere endringer i IT-systemene. Det fører til mange misfornøyde brukere. Undersøkelser i offentlig sektor i Danmark viser at driftskostnadene går ned når man har god styring på endringene. Derfor lønner det seg å involvere brukerne med opplæring og medvirkning knyttet til endringene som gjøres.
Det er helt avhengig av skikkelige prosesser ved endringsmeldinger. Dette gjelder uavhengig om endringene er små eller store. Derfor er det viktig å ha på plass riktige personer når man gjør endringer slik at det både er gitt opplæring og det er folk til å svare på spørsmål. Dette blir spesielt viktig når man tar i bruk nye utgivelser av programvare og tjenester. Det har ingen ting med om man bruker fri eller produsenteid programvare.
Endringsledelsen skal sørge for at alle endringer gjøres på en standardisert og riktig måte. Det er viktig å få til beslutning om endring på riktig nivå i organisasjonen, Standard endringer kan ofte være forhåndsgodkjente når de er gjort et par ganger. Men større endringer vil ofte involvere et høyre beslutningsnivå mellom skoleledelsen og driftsoperatør.
Grunnen til at ledelsen skal være med er at endringer i systemet er at en oppgradering ofte vil kreve opplæring av brukerne. Det kan være oppgradering til ny nettleser eller ny utgave av kontorprogrammet. Dette kan fort føre med seg en halv dags opplæring i hva som er nytt i et program. Slike endringer må derfor avklares med ledelsen. Endringene må også gjøres uten at det andre deler av systemet slutter å fungere.
De med ansvar for å godkjenne endringer mottar en mottar en såkalt endringsmelding eller RFC (Request For Change) som er den engelske forkortelsen. Når man har en endringsmelding kan man vurdere om endringen skal utføres. Mange ganger må man avklare med ledelsen om eventuelle endringer skal gjøres, og eventuelt når det skal skje.
Ved endringer må man også samarbeide med skolens IKT-ansvarlig. Man må sørge for at endringene skjer når det passer med skolenes planer. Å gjennomføre betydelige endringer uten endringsledelse kan føre til mye misnøye og ekstra henvendelser til servicekontoret. Da får man betydelig ekstraarbeid uten at dette er planlagt. I tillegg kan det føre til en endring som ville fort må rulles tilbake. Man får fort dobbelt så mye arbeide uten å havne noe annet sted enn tilbake til start. Hadde man sørget for de nødvendige godkjenninger ville endringen kunne gjøres på en planlagt og grei måte.
Endringsledelse gjøres for å unngå mer ekstra arbeide enn hva som er nødvendig. Å gjøre endringer krever selvsagt mer arbeide, men man vil få mindre ekstra arbeide om endringene planlegges. Man unngår også at man må rulle tilbake endringer fordi det oppstår problemer der brukerne ikke er forberedt på betydelig omlegging.
Når man f.eks. oppdaterer hele systemet til ny versjon må man passe på at alle er orientert. Man må undersøke om de som berøres av endringen trenger opplæring. De rette fagpersonene må forberede det hele slik at det ikke oppstår overraskelser.
Men må unngå at alt ansvar havner hos den som står for styring av versjonene av programvaren. Det er den som har ansvaret for håndtering av utgivelser (release manager). Utgivelseshåndteringen er en prosess som fortrinnsvis skal arbeide med endringer som inneholder mange mindre endringer. Dette skjer som regel ved utrulling av nye systemer og tjenester, eller ved oppgradering av hele systemet til ny versjon.
=== Aktiviteter ===
* Se over endringsmeldingen (RFC) og sjekk at den også har fått et unikt nummer.
* Prioriter og kategoriser endringer
* Fjern endringer som ikke er mulige. Dette kan gjøres ved å merke disse som ikke mulig.
* Gi tilbakemelding til den som gav endringsmeldingen
* Sørg for at man har en rådgivingsgruppe (eng. Change Advisory Board) der endringen blir tatt opp, diskutert og vurdert. Rådgivningsgruppa kan være utvalgte IT-kontakter og driftspersonell med lang erfaring.
* Koordiner endringene med den som håndterer forskjellige versjoner av programmer og tjenester (eng. Release Management)
* Se over og avslutt endringsmeldingen (RFC)
* Husk å lagre endrede konfigurasjoner i lageret for oppsettfiler
* Rapporter
Selv hva som kan se ut som en liten ubetydelig endringsmelding kan få omfattende konsekvenser om endringen gjøres. Vi har eksempler på skoler som har et stabilt Skolelinux-nett der alle programmene virker. Så installeres en testutgave av et populært program som kræsjer hele tiden. Skolelinux får skylda.
Et eksempel er skoler som har installert testversjonen av nyeste !OpenOffice.org før programmet var endelig ferdig. Flere syntes at det kunne være gøy og prøve ut. Problemet er at testutgaver som regel er utgitt for å finne feil og ustabilitet i programmer. De er ikke ment for bruk i produksjon.
Hovedregel er at man ikke installerer testutgaver av programvare i produksjon. De fleste driftsoperatører anbefaler å bruke nest siste versjon av et program beregnet på produksjon. Etter 6-12 måneder er som regel de verste feilene plukket av en ny hovedutgave av et program.
Det betyr at man gjerne venter til sommeren før man oppdaterer til et program som kom i ny utgave rett før nyttår. Dette passer bra med skoleåret. Alternativet kan være ustabilitet og irriterte brukere. Derfor har rådgivningsgruppa en sentral rolle når det gjøres små eller store endringer.
== Utgivelsesledelse (Release Management) ==
Utgivelseshåndteringen er administrasjon og planleggingsaktiviteter for å klargjøre for ønskede endringer. Endringene kan være små eller store der store endringer kan bestå av mange mindre delendringer. Utgivelseshåndringingen skjer før man setter igang selve jobben med å installere program- og maskinvare i produksjon.
Først gjennomføres planlegging og testing av nye utgivelser. Deretter så rulles det hele ut i produksjon. Utrulling er en del av infrastrukturledelse. Prosedyren er å gjennomføre det som er planlagt, testet, og ligger klar i systemene for konfigurasjonsstyring. Når alt er planlagt, testet og konfigurasjonene er lagret, så ruller man ut løsningen i drift.
Som regel er mange tjenestetilbydere og leverandører involvert. Det gjelder både i forbindelse med anskaffelse av maskiner, den programvaren som brukes, og de konfigurasjonene som er anbefalt. God ressursplanlegging er grunnleggende for å kunne pakke og distribuere en ny utgivelse på en bra måte for brukerne. Slurver man på dette området kan man ende opp med at utstyret ikke virker, eller blir stående ubrukt fordi det er mangler ved installasjonen.
Utgivelsesledelsen tar et helhetlig grep ved endring i en tjeneste, og skal sikre at alle deler av en utgivelse ses i sammenheng. Det gjelder både for tekniske og ikke-tekniske forhold.
=== Grunnleggende ===
Som man ser er utgivelseshåndtering helt grunnleggende for at datamaskiner, programvare og nettverket virker som planlagt. Skikkelig håndtering av utgivelser gjøres for å hindre driftsforstyrrelser. Ved nye utgivelser eller endringer er det forventet at driften skal gå som normalt uten avbrudd eller reduksjon i kvaliteten.
Håndtering av endringer eller nye utgivelser kan sammenlignes med å bygge ny vei. Bilene må fortsatt komme fram selv om man bygger ny vei oppå den gamle. God skilting må være på plass. Man må også ha de nødvendige ressurser til å legge om veien. Mangler man ressurser til å gjøre endringene så er det like greit å la vær.
For noen kan det være kjedelig med skikkelig utgivelseshåndtering. Man får ikke brukt det nyeste nye hver gang det kommer noe nytt. Men som oftest er det ikke satt av ekstra tid i driftsavdelingen for å håndtere en flom av klager når helt ny programvare svikter. Linux-eksperten David Elboth slår fast at høye oppetider krever etablert teknologi. I LINUXmagasinet (1/2004) skriver han:
Desto høyere krav desto strengere blir kravene til de enkelte komponentene. Høye krav til oppetid resulterer også at valgene du står igjen med er gammel teknologi. Det er nemlig erfaringsmateriale over tid som kan si noe om nedetid. Vi har alle lagt merke til hvor lenge etter Red Hat og SuSE ligger på sine serverprodukter.
Vil man ha lite klager med stabilt og driftssikkert miljø krever dette solid utgivelseshåndtering. Alternativt er en haug med klager og misfornøyde brukere man har installert siste skrik av programvaren som ikke er godt nok testet. Personer med «gutteromskompetanse» har en lei tendens til å undervurdere konsekvenser ved oppgradering av programvare. At noe går fint på hjemmedatamaskinen betyr ikke at dette vil fungere i et stort datanett med 500 klientmaskiner og 3200 brukere.
=== Sentralt programarkiv (DSL) ===
Programarkivet i driftssammenheng er en samling av originalutgaven av den programversjonen av programvaren som er i produksjon. Bruker man Skolelinux 2.0 er det dette som er programarkivet. I dataverdenen brukes ordet programarkiv i flere sammenheng, spesielt når man programmerer. Når det gjelder drift snakker vi den originale sammensatte programvare av en bestemt versjon som er utgangspunktet for installasjonen.
Bruker man fri programvare kan programarkivet være Skolelinux 2.0 pluss de ekstra programmene man har lagt inn i tillegg fra forskjellige kilder. Det kan være bestemte versjoner av Macromedia Flash, Java og decodere som gjør det mulig å kjøre nasjonale prøver i nettleseren, eller se sendinger fra NRK.
Har man planlagt og oppgradere til neste versjon av Skolelinux når den har kommet, vil det være den nye versjonen som blir hoved programarkiv. Også her vil alle ekstra programmer ut over ny Skolelinux være en del av arkivet.
Oppsettfiler som er justert eller laget lokalt av driftsavdelingen er følger ikke med som en del av hovedarkivet for programmer. Konfigurasjoner lagres i en egen versjonshåndtert katalog eller database.
=== Database for konfigurasjoner og maskinvare ===
Som nevnt under kapitlet med konfigurasjonsstyring må man opprette en database eller en versjonshåndtert katalog for å ta vare på oppsettfiler. Man må også ha oversikt over alle datamaskiner, hva slags maskiner det er snakk om, ytelse, og unike standardadresser på nettverkskortene (MAC adresser).
Det er mange grunner til å ha oversikt over utstyret. En av hovedgrunnene er å ha oversikt over hvor mange maskiner som er i drift, antall maskiner som ikke er i bruk, og antall maskiner på reparasjon. En annen grunn går på planlegging ved oppgraderinger. Det går både på hvor mye
=== Bygg-håndtering ===
I skolen installeres en rekke program i tillegg til nettleser og kontorprogram. Det trengs pedagogiske program for læring, tilleggsprogram i nettleseren, og det trengs program for multimedia. Systemene har også nettverksoppsett og endrede innstillinger i bestemte programmer. Har man mange tjenermaskiner og kanskje tusenvis av klienter ser man raskt at det er behov for effektive verktøy for utrulling. Slike verktøy er standard i Skolelinux.
Bygg-håndtering handler om å få installert de ønskede programpakkene, tjenestene og riktig innstillinger både av enkelte program og datanettverket. Mange har hørt om å bygge såkalte «images». Man installerer operativsystem og alle de programmene man trenger. Stiller inn nettverket. Deretter bruker man et image-program for å lage en kopi av det som er installert på harddisken. Dette kopieres så ut til de andre datamaskinene.
Det er slett ikke nødvendig å bygge såkalte «images» eller diskbilder man kan kalle det på norsk. Skolelinux bygger på Debian som har et utmerket pakkesystem. Man trenger på ingen måte å kompilere programmer da dette er ferdig satt sammen, og kan installeres rett fra Internett. Det man må ha orden på er ønskede endringer i standardoppsettet til Skolelinux eller hoved programarkivet som er i bruk. Deretter lager man et eller flere skript som kan kjøre på de forskjellige maskinene for å få alt installert og satt opp.
For de fleste situasjoner er skripting en enkel måte å «bygge» og rulle ut programmer og oppsett. Men det er situasjoner der bygging av diskbilder kan være løsningen. F.eks. ved installasjon på mange bærbare datamaskiner.
Som vi ser handler håndtering av bygg-prosessen om å tilrettelegge for utrulling på mange datamaskiner. Helt unntaksvis handler det om å bygge en skreddersydd Debian-pakke. Men i de aller fleste situasjoner er alt pakket ferdig. Da må man få på plass et skript for som installerer ekstra programmer og bestemte innstillinger. Man kan også lage diskbilder om man har mange like maskiner, som f.eks. bærbar PC til alle elevene.
=== Testing ===
Det er helt avgjørende å teste nye programmer, konfigurasjoner, og nye tjenester før de settes i produksjon. Flere skoler har erfart ustabilitet fordi de har installerer programvare uten å gjøre de nødvendige justeringene. Derfor er det helt avgjørende å teste endringer i konfigurasjoner eller ny versjon av programvaren før endringen gjøres på alle maskinene.
Testing skjer gjerne i tre steg.
* Først gjør man en installasjon av endringene på et testnettverk. Dette er teknisk testing der man forsikrer seg at alt henger sammen på et system uten brukere. Ta vare på alle endringene i oppsettfilene.
* Når man er sikker på at alt virker på den tekniske siden prøveinstalleres løsningen på en skole. Det er svært viktig å avtale testingen med skolens IT-kontakt. Brukerne må også få full orientering om at det vil bli endringer fordi man utfører testing. Ta vare på aktuelle justeringer i oppsettfiler som er gjort underveis ut fra de driftsmeldingene som har kommet.
* Når man er sikker på at alt virker kan man rulle ut løsningen til alle skolene. Det gjøres enklest med å lage et skript som forenkler oppgradering av programpakker, tjenester og konfigurasjoner.
=== Reserveløsning ===
Mye kan gå galt under en ny installasjon eller oppgradering. Derfor må man ha klar en reserveløsning. Det betyr at man på kort tid kan ta i bruk systemet slik det var før oppgraderingen. På fagspråket heter dette tilbakerulling.
Når man skal rulle tilbake er det helt avgjørende å ha klar forrige versjon av arkivet for programvare og oppsettfiler. Det betyr at man kan installere f.eks. Skolelinux 1.0 på under en time, og legge på plass aktuelle konfigurasjonsfiler.
Men tilbakerulling tar tid. Derfor kan det være greit å ha en tjenermaskin klar med forrige utgave av programvaren, de riktige konfigurasjonene, og hjemmekatalogene til brukerne. Denne tjeneren kan raskt erstatte maskinene som ble oppgradert, men ikke virket etter planen. Ved å ha tjenermaskin(er) i reserve kan man sørge for høy tilgjengelighet selv om noe skulle gå galt.
=== Fordeler og mulige problemer ===
Fordelen med å ha arkiv over programvaren som er i produksjon kan ikke undervurderes. Mange satser på å ha programvaren på sine respektive CD-er og enkelte DVD-er. Dette gir lite effektiv distribusjon. For å spare tid og bryderi er all programvaren i Skolelinux tilgjengelig på Internett.
Driftsavdelingen kan lage kopi av Skolelinux-arkivet på en sentral tjenermaskin. Herfra kan all programvaren raskt og greit installeres på de andre maskinene. Fordelen med dette er at IT-tjenesten hele tiden har oversikt over hvilke versjoner av programvaren som de har gjort tilgjengelig for skolene. Man hindrer også installasjon av programvare som ikke har vært vurdert av styringsgruppa for endringer.
Det kan oppstå betydelig problemer om man ikke vedlikeholder programarkivet og konfigurasjoner. Det kan også være at man gjør feil med en konfigurasjonsfil eller programpakke. Da rulles dette ut til alle maskinene. I tillegg kan enkelte skoler installere lite testet programvare eller beta-program som de setter i produksjon. Så man må ha gode prosesser og ha noen å holde ansvarlige for vedlikehold av programarkivet og konfigurasjonene.
Det kan virke som man må ha på plass mye ekstra for å installere og vedlikeholde tjenesten og programvaren som er i bruk. Velger man vekk de verktøyene som gir styring med oppgraderingene gir man seg selv mye ekstra arbeide. IT-tjenesten må bruke masse tid på manuelt arbeide med installasjon på hver enkelt maskin. Faren for å gjøre feil øker. Når ting ikke virker får man misfornøyde brukere, og mye tid går med til feilretting.
Mange som drifter store IT-systemer har mangelfulle planer for endringer. Noen har ikke planer i det hele tatt, men bare installerer nye utgaver av programvaren. Endringene som gjøres kan oppleves som problematiske for en del brukere fordi funksjoner de er komfortable med endrer plass i brukergrensesnittet. På driftssiden kan det gå fullstendig galt. F.eks. skulle de oppgradere til fra eldre utgave av Windows til nyere i Arendal Kommune. Det meste sluttet å virke. IT-tjenesten sa de hadde flere dataprogram som var holdt sammen med «ståltråd og tape». Det tok de et halvt år å rydde opp.
=== Planlegging og implementasjon ===
Årsaken til at man planlegger før man gjennomfører endringer er for å hindre uker eller ekstra måneder med problemer. Selv om man skulle bruke noe ekstra tid på planlegging, så tjenes dette raskt inn fordi man unngår ekstra problemer. Det vil alltid være personer som forteller at de ikke har hatt problemer med ad-hoc-endringer i systemene. Men når man undersøker nærmere viser det seg at det er problemer etter endringer, og at henvendelser om dette ikke formidlet videre.
I våre øyne er ad-hoc-løsninger kun en omvei ved endringer, og kun en nødløsning. En ad-hoc løsning kan sammenlignes med en midlertidig reparasjon med «ståltråd og tape». Man må på sikt rydde opp i slike løsninger når man vil ha stabil drift uten stadige overraskelser. Ved å hoppe over en planleggingsfase vil man få mange flere ad-hoc-løsninger, og flere driftsproblemer ved endringer eller oppgraderinger. Derfor er det helt avgjørende at fagfolk og ledelsen forstår verdien av en god planprosess. endringer.
Derfor anbefaler vi at man innkaller til planmøte, og lager en stegvis plan ved endringer av systemet. En stegvis plan vil selvsagt variere i forhold til hva som skal endres. Det å oppgradere kontorprogrammet !OpenOffice.org er noe annet enn å oppgradere hele systemet. Ved oppgradering til nytt kontorprogram holder det kanskje med en 2-3 timers gjennomgang av kontorpakken for læreren på hver skole. Når man skal oppgradere hele systemet må man både sørge for brukeropplæring og at det tekniske fungerer etter forutsetningene.
Hovedpoenget er at det er få snarveier når det kommer til planlegging og implementasjon. Undersøkelser viser at de som planlegger skikkelig og sørger for at folk har riktig kompetanse har lavere driftskostnader knyttet til driften.
=== Aktiviteter ===
Det er helt avgjørende å planlegge nye utgivelser. De fleste endringer av systemet skal avklares med ledelsen. Følgende liste over aktiviteter er laget som støtte ved oppgraderinger i en plan- og gjennomføringsfase.
||'''Oppgaver'''||'''Detaljer'''||
||Prioritering av utgivelsen:||Sjekk om nødvendige beslutninger er gjort før en endring eller oppgradering skal rulles ut.||
||Sentralt programarkiv||Sørg for at de aktuelle programpakker som ønskes installert er på plass i det sentrale programarkivet.||
||Konfigurasjonsdatabase||Sørg for å ha på plass alle oppsettfiler. Det gjelder både de som er i bruk, og de nye som følger med systemene som endres eller oppdateres.||
||Bygg-håndtering||Alle skript og systemer som brukes til utrulling eller å lage diskbiler (images) må på plass.||
||Testing||Kjør først utprøving på testutstyr. Når dette fungerer uten problemer så kan det prøves ut med en skole. Skolen må være fullt orientert om, og med på at de skal prøve ut ny programvare. Når man er sikker på at alt virker kan man oppgradere hos alle.||
||Reserveløsning||Selv med omfattende testing kan nye utgivelser gå galt. Derfor er det avgjørende å ha en reserveløsning. Den enkleste reserveløsningen er å ha den gamle installasjonen med data på en egen tjenermaskin. En slik maskin kan plugges inn om endringen eller oppgraderingen ikke virker.||
=== Verktøy ===
Som man ser av aktivitetslisten trenger man flere verktøy for å holde orden på forskjellige utgivelser av programvaren, tjenester og maskinvare i systemet. Noen av disse verktøyene er nevnt tidligere. Men vi gjentar dette allikevel:
* Debian-verktøy for sentralt programarkiv
* Database for konfigurasjoner og maskinvare (subversion for oppsettfiler, regneark med oversikt over all maskinvare med fysisk plassering)
* System for bygghåndtering
* Maskinvare for testing og reserveløsning
=== Relasjoner til andre prosesser ===
Utgivelsesledelse griper rett inn i kjernen til IT-tjenesten. Det går på å gjennomføre ønskede sikkerhetsoppdateringer, endringer i tjenester, eller og oppgradering av dataprogram. Forespørsler om nye utgivelser kan skyldes driftsproblemer eller ønske om ny programvare. Før en ny utgivelse så er det gjort en vurdering om endringen er ønskelig.
Om endringen er grei så vil man gjøre nødvendige endringer i konfigurasjoner og klargjøre programpakker for utrulling. Dette vil være testet, og man vil ha på plass reserveløsninger. Når endringene er utført vil man kanskje måtte legge om deler av driftsaktiviteten. Så det er enkelt å se at endringshåndtering påvirker alle deler av driftsstøtten.
== Verktøy for driftsstøtte ==
Det første man skal spørre seg selv om: «trenger vil virkelig programvareverktøy?» Trenger man verktøy så er det avgjørende å undersøke alternativene grundig.
Tar man en glanset brosjyre, og lytter til salgsprat, så er man helt avhengig av slike verktøy. Men gode folk, gode prosessbeskrivelser, og gode prosedyrer og arbeidsbeskrivelser er et grunnlag for god tjenestestyring. Behovet for, og hvor kompliserte verktøyene er, er avhengig av virksomhetens behov for datasystemer, og størrelsen på organisasjonen.
I en liten organisasjon vil en enkel fritt tilgjengelig database være nok for logging og styring på hendelser (request tracker). Men i større organisasjoner vil man ganske sikkert ha behov for et sofistikert distribuert og integrerte verktøy for tjenestestyring. Det betyr at man linker alle prosesser til et system for hendelseshåndtering.
Selv om verktøy kan være viktig, så er ikke disse viktige i seg selv. Det er de oppgaver og prosesser som må gjøres, og informasjonen som det er behov for som er utgangspunktet. Dette vil gi nødvendig informasjon til en spesifisering for hvilke verktøy som passer best til å støtte driften. Her er noen grunner til hvorfor man kan bruke programvare til driftsstøtte og tjenestehåndtering:
* økte krav fra brukerne
* mangel på IT-kunnskap
* budsjettbegrensninger
* virksomheten er helt avhengig av kvaliteten på tjenesten
* integrasjon av systemer fra flere leverandører
* økt kompleksitet i IT-infrastrukturen
* fremvekst av internasjonale standarder
* økt omfang og endringer innen IT
Automatiske verktøy tillater:
* sentralisering av nøkkelfunksjoner
* automatisering av funksjoner i tjenesteleveransen
* analyse av data
* identifisering av trender
* preventive tiltak kan implementeres
=== Type verktøy ===
I dette kapitlet har vi forestått en rekke verktøy for å forbedre driftsstøtten. Her følger en oppsummering av verktøyene:
* Debian-verktøy for sentralt programarkiv
* Database for konfigurasjoner og maskinvare (subversion for oppsettfiler, regneark med oversikt over all maskinvare med fysisk plassering)
* System for bygghåndtering
* Maskinvare for testing og reserveløsning
* Hendelseslogger (Request Tracker)
* System for overvåking (Munin)
Etter som driftsavdelingen får mer erfaring med systematisk drift vil det lages, eller skaffes flere typer verktøy.
=== Evalueringskriterier ved valg av verktøy ===
Selv om det er brukt store beløp på å lage evalueringskriterier for programvare, så finnes ikke annet enn erfaringsbaserte retningslinjer. Det er ingen endelige svar på hva som er god eller mindre god programvare. Som med mye annet dreier en del seg om smak og behag. Flere løsninger gjøre samme jobben like godt, men kan ha ganske forskjellig utforming. Men det er noen tommelfingerregler som kan være nyttige å ta med seg.
Det viktigste evalueringskriteriet er om man har behov for å gjøre en jobb i det hele tatt. Mange IT-verktøy er helt perfekt og løser sine oppgaver uten feil, men det løser oppgaver ingen trenger å ha løst. Så det viktigste kriteriet er om man løser riktig problem, og om det i det hele tatt er nødvendig å gjøre noe som helst.
* Så det første man spør om er om verktøyet er ønsket.
Om det viser seg at man vil ha løst en oppgave, kan det vise seg at løsningen er så enkel at det er like greit å kjøre noen kommandoer for hånd. Det enkleste er gjerne det beste. Men når man får mange maskiner å drifte blir automatisering helt avgjørende. Det blir for mye jobb å logge seg inn på 20 likeartede tjenermaskiner for å gjøre en sikkerhetsoppgradering. Da er automatisering tingen.
* Så her må man spørre om verktøyet er nyttig til å løse oppgaven.
* Deretter må man spørre om verktøyet er brukbart.
Det er ofte et stort utvalg av programmer og fremgangsmåter for å løse et bestemt oppgave. Men en del problemer løses helt annerledes når man vedlikeholder 500 datamaskiner og 11 tjenermaskiner enn når man fikser hjemme-PC-en. Et eksempel kan være verktøy for at læreren kan se skrivebordet til hver enkelt elev på sin klientmaskin. Læreren kan stoppe og starte programmer hos alle elevene, og hindre enkeltelever å bruke f.eks. lynmeldinger når dette forstyrrer skolearbeide.
Når det gjelder valg av driftsverktøy handler det om automatisering og forenkling av driftsoppgaver. Det er om å gjøre og få redusert manuelt arbeide til et minimum. Så motivasjonen er å kun vedlikeholde automatikken. Også her går det på å gjøre ting enkelt, noe som kan være en betydelig jobb å få til.
Som man ser er det slett ikke enkelt å sette opp gode kriterier for valg av driftsverktøy for store installasjoner. Mest av alt kan dette skyldes at utviklere av programvare ofte mangler erfaring fra drift av IT-systemer. De er kun kjent med å lage nye ting, og det å lage gode og relevante verktøy for drift krever mange års erfaring.
En del generelle driftsverktøy som ikke har vært byttet ut de siste 20 årene. Men de produktene som brukes kan være byttet ut. Også noen programmer kan om få år være uaktuelle å bruke. Derfor må man belage seg på trening i nye utgaver av programmene som brukes til drift, eller ved oppgradering og endringer i brukerprogram.
=== Produkttrening ===
Grundig brukeropplæring gjør at mye av brukerstøtten kan ivaretas uformelt i direkte samtale mellom brukere. Ofte er opplæringskostnadene så lite som 1% av de totale driftskostnader. Det er vel verdt å bruke litt mer til opplæring. Effekten er svært positiv. Det samme gjelder riktig opplæring for IT-kontaktene på skolene, og driftsoperatører. Trening av IT-kontakter i bruk av enkle systemer for passordbytte, feilmeldinger ol. vil gi bedre kvalitet på henvendelsene til IT-tjenesten.
Opplæring og produkttrening er regulert i Arbeidsmiljøloven (§ 4-2):
Arbeidstakerne og deres tillitsvalgte skal holdes løpende informert om systemer som nyttes ved planlegging og gjennomføring av arbeidet. De skal gis nødvendig opplæring for å sette seg inn i systemene, og de skal medvirke ved utformingen av dem.
Så kort fortalt kan man med fordel øke innsatsen på opplæring, noe som vil forbedre IT-tjenesten og gi betydelig kostnadsreduksjon. Dette fordi brukere og IT-kontakter blir tryggere og flinkere til å hjelpe hverandre. Det bør også nevnes at overgang til ny programvare kan også gi en anledningen til å forenkle noen av driftsrutinene. Forenklinger kan redusere kravet til produkttrening.
== Planlegging ved igangsetting av servicestøtte ==
Et stadig økende antall virksomheter ser nødvendigheten av tjeneste-styring. Det er ofte praksis at man baserer beslutninger på historiske og politiske vurderinger, framfor gjeldende behov i virksomheten. Derfor er det viktig å sikre at ledelsen forplikter seg til deltagelse, og forståelse for arbeidsmåten i organisasjonen, og gå gjennom eksisterende prosesser og sammenligne disse med virksomhetens behov og «best practice».
=== Innføring av servicestøtte ===
Helsesjekk
=== Brukbarhetsstudie (Feasibility study) ===
=== Fastslå gjeldende situasjon ===
Helsesjekk
=== Generelle retningslinjer for prosjektplanlegging ===
Forretningstilfelle for prosjektet
Kritiske suksessfaktorer og mulige problemer
Prosjektkostnader
Organisasjonen
Produkt
Planlegging
Kommunikasjonsplan
=== Prosjektgjennomgang og rapportering ===
Fremdrift
Evaluering av prosjektet
Etterarbeide
Gjennomgang for å sjekke samsvar med kvalitetsparametere
Gjennomgang i forhold til nøkkelfaktorer
More information about the debian-edu-commits
mailing list