TroubleShooting - a arte de resolver problemas;

Técnicos percorriam quilômetros de linhas telegráficas a cavalo para localizar e “martelar” o ponto exato da falha - a palavra fundiu trouble (problema) e shoot (atirar) e literalmente temos o “atirar em problemas”, que é um termo “intraduzível” e do caralho.

Quando eu pensei em uma imagem, me veio a capa do Doom atirando em demônios, uma representação visual digna:

Passado esse intro inicial, uma verdade:

Queiramos ou não, grande parte do tempo de nossa vida será dedicado ao troubleshooting, que se resume a entender mecanismos, processos e pessoas e marretar o problema.

Então, se o nosso troubleshooting melhorar, teremos uma melhoria em todas as áreas de nossa vida.

Esse texto se inicia do texto de Curiosity

Conhecimento do Sistema

A premissa inicial é que, para realizar um bom ts, você precisará conhecer o sistema em que está trabalhando. Quanto menos conhecimento do sistema, mais genérico será seu ts — esse é o escopo Globalista. Isso não é problema: você pode acertar no seu tiro genérico ou falhar e ter que esmiuçar o problema ainda mais.

Escopo Globalista: A ————————————————— B Legenda: Problema está em “A” ou Problema está em “B”

Porém, isso pode levar a crer em premissas falsas. Uma vez que você já terá feito o ts diversas vezes, pode crer que determinado problema é X quando na verdade é Y e perder muito tempo na sua premissa.

Escopo Especialista: A _ A1 _ A2 _ A3 _ Conectores C1, C2, C3 _ B3 _ B2 _ B1 _ B Legenda: Encontra mais pontos de falha e com mais precisão que o primeiro ts nem sequer imagina: Problema está no B3

No texto de Curiosity, ele fala que é preciso dar um passo atrás e ter consciência de que você está observando o sistema e não integrado a ele, tocando as teclas certas.

A intuição e a avaliação

O livro Rápido e Devagar, de Daniel Kahneman, chama de Sistema 1 e Sistema 2, também como Intuitivo e Deliberado, e a nossa tendência de seguirmos sempre pelo caminho intuitivo (mais fácil e de menor esforço), o que pode nos levar a perder tempo investigando demasiadamente por intuição do que logicamente.

Hipótese Absoluta

Um erro comum no ts é considerar uma única e absoluta hipótese. O erro está no ponto B, sem investigar isso de maneira extensa. Muitas vezes não é possível identificar o erro, e as demais premissas não são investigadas. Ou seja, identificou-se um erro amplo, mas não foi possível identificar que o processo estava falhando nos conectores C1. Encontra-se o erro, mas não a responsabilidade.

Viés de Confirmação

Kahneman demonstra que, quando formulamos uma hipótese, nosso cérebro automaticamente busca evidências que a confirmem, não que a refutem.

No direito, isso é muito perigoso. Sustentamos uma tese integralmente amparada por uma única jurisprudência de uma turma em um tribunal distante, de um ano não muito próximo, como se isso fosse o baluarte da verdade, e nos esquecemos de trezentos entendimentos contrários de tribunais mais próximos e com fundamentações melhores.

Pressuposições

Pressuposições em problemas podem consumir horas e dias em ts. Portanto, por mais absoluta certeza que você tenha de que o sistema está funcionando e o problema esteja em um ponto X, é preciso voltar e olhar para todos os processos isoladamente até que se chegue a esse ponto X.

Quantas vezes eu perdi tempo tentando solucionar um problema quando, na verdade, o problema vinha de processos anteriores que pareciam estar superados.

Acontece que, ao implementar uma nova solução no processo, você pode quebrar uma solução anterior e nem perceber isso.

No texto de curiosity, esta etapa é muito importante e, para evitá-la, é preciso:

1. Observar os sintomas;
2. Isolar os problemas;
3. Desconectar os subsistemas ou prová-los;
4. Achar pontos de corte.

Não se esqueça de ler o artigo principal, o meu texto não substitui aquele.

Na visão de Kahneman, temos dois mecanismos que podem nos levar a pressuposições:

1. WYSIATI (What You See Is All There Is — O que você vê é tudo que há): o cérebro constrói uma história coerente com a informação disponível e sente confiança nessa história — mesmo que a informação seja incompleta. Você JÁ VIU que o processo anterior funciona e funcionou adequadamente, e isso é tudo que há para o seu Sistema.

2. Ancoragem: a primeira hipótese funciona como âncora mental, e todas as investigações subsequentes orbitam ao redor dela. Até números aleatórios influenciam julgamentos posteriores — imagine o peso de uma premissa que você construiu com base na sua experiência e testagem extensa.

A pressuposição não é apenas falta de rigor, é o funcionamento padrão do cérebro. A disciplina de voltar e isolar cada processo é o antídoto contra o WYSIATI.

Culpabilidade antecipada

Tome cuidado para não culpar antecipadamente ou atribuir o erro a alguém ou algum sistema:

• O usuário fez algo de errado;
• O usuário está usando uma versão desatualizada do navegador;

Ao atribuir a culpa exclusivamente por uma crença, especialmente relacionada à pessoa ou à sua particularidade de configuração, não estamos dando chance de resolução do problema, e uma parte importante do feedback e avaliação são perdidos.

