ITIL: Problemas e incidentes (pt1)

É muito comum encontrar em empresas uma separação entre analistas que tratam problemas e analistas que tratam incidentes, seja dentro do mesmo time, em times separados ou até setores separados.

Eu acredito que essa abordagem gera mais problemas do que resolve e, além disso,  discordo dos que dizem que o ITIL recomenda assim pois, o ITIL diz muita coisa, mas ele não diz o *como implementar*.

Por outro lado, se um cargo capacita a pessoa, minha opinião deve mesmo estar errada frente ao número de pessoas capacitadas que implementaram dessa forma.

Aqui reflito sobre essa questão e porque eu faria diferente.

Quando as pessoas lêem algo já buscando uma resposta, normalmente elas encontram. Mesmo que o texto lido não a dê.

Apesar de todo seu conteúdo o ITIL não te desenha nenhum processo, no entando, tem gente que lê e ja sai desenhando os processos como se tivesse lido nos livros. As pessoas simplesmente suprem as lacunas com as suas próprias opiniões prévias e, como isso é um processo subconsciente, se convencem de que leram aquilo no material.

Em 2015 fui responsável por desenhar o processo de gerenciamento de problemas do setor de serviços compartilhados em um Datacenter, e outro amigo da equipe ficou responsável pelo de incidentes. Ora, mas que bela oportunidade para que, juntos, desenhemos processos que façam sentido, diferente das implementações separatistas com seus problemas.

Antes de começarmos a desenhar os processos, precisávamos ter em mente o seguinte:

  • Erros que queremos evitar ? É bom que aprendamos com nossos erros, mas se pudermos aprender com os que erraram antes, melhor né ?
  • O que, de fato, são problemas e o que são incidentes ? Processos diferentes irão tratar coisas diferentes, não adianta desenhar os processos sem ter bem definido o que eles irão tratar.
  • Relacionamentos entre os processos. A dependência entre processos não pode atrapalhar seus objetivos. O ITIL só é burocrático quando implementam errado.
  • Que métricas queremos coletar ? Informações muito relevantes podem ser obtidas a partir de um processo com fluxo e métricas bem definidas.

Esses serão os assuntos dos próximos posts sobre o tema.

Quiz

Quando conseguimos definir uma visão geral dos objetivos de cada processo, fizemos um pequeno questionário para levarmos em reuniões e levantar discussões. Afinal, é muito mais eficiente mostrar breves perguntas que atacam diretamente os pontos mais polêmicos e mostrarmos nossas respostas e justificativas do que simplesmente apresentar dezenas de slides com o fluxo detalhado de cada um dos processos.

Essas perguntas, então, resumem nossa visão sobre incidentes e problemas, que depois foi detalhada nos processos em si.

Perguntas

Responda Verdadeiro/Falso nestas perguntas pensando do ponto de vista do (que você conhece sobre o) ITIL:

  1. Quando um incidente é aberto, o analista checa a base de dados de erros conhecidos em busca daquele erro. Quando não houver, ele deve gerar um problema para que a causa raiz seja analisada, o erro conhecido seja documentado e uma solução de contorno ou definitiva seja fornecida.
  2. Incidentes e problemas devem ser tratados por analistas/equipes/setores diferentes, pois há um conflito de interesses entre os dois processos (um precisa resolver o mais rápido possível, admitindo soluções de contorno, e o outro da melhor forma possível e definitiva).
  3. É possível abrir um registro de problema sem que haja nenhum incidente relacionado.
  4. A identificação e eliminação de SPOFs (pontos únicos de falha) é um exemplo de execução do processo de gerenciamento de problemas.
  5. Um alerta de monitoramento pode gerar diretamente um problema.
  6. Quando uma mudança for necessária para a solução de um incidente, o processo de gerenciamento de incidentes deverá submeter uma RDM ao processo de gerenciamento de mudanças e aguardar até que ela seja executada.
  7. Quando há uma crise, mesmo que se saiba o motivo, o processo de gerenciamento de problemas deve ser acionado.
  8. Em uma crise causada por um incidente num storage, os serviços são totalmente restabelecidos quando uma das controladoras fica estável. A outra controladora ainda está desligada e aguarda upgrade de firmware pelo fabricante. Apesar de não haver redundância, os serviços estão OK e, por isso, os registros dos incidentes devem ser finalizados.

Respostas

  1. Falso. Se o processo de incidentes depender do de problemas você está escalando um incidente pra problema.
  2. Falso. O conflito existe mas é entre processos, mas papéis (num processo) não são cargos nem funções. Um analista consegue exercer diversos papéis.
  3. Verdadeiro. Se não não haveria o aspecto proativo do gerenciamento de problemas.
  4. Verdadeiro. É um dos exemplos do processo de problemas agindo proativamente.
  5. Verdadeiro. Imagine que seja um alerta dizendo que teu firewall inativo no HA morreu. Não ocorreu nenhum incidente pois o ativo permanece, mas agora você tem um SPOF.
  6. Falso. Nenhuma mudança é necessária para resolver nenhum incidente. Se for, há algo errado. Resolver um incidente é restabelecer o que funcionava antes. Se funcionava antes, dá pra funcionar novamente sem mudar nada. Se é recorrente e precisa melhorar a arquitetura, é outro assunto. Por isso, workarounds são aceitáveis no processo de incidentes.
  7. Falso. Um incidente pode causar uma crise. A quantidade de ativos/serviços/clientes afetados não torna um incidente em problema.
  8. Verdadeiro. Se os serviços foram restabelecidos, o incidente foi resolvido. O fato de haver um risco significa que será aberto um problema para tratar isso desse momento em diente.

No próximo artigo falarei sobre os erros que queríamos evitar.

2 comentários em “ITIL: Problemas e incidentes (pt1)

Os comentários estão encerrados.