Il Gestore problemi identifica la causa principale ed elimina i problemi ricorrenti

Caso d'uso a colpo d'occhio

Profilo: Un responsabile dei problemi responsabile dell'identificazione delle cause sistemiche, del coordinamento delle indagini e della prevenzione di interruzioni ricorrenti del servizio

Lavoro da eseguire: Collegare incidenti ricorrenti a un singolo record problema, stabilire e documentare la causa principale e favorire una correzione permanente o una decisione esplicita sul rischio

Punto di partenza: La cronologia degli incidenti, i dati di servizio o le tendenze operative indicano che la stessa interruzione o l'interruzione correlata è ricorrente

Risultato positivo: Il problema ha un'analisi delle cause principali supportata, gli incidenti correlati e i record di riparazione sono tracciabili, gli utenti interessati hanno approvato le linee guida e le prove post-modifica indicano che la ricorrenza o l'impatto è diminuito.

Utilizzare questo scenario per determinare se un problema ricorrente è compreso e controllato. Utilizzare gli argomenti della Guida correlati per le fasi di creazione e associazione di record, aggiornamento dell'analisi dei problemi, documentazione di una soluzione, creazione di una richiesta di modifica, accettazione del rischio, riapertura di un problema e chiusura.

Rilevamento di uno schema che vale la pena analizzare

Iniziare con l'evidenza di una condizione sottostante condivisa anziché con il solo numero di incidenti. Confrontare sintomi, firme degli errori, servizi interessati ed elementi di configurazione (IC), tempistica, modifiche recenti, popolazioni di utenti, risoluzioni e ricorrenza dopo il ripristino del servizio. Formulazioni simili possono descrivere cause diverse, mentre incidenti con formulazioni diverse possono originare dallo stesso errore.

Utilizzare i cruscotti digitali dei problemi per trovare tendenze, lavoro aperto, violazioni del contratto sul livello di servizio (SLA), record non assegnati, tempo di risoluzione e schemi di codice di risoluzione. Considerare le informazioni del cruscotto digitale come lead di indagine anziché come prova che gli incidenti condividono una causa. Per informazioni dettagliate sulle metriche dei cruscotti digitali, vedere Problem Manager Dashboard for IT Services.

Definizione del problema senza ritardare il ripristino

Gestione incidenti ripristina il servizio per ogni interruzione attiva. Gestione dei problemi indaga e rimuove la causa sistemica. Mantenere separati questi esiti: un incidente può essere risolto tramite una soluzione mentre il problema correlato rimane aperto e un problema non deve essere chiuso semplicemente perché l'incidente più recente non interessa più gli utenti.

Creare o selezionare un problema che descrive la condizione ricorrente nell'ambito appropriato. Confermare l'oggetto, la descrizione, la categoria, la sottocategoria, i servizi e le informazioni aziendali interessati, l'impatto, l'urgenza, la priorità, il titolare e lo stato dell'indagine. Associare gli incidenti di supporto e altri problemi, richieste di modifica, rilasci o articoli Knowledge pertinenti in modo che gli investigatori possano distinguere le prove dalle coincidenze.

Evitare di creare un problema per ogni incidente o un problema generale per errori non correlati. Utilizzare associazioni come Causato da e Simile solo quando le prove disponibili supportano la relazione.

Se l'azione proattiva Associa problemi simili è abilitata, può associare automaticamente i record problema in base alla somiglianza semantica. Un'associazione simile non stabilisce una relazione Causato da. Esaminare i problemi associati automaticamente prima di utilizzarli come prova di una causa principale condivisa.

Per associare manualmente i record, aprire il problema. Nella scheda Associazioni, fare clic su Associa e quindi selezionare un Tipo di record e un Tipo di relazione, ad esempio Causato da o Simile. La rimozione di un'associazione non elimina il record associato. Risolvi è separato dal collegamento e può chiudere più record correlati, quindi rivedere i record selezionati prima di fare clic su Risolvi.

