ITIL: Problemas e incidentes (pt3)

Fechando o assunto sobre Problemas e Incidentes (parte 1 e parte 2), comentando sobre mais algumas diferenças e agora recomendações sobre que objetivos você deve ter em mente quando desenhar tais processos.

Gerenciamento de Incidentes

A primeira coisa que me vem à cabeca é: agilidade.

A beleza do ITIL é justamente não te dizer como fazer as coisas. Enquanto que, pra ter agilidade, eu entendo q seria bom não depender de ninguém, outros podem entender que precisam acionar todos os fabricantes o mais rápido possível. Não está escrito o que é o certo nem o errado.

O importante é que um bom processo de incidentes restabelece o serviço no menor tempo possível.

Em minha opinião, é você mesmo (sua equipe) que faz o tshoot num incidente e descobre o que precisa fazer para restabelecer o serviço. Se, e somente se, o que deve ser feito para restabelecer o serviço estiver fora de seu controle (não tem acesso, ou é um problema em um appliance proprietário ou problema de link ou energia por exemplo), você entra em contato com o fornecedor para que resolva o problema. Mas você já fez o tshoot e aciona apenas o fornecedor que tomará a ação para restabelecer o serviço.

Evite contactar fornecedores para fazer tshoot por você em incidentes. Por mais q você tenha contratado um bom SLA com seu fornecedor, seu cliente não se importa com isso. Seu cliente tem um contrato contigo, não com teus fornecedores. Além disso, ninguém melhor do que você para fazer tshoot do seu ambiente.

Exemplo:

O cenário extremo à ser evitado é aquele que quando um serviço cai, você passa a depender de partes externas para que acusem onde está o problema.

Imagine que alguns serviços caíram porque todas as VMs rodando num host caíram.

Você liga para o fornecedor do S.O. e ele põe a culpa no hardware. Você liga pro fornecedor do hardware e ele põe a culpa no storage. O pessoal de storage diz que o problema está na rede. Você chama todos os fornecedores pra uma call e eles discutem por horas (sendo que já levou horas pra chegar ate aqui).

Os fabricantes sugerem uma mudança no ambiente. Para fazer qualquer GMUD é  necessário submeter ao comitê semanal. Não é uma opção.

Alguém, por curiosidade, olha a configuração da porta daquele host no switch e descobre que alguém setou o mtu pra 150(faltando 0 pra 1500). Por isso o host não acessava o storage e por isso as vms dele caíram.

Você poderia detectar isso rapidamente se tivesse feito o tshoot você mesmo (sua equipe). Ou melhor, você poderia monitorar as configurações das portas no switch. Ou melhor ainda, você poderia usar uma ferramenta de gerenciamento de configuração que teria reportado e corrigido rapidamente o problema automaticamente. Mas isso é assunto pra outro post.

Ou seja, num incidente, não dependa de outros a não ser para coisas q realmente você nao consegue controlar. Resolva logo. Admite-se “gambiarras” na solução de incidentes. O que não se admite é não resolver o incidente no menor tempo possível. Mantenha isso em mente.

 

Gerenciamento de problemas.

Aqui o que me vem à cabeca eh: proatividade.

Pode parecer estranho não citar “causa raiz” mas é que a causa raiz, à grosso modo, é um termo muito desvirtuado. E fundamentalmente a característica que separa um incidente de um problema é a proatividade.

Como assim?

Num cenário comum, quando serviço sai do ar porque um servidor pára porque a fonte queimou, qual foi a causa raiz ? A fonte.

Isso está errado. Isso é um incidente e não um problema, logo, não tem causa raiz à ser analisada posto que se sabe que foi a fonte que queimou  e que fontes simplesmente queimam.

 

Vale invesgitar porque a fonte queimou? Não. Fontes queimam. Todo equipamento tem MTBF e não é necessário analisar o porque eles dão problema a não ser que você tenha evidências que os equipamentos estão muito abaixo do MTBF previsto.

Porém, porque o serviço falhou com a queda de um único servidor? Isso sim é um problema. Se você depende de um único servidor para um serviço fundamental, mesmo que ele esteja funcionando bem, você já tem um problema (risco).

Se há risco, há problema. O risco pode ser descoberto e resolvido antes que cause um incidente ou, nesse caso, antes que cause o próximo. Nisso sim tem proatividade pois quem apenas reage ao incidente é o processo de incidentes, o de problemas evita a recorrência.

Então vamos lá, qual objetivo do processo de problemas?

Evitar incidentes, recorrentes ou novos. 

Algumas vezes mudanças estruturais serão necessárias para melhorar a estabilidade de um serviço, por isso o processo de problemas pode acionar processo de mudanças (o de incidentes não).

Processos e seus objetivos

Um dos objetivos de se implantar processos eh gerar métricas. Ninguém implementa ITIL para “estar em conformidade com ITIL” porque isso não existe, não existe certificação ITIL para os processos em uma empresa.

Apenas falando dos processos de incidentes e problemas, quando bem implementados, é  possível ter métricas como:

  • Tempo médio q um incidente leva até ser resolvido, por tecnologia/produto/analista
  • Taxa de solução vinda dos analistas internos ou dos fornecedores para cada tecnologia
  • Eficiência na solução de problemas por fornecedor (medindo taxa de sucesso em gmuds por exemplo)

 

Conclusão

Dá pra usar qualquer coisa de forma errada, e com ITIL não é diferente.

Se implementar ITIL te trouxe os problemas citados aqui, lamento. Você certamente poderia ter evitado boa parte deles se tivesse lido um pouco mais à respeito antes, como eu fiz.

Fora isso, se implementou com sucesso, até mesmo separando analistas de incidentes e problemas sem que isso causasse nenhum problema, me deixe saber como ! Poste em algum lugar e ponha o link aqui !

Obrigado !