Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
January 22, 2023 09:47 pm GMT

Como realizar um bom troubleshooting ?

Bom, atualmente muito de ns 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 cdigo. Mas, antes dessas perguntas, extremamente necessrio que todo engenheiro treine uma habilidade bsica, inerente a prpria 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 iro simplesmente navegar no mar da dvida sem atacar o problema real. Tal como um mdico que receita remdios 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 no a dor.

Para isso, a mentalidade por trs dessa soluo e investigao deve ser completamente analtica: paramos o sangramento, investigamos e por fim completamos o ciclo corrigindo o problema. Mas para isso, necessrio no s experincia e muitas vezes tcnicas, as quais com o tempo se tornaro naturais no dia a dia. Sobre isso, falarei um pouco mais sobre as tcnicas logo abaixo, onde dividirei esse artigo em cada parte do ciclo de soluo.

Sumrio

1 Parar o sangramento
1 Investigao
1 Correo
1 Concluso

Parar o sangramento

Por mais que seja tentador falar que a correo 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 sada 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 ficaro. Para isso, voc pode utilizar o acrnimo O.Q.C:

  • O que mudou?

  • Quando mudou?

  • Como mudou?

Fazendo essas trs perguntas, voc conseguir ter uma viso mais imediata do que mudou no seu sistema, seja um fator interno ou externo, e assim reverter essa situao ou contorn-la, diminuindo o impacto nos seus clientes.

Logs de aplicao, traces, change orders e documentaes so sempre bem-vindos nessa hora, mas entenda que apenas ter essas informaes no mudar muito, necessrio adicionar na frmula a sua anlise do problema.

Investigao

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 investigao. Nessa etapa, podemos ter algumas ferramentas que podem nos ajudar: reproduo e isolamento.

Se seu sistema permitir a capacidade de reproduo daquele cenrio, timo, utilize-a exaustivamente. Tente reproduzir o mximo possvel da condio daquele incidente, suba a aplicao localmente, coloque os mesmos dados de entrada e atravs dos breakpoints na sua IDE observe passo a passo da aplicao at chegar no erro esperado. Essa uma tcnica muito poderosa, mas que infelizmente muitos programadores no a utilizam frequentemente, seja por no conseguir simular completamente as condies (por questes de uma m arquitetura ou falta de ferramentas) ou por simplesmente desconhecerem sua utilizao.

Outra possvel tcnica isolar o problema. Comece pensando no seu sistema de fora para dentro. Ser que foi alguma integrao externa que causou isso? Alguma dependncia de outro sistema? Ser que foi algum tratamento de dado que falhou, alguma regra no prevista ou entrada de dado no prevista? Ser que foi alguma comunicao entre os servios que falhou? Ser que o prprio servio falhou?

Anlise externa a interna de um sistema

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, porm essa etapa tambm importante para elucidarmos se o nosso sistema foi bem testado ou no.

Nos momentos em que percebemos que o ofensor externo, sempre se lembre disso: no busque culpados, busque causas. No 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 direo ao outro departamento. No faa isso. Ao contrrio, 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.

Correo

A fase final do ciclo na soluo de um problema. quando ao j termos parado o sangramento e investigarmos, procurarmos uma fora de corrigir aquele problema j sabendo sua causa raiz, procure solucionar o problema no apenas para tapar o buraco, mas sim para entender como melhorar o cdigo ou como evitar que isso ocorra novamente.

Aps feito, teste o sistema exaustivamente, afinal nem voc nem seus clientes querem que isso volte a ocorrer, implemente a correo e no esquea de documentar o que foi feito. Assim voc ou outros colegas no futuro sabero o que causou e como foi resolvido, se um problema similar aparecer, j tero um bom norte.

Concluso

Resolver problemas no fcil, 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 aptido para masterizar. A linguagem X ou Y, os detalhes da tecnologia e arquiteturais, tudo isso importante, mas tudo isso so ferramentas, e se voc no souber qual o problema a ser resolvido, de nada adianta ter o melhor martelo. No adianta ter as melhores tintas e pincis, 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.


Original Link: https://dev.to/brunonovais/como-realizar-um-bom-troubleshooting--1h4p

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To