Per istruzioni su come creare e associare i problemi, risolvere i problemi, accettare i rischi e riaprire i problemi, vedere Gestione dei problemi per i servizi IT. Per creare un problema direttamente da un incidente, vedere Gestione degli incidenti per i servizi IT.

Analisi e determinazione della causa principale

Creare una spiegazione testabile basata su tempistiche degli incidenti, registri, telemetria, dati di configurazione e asset, modifiche recenti, errori noti, articoli Knowledge e competenze in materia. Ove possibile, riprodurre l'errore in modo sicuro. Confrontare le condizioni interessate e non interessate, contestare le spiegazioni concorrenti e registrare le prove che confermano o rifiutano ogni ipotesi.

Documentare la catena causale anziché ripetere il sintomo. Spiegare la condizione non riuscita, il motivo dell'impatto osservato, l'ambito interessato e le condizioni in cui il problema può ripresentarsi. Citare i record o i test che supportano la conclusione. Contrassegnare le ipotesi non risolte e assegnare il lavoro di follow-up anziché presentare l'inferenza come fatto.

Tenere traccia del punto saliente della causa principale configurato senza compromettere la qualità dell'indagine. Il Problem SLA standard tiene traccia del tempo di completamento della causa principale per i problemi con priorità critica e alta, ma le policy dell'organizzazione possono essere diverse. Il completamento del punto saliente non dimostra che l'analisi è corretta. Vedere Policy sui contratti di servizio.

Riduzione dell'impatto con una soluzione o un errore noto

Quando un metodo temporaneo sicuro riduce l'interruzione, documentarne l'applicabilità, i prerequisiti, le fasi, le limitazioni, i rischi e i risultati della verifica nelle informazioni per risolvere il problema. Rendere disponibili le indicazioni per gli addetti all'evasione degli incidenti in modo che possano ripristinare il servizio in modo coerente mentre la correzione permanente è in sospeso.

Creare o aggiornare un articolo Knowledge su un errore noto quando una causa principale confermata e una soluzione riutilizzabile devono essere disponibili oltre il record del problema. Rimuovere i dettagli specifici e sensibili dei record, instradare l'articolo attraverso il processo di revisione configurato e verificare che il pubblico di assistenza previsto possa trovarlo. Una soluzione controlla i sintomi o l'impatto, non elimina la causa sottostante.

Se non esiste una soluzione sicura, indicarla esplicitamente e rafforzare il monitoraggio, l'inoltro al livello superiore, la comunicazione e la preparazione al ripristino. Utilizzare un articolo Knowledge per rendere disponibile al pubblico di destinazione una soluzione temporanea verificata. Vedere Flussi chiave nei servizi IT.

Eliminazione della causa tramite un cambiamento controllato

Quando prove sufficienti supportano la causa principale e la risoluzione, creare e associare una richiesta di modifica dal problema. Includere l'ambito interessato, le prove causali, la correzione proposta, i requisiti di implementazione, il piano di test, l'approccio di ritiro, i vincoli di pianificazione e i criteri di verifica. Mantenere aperto il problema mentre la modifica procede attraverso la valutazione del rischio, l'approvazione, la pianificazione, l'implementazione e la verifica.

L'esito della modifica deve testare la richiesta di risarcimento. Verificare che la condizione mirata sia cambiata come previsto, che lo stato del servizio sia rimasto accettabile, che il ritiro non sia stato richiesto o abbia avuto esito positivo e che non siano comparsi effetti collaterali materiali. Una modifica implementata correttamente non è sufficiente se l'errore ricorrente continua.

