Problemmanager identificerer grundlæggende årsag og eliminerer tilbagevendende problemer

Brug sag ved et enkelt blik

Persona: En problemmanager, der er ansvarlig for at identificere systemiske årsager, koordinere undersøgelse og forhindre tilbagevendende tjenesteafbrydelser

Det skal gøres: Tilslut tilbagevendende hændelser til en enkelt problemregistrering, fastslå og dokumenter grundårsagen og fremme en permanent løsning eller en eksplicit risikobeslutning

Startpunkt: Hændelseshistorik, servicedata eller driftstendenser angiver, at den samme eller relaterede afbrydelse gentages

Succesfuldt resultat: Problemet har en understøttet grundlæggende årsagsanalyse, relaterede hændelser og rettelsesregistreringer kan spores, påvirkede brugere har godkendt vejledning, og efter ændringsbevis viser, at gentagelse eller påvirkning er reduceret.

Brug dette scenarie til at bestemme, om et tilbagevendende problem forstås og kontrolleres. Brug de relaterede hjælpeemner til trin til at oprette og tilknytte registreringer, opdatere problemanalyser, dokumentere en løsning, oprette en ændringsanmodning, acceptere risiko, genåbne et problem og lukke det.

Registrer et mønster, der er værd at undersøge

Start med beviser for en delt underliggende sygdom snarere end antallet af hændelser alene. Sammenlign symptomer, fejlsignaturer, påvirkede tjenester og konfigurationselementer (CI'er), timing, seneste ændringer, brugerpopulationer, løsninger og gentagelse efter servicegendannelse. Tilsvarende ordlyd kan beskrive forskellige årsager, mens forskelligt formulerede hændelser kan stamme fra den samme fejl.

Brug problemdashboards til at finde tendenser, åbent arbejde, SLA-overtrædelser (service-level agreement), ikke-tildelte registreringer, løsningstider og mønstre for løsningskode. Behandl dashboardoplysninger som et undersøgelsesemne snarere end bevis for, at hændelser deler en årsag. Hvis du ønsker oplysninger om dashboardmetrikker, kan du se Problemmanager-dashboard for it-tjenester.

Etabler problemet uden at udsætte gendannelse

Hændelsesstyring gendanner service for hver aktiv afbrydelse. Problemstyring undersøger og fjerner den systemiske årsag. Bevar disse resultater adskilte: en hændelse kan løses gennem en løsning, mens dens relaterede problem forbliver åben, og et problem bør ikke lukkes blot fordi den seneste hændelse stoppede med at påvirke brugere.

Opret eller vælg et problem, der beskriver den tilbagevendende betingelse i det relevante omfang. Bekræft dens emne, beskrivelse, kategori, underkategori, påvirkede tjenester og CIs, påvirkning, vigtighed, prioritet, ejer og undersøgelsesstatus. Tilknyt de understøttende hændelser og andre relevante problemer, ændringsanmodninger, frigivelser eller Knowledge, så undersøgere kan skelne beviser fra tilfældigheder.

Undgå at oprette et problem for hver hændelse eller et bredt problem for ikke-relaterede fejl. Brug kun tilknytninger som Forårsaget af og Tilsvarende, når de tilgængelige beviser understøtter relationen.

Hvis den proaktive handling Tilknyt lignende problemer er aktiveret, kan den automatisk tilknytte problemregistreringer baseret på semantisk lighed. En Lignende tilknytning etablerer ikke en Forårsaget af-relation. Gennemse automatisk tilknyttede problemer, før du bruger dem som bevis for en delt grundlæggende årsag.

Hvis du vil tilknytte registreringer manuelt, skal du åbne problemet. På fanen tilknytninger skal du klikke på Tilknyt og derefter vælge en registreringstype og en relationstype, f.eks. Forårsaget af eller lignende. Fjernelse af en tilknytning sletter ikke den tilknyttede registrering. Løs er adskilt fra linkning og kan lukke flere relaterede registreringer, så gennemse de valgte registreringer, før du klikker på Løs.

Hvis du ønsker trin til at oprette og tilknytte problemer, løse problemer, acceptere risiko og genåbne problemer, kan du se Administrer problemer for it-tjenester. Hvis du vil oprette et problem direkte fra en hændelse, kan du se Administrer hændelser for it-tjenester.

Undersøg og etabler grundlæggende årsag

Opbyg en forklaring, der kan testes, fra hændelsestidslinjer, logfiler, telemetri, konfigurations- og aktivdata, seneste ændringer, kendte fejl, Knowledge og ekspertise inden for emne. Genafspil fejlen sikkert, når det er muligt. Sammenlign påvirkede og ikke-påvirkede betingelser, udfordr konkurrerende forklaringer, og registrer, hvilke beviser der bekræfter eller afviser hver hypotese.

Dokumenter årsagskæden i stedet for at gentage symptomet. Forklar den mislykkede betingelse, hvorfor den producerede den observerede påvirkning, det påvirkede omfang og de betingelser, hvorunder problemet kan gentages. Tilknyt de registreringer eller test, der understøtter konklusionen. Marker uløste antagelser, og tildel opfølgningsarbejde i stedet for at præsentere konklusion som fakta.

Spor den konfigurerede grundlæggende årsagsmilepæl uden at kompromittere undersøgelseskvaliteten. Standard-Problem-SLA'en sporer tidspunktet for fuldførelse af grundlæggende årsag for kritiske problemer og problemer med høj prioritet, men organisationens politikker kan være forskellige. Fuldførelse af milepælen beviser ikke, at analysen er korrekt. Se SLA-politikken for Problem for it-tjenester.

Reducer påvirkning med en løsning eller en kendt fejl

Når en sikker midlertidig metode reducerer afbrydelse, skal du dokumentere dens anvendelighed, forudsætninger, trin, begrænsninger, risici og bekræftelsesresultater i problemets løsninger. Gør vejledningen tilgængelig for hændelsesfuldførere, så de kan gendanne servicen ensartet, mens den permanente løsning afventer.

Opret eller opdater en Knowledge om en kendt fejl, når en bekræftet grundlæggende årsag og en genanvendelig løsning skal være tilgængelig ud over problemregistreringen. Fjern registreringsspecifikke og følsomme detaljer, distribuer artiklen gennem den konfigurerede gennemgangsproces, og bekræft, at den tilsigtede supportmålgruppe kan finde den. En løsning kontrollerer symptomer eller påvirkning. Den eliminerer ikke den underliggende årsag.

Hvis der ikke findes nogen sikker løsning, skal du angive det eksplicit og styrke overvågning, eskalering, kommunikation og gendannelsesforberedelse. Brug en Knowledge til at stille en bekræftet midlertidig løsning til rådighed for den tilsigtede målgruppe. Se Nøglearbejdsflows i it-tjenester.

Eliminer årsagen gennem kontrolleret ændring

Når der er tilstrækkelig beviser, der understøtter grundlæggende årsag og løsning, skal du oprette og tilknytte en ændringsanmodning fra problemet. Inkluder det påvirkede omfang, årsagsbevis, foreslået løsning, implementeringskrav, testplan, tilbagerulningsmetode, tidsplansbegrænsninger og bekræftelseskriterier. Bevar problemet åbent, mens ændringen fortsætter gennem risikovurdering, godkendelse, planlægning, implementering og bekræftelse.

Ændringsresultatet skal teste årsagskravet. Bekræft, at den målrettede betingelse blev ændret som forventet, at servicetilstanden forblev acceptabel, at tilbagerulning ikke var påkrævet eller lykkedes, og at der ikke blev vist nogen materielle bivirkninger. En korrekt implementeret ændring er ikke nok, hvis den tilbagevendende fejl fortsætter.

Når en permanent løsning ikke er gennemførlig, skal du kun bruge Accepter risiko, når de relevante interessenter har forstået restpåvirkningen, sandsynligheden, de aktuelle kontroller, ejerskab og gennemgangsbetingelser. Registrer begrundelsen og de betingelser, der udløser overvågning eller genåbning. Risk accept er en styret beslutning, ikke en erstatning for ufuldstændig analyse. Hvis du ønsker ændringsanmodninger og trin til accept af risici, kan du se Administrer problemer for it-tjenester.

Bekræft gentagelsesreduktion og Luk

Observer tjenesten i en periode og mængde, der svarer til det oprindelige gentagelsesmønster. Sammenlign før- og efter-hjælp-hændelsesfrekvens, påvirkede brugere eller transaktioner, fejlfrekvenser, nedetid, løsning, supportindsats og resultater på serviceniveau. Tag højde for sæsonudsving, trafik, frigivelser og rapporteringsændringer, før du tildeler forbedring til rettelsen.

Luk kun problemet, når registreringen indeholder den understøttede grundlæggende årsag, løsningsoplysninger, tilknyttede hændelser og afhjælpning, bekræftelsesbevis, resterende risiko og genanvendelig Knowledge. Løs relaterede tilknytninger i henhold til din organisations proces, mens du bevarer deres historik. Genåbn problemet, når problemet gentages, årsagsforklaringen afvises, eller nye beviser ændrer den krævede handling.

Problemstyring lykkes, når en bekræftet løsning eller en eksplicit risikobeslutning resulterer i en sporbar reduktion i gentagelse eller påvirkning. Lukning af et problem, udgivelse af en artikel eller udførelse af en ændring alene viser ikke, at det tilbagevendende problem er elimineret.

Brug AI som hjælp, ikke bevis

Når det er konfigureret, kan Einstein kladde et problem fra en hændelse, og Agentforce kan opsummere problemer, kontrollere attributter, finde relaterede registreringer, foreslå løsninger og kladde årsags- eller løsningssammendrag. Gennemse genererede felter og tilknytninger, før du gemmer eller reagerer på dem.

Genererede sammendrag og foreslåede rettelser er ikke bekræftet grundlæggende årsagsbevis. Bekræft alle materielle krav mod logfiler, registreringer, test, betroede Knowledge kilder og emneeksperter. Bevar forskellen mellem et semantisk match, en plausibel hypotese og en demonstreret årsag. Se Opret problemer automatisk fra hændelser med Einstein, AI-handlinger for problemstyring og proaktive handlinger for it-problemer.

Bekræft, at problemstyring er klar

Før du implementerer denne proces mere bredt, skal du bekræfte, at Problemstyring og dens feltvalideringer, prioritetsmatrix, registreringslayouts, tilknytninger, dashboards og SLA'er understøtter din proces. Bekræft også, at de krævede Knowledge, Change Management- og konfigurationsstyringsdatabase-komponenter (CMDB) er konfigureret. Einstein, Agentforce og proaktive handlinger er valgfri funktioner, der kræver separat opsætning og tilladelser.

Tildel den relevante tilladelsessætgruppe Problemmanager eller Problem Fulfiller. Tildel også de tilladelser, der kræves for at acceptere risiko, genåbne problemer, tilknytte hændelser, ændringsanmodninger og versioner med problemer og løse tilknytninger. Se Opsæt problemstyring for it-tjenester og tilladelsessættene problemstyring for it-tjenester.

Valider konfigurationen, før du implementerer den mere bredt. Bekræft, at en godkendt bruger kan finde problemregistreringer og dashboards, undersøge analyse- og løsningsfelter og se relaterede hændelser og andre tilknytninger. Bekræft, at de relevante ændringsanmodninger og risikohandlinger er tilgængelige for registreringens tilstand sammen med enhver konfigureret Knowledge og AI-hjælp. Når du tester, skal du afslutte ethvert oprettelses-, redigerings-, spørgeskema-, genererings-, godkendelses- eller lukkeforløb uden at gemme ændringer.