Problembehandling identifiserer rotårsak og eliminerer gjentagende problemer

Bruke sak med et blikk

Persona: En problemleder som er ansvarlig for å identifisere systemiske årsaker, koordinere undersøkelser og hindre gjentagende tjenesteavbrudd

Job å gjøre: Koble gjentagende hendelser til en enkelt problempost, fastslå og dokumenter rotårsaken og fremme en permanent løsning eller en eksplisitt risikobeslutning

Startpunkt: Hendelseshistorikk, tjenestedata eller driftstrender angir at samme eller relatert avbrudd er gjentakende

Vellykket resultat: Problemet har en støttet rotårsaksanalyse, relaterte hendelser og rettelsesposter kan spores, berørte brukere har godkjent veiledning, og etterendringsbevis viser at gjentagelse eller innvirkning har blitt redusert.

Bruk dette scenariet til å finne ut om et gjentagende problem er forstått og kontrollert. Bruk de relaterte hjelpeemnene for trinnene for å opprette og knytte til poster, oppdatere problemanalyse, dokumentere en løsning, opprette en endringsforespørsel, godta risiko, åpne et problem på nytt og lukke det.

Oppdage et mønster som er verd å undersøke

Start med bevis for en delt underliggende tilstand i stedet for bare antall hendelser. Sammenlign symptomer, feilsignaturer, berørte tjenester og konfigurasjonselementer (CI-er), tid, siste endringer, brukerpopulasjoner, løsninger og gjentagelse etter gjenoppretting av tjenesten. Lignende ordlyd kan beskrive forskjellige årsaker, mens forskjellig ordlydende hendelser kan stamme fra samme feil.

Bruk problemkontrollpaneler til å finne trender, åpent arbeid, brudd på tjenestenivåavtale (SLA), ikke-tildelte poster, løsningstid og mønstre for løsningskode. Behandle kontrollpanelinformasjon som et undersøkelsessalgsemne i stedet for bevis på at hendelser deler en årsak. Hvis du vil ha detaljer om kontrollpanelmålinger, kan du se Problembehandlingskontrollpanel for IT-tjenester.

Fastsette problemet uten å utsette gjenoppretting

Hendelsesbehandling gjenoppretter service for hver aktive avbrudd. Problembehandling undersøker og fjerner den systemiske årsaken. Hold disse utfallene separate: en hendelse kan løses gjennom en løsning mens dens relaterte problem forblir åpent, og et problem bør ikke avsluttes bare fordi den siste hendelsen sluttet å påvirke brukere.

Opprett eller velg ett problem som beskriver den gjentagende tilstanden i riktig omfang. Bekreft emne, beskrivelse, kategori, underkategori, berørte tjenester og CIs, innvirkning, haster, prioritet, eier og undersøkelsesstatus. Knytt de støttende hendelsene og andre relevante problemer, endringsforespørsler, utgivelser eller Knowledge slik at undersøkere kan skille mellom bevis og tilfeldighet.

Unngå å opprette ett problem for hver hendelse eller ett omfattende problem for ikke-relaterte feil. Bruk tilknytninger som Forårsaket av og Lignende bare når det tilgjengelige beviset støtter relasjonen.

Hvis den proaktive handlingen Tilknytt lignende problemer er aktivert, kan den automatisk knytte til problemposter basert på semantisk likhet. En lignende tilknytning etablerer ikke en Forårsaket av-relasjon. Se gjennom automatisk tilknyttede problemer før du bruker dem som bevis på en delt rotårsak.

Hvis du vil knytte poster manuelt, åpner du problemet. Klikk på Tilknytt på fanen Tilknytninger, og velg deretter en posttype og en relasjonstype, som Forårsaket av eller lignende. Fjerning av en tilknytning sletter ikke den tilknyttede posten. Løs er atskilt fra kobling og kan lukke flere relaterte poster, så se gjennom de valgte postene før du klikker på Løs.

