Análise de Incidentes: O Que Aconteceu e Como Descobrir
A maioria dos times de infraestrutura ou desenvolvimento passa por pelo menos um incidente crítico por mês. O problema não é o incidente em si, mas sim a forma como a informação é coletada depois. Eu vi equipes perderem horas tentando reconstruir uma timeline a partir de screenshots de chats, logs fragmentados e memórias conflitantes. O que acontece na prática é que a verdade se perde nos primeiros minutos após o evento.
Por onde começar quando surge o que aconteceu
O primeiro passo é sempre travar o estado. Se você está lidando com um sistema produtivo que ainda está em colapso, não reinicie serviços, não apague logs, não faça rollback às cegas. Anote os IDs dos containers, os nomes dos hosts, os timestamps exatos de cada ação que alguém executar a partir daquele momento. A diferença entre uma investigação rápida e uma que dura dias costuma estar nos primeiros cinco minutos de contenção. No meu caso, tivemos um incidente em que o serviço de autenticação parou de responder durante um horário de pico. O time de suporte já estava aplicando workarounds manuais enquanto o time de engenharia tentava entender a causa raiz. O que aconteceu naquela noite foi uma cascata de timeouts no banco de dados que disparou um efeito dominó. A causa inicial foi uma query mal otimizada que passou por code review porque o índice necessário tinha sido removido em uma migração três semanas antes. Demoramos doze horas para fechar o relatório porque não tínhamos centralizado os logs de acesso do banco na mesma janela temporal dos logs da aplicação.
A solução que funcionou foi criar um pipeline simples que agrega timestamps de todas as camadas — CDN, load balancer, aplicação, banco de dados — num único fluxo com fuso horário unificado. Hoje, qualquer investigação do tipo o que aconteceu leva de quarenta minutos a duas horas, dependendo da complexidade do problema.
Coleta de evidências: o que realmente importa
Lembre-se de que nem tudo que aparece nos dashboards é útil. Métricas agregadas disfarçam padrões importantes. Um p99 de latência estável pode esconder um subgroup de requisições com comportamento totalmente anômalo. Quando investigo algo, começo sempre pelos percentis mais altos e pela taxa de erro por rota, não pela média geral. Métricas de média são as que mais enganam em incidentes reais. Os logs também precisam ser capturados com estrutura. Log de texto solto sem campos padronizados é um pesadelo deTRIAGEM. Eu prefiro estruturas JSON com campos fixos: timestamp, nível, trace_id, service_name, user_id, operation. Com trace_id consistente entre todos os serviços, você consegue reconstruir o caminho completo de uma requisição mesmo em arquiteturas microsserviçadas. Sem isso, você gasta tempo correlacionando eventos manualmente e acaba fazendo suposições.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que poucas equipes consideram é a coleta de estado do sistema. Memória, connections abertas, threads ativas, filas de mensagens pendentes. Durante um incidente, esses dados mudam rapidamente. Se você não tiver snapshots periódicos — a cada trinta segundos, por exemplo —, terá apenas informações pós-correção, que já são inúteis para entender a progressão do problema. Ferramentas como Prometheus com retenção configurada para pelo menos quarenta e oito horas resolvem isso de forma prática.
A linha do tempo: onde a maioria erra
Construir uma linha do tempo precisa exige disciplina. O formato que eu uso funciona bem: uma tabela com colunas de timestamp, evento, fonte dos dados, impacto estimado e ação tomada. Cada linha deve ter referência cruzada aos logs ou métricas correspondentes. Sem referências cruzadas, a timeline vira narrativa, não documento técnico. O erro mais comum é confundir correlação com causalidade. Dois eventos acontecendo juntos não significam que um causou o outro. Durante um incidente, é tentador apontar o primeiro sintoma visível como causa raiz. Na prática, o sintoma costuma ser consequência de algo que aconteceu minutos ou até horas antes, em outra camada do sistema. A causalidade real muitas vezes fica enterrada em logs de rotas secundárias ou em mudanças de configuração que ninguém registrou.
Ferramentas que realmente funcionam
Não existe ferramenta única que resolva tudo. O stack que eu recomendo depende do porte do sistema, mas o essencial é ter integração entre coleta, agregação e consulta. Prometheus para métricas, Loki ou ELK para logs, e Jaeger ou OpenTelemetry para tracing. Se você tiver orçamento limitado, o trio Prometheus + Loki + Grafana cobre a maior parte dos casos com custo próximo de zero em infraestrutura própria. Para download e instalação, o repositório oficial do Prometheus fica em github.com/prometheus/prometheus, o Loki em github.com/grafana/loki e o OpenTelemetry em github.com/open-telemetry/opentelemetry.io. Todas seguem o padrão de deployment via docker compose para ambientes de desenvolvimento e Kubernetes manifests para produção. A configuração inicial leva cerca de uma hora para cada componente, mas o retorno vem na primeira investigação real.
Limitações que ninguém discute
Coletar dados completos tem um custo que muitos subestimam. Armazenar logs brutos de tráfego alto gera despesas significativas de disco e banda. Métricas de alta cardinalidade — como trace_id por usuário final — podem transformar um dashboard simples em um problema de performance. O ideal é definir políticas de retenção claras desde o início e fazer agregação em camadas: dados brutos por setenta e dois horas, dados agregados por trinta dias, relatórios finais por um ano. Outra limitação séria é a dependência de instrumentação. Se um serviço não exporta métricas ou logs estruturados, você fica cego em relação a essa parte do sistema. Isso é especialmente crítico em microsserviços desenvolvidos por times diferentes, onde o padrão de logging varia de um time para outro. A solução prática é exigir um contrato mínimo de observabilidade como condição para deploy, não como sugestão. Sem isso, a investigação do que aconteceu depende de sorte.
Por fim, vale mencionar que nenhuma ferramenta substitui a prática de postmortem. O documento que resume o incidente, as ações corretivas e os indicadores para evitar recorrência é tão importante quanto a coleta de dados em si. Equipes que tratam postmortem como burocracia perdem o aprendizado acumulado. Equipes que revisam esses documentos mensalmente reduzem o MTTR em média em sessenta por cento ao longo do segundo ano de adoção.
