Trazendo observabilidade de erros para um time que não tinha nenhuma

na Dynamox

Dei a um time que não tinha nenhum monitoramento de erros uma prática estruturada de observabilidade construída a partir de um reporter compartilhado e um interceptor de API com tagging em tempo de requisição mais dashboards e um fluxo de triagem, transformando bugs de produção de algo reportado pelo suporte em algo que o time pode ver e priorizar.

impactoO time passou de nenhum monitoramento de erros para uma prática estruturada de observabilidade, capaz de responder "qual serviço ou funcionalidade está falhando mais?" e de revisar issues abertas por prioridade.Bugs de produção se tornaram visíveis proativamente em vez de chegar só pelo suporte.Erros são atribuíveis a funcionalidade e endpoint, graças ao tagging de contexto em tempo de requisição, e a configuração é a base para alertas pós-deploy.Qualitativo: detecção mais rápida de problemas de produção; nenhum número rígido de tempo médio de detecção foi capturado.

Contexto

Esta é evidência de que identifico e fecho lacunas que ninguém me atribuiu, a mesma iniciativa que definiu meu crescimento mais inicial, agora aplicada em escala de time. Ninguém pediu observabilidade. Percebi que éramos o único time voando às cegas e defendi a correção disso.

Isso também mostra pensamento de sistemas de frontend. O núcleo da solução é uma camada de instrumentação compartilhada e reutilizável com um design deliberado de tagging em vez de um espalhamento de logs de erro pontuais, mais o senso de produto para construir dashboards em torno de como o time realmente faz triagem.

Problema

O frontend era uma base de código compartilhada dividida entre as áreas de vários times. Toda área de outro time tinha monitoramento de erros; a minha não tinha nenhum. A consequência era concreta: ficávamos sabendo de bugs de produção quando um ticket de suporte chegava, não quando o erro acontecia. Não tínhamos como ver quais partes da nossa área estavam falhando, com que frequência, ou se um release tinha piorado as coisas, então a triagem era reativa e anedótica.

Restrições

—Ninguém era dono do problema. Era uma lacuna estrutural, não um ticket. Alguém tinha que percebê-la e decidir que valia a pena resolver.

—Atribuição de erro é a parte difícil. Capturar erros é fácil. Fazer cada erro carregar contexto suficiente para dizer *qual funcionalidade e qual chamada de API* o produziu, preservando a rota que de fato falhou, é onde o design mora.

—Instrumentação precisa ser compartilhada, não espalhada. Logging de erro ad-hoc por dezenas de rotas teria produzido ruído. O valor está em uma camada única e consistente e reutilizável.

—Observabilidade só é útil se conduz a ação. Um dashboard que ninguém faz triagem não muda nada, então a prática precisava incluir um fluxo de trabalho.

Decisão

Tratei isso como introduzir uma prática, não instalar uma ferramenta.

—Diagnostiquei e defendi a causa. Identifiquei que nossa área era a única sem monitoramento e propus a iniciativa a partir do meu próprio diagnóstico.

—Construí um reporter de erros compartilhado conectado aos fluxos assíncronos críticos, para que erros fossem capturados de forma consistente em vez de por tela.

—Adicionei um interceptor de API compartilhado que marca em tempo de requisição. Cada erro carrega tags de contexto para time, funcionalidade, e o serviço e endpoint de API específicos. Eu os capturei no momento da requisição para que a tag reflita a rota que de fato falhou, em vez de qualquer contexto que existisse quando o erro surgiu. Fiz isso de forma aditiva para que nunca sobrescrevesse tags existentes.

—Construí dashboards com limiares, organizados em torno de como o time realmente os usaria, e mapeei as rotas da nossa área para filtros para que erros pudessem ser fatiados por funcionalidade.

—Defini o fluxo de triagem, ou seja, como um erro se torna um ticket rastreado, para que o monitoramento se transforme em ação, e estabeleci a base para alertas pós-deploy.

Trade-offs

—Marcar em tempo de requisição em vez de marcar na resposta/erro. Capturar contexto quando a requisição é feita preserva o endpoint que de fato falhou para atribuição correta; lê-lo depois às vezes atribuiria o erro errado. Custo aceito: um pouco mais de cuidado no interceptor.

—Uma camada de instrumentação compartilhada em vez de logging de erro por tela. Um reporter e interceptor únicos e reutilizáveis são mais design antecipado do que blocos `catch` espalhados, mas blocos espalhados não teriam produzido nada sobre o qual um time pudesse agir.

—Tagging aditivo em vez de sobrescrever. Nunca atropelar tags existentes mantém intacto o outro contexto da base de código compartilhada, ao custo de ser disciplinada sobre como as tags são definidas.

—Dashboards por persona de uso em vez de um padrão genérico. Construir views em torno de como o time faz triagem exige mais reflexão do que um dashboard pronto, mas então os dados respondem às perguntas que as pessoas realmente fazem.

Impacto

—O time passou de nenhum monitoramento de erros para uma prática estruturada de observabilidade, capaz de responder "qual serviço ou funcionalidade está falhando mais?" e de revisar issues abertas por prioridade.

—Bugs de produção se tornaram visíveis proativamente em vez de chegar só pelo suporte.

—Erros são atribuíveis a funcionalidade e endpoint, graças ao tagging de contexto em tempo de requisição, e a configuração é a base para alertas pós-deploy.

—Qualitativo: detecção mais rápida de problemas de produção; nenhum número rígido de tempo médio de detecção foi capturado.

Lições Aprendidas

Conhecimento de engenharia reutilizável que levo adiante disso:

—Ninguém consegue priorizar um bug que não consegue ver. Observabilidade vem antes do trabalho de confiabilidade, não depois.

—Atribua erros onde o contexto é verdadeiro. Marque no ponto (tempo de requisição) que preserva o que de fato falhou, ou seus dashboards vão te enganar.

—Instrumente uma vez, de forma compartilhada. Um reporter e interceptor reutilizáveis vencem logging espalhado, porque consistência é o que transforma dado de erro em algo acionável.

—Observabilidade precisa de um fluxo de trabalho. Sem um caminho de triagem do erro ao ticket, o dado nunca vira uma correção.

—Perceber uma lacuna não atribuída é parte do trabalho. O diagnóstico valeu tanto quanto o código que veio depois.

Evidência

—Propus e liderei a iniciativa a partir do meu próprio diagnóstico (nossa área era a única sem monitoramento).

—Construí um reporter compartilhado e um interceptor de API com tagging em tempo de requisição, dashboards com limiares, e um fluxo de triagem de erro-para-ticket.

—Verificado contra o tracker (2026-05 a 2026-06): um épico que abri em 2026-05-25 e decompus em cinco tarefas: o reporter compartilhado conectado às sagas do time (fechado 2026-05-27), o dashboard do time (2026-06-18), tags de contexto nas páginas críticas (2026-06-22), cobertura automática via um interceptor de cliente HTTP, e identificação de usuário mais rastreamento de release.

—Verificado honestamente como inacabado: duas das cinco tarefas continuam abertas. Rastreamento de release nunca começou, e a tarefa de cobertura do interceptor permanece no backlog mesmo que o interceptor em si tenha ido para produção (um pull request de 27 comentários, mesclado em 2026-06-08). A prática é real e em uso; não está completa.

—Fonte (privada): épico do Jira no domínio de inspeção, 2026-05 a 2026-06; base de conhecimento de carreira consolidada.