O usuário encontrou um erro. Você vai descobrir?

Existe uma situação desconfortável em qualquer produto digital:

o usuário pode descobrir que alguma coisa está quebrada antes de você.

Ele abre uma página.

Tenta concluir uma ação.

Nada acontece.

Tenta novamente.

Atualiza.

Desiste.

Do lado do sistema, talvez tenha ocorrido uma exceção.

Do lado do usuário, aconteceu algo muito mais simples:

o produto não funcionou.

E existe uma diferença importante entre um sistema que apresenta erros e um sistema em que os erros acontecem sem que ninguém perceba.

O primeiro é inevitável.

O segundo é uma escolha de operação.

Erros não desaparecem quando o código chega em produção

Durante o desenvolvimento, falhas costumam ser relativamente visíveis.

Alguma coisa quebra e o console mostra.

Uma requisição retorna erro.

Um componente não renderiza.

Um teste falha.

Estamos próximos do problema e, muitas vezes, conseguimos reproduzi-lo imediatamente.

Produção é diferente.

O ambiente é muito menos previsível.

Existem combinações de dados que nunca apareceram durante o desenvolvimento.

Dispositivos diferentes.

Navegadores diferentes.

Conexões instáveis.

Extensões.

Sessões antigas.

APIs externas.

Estados que surgiram depois de meses de uso.

E usuários seguindo caminhos que ninguém imaginou durante a implementação.

A aplicação pode funcionar perfeitamente para você e falhar todos os dias para uma pequena parcela das pessoas.

Sem algum tipo de monitoramento, talvez você nunca saiba.

“Ninguém reclamou” não significa “está funcionando”

Esse é um dos falsos sinais de segurança mais comuns.

Se ninguém abriu um chamado, talvez esteja tudo certo.

Só que usuários não funcionam como uma equipe de QA.

Boa parte deles não vai reportar um problema.

Alguns vão tentar novamente.

Outros vão procurar outro caminho.

Alguns simplesmente vão embora.

Quanto menor a importância percebida da ação, menor a chance de alguém gastar tempo explicando o que aconteceu.

Imagine uma feature secundária que começou a falhar depois de um deploy.

Ela não derruba a aplicação.

Não impede login.

Não produz uma tela branca.

Apenas falha silenciosamente quando determinada combinação de dados acontece.

Pode permanecer assim por semanas.

Tecnicamente, o produto continua disponível.

Na prática, existe um fluxo quebrado.

Ausência de reclamação não é observabilidade.

É ausência de informação.

Saber que aconteceu é apenas o primeiro passo

Uma ferramenta de error tracking pode mudar bastante essa situação.

Sentry é um exemplo conhecido, mas a ferramenta específica importa menos do que a capacidade que estamos tentando criar.

Queremos saber que alguma coisa falhou.

Quando.

Onde.

Com que frequência.

Em qual versão.

E, principalmente, em qual contexto.

Porque existe pouca utilidade em receber uma mensagem dizendo:

TypeError: Cannot read properties of undefined.

Ótimo.

Existe um erro.

Agora precisamos descobrir todo o resto.

Qual usuário estava envolvido?

Qual página estava aberta?

Que ação aconteceu antes?

Qual dado chegou inesperadamente?

Esse erro apareceu depois de um deploy específico?

Aconteceu uma vez ou quinze mil?

Todos esses detalhes transformam uma exceção técnica em algo que pode ser investigado.

Detectar é importante.

Contextualizar é o que torna a detecção útil.

Nem todo erro tem o mesmo peso

Quando começamos a monitorar uma aplicação, outra coisa acontece.

Descobrimos que ela provavelmente apresenta muito mais erros do que imaginávamos.

Alguns são importantes.

Outros não.

Pode existir uma exceção causada por uma extensão específica do navegador.

Um request cancelado durante navegação.

Uma API externa instável.

Um comportamento que ocorre apenas em uma versão antiga de determinado browser.

E, no meio disso, pode existir uma falha impedindo usuários de concluir uma compra.

Se tudo gera o mesmo alerta, nada realmente gera alerta.

Depois de algum tempo, notificações demais viram ruído.

E ruído é perigoso porque cria hábito.

O alerta chega.

Alguém olha rapidamente.

Parece conhecido.

