IT Service Management

Størrelse: px

Begynne med side:

Download "IT Service Management"

Odd Davidsen
10 år siden
Visninger:

1 IT Service Management Forelesning uke 3 Innhold Repetisjon fra forrige uke. Service Operation: Incident Management Repitisjon Service Operation: Finne rette balansen Event Management: Få oversikt over hva som skjer. Service Operation: Incident Management Incident management er definert som: Å gjennopprette normal drift av tjenesten så raskt som overhodet mulig og minimere konsekvensene for virksomheten. Husk: normal drift er alltid definert i SLA Vi oversetter her incident med tilfelle Incident Management - Omfang Administrere alle brudd, eller potensielle brudd av en tjeneste i produksjon Tilfeller blir indentifisert gjennom: Direkte av brukerne gjennom Service Desk Gjennom grensesnitt og verktøy. Gjennom teknisk personale. Husk: Alle hendelser eller henvendelser er ikke alltid nødvendigvis et tilfelle. 1

Service Operation: Incident Management Incident management er definert som: Å gjennopprette normal drift av tjenesten så raskt som overhodet mulig og minimere konsekvensene for virksomheten.

2 Incident Mangement - Forretningsverdier Raskere løsing av tilfeller. Høyere kvalitet. Reduserte kostnader til brukerstøtte. Incident Management - Definisjoner Tilfelle (Incident) Et ikke planlagt brudd eller reduksjon av kvalitet på en tjeneste Enhver hendelse som i fremtiden kan påvirke en tjeneste er også et tilfelle. Tidsfrister (Timescales) Det bør gjøres en vurdering over hvor lang tid man skal bruke på hvert tilfelle, dette bestemmes av klassifisering og SLAer. Begivenhetsmodeller (Incident Models) Det bør være et sett med rutiner som fanger opp gjentagende tilfeller, og hvordan de behandles. Alvorlige tilfeller (Major Incidents) Egne prosedyrer med kortere tidsfrister og høyere prioritet enn for vanlige tilfeller som klasifiseres som alvorlige. Incident Management - Aktiviteter Identifisering (Identification) Logging (Logging) Kategorisering (Categorization) Prioritering (Prioritization) Initsiell diagnose (Initial diagnosis) Eksalering (Escalation) Undersøkelse og grundig diagnose (Investigation and diagnosis) Løsning og gjennoppretting (Resolution and recovery) Lukking (Closure) Identifisering Et tilfelle eksisterer ikke før det rapportert inn av noe eller noen Er det bra nok at brukeren er den som forteller IT om et tilfelle? 2

Tidsfrister (Timescales) Det bør gjøres en vurdering over hvor lang tid man skal bruke på hvert tilfelle, dette bestemmes av klassifisering og SLAer.

3 Logging Alle tilfeller må loggføres uansett hvem eller hva som rapporterer dem, eller hvordan de rapporteres. All relevant informasjon bør også loggføres for lettere finne releavant historiske data senere. Logging av et tilfelle kan inneholde: Unikt referansenummer. Kategori (2-4 subkategorier). Prioritet. Dato og tid. Navn og ID på den som har meldt tilfelle. Hvor? (navn, avdeling, telefon, sted). Beskrivelse av symtomer. Status (new, active, waiting, closes). Configuration Item. Relaterte problem (allerede kjente feil?). Aktiviteter som er brukt til å løse saken. Tidsbruk. Når er tilfelle løst? Når er saken lukket? Kategorisering Hardware Server Software Disk Application Office Outlook Vær forsiktig med å lage for komplisert kategorisering Prioritering Et forslag til priortering kan være: 3

Dato og tid. Navn og ID på den som har meldt tilfelle. Hvor? (navn, avdeling, telefon, sted). Beskrivelse av symtomer. Status (new, active, waiting, closes). Configuration Item.

4 Impact/Urgency High Medium Low High Medium Low Kode Prioritet Tid 1 Critical 1 time 2 Høy 8 timer 3 Medium 24 timer 4 Lav 48 timer 5 Planlagt Som planlagt Initsiell diagnose Om tilfelle først er rapportert via Service Desk, må personale der foreta den initsielle diagnosen. Få frem flest mulig symtomer. Informer brukeren om hva som skjer videre. Eksalering Om tilfelle ikke kan løses av Service Desk, eller en tidsfrist er overskredet, så må den på en eller annen måte skaleres. Service Desk er alltid eier av tilfelles, uansett skalering. Undersøkelser og grundig diagnose Alle eksaleringer og enheter har sin egen fase med diagnose Alle faser må dokumenteres og loggføres skikkelig. Løsning og gjennoppretting Når en feil er lokalisert, må løsningen implementeres, og senere verifiseres. Ikke fusk med verifiseringen! Lukking (Closure) Service Desk bør sjekke ut med kunden om denne er fornøyd med resultatet, og at kunden er enig at tilfelle kan lukkes. 4

