Close

O caminho para um gerenciamento de incidentes melhor começa aqui

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

Por Nick Wright, gerente de operações de serviço da Atlassian

Primeiro, preciso dizer algo: as pessoas do suporte da linha de frente são os heróis desconhecidos de todas as empresas.

Todas. As empresas.

Acredito que o suporte técnico deve ser considerado um setor de serviços e os clientes deveriam dar gorjetas para os agentes que prestam um excelente serviço. Ficaria feliz em dar uma gorjeta para cada funcionário do suporte que resolvesse os itens com rapidez e com um sorriso se eu pudesse.

Mas é apenas um parêntese. Se você estiver lendo aqui, é bem provável que você gerencie ou faça atendimento em uma equipe da central de ajuda. É bem provável também que seu cabelo esteja em pé agora. E pegando fogo. O cheiro é péssimo. Então, vamos fazer algo a respeito disso e colocar o processo de gerenciamento de incidentes de TI sob controle.

Antes de entrarmos de cabeça no gerenciamento de incidentes, que tal entrar em sintonia em relação à terminologia?

ITSM e gerenciamento de incidentes

Se você trabalha com TI, é bem provável que esteja familiarizado com ITIL, ITSM, incidentes e problemas. Mas para manter todos em sintonia, veja abaixo algumas definições rápidas que usamos na Atlassian:

ITIL (Biblioteca de infraestrutura de TI) é um conjunto das melhores práticas para ITSM (como um esquema tático).

ITSM (Gerenciamento de serviços de TI) é uma abordagem comum para criar, dar suporte e gerenciar serviços de TI. O principal conceito do ITSM é a crença de que a TI deve ser oferecida como um serviço. E uma das principais práticas do ITSM é o gerenciamento de incidentes.

Incidentes são eventos não planejados de qualquer tipo que interrompem ou reduzem a qualidade do serviço (ou que ameacem fazê-lo). Um aplicativo de negócios que deixa de funcionar é um incidente. Um servidor da web muito lento também pode ser um incidente. A execução está muito lenta e afetando a produtividade. Pior ainda, ele apresenta o risco ainda maior de falha total.

Um problema é a causa-raiz ainda desconhecida por trás de um ou mais incidentes. No incidente acima, em que a rede está lenta e o aplicativo de negócios está inativo, um roteador com a configuração errada poderia ser o problema subjacente por trás deles.

A importância do gerenciamento de incidentes é uma prática de ITSM

Então, por que o gerenciamento de incidentes é importante? Por que ele faz parte do universo do ITSM?

A resposta está no impacto. Segundo pesquisas, os incidentes graves custam às empresas uma média de US$ 100.000 a US$ 300.000 para cada hora de inatividade do sistema.

Ter um processo bem definido de gerenciamento de incidentes pode ajudar a reduzir muito esses custos. Os benefícios de um processo bem definido incluem:

  • Resolução mais rápida de incidentes
  • Custos reduzidos ou perdas de receita da empresa
  • Melhor comunicação — interna e externa — durante incidentes
  • Aprendizagem e melhoria contínuas

O processo de gerenciamento de incidentes

Vou usar a estrutura da ITIL para dar o passo a passo de uma visão geral do tratamento adequado de tickets, mas a maioria das outras estruturas populares oferecem conceitos bastante semelhantes por meio de uma linguagem um pouco diferente.

A chave para o gerenciamento de incidentes é ter um processo — um bom — e aderir a ele.

Pode parecer assustador, eu sei. Mas a boa notícia é que você pode aprender com as experiências de milhares de outras equipes de serviço de TI.

Um dos erros mais comuns das empresas de TI ocupadas e em crescimento é tentar reinventar a roda e criar processos do zero (sem recorrer a práticas recomendadas) ou criar as próprias ferramentas para lidar com os tickets.

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

Nick Wright
Gerente de operações de serviço, Atlassian

Eu e a equipe nos certificamos que as aplicações e infraestrutura de nuvem da Atlassian funcionem com excelência e eu fico feliz em dividir como o fazemos enquanto dimensionamos rápido. Nasci na Nova Zelândia, mas, apesar desta desvantagem linguística, eu consigo me virar bem. Quando não estou trabalhando, ando de bicicleta, jogo vídeo games ou saio com minha esposa e minha filhinha.