ITIL: Problemas e incidentes (pt2)

Continuando o post anterior, queríamos evitar alguns erros bem comuns já que estávamos desenhando os dois processos juntos.

Aprender com nossos erros é obrigação, mas aprender com os que erraram antes é melhor. Muitas decisões nos desenhos dos processos podem gerar conflitos e ineficiência lá na frente.

É claro que não há como prever tudo que pode dar errado, mas saber erros que queremos evitar é um direcionador muito importante.

Os problemas mais graves que frequentemente ocorrem são:

  • Tratar incidente como problema e/ou problema como incidente, cuja causa é a falta de definição dos dois termos.
  • Um incidente gerar um problema urgente, cuja causa é a separação dos analistas.

Vamos falar do primeiro que é mais simples.

Má definição de problemas e incidentes

A percepção que tenho é que todo mundo sabe o objetivo do processo de gerenciamento de incidentes, que é “Restabelecer o serviço no menor tempo possível.”, mas vejo pouca gente definindo claramente o que é um incidente.

Todos também sabem que “um problema é a causa raiz desconhecida de zero* ou mais incidentes.”, mas vejo pouca gente falando o objetivo do processo de gerenciamento de problemas.

Notaram que uma é a definição de um termo e outro de um objetivo do processo ?

O ponto que eu acredito que origine toda confusão está na interpretação dessas duas definições acima por serem definições sobre coisas diferentes.

“Restabelecer o serviço no menor tempo possível.” leva a crer que, enquanto algo estiver fora, é o processo de incidentes que deve resolver o caso e com urgência.

“Um problema é a causa raiz desconhecida de zero* ou mais incidentes.” leva a crer que, se ninguém sabe a causa, então é um problema. Nessa linha surge o: “aciona o pessoal de problemas pq ninguém sabe o que tá acontecendo!”

Obviamente o erro está na segunda.

Vamos à uma definição clara do que seja problema e incidente:

  • Um problema é a causa raiz desconhecida de zero* ou mais incidentes.
  • Incidente é uma situação inusitada que gera impacto no serviço e exige providências para que a normalidade seja restaurada.

*zero: se fosse “um” todo problema seria apenas reativo embora o próprio ITIL cite aspectos proativos no gerenciamento de problemas. Para que possa ser proativo, como no tratamento de um SPOF antes que cause incidentes, a frase precisa ser com “zero” e não “um”.

Exemplos

Imagine que a fonte de um servidor queime e cause impacto em um serviço. É um incidente. Não há cabimento em pedir análise de causa raiz do motivo pelo qual a fonte queimou.

Fontes queimam, HDs queimam, sapo sapeia, chuva chove e hardware queima (software voa).

Porém… se dos seus 785 servidores, este mesmo servidor queima a fonte a cada 3 meses enquanto a média dos outros é a cada 4 anos,  opa, recorrência *pode* indicar um problema. Vale a pena investigar a régua, o cabo, o que for… abra um registro de problema.

Eu já vi pessoa cobrando análise de causa raiz de um certificado SSL que expirou e o serviço parou de funcionar. Ok então, causa: “Chronos.”. O tempo passa o tempo voa, e a poupança bamerindus continua numa boa e os certificados expiram.

Também ja vi uma pessoa dar uma “dedada” ou “orelhada” que derrubou muitos serviços e choveu chamado no suporte. Pro pessoal do suporte, a causa era desconhecida, pro artista que deu a dedada não. Então é problema ou não é ? “Tem carburador ou não tem carburador ?” – dilema da dúvida tropa de elite.

Mesmo em uma crise com causa desconhecida, não há justificativa para se analisar a causa raiz da crise pois um incidente não é um problema e não importa seu tamanho. O ITILv3 introduziu o conceito de incidente maior justamente para que correlacionassem incidentes diversos com a mesma origem (numa crise), mas sem confundir com um problema.

Até pode haver um problema, mas isso deve ser investigado depois da crise resolvida. Lembram que os incidentes são urgentes ? Problemas não são.

Exemplos de tratamento errado

Meu amigo do processo de incidentes formulou um exemplo fantástico de um incidente sendo tratado erroneamente como problema.

Incidente tratado como problema

Imagine que domingo ocorrerá, num ginásio, um espetáculo de queda de peças de dominó com um google de peças enfileiradas caindo e revelando diversos efeitos, animações etc… aqueles shows que passam no fantástico (not a sponsor).

Sábado à tarde o pessoal está montando as peças e, de repente, no meio do circuito as peças começam a cair… e vão caindo a partir dali…

As pessoas pensam: “Será que foi o vento ? Vamos fechar a janela !”, “Será que a mesa tá bamba ? Vamos colocar calços!”.