Quando una soluzione permanente non è possibile, utilizzare Accetta rischio solo dopo che gli stakeholder appropriati hanno compreso l'impatto residuo, la probabilità, i controlli correnti, la proprietà e le condizioni di riesame. Registrare la giustificazione e le condizioni che attivano il monitoraggio o la riapertura. L'accettazione del rischio è una decisione disciplinata e non sostituisce un'analisi incompleta. Per le fasi di richiesta di modifica e accettazione del rischio, vedere Gestione dei problemi per i servizi IT.

Verifica riduzione e chiusura della ricorrenza

Osservare il servizio per un periodo e un volume appropriati allo schema di ricorrenza originale. Confrontare la frequenza degli incidenti pre- e post-rimedio, gli utenti o le transazioni interessati, le percentuali di errore, i tempi di inattività, l'utilizzo della soluzione, l'assistenza e gli esiti dei livelli di servizio. Tenere conto della stagionalità, del traffico, dei rilasci e delle modifiche ai rapporti prima di attribuire il miglioramento alla correzione.

Chiudere il problema solo quando il record contiene la causa principale supportata, le informazioni sulla risoluzione, gli incidenti e la riparazione associati, le prove di verifica, il rischio rimanente e Knowledge riutilizzabile. Risolvere le associazioni correlate in base al processo dell'organizzazione preservandone la cronologia. Riaprire il problema quando il problema si ripresenta, la spiegazione della causalità viene smentita o nuove prove modificano l'azione richiesta.

La gestione dei problemi ha esito positivo quando una risoluzione verificata o una decisione esplicita sul rischio determina una riduzione tracciabile della ricorrenza o dell'impatto. Chiudere un problema, pubblicare un articolo o completare una modifica da soli non indica che il problema ricorrente è stato eliminato.

Utilizzo dell'intelligenza artificiale come assistenza, non come prova

Quando è configurato, Einstein può creare bozze di un problema da un incidente e le azioni Agentforce possono riepilogare i problemi, controllare gli attributi, trovare i record correlati, proporre soluzioni e creare bozze di riepiloghi cause principali o risoluzioni. Esaminare i campi e le associazioni generati prima di salvarli o di intervenire su di essi.

I riepiloghi generati e le correzioni proposte non sono prove verificate della causa principale. Confermare ogni richiesta materiale relativa a registri, record, test, fonti Knowledge affidabili ed esperti in materia. Mantenere la distinzione tra una corrispondenza semantica, un'ipotesi plausibile e una causa dimostrata. Vedere Creazione automatica di problemi da incidenti con Einstein, Azioni AI per la gestione dei problemi e Azioni proattive per problemi IT.

Verifica che la gestione dei problemi sia pronta

Prima di distribuire questo processo in modo più ampio, verificare che Gestione dei problemi e le relative convalide dei campi, la matrice di priorità, i layout di record, le associazioni, i cruscotti digitali e gli SLA supportino il processo. Verificare inoltre che i componenti Knowledge, Change Management e Configuration Management Database (CMDB) richiesti siano configurati. Einstein, Agentforce e le azioni proattive sono funzionalità facoltative che richiedono impostazioni e autorizzazioni separate.

Assegnare il gruppo di insiemi di autorizzazioni Problem Manager o Problem Fulfiller appropriato. Assegnare anche le autorizzazioni necessarie per accettare i rischi, riaprire i problemi, associare incidenti, richieste di modifica e rilasci ai problemi e risolvere le associazioni. Vedere Impostazione della gestione dei problemi e degli insiemi di autorizzazioni.

Convalidare la configurazione prima di distribuirla in modo più ampio. Verificare che un utente autorizzato possa trovare record e cruscotti digitali dei problemi, ispezionare i campi di analisi e risoluzione e visualizzare gli incidenti correlati e altre associazioni. Verificare che la richiesta di modifica e le azioni di rischio appropriate siano disponibili per lo stato del record, insieme a qualsiasi assistenza Knowledge e AI configurata. Durante il test, uscire da qualsiasi flusso di creazione, modifica, questionario, generazione, approvazione o chiusura senza salvare le modifiche.