Desenvolvimento, Dicas

Informações sobre erros são suas amigas — então trate bem delas

A verdade inconveniente: programas falham.

Claro que bom planejamento, revisão e teste reduzem a quantidade e gravidade dessas falhas. Mas ainda assim: programas falham.

E quando isso acontece, no mundo selvagem que é o ambiente de produção, nas condições de falha que nunca se pensou a respeito, como fazemos para saber os detalhes que levaram a falha?

A resposta é: usamos boas práticas de logging e de tratamento de erros. E hoje falaremos sobre tratamento de erros, numa lista de DO’s (faça) e DON’Ts (não faça).

  • DO: planeje, desde o início, uma estratégia de logging;
  • DON’T: não exagere na estratégia — ter informação demais nos logs é quase tão ruim quanto não ter;
  • DO: trabalhe com um nível configurável de logging. Ex.: no início dos testes, coloque tudo no log (Verbose mode): erros, avisos, rastreio. Quando atingir produção, grave apenas informações de erro. Torne isso uma configuração simples da aplicação (a maior parte dos frameworks de logging considera isso);
  • DON’T: evite logar como erro coisas que fazem parte de um fluxo normal. Ex: o usuário entrou dados errados na tela de cadastro? Valide e trate ao invés de deixar um erro estourar;
  • DO: pense numa política de retenção de logs. Por exemplo: se em arquivo, estabeleça um tamanho máximo e a partir dele passe a truncar as entradas mais antigas;
  • DON’T: não perca informação relevante ao logar. Logar algo como “ocorreu um erro” é o equivalente a chegar no médico dizendo “doutor, estou me sentindo mal” e só com isso esperar um diagnóstico completo. Coloque nos logs toda a informação de contexto disponível: em que ponto do código ocorreu o erro? Em que processo de negócio houve o problema? Que usuário foi impactado? Quais os IDs dos objetos envolvidos nos erros?
  • DO: grave seu log no ponto mais “próximo” e robusto disponível. Logar no banco, por exemplo, pode não funcionar justamente nos casos de problemas de comunicação entre o servidor de aplicação e o de banco;
  • DON’T: não permita que erros ao logar impactem o funcionamento da aplicação. Uma falha ao gravar em log (com exceção de auditoria, mas isso é uma questão à parte) não deveria impedir a transação na qual o log falhou. Tentou gravar no Event Viewer e por algum motivo deu pau? A operação sendo monitorada funcionou mesmo assim? Deixa rolar — pior do que não ter informações sobre uma falha, é não ter informações sobre uma situação normal E ainda gerar uma falha por isso;
  • DO: considere monitorar (automaticamente) os seus logs. Falhas críticas lançadas em logs podem ser detectadas por monitores e alertar rapidamente a equipe de suporte;
  • DON’T: evite mostrar informações de troubleshooting (ex.: call stack) para o usuário da aplicação. Isso pode representar uma vulnerabilidade de segurança e não vai ajudar em nada (a não ser que o usuário seja um desenvolvedor da aplicação);
  • DO: pense em estratégias para manter o log “ao alcance” da mão. Por exemplo, logs em arquivo podem dar muito trabalho para se obter, já que eles normalmente se encontram numa pasta de acesso restrito nos servidores. Se for trabalhar com arquivos, por exemplo, considere o uso de um share ou de replicação de arquivo para fácil acesso por parte da equipe de suporte;

 

A lista acima claramente não está completa — prova é que mexi nela diversas vezes deste a primeira “postagem candidata”. E vários desses itens merecem maior detalhamento. Quem sabe falamos a respeito em outro post…

 

Padrão

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s