Bom, atualmente muito de nós engenheiros de software (em especial os mais iniciantes) preocupam-se com a tecnologia X ou Y a ser usada, qual provedor cloud usar ou qual design pattern devo usar nesse código. Mas, antes dessas perguntas, é extremamente necessário que todo engenheiro treine uma habilidade básica, inerente a própria engenharia: a habilidade de quebrar problemas e solucioná-los, em outras palavras, como realizar um bom troubleshooting?
Ao se esquecer dessa parte primordial, muitos engenheiros irão simplesmente navegar no mar da dúvida sem atacar o problema real. Tal como um médico que receita remédios ao seu paciente sem procurar a causa-raiz, um engenheiro de software sem compreender o problema real apenas nadará no mar de incertezas, muitas vezes aumentando o custo do projeto, sem saber exatamente se solucionou de fato ou não a dor.
Para isso, a mentalidade por trás dessa solução e investigação deve ser completamente analítica: paramos o “sangramento”, investigamos e por fim completamos o ciclo corrigindo o problema. Mas para isso, é necessário não só experiência e muitas vezes técnicas, as quais com o tempo se tornarão naturais no dia a dia. Sobre isso, falarei um pouco mais sobre as técnicas logo abaixo, onde dividirei esse artigo em cada parte do ciclo de solução.
Sumário
Parar o sangramento
Por mais que seja tentador falar que a correção do problema seja a fase mais importante, as vezes interromper imediatamente o efeito direto ou colateral causado por uma falha, na maioria das vezes, é a melhor saída inicial. Se você trabalha em algum sistema financeiro, sabe que uma falha pode custar muito, muito dinheiro. Quanto mais cedo parar o sangramento, mais feliz os stakeholders ficarão. Para isso, você pode utilizar o acrônimo O.Q.C:
O que mudou?
Quando mudou?
Como mudou?
Fazendo essas três perguntas, você conseguirá ter uma visão mais imediata do que mudou no seu sistema, seja um fator interno ou externo, e assim reverter essa situação ou contorná-la, diminuindo o impacto nos seus clientes.
Logs de aplicação, traces, change orders e documentações são sempre bem-vindos nessa hora, mas entenda que apenas ter essas informações não mudará muito, é necessário adicionar na fórmula a sua análise do problema.
Investigação
Essa fase é quando a primeira tempestade acabou, agora é hora de analisar o problema mais profundamente, procure reler o que aconteceu no incidente para relembrar de alguns detalhes e assim parta para a investigação. Nessa etapa, podemos ter algumas ferramentas que podem nos ajudar: reprodução e isolamento.
Se seu sistema permitir a capacidade de reprodução daquele cenário, ótimo, utilize-a exaustivamente. Tente reproduzir o máximo possível da condição daquele incidente, suba a aplicação localmente, coloque os mesmos dados de entrada e através dos breakpoints na sua IDE observe passo a passo da aplicação até chegar no erro esperado. Essa é uma técnica muito poderosa, mas que infelizmente muitos programadores não a utilizam frequentemente, seja por não conseguir simular completamente as condições (por questões de uma má arquitetura ou falta de ferramentas) ou por simplesmente desconhecerem sua utilização.
Outra possível técnica é isolar o problema. Comece pensando no seu sistema de fora para dentro. Será que foi alguma integração externa que causou isso? Alguma dependência de outro sistema? Será que foi algum tratamento de dado que falhou, alguma regra não prevista ou entrada de dado não prevista? Será que foi alguma comunicação entre os serviços que falhou? Será que o próprio serviço falhou?
Repare que nessa linha estamos sempre questionando nosso sistema de fora para dentro, avaliando se o ofensor é externo ou se de fato é interno. Se o sistema foi bem testado, a chance de ser um ofensor externo é grande, porém essa etapa também é importante para elucidarmos se o nosso sistema foi bem testado ou não.
Nos momentos em que percebemos que o ofensor é externo, sempre se lembre disso: não busque culpados, busque causas. Não é interessante para você ou para sua empresa que ao localizar que a falha veio por um sistema de outro setor que falhou, saia apontando o dedo em direção ao outro departamento. Não faça isso. Ao contrário, busque mostrar aos seus colegas a causa daquela falha no seu sistema e como eles podem fazer para ajustar. Será uma conversa muito mais proveitosa para ambos.
Correção
A fase final do ciclo na solução de um problema. É quando ao já termos parado o sangramento e investigarmos, procurarmos uma força de corrigir aquele problema já sabendo sua causa raiz, procure solucionar o problema não apenas para “tapar o buraco”, mas sim para entender como melhorar o código ou como evitar que isso ocorra novamente.
Após feito, teste o sistema exaustivamente, afinal nem você nem seus clientes querem que isso volte a ocorrer, implemente a correção e não esqueça de documentar o que foi feito. Assim você ou outros colegas no futuro saberão o que causou e como foi resolvido, se um problema similar aparecer, já terão um bom norte.
Conclusão
Resolver problemas não é fácil, mas é uma habilidade crucial de todo engenheiro. Se você se vê como um engenheiro de software ou deseja se tornar, talvez essa seja a melhor aptidão para masterizar. A linguagem X ou Y, os detalhes da tecnologia e arquiteturais, tudo isso é importante, mas tudo isso são ferramentas, e se você não souber qual é o problema a ser resolvido, de nada adianta ter o melhor martelo. Não adianta ter as melhores tintas e pincéis, se você sequer tem ideia do que quer pintar.
Inclusive, se você já pensou um pouco sobre o problema do excesso de engenharia (overengineering) dê uma lida neste artigo.
Oldest comments (4)
Muito bom! Uma coisa que eu acrescentaria no seu texto: nem sempre a pessoa jr vai conseguir resolver o problema e é uma prática comum alguem mais experiente entregar o problema pra pessoa jr começar a navegar por ele. Não esperamos que o problema seja resolvido, só esperamos que a pessoa descarte possibilidades, por exemplo. Assim, ela pode aplicar resolução de problemas e entregar algo como:
testei essa, essa e essa hipotese. Essa e essa eu acredito que nao seja por este e este motivo. Essa outra hipotese eu não consegui ter certeza mas consegui desenvolver o problema até aqui.
Com certeza, troubleshooting é uma habilidade essencial, mas que se for só "jogada" para algum dev, pode mais causar traumas do que felicidades, concordo 100% !
Muito interessante, Bruno!
O legal é que você dá uma metodologia para o trouble shooting: estancar a sangria, investigar, corrigir a causa raiz e documentar num post-mortem.
Costumo a pensar na etapa de investigação como se fosse o método científico. Olha para o sistema como um todo e pro defeito em específico. Aí, a partir disso, levantamos hipóteses, fazemos experimentos com as ferramentas que temos disponível (logs, traces, reprodução com debugging, etc), aprendemos, levantamos novas hipóteses. Ficamos nesse ciclo até isolar o erro.
Acho que não concordo com considerar a investigação do externo para o interno. Na minha experiência e no tipo de sistema que mexo, é bem mais provável que o erro seja causado pelo próprio time. Mas entendo que depende do contexto.
Mas obrigado pelo excelente texto!
Quanto à investigação, com certeza somos muito inclinados a pensar no método científico, de certa forma é um pensamento que temos muito enquanto engenheiros, isolar e testar, descartar hipótese, voltar e testar e por aí vai.
Sobre a investigação externa para a interna, muitas vezes somos pegos por aquele erro "besta" mesmo que esquecemos de validar. Mas acho que olhar de forma externa para a interna ajuda a elucidar melhor as vezes, entretanto todo software deveria ao mínimo passar por uma bateria de testes intensa para validarmos as fragilidades do nosso programa.
Eu que agradeço pela leitura e pelo comentário, uma honra !!