gigacampus » start page » gc-b-2

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

gigacampus:gc-b-2 [2010/02/08 14:27] (current)
Line 1: Line 1:
 +====== UH sektorens beste praksis innen IKT drift ======
 +
 +===== Bakgrunn =====
 +
 +UH sektorens institusjoner har bred og tung erfaring med drift av IKT-systemer. I regi av GigaCampus presenterer vi her et konsentrat av denne erfaringsdatabasen til nytte for hele sektoren.
 +
 +Det er ingen hemmelighet at vi er inspirert av ITIL. Det pågår ITIL-innføring ved flere universiteter. ITIL tilbyr et rammeverk for beste praksis som det er fornuftig å se til. ITIL kan imidlertid virke svært, for omfattende og oppslukende. Vi ønsker å overordnet trekke ut essensen, fornorske dette og sette det inn i UH-sektorens kollektive erfaringskontekst.
 +
 +GigaCampus har ingen ambisjon om å gripe inn i de enkelte universiteters/høgskolers ITIL-prosess, ei heller gi råd til om en slik prosess bør kjøres, og i så tilfelle hvordan. En ITIL-prosess er gjennomgripende for hele organisasjonen. Den må initieres lokalt, og drives lokalt. Dette er definitivt utenfor GigaCampus sitt mandat.
 +
 +Det vi her presenterer er en sjekkliste over de mest grunnleggende tingene man i det minste bør ha et bevisst forhold til.
 +
 +===== Overoverdnet mål med IKT drift =====
 +
 +IKT er et sentralt verktøy for å sikre virksomhetens forretningsmessige behov. For et universitet og en høgskole er primæroppgaven å drive forskning, undervisning og formidling. IKT skal strategisk understøtte disse prosessene.
 +
 +===== Organisering av IKT drift =====
 +
 +Profesjonell IKT drift kjennetegnes ved:
 +
 +    * Fokus på kunder og tjenester, ikke på teknologi
 +    * IKT understøtter virksomhetens mål
 +    * IKT drift kan brytes ned i prossesser, og organiseres i prosesser
 +    * Prosessene har kjøreregler, nedskrevne rutiner og veiledninger
 +    * Verktøy understøtter prosessene, de er hjelpemidler, hverken mer hverken mindre.
 +
 +Med andre ord; ikke tenk verktøy først, tenk organisering, tenk prosess, tenk arbeidsmåte og kjøreregler.
 +
 +==== Kontinuerlig forbedringsprosess ====
 +
 +    * IKT drift er en kontinuerlig forbedringsprosess. Det er en kollektiv forbedringsprosess for hele IKT avdelingen, den må formes og videreutvikles med grobunn i kulturen. Menneskene må engasjere seg og aktivt delta i forbedringsprosessen.
 +
 +Forbedringsmodellen kan skisseres slik (ascii-art):
 +
 +<code>
 +     --------------
 +   /               |
 +   |               v
 +   |       Hvor ønsker vi å være?
 +   |               |
 +   |               v
 +   |       Hvor er vi nå?
 +   |               |
 +   |               v
 +   |       Hvordan kommer vi dit vi vil?
 +   |               |
 +   |               v
 +   |       Hvordan vet vi at vi er i mål?
 +   |               |
 +    \              |
 +      -------------
 +</code>
 +
 +Man må altså ta utgangspunktet i nåsituasjonen, evaluere denne, sette seg noen realistiske forbedringsmål, jobbe med disse, måle underveis, vite når de er nådd, for så å starte en ny syklus, eller i parallell kjøre tilsvarende sykluser. Vi er aldri i mål, vi kan alltid bli bedre.
 +
 +Et sentralt aspekt er kvalitetssikring. Vi må måle. Måle hvor gode vi er. Måle om våre mål er oppnådd.
 +
 +===== Driftsprosessene =====
 +
 +IKT drift kan brytes ned i følgende essentielle prosesser:
 +
 +    * Insidenthåndtering (enkeltstående uforutsette feilsituasjoner)
 +    * Problemhåndtering (systematiske/metodiske problemer)
 +    * Endringshåndtering (planlagte/kontrollerte endringer)
 +    * Konfigurasjonshåndtering (dokumentere kjørende konfigurasjon, samt holde rede på historien)
 +
 +I tillegg til driftsprosessene, har vi de strategiske, som fokuserer på avtalemessige forhold, langsiktig planlegging, investeringsplan m.m. Vårt dokument forfølger ikke dette sporet.
 +
 +For å understøtte insidenthåndtering trengs funksjonene:
 +
 +    * driftsenter (eller tilsvarende)
 +    * beredskapsvakt
 +    * proaktivt overvåkningssystem
 +
 +==== Insidenthåndtering ====
 +
 +Insidenthåndtering har fokus på daglig drift, på håndtering av enkeltstående uforutsette feilsituasjoner.
 +
 +Sjekkliste:
 +
 +    * Brukerstøtte/driftsenter skal nåes på ett sted/ett tlfnr
 +    * Alle henvendelser må registreres
 +      * bruk verktøy for dette (se til hvilke verktøyerfaringer andre i sektoren har)
 +        * kan benyttes som erfaringsdatabase, det er dog underordnet, det viktigste er at man har et system for å følge opp henvendelser. 
 +    * Alle henvendelser tildeles en ansvarlig
 +    * Alle henvendelser klassifiseres (tenk gjennom en hensiktsmessig klassifisering som virker for dere).
 +      * Alarmer i alvorlighetsgrad (severity)
 +      * Tjenester i "viktighet" 
 +    * Gi tilbakemelding til brukeren!
 +      * Saker må være sporbare
 +      *Feil vil oppstå/skje, det er akseptabelt, men ikke om det er et sort hull for brukerne. De vil vite at man har oppdaget problemet og jobber med det. 
 +    * Måltall:
 +      * Sett dere måltall for hvor stor prosentandel av sakene som bør løses umiddelbart (på strak arm, med brukeren på tråden/i skranken/direkte svar på innkommende epost).
 +      * Sett tilsvarende måltall for andel av sakene som skal være løst innen 4 timer. 
 +    * Saker må kunne eskaleres
 +
 +==== Problemhåndtering ====
 +
 +Problemhåndtering kan være litt vanskelig å få tak på, den er ikke like konkret som insident- og endringshåndtering. Dette dreier seg først og fremst om sunn arbeidsmåte.
 +
 +    * Tenk langsiktig - skap varige forbedringer.
 +
 +Sjekkliste:
 +
 +    * Se etter følgefeil, systematiske/metodiske feil
 +    * Før man løser et problem, har man gjort en prioritering etter viktighet
 +    * Endringer utføres ikke umiddelbart, se endringshåndterng under.
 +
 +==== Endringshåndtering ====
 +
 +Endringshåndtering dreier seg om planlagte, kontrollerte endringer. All erfaring tilsier at svært mange feil skyldes menneskelig svikt, herunder manglende/fraværende planlegging.
 +
 +Det er viktig å ha en nøktern tilnærming til endringshåndtering. Lag noen enkle kjøreregler til å begynne med. Videreutvikle denne over tid, se etter forbedringer. Ikke dokumenter dere i hjel, ikke klassifiser på detaljnivå, lag et røft veikart.
 +
 +Sjekkliste:
 +
 +    * Klassifisering av endringer. Vurder hensiktsmessig klassifisering. Vi anbefaler fire kategorier: 
 +
 +<code>
 +    1. Daglig drift      => kjør på
 +    2. forhåndsgodkjente => kjør på, men følg rutine
 +    3. større            => må godkjennes (benytt RFC = request for change), 
 +                            krever plan, kanskje labtest
 +    4. hasteendring      => det brenner, begrens skaden, dokumenter i ettertid
 +</code>
 +
 +    * Definer servicevindu, dvs tidsluker i uken/måneden der tyngre vedlikeholdsarbeid kan gjennomføres. Forhold dere aktivt til servicevinduet. Gjør det godt kjent for brukerne.
 +
 +    * Definer varslingsrutiner
 +      * Forhåndsgodkjente: så så lenge før endringen (f.eks 2 dager)
 +      * Større: lenger før (f.eks 1 uke, evt kortere)
 +
 +    * Ansvar (hvem har ansvar for hva)
 +    * Endringslogg: Ha en god endringslogg. Dette er viktig! Man må kunne se hva som er gjort, av hvem og når. I prinsippet bør "alt" loggføres.
 +    * Dokumentasjon for endringsprosessen
 +      * rutiner/sjekklister for komplekse endringer
 +      * howto (hjelp og lær opp dine kollegaer, hjelp til selvhjelp også)
 +
 +==== Konfigurasjonshåndtering ====
 +
 +Konfigurasjonshåndtering fokuserer på dokumentasjon av egen IKT infrastruktur.
 +
 +=== Som et minimum ===
 +
 +    * Konfigurasjonsdatabase for de mest vitale komponentene
 +      * Rutere, sentrale svitsjer, servere 
 +    * De viktigste tjenestene må beskrives, herunder relasjonene mellom bokser og tjenester (skyggeforhold / tjenesteavhengigheter)
 +    * RCS er en "billig" måte å implementere historikk for nettkonfigurasjon (på boksnivå)
 +      * Dette bør suppleres med en reservekopi liggende hos partner. Det er ikke sikkert din lokale løsning er tilgjengelig/fungerende i en gitt feilsitiuasjon. 
 +    * Definer og implementer gode navnestandarder!
 +
 +=== Fullverdig ===
 +
 +Alle komponenter og dets konfigurajon skal være dokumentert, likeså topologien og relasjonene mellom komponentene. Man skal ha et oppdatert bilde av nåsituasjonen, men man skal også kjenne historien, gjennom dette de endringer som er gjort.
  
 
 
gigacampus/gc-b-2.txt · Last modified: 2010/02/08 14:27 (external edit)

Viktig melding: openwiki.uninett.no

UNINETT OpenWiki er under utfasing. Wikier som er lite brukt er satt i kun-lese-modus. Ta kontakt med UNINETT for å åpne for skrivetilgang ved behov.

Group memberships: no groups