O desafio
O problema central não era falta de monitoramento. Era fragmentação de leitura.
A área de tecnologia já tinha visibilidade sobre erros de infraestrutura por meio de ferramentas como Dynatrace, incluindo respostas 4xx e 5xx. Mas esses sinais estavam desconectados da experiência do usuário final. A operação sabia que havia falhas no ambiente, mas não conseguia responder com precisão quem havia sido impactado, em qual ponto da jornada e com qual consequência sobre a conversão de operações.
Esse ponto cego criava um efeito direto sobre continuidade e performance. O indicador de disponibilidade do app operava consistentemente abaixo da meta crítica de 99,5%, enquanto a taxa de abandono de transações seguia acima da média esperada. Sem uma correlação entre erro técnico e comportamento do cliente, incidentes levavam mais tempo para serem entendidos, priorizados e resolvidos.
A consequência era um MTTR inflado por falta de contexto. As squads recebiam alertas, mas sem clareza suficiente sobre a dimensão do impacto e sem definição objetiva de ownership. Isso aumentava o tempo gasto em triagem, dificultava o encaminhamento correto e mantinha a operação mais próxima da especulação do que da decisão baseada em evidência.
Na prática, a operação não enfrentava apenas um problema de aplicativo instável. Enfrentava uma falha de governança técnica que impedia transformar sinais operacionais em ação rápida sobre receita, experiência e continuidade digital.
A solução
A resposta não foi adicionar mais alertas. Foi construir contexto.
A MATH desenhou uma arquitetura de observabilidade unificada para conectar três camadas que antes operavam de forma separada: infraestrutura, experiência digital e impacto de negócio. O objetivo era sair da leitura isolada de logs para uma visão aplicável da jornada, capaz de mostrar onde o erro acontecia, quantos usuários eram afetados e qual squad precisava atuar.
A base dessa arquitetura foi o cruzamento de streams distintos de dados no BigQuery. De um lado, entravam os logs de infraestrutura capturados pelo Dynatrace. De outro, os eventos de frontend e client-side vindos de Firebase, Crashlytics e GA4. A terceira camada reunia os dados do core banking, permitindo associar falhas técnicas a operações financeiras concretas.
O diferencial do projeto esteve na engenharia de correlação. Com tagueamento unificado e leitura integrada dos eventos, passou a ser possível rastrear o passo exato do cliente antes da falha. Isso eliminou a ambiguidade entre um erro de sistema e um comportamento de abandono não relacionado ao ambiente técnico. A operação deixou de inferir impacto e passou a medi-lo.
A segunda frente foi a governança de resposta. Dentro da ferramenta de visualização, cada API, erro e fluxo passou a ter ownership claro por squad e célula responsável. Quando um incidente surgia, o sistema não apenas mostrava a falha. Ele indicava quem deveria agir, com base na origem do problema e no impacto observado na jornada.
A terceira frente foi a aceleração técnica da implantação. A MATH aportou expertise em Google Cloud e dados para estruturar o Crashlytics de forma mais padronizada, saneando mensagens de erro, organizando a taxonomia dos eventos e criando um legado de monitoramento mais limpo, comparável e acionável.
O ganho da solução veio da correlação entre erro, jornada e negócio. Observabilidade deixou de ser leitura de sistema e passou a ser ferramenta de decisão operacional.
Os resultados
Os efeitos do projeto apareceram em disponibilidade, receita e eficiência operacional.
Na disponibilidade, a operação recuperou 1,68% no trimestre subsequente à implantação. Esse avanço foi suficiente para fechar o ano dentro da meta crítica de 99,5%, um indicador com peso direto sobre continuidade digital e qualidade percebida pelo cliente.
Na camada de negócio, houve aumento de 13,1% na finalização de transações financeiras. Esse número mostra que o projeto não atuou apenas sobre monitoramento técnico. Ele melhorou jornadas críticas o bastante para reduzir abandono e permitir que mais clientes concluíssem suas operações.
Na eficiência operacional, a priorização baseada em usuários afetados e impacto real substituiu a lógica de resposta centrada apenas em alertas técnicos. Com isso, o tempo médio de reparo foi reduzido e as equipes deixaram de dispersar esforço em ocorrências com baixo efeito prático. A atuação passou a ser mais cirúrgica, conectada ao ponto exato em que valor estava sendo perdido.
Na governança, a definição de ownership por API e squad criou um fluxo mais claro de responsabilização e resposta. Isso reduziu ambiguidade, acelerou o direcionamento de incidentes e tornou a observabilidade um mecanismo mais útil para coordenação entre times.
Mais do que melhorar a leitura de erros, o projeto reorganizou a forma como a operação interpreta impacto. Ao conectar infraestrutura, frontend e negócio, a equipe passou a atuar com mais clareza sobre o que precisava ser corrigido primeiro.
