Como se sair bem no processo de gerenciamento de incidentes como um profissional de operações de TI

Identificar e registrar um incidente

Um incidente pode vir de qualquer lugar. Um funcionário pode chamar você para fazer relato, ou o incidente pode cair do teto no seu colo, no caso de um hub de rede mal posicionado e um teto fraco. (Não que eu esteja falando por experiência própria...)

Não importa a origem, as primeiras duas etapas são simples: alguém identifica um incidente e, depois, alguém o registra.

Se você receber o incidente já registrado pela central de atendimento, essas primeiras duas etapas já foram feitas. Se você receber uma ligação ou o incidente for relatado por e-mail ou mensagem ou pombo-correio, a equipe da central de atendimento é responsável por fazer o registro correto.

Esses registros de incidente (ex.: tickets) costumam incluir:

• O nome da pessoa que relatou o incidente
• A data e hora que o incidente foi relatado
• Uma descrição do incidente (o que está inativo ou não funciona direito)
• Um número de identificação exclusivo atribuído ao incidente para o rastreamento

Categorizar o incidente

Essas próximas duas etapas — categorizar e priorizar — são essenciais e muitas vezes ignoradas. Elas também separam as centrais de atendimento mais "sãs" com as quais já trabalhei lá...bem, nem tanto.

Primeiro, você deve atribuir uma categoria lógica e intuitiva (e subcategoria, conforme necessário) a cada incidente. Se você não o fizer, vai eliminar a possibilidade de analisar os dados mais tarde e buscar tendências e padrões, o que é uma parte essencial de um gerenciamento de problemas efetivo e da prevenção de incidentes futuros.

Em outras palavras, não se esqueça. E não se contente com uma solução de central de atendimento de TI que não permita personalizar com facilidade categorias de incidentes.

Priorizar o incidente

Em segundo lugar, todos os incidentes devem ser priorizados.

Para priorizar um incidente, comece avaliando o impacto nos negócios. Considere tanto o número de pessoas que vão ser afetadas, bem como as possíveis implicações financeiras, de segurança e conformidade do incidente para determinar o dano que o incidente está causando e a urgência da empresa na resolução.

A prática recomendada aqui é definir os níveis de gravidade e prioridade antes que ocorra um incidente, facilitando aos gerenciadores de incidentes medir a prioridade com rapidez.

E quando estiver em dúvida sobre prioridade? Escolha o nível de prioridade mais alto. É melhor errar por excesso de cautela do que deixar algo grave passar despercebido.

Depois de definir essas prioridades, aborde todos os incidentes abertos em ordem de prioridade. A maioria das empresas define acordos claros de serviço para cada nível de prioridade, assim os clientes ficam sabendo com que rapidez esperar uma resposta e resolução. Recomendo muito essa prática.

Responder

Resposta a incidentes é um termo bem amplo. Então, ele foi dividido em etapas mais prováveis de você seguir depois de identificar, categorizar e priorizar um incidente.

Diagnóstico inicial
É como a triagem que um hospital realiza nos pacientes novos. O funcionário da central de atendimento está formulando uma hipótese rápida sobre o que pode estar errado, para que ele possa decidir entre corrigir ou seguir os procedimentos adequados e compilar os recursos certos para que ele seja resolvido.

As bases de conhecimento e os manuais de diagnóstico são ferramentas úteis nesta etapa também.

Se o primeiro agente da central de atendimento for capaz de resolver o incidente com base nos diagnósticos iniciais e no conhecimento e nas ferramentas disponíveis, o incidente está resolvido. Caso contrário, é hora de escalonar.

Escalonamento de incidentes
A palavra pode parecer estranha, mas não é.

A equipe da linha de frente de suporte deve conseguir resolver grande parte dos incidentes mais frequentes sem precisar escalar. Porém, nos casos em que não conseguirem, a meta é reunir e registrar as informações certas para ajudar o suporte no segundo e terceiro níveis (mais técnicos) a entender com rapidez para conseguir resolver o incidente logo.