Eksalering Om tilfelle ikke kan løses av Service Desk, eller en tidsfrist er overskredet, så må den på en eller annen måte skaleres. Service Desk er alltid eier av tilfelles, uansett skalering.

5 Incident Management - Målepunker Antall tilfeller Kategoriering av tilfeller Størrelsen på antall åpne tilfeller Gjennomsnittlig tid det tar å løse et tilfell % løst på Service Desk % som ble påbegynnt innen avtalt responstid % som ble løst innen avtalt tid (SLA) Antall og % av Major Incidents Gjennomsnittelig kostnad for tilfellehåndering. Fordi Incident Management er så lett målbar og synlig, så er den som oftest det første man innfører i ITIL Incident Management - grensesnitt Problem Management Configuration Management Change Management Capacity Management Availablity Management Service Level Management Incident Management <--> Problem Management Tilfeller er ofte forårsaket av problemer Ofte må det dypere problemløsning til for å redusere antall tilfeller. Service Desk er ofte den som oppdager disse sammenhengene. Incident Management <--> Configuration Management En riktig database over utstyr er ofte helt nødvendig for å kunne løse tilfeller effektivt F.eks.: Hvilken nettport går til hvilken switch? Service Desk kan ha et ansvar for å oppdatere databasene. 5

Fordi Incident Management er så lett målbar og synlig, så er den som oftest det første man innfører i ITIL Incident Management - grensesnitt Problem Management Configuration Management Change

6 Incident Management <--> Change Management Når dypere endring er påkrevet for å løse opp i tilfeller, må det loggføres en Request For Change som føres videre til Change Management. Endringer som kommer fra Change Management vil kunne generere tilfeller. Incident Management <--> Capacity Management Antall tilfeller på et sted, kan gi indikasjoner på at kapasiteten ikke er riktig. Incident Management <--> Availablility Management Loggdata fra Service Desk-systemet kan brukes til å verifisere en tjenestes oppetid og hvor det kan gjøres forbedringer. Incident Management <--> Service Level Management Henger nøye sammen Data fra Service Desk er med på å påvirke SLA og omvendt. Incident Management <--> Event Management Hendelser og overvåkningsystem kan generere saker automatisk Incident Management - Roller Incident Manager Super User Førstelinje Andrelinje Tredjelinje Incident Manager Monitorere og drive frem prosessen Koordinere de ulike teamene Rapportere til ledelsen 6

Incident Management <--> Availablility Management Loggdata fra Service Desk-systemet kan brukes til å verifisere en tjenestes oppetid og hvor det kan gjøres forbedringer.

7 Super User Kommunikasjonsledd mellom IT og brukerne Opplæring av brukere Enklere supporttilfeller Være involvert i nye prosjekter Førstelinje Først og fremst Service Desk. Personale med bred og generell kompetanse Andrelinje Ikke alltid implementert. Personale med litt dypere men fremdeles generell kompetanse Tredjelinje Personale med dyp spesialkompetanse. Nettverk, Telefoni, Server, Hardware, Databaser Incident Management - Utfordringer Oppdage tilfeller så raskt som mulig. Sørge for at alle tilfeller er logget. Sørge for at historiske data er tilgjengelig. Ha klare mål og avtaler (SLA). Oppfølging av uløste tilfeller. Ha riktig og god nok kompetanse. Integrasjon med andre systemer. Incident Management - Verktøy Request Tracker (GPL) OTRS (GPL) Remedy Action Request System IBM Rational ClearQuest 7

Nettverk, Telefoni, Server, Hardware, Databaser Incident Management - Utfordringer Oppdage tilfeller så raskt som mulig. Sørge for at alle tilfeller er logget.

8 Incident Management - Høgskolen i Gjøvik Request Tracker 8

Like dokumenter

Kvalitetssikringssystemer i IKT Agder

9.4.2015 Kvalitetssikringssystemer i IKT Agder Kvalitetssikringssystemer 1 Innholdsfortegnelse 1 KVALITETSSIKRINGSSYSTEMER I IKT AGDER... 3 1.1 INCIDENT MANAGEMENT...3 1.2 CHANGE MANAGEMENT...3 1.3 PROBLEM