O Gerenciador de problemas identifica a causa raiz e elimina problemas recorrentes

Usar caso em uma visão geral

Persona: Um gerente de problemas responsável por identificar causas sistêmicas, coordenar a investigação e prevenir interrupções de serviço recorrentes

Trabalho a ser feito: Conecte incidentes recorrentes a um único registro de problema, estabeleça e documente a causa-raiz e promova uma correção permanente ou uma decisão explícita sobre o risco

Ponto de partida: Histórico de incidentes, dados de serviço ou tendências operacionais indicam que a interrupção mesma ou relacionada está recorrendo

Resultado bem-sucedido: O problema tem uma análise de causa-raiz com suporte, os incidentes relacionados e os registros de remediação são rastreáveis, os usuários afetados aprovaram a orientação e a evidência pós-alteração mostra que a recorrência ou o impacto diminuíram.

Use esse cenário para determinar se um problema recorrente é compreendido e controlado. Use os tópicos de Ajuda relacionados para etapas para criar e associar registros, atualizar a análise de problema, documentar uma solução alternativa, criar uma solicitação de alteração, aceitar o risco, reabrir um problema e fechá-lo.

Detectar um padrão que vale a pena investigar

Comece com a evidência de uma condição subjacente compartilhada, em vez de apenas o número de incidentes. Compare sintomas, assinaturas de erro, serviços e itens de configuração (CIs) afetados, tempo, alterações recentes, populações de usuários, resoluções e recorrência após a restauração do serviço. Frase semelhante pode descrever causas diferentes, enquanto incidentes com texto diferente podem se originar da mesma falha.

Use painéis de problema para localizar tendências, trabalho aberto, violações do acordo de nível de serviço (SLA), registros não atribuídos, tempo de resolução e padrões de código de resolução. Trate as informações do painel como um lead de investigação, em vez de provar que os incidentes compartilham uma causa. Para obter detalhes sobre as métricas do painel, consulte Painel do gerenciador de problemas para serviços de TI.

Estabelecer o problema sem atrasar a recuperação

O Gerenciamento de incidente restaura o serviço para cada interrupção ativa. O Gerenciamento de problemas investiga e remove a causa sistêmica. Mantenha esses resultados separados: um incidente pode ser resolvido por meio de uma solução alternativa enquanto seu problema relacionado permanece aberto e um problema não deve ser fechado apenas porque o incidente mais recente parou de afetar os usuários.

Crie ou selecione um problema que descreva a condição recorrente no escopo adequado. Confirme seu assunto, descrição, categoria, subcategoria, serviços e CIs afetados, impacto, urgência, prioridade, proprietário e status da investigação. Associe os incidentes de suporte e outros problemas relevantes, solicitações de alteração, versões ou artigos do Knowledge para que os investigadores possam distinguir evidências de coincidências.

Evite criar um problema para cada incidente ou um problema geral para falhas não relacionadas. Use associações como Causado por e Semelhante apenas quando a evidência disponível apoiar o relacionamento.

Se a ação proativa Associar problemas semelhantes estiver habilitada, ela poderá associar automaticamente registros de problema com base na similaridade semântica. Uma associação semelhante não estabelece um relacionamento causado por. Revise automaticamente os problemas associados antes de usá-los como evidência de uma causa-raiz compartilhada.

Para associar registros manualmente, abra o problema. Na guia Associações, clique em Asocie e selecione um tipo de registro e um tipo de relacionamento, como Causado por ou semelhante. Remover uma associação não exclui o registro associado. A opção Resolver é separada da vinculação e pode fechar vários registros relacionados, portanto, revise os registros selecionados antes de clicar em Resolver.

Para etapas para criar e associar problemas, resolver problemas, aceitar riscos e reabrir problemas, consulte Gerenciar problemas para serviços de TI. Para criar um problema diretamente de um incidente, consulte Gerenciar incidentes para serviços de TI.

Investigar e estabelecer a causa raiz

Crie uma explicação testável com base em cronogramas de incidentes, registros, telemetria, dados de configuração e ativos, alterações recentes, erros conhecidos, artigos do Knowledge e conhecimento sobre o assunto. Reproduza a falha com segurança quando possível. Compare condições afetadas e não afetadas, desafie explicações concorrentes e registre quais evidências confirmam ou rejeitam cada hipótese.

Documente a cadeia danificada em vez de repetir o sintoma. Explique a condição com falha, por que ela produziu o impacto observado, o escopo afetado e as condições sob as quais o problema pode recorrer. Cite os registros ou testes que dão suporte à conclusão. Marque pressuposições não resolvidas e atribua trabalho de acompanhamento em vez de apresentar inferência como fato.

Acompanhe o marco de causa-raiz configurado sem comprometer a qualidade da investigação. O SLA Problema padrão rastreia o tempo de conclusão da causa raiz para problemas críticos e de alta prioridade, mas as políticas da sua organização podem ser diferentes. Concluir o marco não prova que a análise está correta. Consulte Política de SLA para Problema para serviços de TI.

Reduzir o impacto com uma solução alternativa ou erro conhecido

Quando um método temporário seguro reduz interrupções, documente sua aplicabilidade, pré-requisitos, etapas, limitações, riscos e resultados de verificação nas informações de solução alternativa do problema. Disponibilize a orientação aos processadores de incidentes para que eles possam restaurar o serviço de modo consistente enquanto a correção permanente está pendente.

