Causa Raiz – da Inexistência à solução – Parte 2

Todos devem lembrar que no Post  anterior (Se você não leu, clique aqui)  falamos de regras, as quais são primordiais à nossa investigação. Mas vamos para o próximo passo. Como definir um problema? Como investigar?

Definindo o problema:

Aqui devemos definir as perguntas obvias, que devem ser feitas para as pessoas que foram envolvidas no incidente, vale lembrar que pessoas tem visões diferentes do mesmo problema, aqui temos suas experiências, percepções, emoções e frustações, que podem mudar o resultado de toda investigação.

Portando devemos utilizar um padrão e observar seu comportamento e respostas.

Segue um modelo de padrão para as entrevistas, este padrão deve ser definido documentado e utilizado por todos.

  1. Qual foi o problema?
    1. O que aconteceu?
    2. Porque aconteceu?
    3. Temos evidências LOGs? Print de tela dos erros?
    4. Sabemos quais serviços foram envolvidos? Afeta negócio?
    5. Fornecedor foi envolvido? Temos laudo?
  2. Quais serviços afetados (Nível técnico e de negócio)?
  3. Quais ICs afetados (Equipamentos)?
  4. Quando (Período – Data e hora)?
  5. Onde (Localização física/logica)?

Devemos lembrar de começar a coletar informações de cada interlocutor, vamos lembra do nosso “Professor Sherlock”,  “DADOS, DADOS, DADOS” e não esquecer das nossas 4 regras que falamos no blog anterior,  mesmo que a análise esteja evidente com alguma informação durante as entrevistas, um detetive nunca emite uma conclusão sem FATOS e relatório, o nosso Detetive de TI (Problemas) precisa ser assertivo.

“Por enquanto, ainda não dispomos de dados — ele respondeu. — É um erro capital formular teorias antes de contarmos com todos os indícios. Pode prejudicar o raciocínio.”

Sempre na entrevista:

  1. Utilizar a técnica dos 5 porquês
  2. NUNCA tirar conclusões com os entrevistados, deixe ele falar e só observe, anote e pergunte, pergunte muito.

Vamos a um exemplo:

Entrevistado

Qual foi o problema:

Indisponibilidade de acesso ao sistema

Porque tivemos falha de acesso?

O usuário estava com a flag de bloqueio

Porque o usuário estava bloqueado?

A conta dele expirou

Porque expirou?

Existe uma regra de segurança

Como você identificou?

Através de LOG do Ative Directory

Você tem as evidências?

Sim

Qual a data e hora do bloqueio que tem no log?

Dia 05/05/2005 as 17hs

Quais serviços foram afetados?

O serviço de troca de arquivos

Afetou o negócio?

Sim

Nosso professor diria: “Nada como a prova colhida diretamente na fonte — comentou ele. — Na verdade, já formei minha opinião sobre esse caso, mas nunca é demais sabermos tudo que há para saber.”

Devemos explorar todos os envolvidos, acima,  temos exemplo de uma única pessoa que respondeu às perguntas, será que estão corretas? Avaliamos os logs? As evidências são assertivas? Devemos sempre tirar a prova e avaliar com um segundo envolvido. No processo devemos fazer um ‘double check’.

Agora já podemos passar para a próxima etapa:

Identificar as possíveis falhas

Com as entrevistas feitas e todos os DADOS coletados, podemos começar a escrever o nosso laudo e identificar as possíveis falhas.

Informações levantadas, um pequeno resumo:

  1. Qual foi o problema?
    1. O que aconteceu?  Falha de acesso
    2. Porque aconteceu? Bloqueio de usuário
    3. Temos evidências LOGs? Print de tela dos erros? Sim
    4. Sabemos quais serviços foram envolvidos? Afeta negócio? Sim
    5. Fornecedor foi envolvido? Temos laudo? Não
  2. Quais serviços afetados (Nível técnico e de negócio)? Troca de arquivos
  3. Quais ICs afetados (Equipamentos)? SERVIDOR01
  4. Quando (Período – Data e hora)? Dia 05/05/2005 as 17hs
  5. Onde (Localização física/logica)? Ambiente de Troca de arquivos localizado no Datacenter Principal

Já temos a possível falha, mas esta é a causa raiz? A conta foi bloqueada.