Segue o dia.

Até que um erro realmente importante entra no mesmo fluxo.

Monitoramento não é apenas capturar falhas.

É conseguir distinguir sinal de ruído.

Prioridade precisa de contexto de produto

Um erro que acontece dez mil vezes parece mais importante do que um erro que acontece cinco.

Mas frequência não é a única medida relevante.

Imagine dois problemas.

O primeiro acontece frequentemente quando alguém abre uma seção pouco utilizada da aplicação. Existe uma falha visual, mas a tarefa ainda pode ser concluída.

O segundo acontece com apenas dez usuários por dia.

Só que impede esses dez usuários de concluir um pagamento.

Qual deveria ser resolvido primeiro?

A resposta dificilmente está apenas na quantidade de eventos.

É preciso entender impacto.

Qual fluxo foi interrompido?

Existe alternativa?

O usuário consegue se recuperar?

Existe perda de dados?

A ação envolve receita?

Segurança?

Confiança?

É por isso que monitoramento técnico funciona melhor quando conectado ao contexto do produto.

O sistema consegue dizer que algo quebrou.

Nós ainda precisamos entender quanto aquilo importa.

O stack trace não conta a história inteira

Quem trabalha com frontend conhece bem esse cenário.

Você recebe um stack trace.

Abre o arquivo.

Encontra a linha.

E o código parece perfeitamente válido.

Porque o problema não estava exatamente naquela linha.

Talvez a API tenha respondido com um estado inesperado.

Talvez uma propriedade tenha desaparecido.

Talvez uma ação anterior tenha deixado o cliente inconsistente.

Talvez o usuário tenha navegado por uma sequência específica que você ainda não conseguiu reproduzir.

O erro mostra onde o sistema falhou.

Nem sempre mostra como chegou até ali.

Por isso, contexto de navegação, breadcrumbs, dados da requisição, versão da aplicação e informações relevantes sobre o estado podem reduzir drasticamente o espaço de investigação.

Existe uma diferença enorme entre:

“alguma coisa deu errado aqui”

e

“isso começou na versão X, afeta usuários com determinada condição e acontece depois desta sequência de ações”.

O segundo cenário ainda exige investigação.

Mas pelo menos sabemos onde começar.

Monitoramento também muda a forma como fazemos deploy

No primeiro artigo desta série, falamos sobre como entrega contínua e monitoramento fazem parte da operação de um produto.

Essas coisas estão mais conectadas do que parecem.

Imagine publicar uma nova versão.

Minutos depois, a quantidade de erros em determinado fluxo aumenta significativamente.

Se conseguimos relacionar os eventos à versão que acabou de entrar, temos uma pista importante.

Talvez seja necessário investigar.

Talvez pausar um rollout.

Talvez reverter uma mudança.

Sem essa visibilidade, o mesmo problema pode continuar em produção até alguém perceber por outro caminho.

Isso muda o significado de deploy.

Publicar não é apenas colocar uma versão no ar.

Também envolve observar o que acontece depois dela.

Uma entrega segura não termina quando o pipeline fica verde.

Bugs silenciosos costumam ser mais perigosos

Algumas falhas são fáceis de perceber.

A aplicação cai.

A página fica branca.

Um erro aparece claramente.

Outras são muito mais sutis.

Um evento deixa de ser enviado.

Uma atualização não persiste.

Uma ação parece concluída, mas não aconteceu.

Um dado aparece desatualizado.

Um botão recebe o clique, mas a requisição não é disparada.

Esses problemas são particularmente complicados porque, em alguns casos, nem mesmo geram uma exceção.

Do ponto de vista do código, nada necessariamente “quebrou”.

O comportamento apenas ficou diferente do esperado.

É aí que error tracking encontra seu limite.

Nem todo problema de produto aparece como erro técnico.

Às vezes precisamos de logs.

Métricas.

Eventos de produto.

Health checks.

Alertas sobre comportamento.

É por isso que observabilidade é maior do que capturar exceptions.

A pergunta real é:

se o sistema começar a se comportar de uma maneira inesperada, teremos evidências suficientes para perceber?

Logs só ajudam quando conseguimos encontrá-los

Logs são uma das ferramentas mais antigas dessa história.

E continuam extremamente úteis.

