artigo disponível também no Medium e no LinkedIn
Visão prática e funcional
Introdução
Cada empresa pode ter a sua definição, mas um incidente costuma ser descrito como…
qualquer interrupção não planejada ou redução na qualidade de um serviço ou de um recurso de Tecnologia.
A ocorrência de um incidente requer dedicação de uma equipe na sua investigação e resolução, tarefa que exige conhecimento sobre os softwares, plataformas e tecnologias afetadas ou relacionadas com o evento adverso. Mas não basta que a pessoa seja especialista nos códigos e configurações técnicas, ela precisa atuar de acordo com um processo para gestão do incidente, algo que funciona como um guia para atuação, permitindo que a pessoa foque naquilo que é crítico: o restabelecimento do serviço. Além de direcionar a atuação, o processo também facilita a rastreabilidade, controle e comunicação dos incidentes, ou seja, um fluxo de gestão de incidente bem estabelecido colabora na redução do impacto negativo e fomenta a Governança de Tecnologia.
É por isso que (assim espero) na sua empresa há um procedimento que contempla as definições gerais de um incidente, além de apresentar as etapas do seu ciclo de vida; normalmente são diretrizes válidas para qualquer equipe de Tecnologia que for atuar em um incidente.
A partir das definições gerais, cada grupo detalha o seu modelo operacional para gestão de incidentes. Está é uma decisão importante, pois evita que um incidente fique eternamente aguardando atuação ou que duas pessoas trabalhem ao mesmo tempo e sem alinhamento. Também há situações onde um incidente requer atuação de outra equipe, por exemplo, o time de Operações de Tecnologia pode direcionar um determinado tipo de incidente para o time de Segurança da Informação. O escalonamento mapeado e alinhado entre as equipes é um fator crítico para o sucesso operacional do processo, ele aumenta a probabilidade da equipe cumprir os níveis de serviço e, consequentemente, potencializa a satisfação dos clientes.
Considerando que a gestão de incidentes é um dos processos mais importantes da gestão de serviços de Tecnologia, escrevi este artigo para ajudá-la a navegar neste fluxo com a plataforma ServiceNow. Ele é baseado na minha experiência e no Incident Management Process Guide, documento disponível no Now Create, conjunto de ativos e processos que aceleram a implementação e uso da plataforma ServiceNow.
Vamos lá? 😉
Como nasce um incidente?
O incidente pode nascer de diversas formas, alguns exemplos:
- Record producer disponível no Service Portal:
imagem acima é do record producer Create Incident, disponível no OOTB para todas as pessoas que acessam a plataforma. Imagino que aí na sua empresa existam vários itens de catálogo para registrar incidentes, talvez separados por sintomas ou específicos para áreas de negócio. O importante é ter um canal que simplifique o registro do incidente, o Service Portal associado com um record producer bem desenhado cumprem muito bem esse papel.
- A pessoa do Service Desk (ou de outro time de Tecnologia) faz o registro a partir do Now Platform UI ou do Agent Workspace:
Formulário para registro de incidentes na UI16.
Formulário para registro de incidentes no Agent Workspace.
- Uma solução externa (por exemplo: Nagios, Zabbix, AppDynamics, Dynatrace etc.) registra o incidente através de uma integração com o ServiceNow.
Por que o incidente precisa ser registrado da forma correta?
- O direcionamento para as pessoas responsáveis pela solução é facilitado (ou feito de forma automática);
- O tempo entre o registro do incidente e a sua solução é reduzido, pois não é necessário solicitar informações adicionais;
- Aumento do First Call Resolution.
Você, que trabalha com gestão de incidentes no dia a dia, com certeza listaria diversos outros benefícios de nos preocuparmos com a qualidade da informação já no momento do registro. Este desafio é maior quando o incidente é informado por telefone, pois nem sempre a pessoa saberá descrever detalhes do sintoma, mas isso é possível quando o desenho da integração com o sistema externo ou o record producer são feitos da forma correta, aproveitando os recursos da plataforma e as recomendações do Incident Management Process Guide:
- Prefira usar os campos Service, Service offering e Configuration item para categorizar o incidente, a recomendação do Incident Management Process Guide (página 13) é que os campos Category e Subcategory sejam usados quando o CMDB não está populado ou sem informações confiáveis.
- Preencha o atributo Support group dos Configuration items e dos Services. É uma informação que sempre esteve no CMDB, mas na versão Quebec ficou mais relevante, pois agora a atribuição do incidente para o grupo pode ser feita automaticamente, a partir do Support group. Uma forma de aproveitar a nova funcionalidade é definir quais grupos atuam em determinadas classes e serviços, por exemplo, você pode direcionar os incidentes com itens de configuração da classe Computer para o time Field Services e os incidentes com o serviço SAP Payroll Control Center para o time de suporte dedicado ao SAP.
Como identificar um incidente que está aguardando atuação do meu time?
Se o seu time possui uma fila para atuar nos incidentes, crie a rotina de acessar algumas vezes por dia a lista dos incidentes aguardando atuação, disponível no filtro My Groups Work:
![My Groups Work: Exibe todos os tickets (incidentes, tarefas, mudanças etc.) atribuídos para o meu grupo, onde não há uma pessoa atuando (campo Assigned to [Atribuído a] vazio).](https://media-exp1.licdn.com/dms/image/C4D12AQFUTRLWqHmDmA/article-inline_image-shrink_1500_2232/0/1613941010884?e=1619654400&v=beta&t=y_UkwQpIhjzfcpiEIwraLsD0cge8hUzHWwPldn190ng)
My Groups Work: Exibe todos os tickets (incidentes, tarefas, mudanças etc.) atribuídos para o meu grupo, onde não há uma pessoa atuando (campo Assigned to [Atribuído a] vazio).
Além disso, a plataforma enviará um e-mail sempre que alguma tarefa (incidente, mudança, requisição ou problema) for atribuída para o seu grupo:
Exemplo de notificação enviada por e-mail. Neste caso, informa que um incidente foi atribuído para o grupo Network.
Como iniciar a atuação no incidente?
Mesmo que um incidente tenha sido direcionado para você a partir de outro grupo solucionador, é fundamental iniciar a atuação com uma revisão das informações. Sugiro um checklist que contempla os tópicos que considero mais importantes:
- Preencha o campo Assigned to [Atribuído a]. Neste momento, talvez seja a tarefa mais importante 😉. Quando você “assume” o incidente, ele deixa de ser exibido no filtro My Groups Work, evitando que outra pessoa da sua equipe comece a atuar no incidente ao mesmo tempo que você.
- A Short description [Descrição resumida] faz sentido? Na pressa para registrar o incidente, a descrição informada talvez faça sentido somente para mim. Verifique se a mensagem é sucinta e objetiva, permitindo que outras pessoas do seu time tenham uma noção do contexto, sem precisar acessar os detalhes.
- A prioridade está correta? Se o meu laptop parou, é urgente! Faz sentido, mas a priorização do incidente precisa contemplar o impacto e a urgência para a empresa e, principalmente, para os clientes. A plataforma ServiceNow traz uma matriz padrão para priorizar os incidentes, mas é importante avaliar se ela faz sentido para a sua empresa, além de revisitar os conceitos de impacto, urgência e prioridade (aqui eu sugiro observar as definições do ITIL 😉).
- O Service [Serviço] e, principalmente, o Configuration Item [Item de Configuração] estão corretos? Classificar corretamente o Item de Configuração e o Serviço permite avaliarmos a qualidade dos serviços e dos recursos de tecnologia, além de influenciar no direcionamento correto dos esforços para manutenção e evolução dos sistemas e infraestrutura de Tecnologia. Aqui estamos falando sobre a base do Application Portfolio Management, convido você a fazer uma pesquisa sobre o assunto. 🙂
- É possível complementar a descrição (campo Description)? Se você conseguir mais detalhes sobre o sintoma relatado (mensagem de erro, passos para reprodução do sintoma etc.), inclua essas informações no campo Description [Descrição].
Após o registro, o incidente fica no estado New [Novo], aguardando que um membro do grupo solucionador assuma e comece a atuar. Quando o campo Assigned to [Atribuído a] é preenchido, o incidente entra automaticamente no estado In Progress [Ativo]. Talvez você esteja pensando…
Poxa… Não deveria ser assim! Eu defino quando o incidente passará para In Progress.
Pois é… Mas a dinâmica de uma operação e, principalmente, do processo de gestão de incidentes consideram que o incidente precisa ter um direcionamento. Por isso, é importante que o analista só assuma aqueles incidentes em que irá atuar, isso evita a falsa percepção de que alguém está resolvendo o incidente, quando a realidade é que a pessoa só incluiu mais uma tarefa na sua lista de 127 coisas para fazer.
Ou seja, não é um problema ter somente dois ou três incidentes na sua lista de atuação, assim como não é um problema você remover um incidente da sua atribuição, devido o surgimento de outras prioridades (um incidente Prioridade 2, por exemplo). O que não pode acontecer é deixar de documentar o histórico, independentemente de você ter feito uma passagem de turno ou conversado pessoalmente com o analista que passou a atuar no incidente. Lembre-se…
Um incidente bem documentado facilita a sua vida e a vida das pessoas que trabalham com você.
Como documentar a atuação no incidente?
Logo após as informações do incidente (que você acabou de atualizar) há três abas no formulário: Notes [Anotações], Related Records [Registros Relacionados] e Resolution Information [Informações de Resolução].
O Notes exibe o Work notes [Anotações de trabalho] e o Additional comments [Comentários adicionais], no primeiro você registra informações que devem ficar disponíveis somente para os times técnicos, enquanto no segundo você registra informações para a pessoa que registrou o incidente, ou seja, é um ótimo recurso para garantir visibilidade sobre a atuação. Embora a pessoa consiga visualizar o estado do incidente, não devemos nos contentar com isso, use sempre o Additional comments. 🙂
Estrutura do Notes: As opções Watch list e Work notes list permitem que você inclua outras pessoas para acompanhar a evolução do incidente. Clique em Show one journal field para exibir o Work notes e o Additional comments.
Quer tentar garantir que as outras partes interessadas leiam o seu comentário? Mencione as pessoas com o @, todos receberão um e-mail avisando sobre a menção:
![Digite a sua mensagem e clique no botão Post [Publicação].](https://media-exp1.licdn.com/dms/image/C4D12AQE_i4rhHwPSJA/article-inline_image-shrink_1000_1488/0/1613941191660?e=1619654400&v=beta&t=m3-1xBPkheqzZle3kSTA0ofSk8Y7iLTKWOkoRWjnUdg)
Digite a sua mensagem e clique no botão Post [Publicação].
Exemplo de mensagem que a pessoa mencionada irá receber:
Veja que a notificação da minha instância segue o padrão da plataforma (incluindo o logotipo antigo da ServiceNow), você ou a pessoa que administra a plataforma na sua empresa pode editá-la (algo que eu recomendo), basta localizar a notificação Activity Stream @Mention Email na tabela Notifications (sysevent_email_action).
Já que citamos o Related Records [Registros Relacionados] no início do tópico, vamos falar um pouco mais sobre ele… 😉
Vinculando o incidente com outros registros
Na aba Related Records [Registros Relacionados] você acessa os principais registros vinculados ao incidente:
Aba Related Records, disponível no registro do incidente.
- Problem [Problema]: Caso o incidente seja recorrente ou não tenha uma solução definitiva dentro do SLA, pode ser necessário registrar um problema para uma investigação mais detalhada. Além da vantagem da rastreabilidade, o vínculo permite que a resolução do problema resulte no fechamento automático dos incidentes relacionados a ele (caso o status do incidente seja On hold [Em espera] | Awaiting problem [Aguardando problema]).
- Change Request [Requisição de Mudança]: A solução do incidente pode depender da execução de alguma mudança no ambiente de Tecnologia, sendo necessário registrar a mudança (provavelmente, do tipo Emergencial).
- Parent Incident [Incidente Primário]: Se uma mesma causa gerou diversos registros de incidente (por exemplo: indisponibilidade de um sistema usado por várias pessoas), é possível fazer o vínculo entre eles. Esta é outra funcionalidade que a vantagem vai além da rastreabilidade, quando você vincula o incidente pai com os filhos, basta resolver o incidente principal para que os demais também sejam resolvidos. Daqui a pouco explico como você vincula diversos incidentes ao mesmo tempo. 😉
- Caused by Change [Causado pela Mudança]: A implementação de uma mudança gerou indisponibilidade ou lentidão em algum recurso de tecnologia. Quem nunca presenciou algo assim? 🙄 Se acontecer com você, não esqueça de vincular o incidente à mudança que o causou.
Vá até o final do formulário e veja que há outras opções para enriquecer as informações do seu incidente:
- Tasks SLAs [SLAs de Tarefas]: Dependendo da prioridade do incidente, um tipo de SLA (Acordo de Nível de Serviço) será disparado. Na configuração padrão da plataforma, os incidentes com prioridade 1 a 4 têm um SLA de resposta (tempo para que alguém comece a atuar) e resolução, incidentes com prioridade 5 têm somente o SLA de resposta. Obviamente, a prioridade mais baixa tem o acordo de nível de serviço mais agressivo: O famoso P1 (incidente com prioridade 1) tem como meta 15 minutos para alguém começar a atuar e 1 hora para a resolução do incidente.
- Affected CIs [ICs Impactados]: No formulário do incidente você informa o principal Service e Configuration Item vinculado com o incidente (se possível, aquele que causou o incidente). Considerando que outros itens de configuração podem ser afetados pela indisponibilidade ou degradação do serviço, use esta opção para fazer o vínculo.
- Impacted Services/CIs [Serviços/CIs Impactados]: A explicação anterior vale também para o Impacted Services/CIs.
- Service Offerings [Ofertas de Serviços]: Este registro relacionado será exibido somente se algum Service offering tiver sido informado no formulário do incidente. O uso correto desta informação depende de uma boa modelagem do CMDB, por isso recomendo novamente que você conheça e estude o CSDM, mesmo que a implementação do ServiceNow aí na sua empresa seja antiga, é importante considerar os conceitos do Commom Service Data Model para aproveitar todo o potencial da plataforma.
- Child Incidents [Incidentes Secundários]: Lembra aquele papo dos diversos incidentes com a mesma causa? Pois é, aqui você consegue relacionar todos. Basta clicar no botão Edit [Editar], selecionar os incidentes (use e abuse dos filtros para localizar os incidentes) e clicar no botão Save [Salvar]. Pronto! O seu incidente estará vinculado com os demais através do Parent Incident [Incidente Primário]:
Incidentes relacionados com o Incidente Primário. Quando o Parent Incident for resolvido, os Child Incidents também serão resolvidos (com o mesmo Resolution code e Resolution notes).
Estados de um incidente
Você já sabe que, após o registro, o incidente fica no estado New [Novo]. Ele continuará neste estado até que um membro do Assignment group [Grupo designado] assuma a atuação, incluindo o seu nome no Assigned to [Atribuído a]. Neste momento, o estado será alterado automaticamente para In Progress [Ativo]. Vamos descrever os demais estados de um incidente (e quando devem ser usados):
- Resolved [Resolvido]: Quando a solução foi aplicada e, na visão do grupo solucionador, o incidente foi resolvido.
- Canceled [Cancelado]: Usado quando o incidente foi registrado erroneamente. O ideal é que o cancelamento seja realizado pela pessoa que registrou o incidente, mas pode ser necessário que o grupo solucionador — após alinhamento com a pessoa solicitante — realize o cancelamento.
- On Hold [Em espera]: Há situações em que o incidente fica “travado”, aguardando uma ação da pessoa solicitante, de um fornecedor, a execução de uma mudança ou uma investigação detalhada, através do processo de gestão de problemas.
Vale falar um pouco mais sobre os estados On Hold e Resolved, pois são os que geram mais dúvidas.
On Hold: Aguardando uma ação externa
Se for necessário colocar o incidente no estado On Hold [Em espera], é necessário escolher um dos sub-estados disponíveis:
- Awaiting Caller [Aguardando Solicitante]: Este subestado pausa o SLA do incidente, por isso, use com cuidado. Mencione o solicitante no Additional comments, deixando claro o que é necessário para que você possa dar andamento na atuação.
- Awaiting Change [Aguardando Mudança]: No mundo real dos incidentes, pode ser necessário executar uma mudança antes mesmo de registrá-la, mas também há situações em que o SLA permite a execução dentro das janelas de execução. Neste caso, use o Awaiting change [Aguardando mudança] e relacione o incidente com o registro da mudança que irá resolvê-lo.
- Awaiting Problem [Aguardando problema]: Pode ser que o incidente requeira uma investigação mais aprofundada e multidisciplinar, algo que não cabe no processo de incidentes, neste caso, ele pode ser vinculado a um registro de problema e permanecer no estado Awaiting problem [Aguardando problema]. Lembro que a grande vantagem de usar este subestado é que o incidente será resolvido automaticamente quando o problema vinculado a ele for encerrado (é claro que isso depende do vínculo ter sido feito) 😉.
- Awaiting Vendor [Aguardando Fornecedor]: Se você estiver aguardando uma ação ou resposta do fornecedor, use o subestado Awaiting vendor [Aguardando fornecedor], mas não se esqueça de incluir um Work notes [Anotações de trabalho] e um Additional comments [Comentários adicionais], assim todas as partes interessadas saberão o motivo de estar aguardando o fornecedor.
![Sub-estados do estado On Hold [Em espera].](https://media-exp1.licdn.com/dms/image/C4D12AQElBNT_aOKzlw/article-inline_image-shrink_1000_1488/0/1613941374351?e=1619654400&v=beta&t=-JcdGwiQP-uLCYFDDQLvG0tNESp-pY3xTvbr5fVw7aQ)
Sub-estados do estado On Hold [Em espera].
Resolvendo o incidente
É só clicar no botão Resolve [Resolver]. 🙂
Caso você tenha clicado no botão Resolve só para testar, viu o seguinte alerta:
Alerta de informações necessárias para que o incidente seja resolvido.
Pois é… Não dá para encerrar um incidente sem informar o Resolution code [Código de fechamento] e o Resolution notes [Anotações de resolução]. Navegando pelo formulário do incidente, talvez você tenha visto a aba Resolution information [Informações de resolução], é só clicar nela:
Aba Resolution Information, com os campos Resolution code e Resolution notes, obrigatórios para o encerramento do incidente.
- Resolution code [Código de fechamento]: O OOTB traz sete códigos de fechamento…
Solved (Permanently) [Solucionado (Permanentemente)] — A ideia é que este seja o código de fechamento de quase todos os incidentes. Caso a solução tenha sido aplicada remotamente, é possível usar o código Solved Remotely (Permanently).
Solved (Work Around) [Solucionado (Contorno)] — Use esta opção para aquele incidente que foi resolvido através de uma solução de contorno. Considere registrar um problema para investigar a solução definitiva (uma solução de contorno pode não ser sustentável). Caso a solução de contorno tenha sido aplicada remotamente, é possível usar o código Solved Remotely (Work Around).
Not Solved (Not Reproducible) [Não Solucionado (Não Reproduzível)] — Há situações em que não é possível reproduzir o sintoma.
Not Solved (Too Costly) [Não Solucionado (Muito Caro)] — Após a investigação e análise, podemos concluir que o custo da solução é muito maior do que os custos gerados pelos sintomas do incidente.
Closed/Resolved by Caller [Encerrado/Solucionado pelo Solicitante] — Usado pela plataforma, quando o solicitante encerra o incidente (ao perceber que foi registrado incorretamente, por exemplo).
- Resolution notes [Anotações de resolução]: Olhe com carinho para as anotações de resolução, esta é uma informação útil para compreendermos o que foi feito para resolver o incidente. Se você concluir que as suas anotações de resolução podem servir para outras pessoas da sua equipe (ou de outras), marque a opção Knowledge [Base de Conhecimento], assim um artigo será sugerido para a base de conhecimento (após o incidente ser fechado).
Após a resolução, o incidente será fechado após 7 dias, permitindo que a pessoa que fez o registro faça a reabertura durante este período, caso não concorde com a solução:
Recapitulando (e ajudando quem veio direto para o final do texto =))
- Antes de iniciar a atuação no incidente, “assuma” o ticket, deixando o seu nome no campo Assigned to [Atribuído a];
- Revise as informações do incidente. Corrija o que for necessário. Complete o que estiver faltando;
- Dê visibilidade para o solicitante através dos estados do incidente e também pelo Additional comments [Comentários adicionais];
- Só assuma (Assigned to [Atribuído a]) os incidentes em que realmente estiver atuando;
- Faça os vínculos com outros registros (mudança, problema, incidente primário ou incidente secundário).
Conclusão
Escrevi este artigo assumindo o risco de você chegar até aqui e pensar…
Caramba, o que esse cara escreveu tem nada a ver com o que fazemos aqui na empresa.
Bom, começo agradecendo por você ter lido o artigo. 🤍 Durante o texto, tentei destacar funcionalidades e conceitos que enxergo como válidos para qualquer implementação de ServiceNow, por isso, te convido a refletir sobre as oportunidades de evolução no processo de gestão de incidentes aí na sua empresa.
Caso você não seja a pessoa responsável pelas definições e melhorias do processo, considere propor um fórum de diálogo com as pessoas. Se você for a responsável, a sugestão do fórum de diálogo permanece, pois promover a colaboração aumenta as chances de sucesso na evolução do processo. 😉 Recomendo que comecem avaliando os seguintes materiais:
- Incident Management Process Guide: Apresenta a visão processual do funcionamento da plataforma nas configurações padrão (o famoso out of the box). Dominar as informações deste documento permite termos ciência de funcionalidades que não estão sendo usadas ou que estão sendo usadas da forma errada.
- Incident Management — Process Workshop: Material normalmente usado na implementação da plataforma, para apresentar as funcionalidades da aplicação, o conteúdo do Process Workshop permanece relevante mesmo depois do go live cake, pois é uma maneira de termos acesso aos detalhes funcionais de gestão de incidentes, permitindo descobrirmos algum recurso que seja útil após o lançamento de uma nova versão.
- Incident Management — Business Outcomes and Corresponding KPIs: “If you don’t know where you are going, any road will get you there.”. Este material começa com a frase do Lewis Carroll para explicar a importância de definir os resultados esperados de um processo. A apresentação traz sugestões de objetivos e KPIs para três pilares: Run the Business, Protect the Business e Grow the Business. Mesmo que vocês tenham indicadores definidos, o Business Outcomes and Corresponding KPIs pode trazer novas ideias e provocações.
Desejo sucesso na gestão dos seus incidentes!
Obrigado e um abraço! 😉