Investigação e diagnóstico
A ITIL chama a função como uma etapa própria. Na verdade, ela acontece durante todo o ciclo de vida do incidente.

A primeira pessoa da linha de frente do suporte a responder já está investigando, até certo ponto, quando coleta informações e pode até diagnosticar com sucesso e resolver o incidente sem qualquer necessidade de escalonamento.

Nesse caso, você pulou direto para as próximas etapas: resolução e recuperação e encerramento do incidente.

Caso contrário, a investigação e o diagnóstico vão acontecer a cada etapa do caminho, à medida que você encaminha ao suporte de nível 2 e 3 ou traz recursos externos ou membros de outros departamentos para consultar e ajudar com a resolução.

Resolução e recuperação
Depois de um tempo — e, em uma situação ideal, dentro dos acordos de nível de serviço (SLAs) estabelecidos — você vai chegar a um diagnóstico e vai seguir as etapas necessárias para resolver o incidente. A recuperação implica a quantia de tempo que pode levar para que as operações sejam restauradas por completo, uma vez que algumas correções (como correções de bugs etc.) podem exigir teste e implementação mesmo após a resolução adequada ser identificada.

Encerramento do incidente
Então, o incidente é transmitido de volta à central de atendimento (se tiver sido escalonado) para ser encerrado. Para manter a qualidade e garantir um processo sem problemas, apenas os funcionários da central de atendimento têm permissão para encerrar incidentes e o proprietário do incidente deve verificar com a pessoa que relatou o incidente se a resolução é satisfatória e o incidente pode, de fato, ser encerrado.

Conclusão: não pule as etapas

O processo pode parecer formal demais, em especial se você tiver apenas alguns analistas da central de atendimento. Seja qual for a estrutura da equipe, o ciclo de vida do incidente ainda é o mesmo.

Se você tiver apenas um analista na central de atendimento, então não há suporte de nível três. Mas os incidentes que estão além do conhecimento do analista da central de atendimento têm de ir a algum lugar, seja para o engenheiro-chefe ou para um consultor externo ou até mesmo você, certo?

Pronto! Você tem suporte de nível dois ou três, é você ou o engenheiro.

O que quero dizer? Mesmo que a ITIL pareça ter a ver só com semântica, não fique preso a ela. Procure maneiras fáceis de adaptar a hierarquia organizacional e fluxos de trabalho de processo para se adequar a uma estrutura de gerenciamento de serviços de TI fácil, como descrevi acima.

Fazendo assim, você vai entregar um atendimento ao cliente muito melhor e muito mais valor de retorno aos negócios. (Além disso, seu cabelo vai parar de ficar em pé, pontos extras!)

Por último, alguns lembretes:

• Registre todos os incidentes. Atribua a ele um número único e capture dados importantes (como data, hora e descrição) em um sistema de central de atendimento central.
• Se você tiver um público grande interno ou externo para comunicar atualizações de incidentes, considere uma página de status para comunicação de incidentes.
• Atribua uma categoria a cada incidente (e subcategoria, conforme necessário).
• Dê um nível de prioridade a cada incidente e a cada nível de prioridade um SLA.
• Tenha papéis bem definidos para respondentes de incidentes, como responsável pela gestão de incidentes, gerente de incidentes graves, líder de comunicações.
• Sempre que possível, habilite a equipe de suporte de linha de frente com artigos de base de conhecimento e scripts de diagnóstico de incidentes para ajudar a resolver incidentes com rapidez.
• Assegure que a central de atendimento sempre retenha controle do progresso, encaminhamento e status do incidente.
• Não faça apenas a captura dos dados do incidente. Faça a análise! Busque por tendências, padrões e potenciais problemas subjacentes que possam reduzir o volume de incidentes e mitigar os riscos.

Sobre a autora