O problema aparece quando registramos informação sem estrutura.

Centenas de linhas.

Mensagens genéricas.

IDs sem contexto.

Dados espalhados por diferentes serviços.

Quando chega a hora de investigar, existe informação.

Mas não existe clareza.

Um log útil deveria ajudar a reconstruir o que aconteceu.

Não precisa registrar tudo.

Na verdade, registrar tudo pode tornar o problema ainda pior.

O importante é preservar informações que ajudem a conectar eventos.

Qual operação estava acontecendo?

Qual serviço participou?

Qual request iniciou aquilo?

Quanto tempo levou?

Onde falhou?

Existe um identificador que permita acompanhar o fluxo entre diferentes partes do sistema?

Quanto mais distribuída a arquitetura, mais importante fica essa capacidade de conectar pontos.

Porque o problema pode começar em um lugar e aparecer em outro.

Observar também tem custo

Existe uma tentação natural de instrumentar tudo.

Mais logs.

Mais métricas.

Mais traces.

Mais dashboards.

Mais alertas.

Mais retenção de dados.

Só que observabilidade também adiciona complexidade.

Existe custo financeiro.

Custo de armazenamento.

Custo de manutenção.

Custo de atenção.

E, dependendo das informações coletadas, existe também responsabilidade sobre privacidade e segurança.

Não deveríamos enviar indiscriminadamente tudo o que existe no estado da aplicação para uma ferramenta externa apenas porque isso facilita debugging.

Dados pessoais.

Tokens.

Informações sensíveis.

Conteúdo fornecido pelo usuário.

Tudo isso precisa de critério.

Ter contexto suficiente para investigar não significa capturar qualquer coisa.

Monitoramento saudável também exige decidir o que não coletar.

O objetivo não é eliminar todo erro

Talvez esse seja o ponto mais importante.

Nenhum sistema real chega a um estado permanente de ausência de erros.

Quanto mais pessoas utilizam um produto, mais situações inesperadas aparecem.

Quanto mais integrações existem, mais dependências podem falhar.

Quanto mais o produto evolui, mais possibilidades de regressão surgem.

Buscar zero erros como objetivo absoluto pode levar a uma quantidade enorme de esforço em problemas de impacto quase inexistente.

A meta mais útil é outra.

Conseguir perceber problemas relevantes.

Entender seu impacto.

Investigar com contexto.

Responder em um tempo compatível com a importância da falha.

Isso é muito diferente de tentar construir um sistema perfeito.

É construir um sistema que consegue explicar quando deixa de funcionar como deveria.

Observabilidade também é experiência do usuário

É fácil enxergar monitoramento como infraestrutura interna.

Algo para desenvolvedores.

Um dashboard que usuários nunca verão.

Tecnicamente, é verdade.

Mas o impacto chega diretamente na experiência.

Um erro detectado rapidamente afeta menos pessoas.

Uma investigação com contexto reduz o tempo de correção.

Um deploy monitorado permite reagir antes que uma regressão se espalhe.

Uma métrica bem definida pode mostrar que um fluxo importante deixou de funcionar.

O usuário nunca precisa saber que existe um Sentry, um sistema de logs ou um dashboard de métricas por trás do produto.

Ele percebe outra coisa:

o sistema funciona.

E, quando falha, volta a funcionar.

Essa invisibilidade é parte do valor.

Indo além da criação

Quando estamos construindo uma feature, nossa atenção está naturalmente voltada para fazer o caminho funcionar.

Clicamos.

Testamos.

Validamos.

Corrigimos.

Entregamos.

Mas depois que o produto entra em produção, não estaremos presentes em cada sessão.

Não veremos cada erro.

Não saberemos qual fluxo alguém tentou concluir.

Não estaremos ao lado do usuário quando alguma coisa falhar.

Por isso, o sistema precisa conseguir nos contar parte dessa história.

Não para substituir investigação.

Nem para eliminar todos os bugs.

Mas para reduzir a distância entre o momento em que alguma coisa quebra e o momento em que conseguimos entender que existe um problema.

Porque bugs são inevitáveis.

Falhas externas são inevitáveis.

Estados inesperados são inevitáveis.

O que não deveria ser inevitável é descobrir tudo isso apenas quando alguém reclama.