Você está aqui:
O gerente de incidentes coordena um incidente importante
Ajude um gerente de incidente a reconhecer uma interrupção crítica e entregar um candidato qualificado para uma resposta coordenada a incidentes principais e restauração de serviço.
Usar caso em uma visão geral
Persona: Um gerente de incidentes trabalhando com um gerente de incidentes principal e equipes de resolução
Trabalho a ser feito: Escalar um incidente crítico para os negócios, estabelecer um contexto operacional compartilhado, coordenar o trabalho de resolução e manter as partes interessadas informadas
Ponto de partida: Um incidente de alto impacto no Service Desk de TI do agente que requer mais atenção e coordenação
Resultado bem-sucedido: O incidente é classificado adequadamente, as equipes de resolução restauram e verificam o serviço, as partes interessadas recebem atualizações claras e o trabalho de acompanhamento passa para o Gerenciamento de problemas.
Esse caso de uso segue um incidente crítico da escalação até a recuperação. Ele não substitui os procedimentos canônicos para propor, revisar, promover ou fechar incidentes importantes. Em vez disso, ele mostra como um gerente de incidente e um gerente de incidente principal usam um registro para tomar decisões, alinhar os respondentes e preservar uma linha do tempo responsável.
Os cumpridores podem propor um incidente como um incidente importante para revisão. Usuários com maior autoridade de incidente principal podem promover um incidente diretamente do registro de incidente sem aprovação. A remoção de um incidente importante requer a permissão Gerente de incidente principal. Mantenha a proposta e os caminhos de promoção direta distintos. Consulte Gerenciamento de incidentes importantes para serviços de TI, Revisar incidentes importantes para serviços de TI e Demonstrar incidentes importantes para serviços de TI.
Qualificar a interrupção
Comece com o impacto comercial, em vez de apenas a prioridade do incidente. Um incidente importante afeta vários usuários ou requer uma resposta imediata porque vários sistemas comerciais estão indisponíveis. Confirme os serviços e usuários afetados, a urgência operacional, as dependências conhecidas e as evidências de incidentes relacionados antes de escalar.
| Sinal | Questião de coordenação | Decisão |
|---|---|---|
| Escopo | Vários usuários, equipes, locais ou serviços são afetados? | Continue o tratamento padrão ou comece a qualificação de incidente principal. |
| Impacto nos negócios | Uma operação de negócios crítica está indisponível ou está gravemente degradada? | Documente o impacto e engaje o gerente responsável. |
| Urgência | A restauração atrasada aumenta o risco operacional, financeiro ou de conformidade? | Acelere a resposta e estabeleça um ritmo de atualização. |
| Incidentes relacionados | Relatórios semelhantes indicam uma interrupção compartilhada? | Associe registros relevantes e consolide o contexto da investigação. |
| Complexidade da recuperação | A restauração requer vários grupos de resolvedor ou uma alteração controlada? | Estabeleça a propriedade coordenada e o caminho de recuperação adequado. |
Use o caminho da proposta quando a interrupção precisar de revisão. Usuários com maior autoridade de incidente principal podem usar o caminho de promoção direta quando essa autoridade estiver configurada. Para qualificação e escopo do processo, consulte Gerenciamento de incidente principal para serviços de TI.
Estabelecer o registro de incidente principal
Registre uma justificativa concisa que explique o impacto, a urgência e o motivo para uma coordenação mais ampla. Uma proposta é revisada, em que um usuário com a autoridade necessária a aprova ou rejeita. A Promoção direta ignora o processo de revisão. Demote retorna um incidente principal para o tratamento de incidente padrão.
Mantenha o ciclo de vida da classificação de incidente principal separado do Status do incidente operacional. Proposta, aprovação ou rejeição, promoção direta e rebaixamento são ações de classificação. Valores de Status operacional, como Novo, Em andamento, Resolvido e Fechado, descrevem o progresso do incidente em relação à restauração e à conclusão. Use os rótulos de estado de ciclo de vida exatos documentados em Ciclo de vida de incidente maior para serviços de TI.
Use Comentários de status de incidente principal para registrar o motivo ao remover um incidente importante. Registre as atualizações da investigação sobre o incidente usando seu feed, listas relacionadas e status operacional. Para o comportamento de estado e campo canônicos, consulte Ciclo de vida de incidente importante para serviços de TI. Para o caminho de revisão e a criação opcional de problemas, consulte Revisar incidentes importantes para serviços de TI.
Coordenar restauração e comunicação
Após a classificação, use o registro de incidente como a origem operacional compartilhada. Identifique um proprietário para cada ação de recuperação, traga os grupos de resolver necessários, acompanhe decisões e dependências e verifique se os incidentes associados representam a mesma interrupção.
Para trabalho complexo, inicie um mutirão configurado para que os especialistas colaborem em um canal. Mantenha decisões materiais e evidência de resolução no registro do incidente em vez de deixar o histórico de diagnóstico apenas no chat. O Agentforce pode resumir um mutirão do Slack e publicar o resumo no feed de registro. Consulte Mutirão em incidentes no Slack para serviços de TI para obter as opções de colaboração canônica.
Envie atualizações da parte interessada em alterações relevantes, como confirmação, escopo confirmado, progresso da recuperação, restauração e fechamento. Separe fatos confirmados de hipóteses de trabalho, informe a próxima atualização esperada e evite prometer um tempo de recuperação sem evidência. As notificações configuradas podem fornecer atualizações por email, canais no aplicativo, Slack ou Microsoft Teams. Consulte Notificações para serviços de TI.
Restaurar, fechar e fazer a transição
Confirme se o serviço foi restaurado para os usuários e sistemas afetados antes de alterar o incidente para Resolvido. Registre a ação de restauração, as provas de verificação, o risco restante e qualquer solução alternativa temporária no Resumo da resolução. Mova o incidente para Fechado quando o ciclo de vida estiver concluído sob o processo da equipe.
A classificação de incidente principal não substitui a investigação de acompanhamento. Faça a transição do evento para o Gerenciamento de problemas para análise de causa raiz e trabalho preventivo. A criação automática de problema ocorre apenas quando a configuração de incidente principal correspondente está ativada; caso contrário, crie ou associe o Problema necessário por meio do processo da equipe.
O marco de adoção ocorre quando a equipe passa de uma resposta fragmentada para um registro coordenado: classificação qualificada, trabalho de recuperação responsável, comunicações consistentes, restauração verificada e um proprietário de acompanhamento explícito. Para resolver incidentes canônicos e comportamentos de associação, consulte Gerenciar incidentes para serviços de TI.
Confirme se o Gerenciamento de incidente principal está pronto
Antes de usar essa jornada como um teste de adoção, confirme se o Gerenciamento de incidente está habilitado, o grupo de aprovação está configurado e os usuários têm as permissões necessárias para suas tarefas atribuídas. Verifique se os processadores podem propor incidentes para revisão, se os usuários autorizados podem revisá-los ou promovê-los diretamente e se os usuários que rebaixam incidentes importantes têm a permissão Gerente de incidente principal. Consulte Configurações para incidentes importantes para serviços de TI para configuração canônica.