Hvis du vil vite hvordan du oppretter og knytter problemer, løser problemer, godtar risiko og åpner problemer på nytt, kan du se Behandle problemer for IT-tjenester. Hvis du vil opprette et problem direkte fra en hendelse, kan du se Behandle hendelser for IT-tjenester.

Undersøke og etablere rotårsaken

Bygg en testbar forklaring fra hendelsestidslinjer, logger, telemetri, konfigurasjons- og aktivumdata, nylige endringer, kjente feil, Knowledge og emneekspertise. Gjengi feilen sikkert når det er mulig. Sammenlign berørte og ikke berørte tilstander, utfordre konkurrerende forklaringer, og registrer hvilke bevis som bekrefter eller avviser hver hypotese.

Dokumenter årsakskjeden i stedet for å gjenta symptomet. Forklar den mislykkede betingelsen, hvorfor den produserte den observerte innvirkningen, det berørte omfanget og betingelsene som problemet kan gjenta seg under. Anfør postene eller testene som støtter konklusjonen. Merk uløste forutsigelser og tildel oppfølgingsarbeid i stedet for å presentere utledning som faktum.

Spor den konfigurerte rotårsaksmilepælen uten å kompromittere undersøkelseskvaliteten. Standard problem-SLA sporer fullføringstiden for rotårsak for kritiske og høyt prioriterte problemer, men organisasjonens policyer kan variere. Fullføring av milepælen viser ikke at analysen er riktig. Se SLA Policy for Problem for IT Services.

Redusere innvirkningen med en midlertidig eller kjent feil

Når en sikker midlertidig metode reduserer avbrudd, dokumenterer du dens anvendbarhet, forutsetninger, trinn, begrensninger, risikoer og bekreftelsesresultater i problemets løsningsinformasjon. Gjør veiledningen tilgjengelig for hendelsesinnfriere slik at de kan gjenopprette tjenesten konsistent mens den permanente rettelsen venter.

Opprett eller oppdater en Knowledge om en kjent feil når en bekreftet rotårsak og gjenbrukbar løsning må være tilgjengelig utover problemposten. Fjern postspesifikke og sensitive detaljer, ruter artikkelen gjennom den konfigurerte gjennomgangsprosessen, og kontroller at den tiltenkte kundestøttegruppen kan finne den. En midlertidig løsning kontrollerer symptomer eller påvirkning. Den eliminerer ikke den underliggende årsaken.

Hvis det ikke finnes noen sikker løsning, angir du det eksplisitt og styrker overvåking, eskalering, kommunikasjon og gjenopprettingsforberedelse. Bruk en Knowledge til å gjøre en bekreftet midlertidig løsning tilgjengelig for den tiltenkte målgruppen. Se Viktige arbeidsflyter i IT-tjenester.

Eliminere årsaken gjennom kontrollert endring

Når det er tilstrekkelig bevis som støtter rotårsaken og rettelsen, oppretter og knytter du en endringsforespørsel til problemet. Inkluder det berørte omfanget, årsaksbevis, foreslått rettelse, implementeringskrav, testplan, tilbakevulningstilnærming, tidsplarbegrensninger og bekreftelseskriterier. Hold problemet åpent mens endringen går gjennom risikovurdering, godkjenning, planlegging, implementering og verifisering.

Endringsutfallet må teste årsakskravet. Kontroller at den målrettede betingelsen ble endret som forventet, at tjenestetilstanden forble akseptabel, at tilbakekalling ikke var nødvendig eller var vellykket, og at det ikke oppsto noen vesentlige bivirkninger. En vellykket implementert endring er ikke nok hvis den gjentagende feilen fortsetter.

