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 INEXISTÊNCIA A SOLUÇÃO, 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?

Artigo elaborado por Carlos Felício, profissional com mais de 20 anos de experiência em tecnologia, infraestrutura e nuvem.