Mas as peças seguem caindo…

O tratamento correto seria:

incidente-domino

Num incidente as coisas precisam ser simples…, mais vale o raciocínio rápido de: “Foda-se o que houve e vamos parar a queda!” do que querer saber se a janela aberta foi a causa raiz do vento que entrou e iniciou o caos. Não importa.

É como, dentro de um avião em queda, você não pegar sua máscara de oxigênio porque está olhando pela janela pra ver se há fogo na turbina.

Esse foi um exemplo de incidente sendo tratado como problema.

Problema tratado como incidente

Da mesma forma, podemos até usar o exemplo anterior para exemplificar um problema sendo tratado como incidente.

Lembra das fontes que queimam no mesmo servidor ? Se em vez de analisar o caso, simplesmente comprarem dezenas de fontes e já deixarem ali pertinho do servidor para substitui-las rapidamente  quando queimarem, esse é um exemplo de tratar problema como incidente. Você sabe que vai ocorrer e se prepara pra reagir rápido em vez de focar em evitar que ocorra novamente.

Separação dos analistas

Um problema urgente é a consequência de uma cadeia de equívocos que começa quando se separam os analistas de problemas e incidentes.

De onde tiram essa idéia ?

Pode ser pela interpretação errada citada lá no começo de que problema é quando a causa é desconhecida e incidente é “coisa rápida, só restartar serviço”. Daí dividem as equipes entre o pessoal que restarta serviço (juniores) e o pessoal que analisa a causa raiz (seniores). Ao meu ver, essa é a explicação da divisão, só pode.

Quando há essa separação é “forçadamente natural” que analistas mais experientes fiquem no time de problemas. Afinal, os analistas de problemas são os caras que precisarão fazer mudanças na arquitetura dos serviços quando for necessário. O pessoal de incidentes se limita a restartar serviços já que a coisa tem que voltar a funcionar como era antes e que nada mudou. Não é bem assim.

Mas… quando já há essa divisão e o time de problemas é composto por analistas mais experientes, o que acontece quando ocorre uma crise ?

Ora, é natural que todos queiram que os analistas mais experientes tratem a crise. Até aí  eu concordo. Mas se eles estão no time de problemas, o que se faz ? Transforma-se a crise, que é um incidente, em um problema para que seja “escalada” ao pessoal mais senior.

Percebem que nessa altura o sistema está trabalhando pra resolver os problemas do próprio sistema ? (outro ensinamento do tropa de elite).

Foi necessário transformar um incidente em um problema porque era necessário que os melhores analistas resolvessem o incidente porque era uma crise mas os melhores analistas não tratariam incidentes.

Quando chega esse ponto, ambos os processos já foram pro caralho.

Quando os processos não funcionam a empresa acaba buscando outra metodologia (ou uma atualização dela) para que resolva o problema que, na verdade, foi uma má implementação.

E normalmente o artista que implementou errado pensa: “Na próxima versão do ITIL eles corrigirão isso”.

Só posso dizer: “Um idiota com um processo, continua sendo um idiota.”.

(substitua livremente a palavra processo por qualquer outra. Sugestões: ferramenta, regra, idéia…)

Obviamente isso também gera o desejo dos analistas de incidentes progredirem em suas carreiras e virarem analistas de problemas.

Ok, mas então ?

Eu digo: “Então não é.”, como entitula o blog.

Um processo é o que transforma funções em papéis e papéis não são cargos. Nunca serão.

Exemplo: em todo processo que descreve o tratamento de crises, há um papel de comunicação. O analista mais indicado pra esse papel em cada crise é aquele que menos tem a ver com a tecnologia em problema.

Seguir um processo de tratamento de incidentes e de tratamento de problemas é um papel que pode ser seguido por qualquer analista, de junior à senior.

Incidente é urgente, e não pode depender de outros processos. Por isso, o processo de incidentes NUNCA pode depender de uma GMUD. Se seu processo de incidentes depende do de mudanças (rdm, comitê etc), está claramente errado.

O processo de problemas trata risco, é orientado a evitar incidentes e por isso trata questões arquiteturais. Interage com fabricantes, interage com o processo de mudanças.

Quem melhor do que os analistas que resolveram uma crise (tratando como incidente que é) pra dar seguimento à análise de causa raiz para que não ocorra novamente ? Porque os analistas que trataram o incidente não podem ser os mesmos que tratarão o problema e evitarão a próxima crise ?

Assim, os melhores analistas podem atender aos incidentes mais críticos, e depois disso analisarem com calma e artitetarem as mudanças necessárias para que a crise não ocorra novamente.

Um comentário em “ITIL: Problemas e incidentes (pt2)

Os comentários estão encerrados.