Podemos aqui identificar o principal PROBLEMA de análise de CAUSA RAIZ, fica complicado falar de Problema do Problema, mas é real, muitas pessoas e empresas entendem que encontrar o que ocorreu seja a causa, muitos iriam parar a analise aqui, emitiriam o RCA e colocariam a solução como monitorar este serviço ou esta conta, ou até mesmo criar uma nova conta de serviço sem expiração, pode até ser a solução final, mas como o nosso blog é DA INEXISTENCIA A SOLUCAO, precisamos resolver de uma vez este problema, para isso devemos nos perguntar:

  1. Qual realmente é a causa RAIZ?
  2. Estou satisfeito com a resposta?
  3. Se acontecer com outro usuário?
  4. Como eu resolvo de vez este caso?
  5. Existem mais casos como este na empresa?

Bom pessoal, para não ficar um blog maçante vou parar por aqui e nos vemos a semana que vem….

Abraços,

Carlos Felício.

 

 

Causa Raiz – da Inexistência à solução

Quando falamos em tecnologia todos sabem que por mais preparado, moderno e controlado que seja o ambiente, em algum momento este pode sofrer uma interrupção, seja ela de pequeno impacto a indisponibilidade de grande proporção, e que após a recuperação do ambiente teremos o famoso e temido “RCA” (Root Cause Analysis).

Apesar deste fato ser conhecido e as empresas cada vez darem maior importância a análise de causa raiz, muitos casos a metodologia não é seguida e/ou implementada com sucesso.

Afinal de constas porque o RCA não funciona?

Este post propõe-se a expor experiências de como melhorar a análise de causa RAIZ para ser solução, e não um novo problema. Vamos debater o tema e passar experiências como:

  • Metodologia de investigação (Processo)
  • Como aplicar a metodologia (Técnico)

Todos já ouviram falar de “Sherlock Holmes”,  este trecho abaixo tive a oportunidade de conhecer em pesquisas de análise de Causa Raiz e vou usar como “CASE”, vou comentar cada item e falarmos das regras básicas para o sucesso. Nesta ficção temos o maior exemplo de método cientifico de análise e solução de problemas, veja o que ela nos ensina:

Sherlock Holmes tinha paixão pelo conhecimento exato e preciso, ou seja, os dados devem ser coletados para provar a hipótese antes de determinar a causa raiz em uma análise.

Regra número 1: Nada deve ser concluído sem “FATO”. Devemos sempre provar a análise.

Sherlock Holmes acreditava que investigando vários crimes (1000) teria informação suficiente para solucionar o 1001º crime. Examine dados de eventos similares pois estes ajudarão a aprimorar o processo de análise.

Regra número 2: A experiência de vários casos ajuda o próximo. Tenha um sistema de base de conhecimento, seja ele qual for.

Sherlock Holmes acreditava que o mundo está repleto de coisas óbvias que ninguém, por qualquer motivo, observa.– Isto implica em não aceitar a primeira explicação, sem atentar para todos os detalhes.

Regra número 3: Aqui está um item que sempre devemos levar para o time, podemos resolver muitos casos com o obvio. Mas nunca devemos esquecer que a riqueza da informação leva a certeza.

Algumas frases do nosso professor “Sherlock Holmes”:

 “É um erro capital teorizar antes de se ter os dados. Insensivelmente, começa-se a distorcer os fatos para adaptá-los às teorias, em vez de fazer com que as teorias se adaptem aos fatos.”

  “Dados! Dados! Preciso de dados! Não posso fazer tijolos sem barro!”

  “Jamais arrisco um palpite. Isso é um hábito chocante… fatal para a capacidade de raciocinar logicamente.”

Regra número 4: Nunca arriscar palpite ou teorizar

Após as regras estarem definidas precisamos definir as fases da análise, cada empresa ou profissional pode ajustar conforme a necessidade, mas vou colocar aqui as que podemos chamar de “obrigatórias”, que atendem inclusive processos de certificação.

  1. Definir o problema
  2. Identificar as possíveis falhas
  3. Verificar a real causa
  4. Propor a solução
  5. Implantação e acompanhamento dos resultados

Bom pessoal, para não ficar um blog maçante vou parar por aqui e nos vemos a semana que vem onde vamos falar de, como definir o problema, identificação das falhas e real causa. Não perca.