Dia comum de trabalho. O sistema apresenta uma falha crítica. O time todo corre para ver o log e, nesse momento, descobre que ele possui muitas informações desnecessárias, o que dificulta chegar ao ponto que realmente falhou. Em alguns casos, o log tem poucas informações, o que força o Dev e/ou QA a debugarem o sistema, recriando as mesmas condições em que o erro ocorreu para tentar identificar a causa da falha. Em situações ainda piores, não há disparo de log nesse ponto do sistema. Quem nunca passou por algo semelhante?
Poucas vezes, nas fases de arquitetura, code review e validação, logs são tratados como pontos críticos. Deveriam ser. Log é como seguro de casa: você só dá importância no momento da catástrofe. Na minha experiência de mais de 20 anos de estrada, raramente vi times tratando esse tema da forma como deveria ser tratado.
Na minha visão de QA, analisar logs muitas vezes é se sentir o Indiana Jones — fazer trabalho de arqueologia. Na maioria das vezes, eles não são estruturados e, muito menos, objetivos. É uma tarefa desgastante: mensagens pouco claras, stacktraces confusos, informações desnecessárias ou ausentes. Perde-se muito tempo em algo que deveria ser rápido. Isso impacta diretamente no tempo de resposta ao cliente, no planejamento e na entrega da correção. Por isso, muitas vezes o QA se sente desencorajado a executar essa tarefa.
Normalmente há falta de padronização de logs nas empresas. Cada produto adota seu próprio padrão de estrutura, nomenclatura, conteúdo e ofuscamento de informações. Soma-se a isso a falta de experiência — ou até mesmo de conhecimento técnico — de muitos Devs para utilizar corretamente esses padrões e, principalmente, para saber onde, no código, a captura de logs deve ser feita.
Agora imagine todo esse cenário em um software crítico para uma empresa. Por exemplo, um microsserviço de um marketplace responsável por débito em cartões de crédito fora do ar em plena Black Friday. Qual seria o tempo de resposta do time? Qual seria a confiança de que estão analisando o ponto correto que causou a falha?
Log deveria começar a ser pensado na arquitetura, ser lapidado no desenvolvimento e, além disso, deveria ser critério de qualidade para barrar no Code Review e também nos testes.
Um bom log deve responder, no mínimo, a estas perguntas:
1- O que aconteceu?
2- Onde aconteceu?
3- Com qual contexto (qual entidade foi afetada)?
4- Qual foi o resultado (sucesso, falha, fallback)?
5- Qual foi o impacto no sistema ou no negócio?
6- Por que aconteceu (quando possível identificar)?
7- O que o sistema fez após isso (retry, fallback, abortou)?
8- Como eu rastreio esse evento (traceId, correlationId)?
9- Isso é um comportamento esperado ou anormal?
Log não é debug.
Log é evidência operacional.
E evidência ruim leva a decisões erradas.
Top comments (0)