Når en permanent løsning ikke er mulig, bruker du godta risiko først etter at de aktuelle interessentene har forstått restinnvirkningen, sannsynligheten, gjeldende kontroller, eierskap og gjennomgangsbetingelser. Registrer begrunnelsen og betingelsene som utløser overvåking eller gjenåpning. Risk acceptance er en styrt beslutning, ikke en erstatning for ufullstendig analyse. Hvis du vil vite mer om endringsforespørsler og trinn for aksept av risiko, kan du se Håndtere problemer for IT-tjenester.

Kontrollere gjentagelsesreduksjon og avslutning

Observere tjenesten i en periode og et volum som passer til det opprinnelige gjentagelsesmønsteret. Sammenlign hendelseshyppighet før og etter utbedring, berørte brukere eller transaksjoner, feilfrekvenser, nedetid, bruk av midlertidige tiltak, støtteinnsats og utfall på tjenestenivå. Ta hensyn til endringer i årstid, trafikk, utgivelser og rapportering før du tilskriver forbedring til rettelsen.

Lukk problemet bare når posten inneholder den støttede rotårsaken, løsningsinformasjon, tilknyttede hendelser og løsning, bekreftelsesbevis, gjenværende risiko og gjenbrukbar Knowledge. Løs relaterte tilknytninger i henhold til organisasjonens prosess samtidig som du beholder historikken for dem. Åpne problemet på nytt når problemet gjentas, årsaksforklaringen blir avvist eller nye bevis endrer den nødvendige handlingen.

Problembehandling er vellykket når en bekreftet løsning eller eksplisitt risikobeslutning fører til en sporbar reduksjon i gjentagelse eller innvirkning. Å avslutte et problem, publisere en artikkel eller fullføre en endring alene viser ikke at det gjentagende problemet ble eliminert.

Bruke AI som assistanse, ikke bevis

Når det er konfigurert, kan Einstein lage utkast til et problem fra en hendelse, og Agentforce kan oppsummere problemer, kontrollere attributter, finne relaterte poster, foreslå løsninger og utkast til rotårsak- eller løsningsoppsummeringer. Se gjennom genererte felt og tilknytninger før du lagrer eller behandler dem.

Genererte sammendrag og foreslåtte rettelser er ikke bekreftet rotårsak-bevis. Bekreft alle materielle krav mot logger, poster, tester, klarerte Knowledge kilder og fageksperter. Behold skillet mellom et semantisk samsvar, en plausibel hypotese og en demonstrert årsak. Se Opprette problemer automatisk fra hendelser med Einstein, AI-handlinger for problembehandling og Proaktive handlinger for IT-problemer.

Bekrefte at problembehandling er klar

Før du distribuerer denne prosessen mer omfattende, må du kontrollere at Problembehandling og dens feltvalideringer, prioritetsmatrise, postoppsett, tilknytninger, kontrollpaneler og tjenestenivåavtaler støtter prosessen. Kontroller også at de nødvendige Knowledge, Change Management- og konfigurasjonsbehandling-databasekomponentene (CMDB) er konfigurert. Einstein, Agentforce og proaktive handlinger er valgfrie funksjoner som krever separat oppsett og tillatelser.

Tildel den riktige tillatelsessettgruppen Problembehandling eller Problem Fulfiller. Tildel også tillatelsene som kreves for å godta risiko, gjenåpne problemer, knytte hendelser, endringsforespørsler og utgivelser til problemer og løse tilknytninger. Se Konfigurere problembehandling for IT-tjenester og tillatelsessett for problembehandling for IT-tjenester.

Valider konfigurasjonen før du distribuerer den mer omfattende. Kontroller at en godkjent bruker kan finne problemposter og kontrollpaneler, inspisere analyse- og løsningsfelt og vise relaterte hendelser og andre tilknytninger. Kontroller at de riktige endringsforespørslene og risikohandlingene er tilgjengelig for postens tilstand sammen med eventuell konfigurert Knowledge og AI-hjelp. Når du tester, avslutter du eventuelle opprettings-, redigerings-, spørreskjema-, genererings-, godkjennings- eller avslutningsflyter uten å lagre endringer.