No direito, isso é muito importante quando escutamos a premissa do cliente. Se deixarmos de considerar detalhadamente seu relato e suas considerações, podemos deixar passar uma tese importante que poderia ter sido formulada.

Não se esqueça do caso clássico do Carro e do Sorvete

Premissas equivocadas

Premissas equivocadas são diferentes de pressuposições: aqui o problema não é assumir que algo funciona, mas partir de uma premissa que está fundamentalmente errada desde o início. Você olha para o cenário, constrói um modelo mental do que está acontecendo e começa a investigar — mas o modelo está errado.

Um exemplo comum: você assume que o erro é de rede porque o sintoma parece timeout, mas na verdade é um deadlock na aplicação. Ou assume que o deploy mais recente causou o problema, quando na verdade é um dado corrompido no banco que estava latente há semanas.

O perigo das premissas equivocadas é que elas podem gerar investigações inteiras que são internamente coerentes — você encontra “evidências”, faz testes que parecem confirmar — mas a conclusão está errada porque o ponto de partida era errado.

Kahneman: fala sobre superconfiança (overconfidence): “a confiança que os indivíduos depositam em suas crenças depende principalmente da qualidade da narrativa que podem contar, mesmo se veem pouco.” Quanto mais coerente sua história do erro, mais confiante você fica — independentemente de estar certa. A saída: trate suas premissas iniciais como descartáveis. Se em 20 minutos a premissa não gerou progresso concreto, jogue fora e comece de outro ângulo.

A Confiança na Abstração

No desenvolvimento de software, estamos tão absortos em camadas e camadas de abstração que não é possível, de forma imediata, compreender a dimensão dos aplicativos e de todas essas camadas.

Mas erros, mesmo em grandes sistemas, podem acontecer, e se você tem confiança cega e absoluta nesses sistemas, pode ser um caminho tortuoso até você achar uma solução.

No meu caso, no ProcStudio, eu dependo de uma Gem chamada Docx que tinha alguns erros. O caminho foi continuar usando-a, mas com uma customização. Porém, até eu descobrir isso, perdi muito tempo editando e reeditando documentos até perceber que o problema não era comigo, mas com o sistema.

Kahneman: Kahneman tem um nome exato para isso: cegueira induzida pela teoria — “uma vez você tendo aceito uma teoria e a utilizado como ferramenta em seu pensamento, é extraordinariamente difícil notar suas falhas.” A gem Docx era uma “teoria aceita” — uma ferramenta que fazia parte do seu modelo mental como algo confiável. Além disso, opera aqui a ilusão de validade: a confiança em sistemas e ferramentas é sustentada pela comunidade profissional que os utiliza (“todo mundo usa”, “tem milhares de stars no GitHub”), não por evidência concreta de que funcionam no seu caso específico. Kahneman mostrou que até profissionais financeiros mantêm fé inabalável em métodos que estatisticamente não funcionam, simplesmente porque a comunidade ao redor acredita neles. No ts, a regra deveria ser: confiança em abstração é proporcional à sua capacidade de verificá-la. Se você não pode descer até a camada que está falhando, sua confiança é fé — não conhecimento.

Culpabilizar o Sistema

Em caminho oposto ao tópico anterior, o comportamento contrário também não é nada salutar: sempre culpar o sistema pelos erros humanos.

Um comportamento muito comum do indivíduo que parte desta premissa é querer mudar o escopo de tecnologia da empresa, sem nem mesmo tentar se adaptar ao que já existe:

• Precisamos de uma outra solução para o Docx!
• Essa solução não funciona, é muito (complexa ou qualquer outra coisa)!

E geralmente, o problema não está no aplicativo ou na solução, mas no usuário que está viciado e quer seguir utilizando aquilo que já conhece, partindo de uma premissa de conforto.

Hiperfoco no problema e o looping infinito

Durante um ts intenso, é comum entrar num estado de hiperfoco em uma área específica do sistema. Você está tão concentrado em analisar logs, depurar uma função ou rastrear uma requisição que deixa de ver sinais óbvios em outros lugares. Nesses momentos, também é preciso dar um ou mais passos para trás — às vezes, deixar o problema de lado um pouco. Como aquela recomendação de quando você termina um texto e deixa para revisá-lo só no dia seguinte.

Existe um momento no ts em que você percebe que está rodando em círculos — tentando as mesmas coisas, relendo os mesmos logs, refazendo os mesmos passos. Geralmente, esse é o ponto em que as piores decisões são tomadas: atalhos perigosos, mudanças sem critério, “tentativa e erro” desesperado.

Na comunicação

Na comunicação, é preciso também usar o ts. Quando é uma conversa rápida, é uma espécie de debugging instantâneo das conversas, mas, em geral, em todos os sistemas de comunicação, é preciso pensar.

• O que eu estou tentando comunicar?
• Como o ouvinte vai perceber a informação?
• Eu estou no mesmo contexto do ouvinte?
• O que ele está tentando me dizer?
• Qual é o contexto que ele está querendo me passar?

Essa parte merece um tópico próprio, quem sabe daqui alguns posts.

Conclusão

Se eu tivesse que selecionar apenas uma coisa, diria: nunca ignore nada, por mais seguro que o sistema possa parecer, por mais seguro que a informação lhe pareça. Desconfie, analise, verifique duas vezes, e assim você vai conseguir encontrar os problemas mais facilmente.