Hendelsesleder koordinerer en hovedhendelse

Bruke sak med et blikk

Persona: En hendelsesleder som arbeider med en hovedhendelsesleder og løsningsteam

Job som skal gjøres: Eskalere en forretningskritisk hendelse, etablere delt driftskontekst, koordinere løsningsarbeid og holde interessenter informert

Startpunkt: En hendelse med stor innvirkning i Agent IT Service Desk som krever mer omfattende oppmerksomhet og koordinering

Vellykket resultat: Hendelsen klassifiseres riktig, løsingsteam gjenoppretter og bekrefter tjenesten, interessenter mottar tydelige oppdateringer, og oppfølgingsarbeid flyttes til Problembehandling.

Dette brukstilfellet følger en kritisk hendelse fra eskalering til gjenoppretting. Det erstatter ikke de kanoniske prosedyrene for å foreslå, gjennomgå, fremheve eller avslutte viktige hendelser. I stedet viser den hvordan en hendelsesleder og hovedhendelsesleder bruker én post til å ta beslutninger, justere respondenter og opprettholde en ansvarsfull tidslinje.

Innfriere kan foreslå en hendelse som en hovedhendelse for gjennomgang. Brukere med høy hovedhendelsesmyndighet kan promotere en hendelse direkte fra hendelsesposten uten godkjenning. Degradering av en hovedhendelse krever tillatelsen Hovedhendelsesbehandling. Hold forslaget og banene for direkte promotering distinkt. Se Hovedhendelsesbehandling for IT-tjenester, Se gjennom viktige hendelser for IT-tjenester og Demontere viktige hendelser for IT-tjenester.

Kvalifisere avbruddet

Start med forretningsvirkning i stedet for bare hendelsesprioritet. En større hendelse påvirker flere brukere eller krever en umiddelbar respons fordi flere forretningssystemer ikke er tilgjengelig. Bekreft de berørte tjenestene og brukerne, operasjonell haster, kjente avhengigheter og bevis fra relaterte hendelser før eskalering.

Bruk forslagsbanen når avbruddet krever gjennomgang. Brukere med forhøyet hovedhendelsesmyndighet kan bruke banen for direkte promotering når denne myndigheten er konfigurert. Hvis du vil vite mer om kvalifikasjon og prosessomfang, kan du se Hovedhendelsesbehandling for IT-tjenester.

Opprette hovedhendelsesposten

Registrer en presis begrunnelse som forklarer innvirkningen, haster og årsak til bredere koordinering. Et forslag går til gjennomgang, der en bruker med den nødvendige autorisasjonen godkjenner eller avviser det. Direkte promotering hopper over gjennomgangsprosessen. Demonstrasjon returnerer en hovedhendelse til standard hendelsesbehandling.

Hold livssyklusen for hovedhendelsesklassifiseringen atskilt fra den operative hendelsesstatusen. Forslag, godkjenning eller avvisning, direkte promotering og degradering er klassifiseringshandlinger. Verdier for driftsstatus som Ny, Pågår, Løst og Avsluttet beskriver hendelsens fremdrift mot gjenoppretting og fullføring. Bruk de eksakte tilstandsetikettene for livssyklusen som er dokumentert i Hovedhendelseslivssyklus for IT-tjenester.

Bruk kommentarer for hovedhendelsesstatus til å registrere årsaken når du deformerer en hovedhendelse. Registrer undersøgelsesopdateringer om hændelsen ved brug af dens feed, relaterede lister og driftsstatus. Hvis du vil vite mer om kanonisk virkemåte for delstater og felt, kan du se Hovedhendelseslivssyklus for IT-tjenester. Se gjennomgå viktige hendelser for IT-tjenester for å se gjennomgangsbane og valgfri problemoppretting.

Koordinatgjenoppretting og kommunikasjon

Etter klassifisering bruker du hendelsesposten som den delte driftskilden. Identifiser en eier for hver gjenopprettingshandling, ta med de nødvendige løsningsgruppene, spor beslutninger og avhengigheter, og kontroller at tilknyttede hendelser representerer samme avbrudd.

Når det gjelder komplekst arbeid, starter du en konfigurert sverm slik at eksperter samarbeider i én kanal. Behold viktige beslutninger og løsningsbevis i hendelsesposten i stedet for å la diagnostisk historikk være bare i chat. Agentforce kan oppsummere en Slack-sversjon og legge inn sammendraget i postfeeden. Se Swarm on Incidents in Slack for IT Services for å finne alternativene for kanonisk samarbeid.

Send interessentoppdateringer ved meningsfylte endringer, som bekreftelse, bekreftet omfang, gjenopprettingsfremdrift, gjenoppretting og avslutning. Skill bekreftede fakta fra arbeidspåstander, angi den neste forventede oppdateringen, og unngå å love gjenopprettingstid uten bevis. Konfigurerte varsler kan levere oppdateringer via e-post, i appkanaler, Slack eller Microsoft Teams. Se Varsler for IT-tjenester.

Gjenopprette, avslutte og gå over

Kontroller at tjenesten er gjenopprettet for de berørte brukerne og systemene før du endrer hendelsen til Løst. Registrer gjenopprettingshandlingen, bekreftelsesbevis, gjenværende risiko og eventuell midlertidig løsning i Løsningssammendrag. Flytt hendelsen til avsluttet når livssyklusen er fullført under teamets prosess.

Hovedhendelsesklassifisering erstatter ikke oppfølgingsundersøkelse. Overfør hendelsen til Problembehandling for rotårsaksanalyse og preventivt arbeid. Automatisk problemoppretting skjer bare når den tilsvarende innstillingen for hovedhendelse er slått på. Ellers oppretter eller tilknytter du det nødvendige problemet gjennom teamets prosess.

Milepælen for tilpassing skjer når teamet går over fra fragmentert svar til én koordinert post: kvalifisert klassifisering, ansvarlig gjenopprettingsarbeid, konsistent kommunikasjon, bekreftet gjenoppretting og en eksplisitt oppfølgingseier. Hvis du vil vite mer om kanonisk hendelsesløsning og tilknytningsvirkemåte, kan du se Behandle hendelser for IT-tjenester.

Bekrefte at hovedhendelsesbehandling er klar

Før du bruker denne reisen som en tilpassingstest må du kontrollere at Hendelsesbehandling er aktivert, at godkjenningsgruppen er konfigurert, og at brukere har tillatelsene som kreves for de tildelte oppgavene. Kontroller at innfriere kan foreslå hendelser for gjennomgang, at autoriserte brukere kan gjennomgå eller promotere dem direkte, og at brukere som degraderer viktige hendelser, har tillatelsen Hovedhendelsesbehandling. Se Konfigurere innstillinger for viktige hendelser for IT-tjenester for kanonisk oppsett.