Crie ou atualize um artigo do Knowledge sobre um erro conhecido quando uma causa-raiz confirmada e uma solução alternativa reutilizável precisarem estar disponíveis além do registro do problema. Remova detalhes confidenciais e específicos do registro, encaminhe o artigo pelo processo de revisão configurado e verifique se o público de suporte pretendido pode encontrá-lo. Uma solução alternativa controla sintomas ou impacto; ela não elimina a causa subjacente.

Se não existir uma solução alternativa segura, informe explicitamente e reforce o monitoramento, a escalação, a comunicação e a preparação para recuperação. Use um artigo do Knowledge para disponibilizar uma solução alternativa temporária verificada ao público-alvo. Consulte Fluxos de trabalho chave em serviços de TI.

Eliminar a causa por meio da alteração controlada

Depois que evidências suficientes dão suporte à causa raiz e à correção, crie e associe uma solicitação de alteração do problema. Inclua o escopo afetado, a evidência causal, a correção proposta, os requisitos de implementação, o plano de teste, a abordagem de reversão, as restrições de agenda e os critérios de verificação. Mantenha o problema aberto enquanto a alteração avança pela avaliação de risco, aprovação, agendamento, implementação e verificação.

O resultado da alteração deve testar a declaração danificada. Confirme se a condição desejada mudou conforme o desejado, a integridade do serviço permaneceu aceitável, o reversão não foi necessário ou foi bem-sucedido e nenhum efeito secundário material apareceu. Uma alteração implementada com sucesso não será suficiente se a falha recorrente continuar.

Quando uma solução permanente não for viável, use Aceitar risco apenas depois que as partes interessadas apropriadas entenderem o impacto residual, a probabilidade, os controles atuais, a propriedade e as condições de revisão. Registre a justificativa e as condições que acionam o monitoramento ou a reabertura. A aceitação de risco é uma decisão regulada, não um substituto para uma análise incompleta. Para ver as etapas de solicitação de alteração e aceitação de risco, consulte Gerenciar problemas para serviços de TI.

Verificar redução de recorrência e fechar

Observe o serviço por um período e um volume adequados ao padrão de recorrência original. Compare a frequência de incidentes pré e pós-remediação, usuários ou transações afetados, taxas de erro, tempo de inatividade, uso de soluções alternativas, esforço de suporte e resultados de nível de serviço. Considere a sazonalidade, o tráfego, as versões e as alterações de relatório antes de atribuir melhoria à correção.

Feche o problema apenas quando o registro contiver a causa-raiz suportada, informações de resolução, incidentes associados e remediação, evidências de verificação, risco restante e Knowledge reutilizável. Resolva associações relacionadas de acordo com o processo da sua organização enquanto preserva seu histórico. Reabra o problema quando o problema recorrer, a explicação causal for negada ou novas evidências alterarem a ação necessária.

O gerenciamento de problemas é bem-sucedido quando uma solução verificada ou uma decisão explícita de risco resulta em uma redução rastreável na recorrência ou impacto. Fechar um problema, publicar um artigo ou concluir uma alteração apenas não mostra que o problema recorrente foi eliminado.

Usar IA como assistência, não evidência

Quando configurado, o Einstein pode criar um rascunho de um problema a partir de um incidente e as ações do Agentforce podem resumir problemas, verificar atributos, localizar registros relacionados, propor resoluções e criar resumos de causa raiz ou resolução. Revise os campos e as associações gerados antes de salvar ou agir com base neles.

Resumos gerados e correções propostas não são evidências de causa-raiz verificadas. Confirme cada reivindicação material contra registros, registros, testes, fontes de Knowledge confiáveis e especialistas em assunto. Preserve a distinção entre uma correspondência semântica, uma hipótese plausível e uma causa demonstrada. Consulte Criar problemas automaticamente a partir de incidentes com o Einstein, Ações de IA para gerenciamento de problemas e Ações proativas para problemas de TI.

Confirme se o gerenciamento de problemas está pronto

Antes de implementar esse processo mais amplamente, confirme que o Gerenciamento de problemas e suas validações de campo, matriz de prioridade, layouts de registro, associações, painéis e SLAs dão suporte ao seu processo. Confirme também se os componentes Knowledge, Change Management e database de gerenciamento de configuração (CMDB) necessários estão configurados. Einstein, Agentforce e ações proativas são recursos opcionais que exigem configuração e permissões separadas.

Atribua o grupo de conjuntos de permissões adequado Gerenciador de problemas ou Problem Fulfiller. Atribua também as permissões necessárias para aceitar risco, reabrir problemas, associar incidentes, solicitar alterações e liberar problemas e resolver associações. Consulte Configurar gerenciamento de problemas para serviços de TI e Conjuntos de permissões de gerenciamento de problemas para serviços de TI.

Valide a configuração antes de implantá-la mais amplamente. Confirme se um usuário autorizado pode localizar registros e painéis de problemas, inspecionar campos de análise e resolução e visualizar incidentes relacionados e outras associações. Confirme se a solicitação de alteração apropriada e as ações de risco estão disponíveis para o estado do registro, junto com qualquer assistência do Knowledge e da IA configurada. Ao testar, saia de qualquer fluxo de criação, edição, questionário, geração, aprovação ou fechamento sem salvar alterações.