Às 23h47 de uma sexta-feira, o time de atendimento do seu banco começa a receber reclamações. O aplicativo está lento. Transferências estão falhando. Em 13 minutos, o volume de reclamações no Twitter triplicou. Às 00h02, alguém acorda o CTO. Às 00h15, o incidente está oficialmente declarado. O problema? Tinha começado às 22h31.

Quarenta e quatro minutos de clientes insatisfeitos, operações falhando e reputação sendo corroída — tudo porque ninguém sabia que algo havia quebrado até o telefone tocar.

Esse cenário não é hipotético. É o cotidiano de boa parte das empresas de tecnologia no Brasil, inclusive de algumas que você reconheceria pelo nome. A diferença entre as empresas que operam com excelência e as que vivem apagando incêndio não está apenas na qualidade do código. Está na capacidade de saber o que está acontecendo dentro dos sistemas em tempo real — antes que o cliente perceba, antes que o negócio seja impactado, antes que o problema vire crise.

Isso tem um nome: observabilidade.

Monitoramento e observabilidade não são a mesma coisa

Existe uma confusão comum no mercado que precisa ser desfeita antes de qualquer conversa sobre o tema. Monitoramento de sistemas e observabilidade são conceitos relacionados, mas fundamentalmente diferentes.

Monitoramento é reativo por natureza. Você define métricas conhecidas, configura alertas para quando elas saem do normal, e recebe uma notificação quando algo ultrapassa um limiar. CPU acima de 90%? Alerta. Tempo de resposta maior que 2 segundos? Alerta. É útil, mas tem um limite estrutural: você só consegue monitorar o que você já sabe que pode dar errado.

Observabilidade vai além. O termo, emprestado da teoria de controle de sistemas dinâmicos, descreve a capacidade de inferir o estado interno de um sistema a partir de suas saídas externas. Em termos práticos, significa que você consegue fazer perguntas que nunca fez antes sobre o comportamento do seu sistema — e encontrar respostas. Não apenas "o servidor está no ar?", mas "por que os usuários da região Sul estão tendo latência 3x maior apenas nas requisições de checkout entre 19h e 21h?"

Para chegar nesse nível, a observabilidade se apoia em três pilares fundamentais: métricas, logs e rastreamento distribuído (traces). Juntos, eles formam o que a comunidade de SRE chama de os três pilares da observabilidade. Isolados, cada um conta apenas parte da história.

Os três pilares na prática

Entender cada pilar de forma prática é o primeiro passo para construir uma plataforma que se auto-explica.

Métricas são séries temporais de dados numéricos. Taxa de requisições por segundo, percentual de erros, latência no percentil 99, uso de memória. São ideais para dashboards, alertas e análise de tendências. Ferramentas como Prometheus e CloudWatch da AWS são referências nessa categoria. O ponto de atenção: métricas agregam informação. Elas dizem que algo está errado, mas raramente dizem exatamente onde ou por quê.

Logs são registros detalhados de eventos. Cada transação, cada erro, cada decisão que o sistema toma pode ser registrada. São a fonte de verdade para investigações pós-incidente. O problema é o volume: sistemas modernos geram gigabytes de logs por hora, e sem estrutura e ferramentas adequadas, encontrar o log relevante em meio ao ruído é como procurar uma agulha num palheiro em chamas.

Traces distribuídos são o pilar mais poderoso e o menos implementado. Em arquiteturas de microsserviços — que hoje dominam os sistemas financeiros, de e-commerce e de logística no Brasil — uma única requisição do usuário pode atravessar dezenas de serviços diferentes. Um trace acompanha essa requisição do início ao fim, mostrando exatamente onde o tempo foi gasto, onde ocorreram erros e como os serviços interagiram. Ferramentas como Jaeger, Zipkin e o AWS X-Ray são referências aqui.

Quando os três pilares trabalham juntos, com correlação entre eles, você consegue ir de um alerta de degradação de performance diretamente até a linha de código responsável, passando pela sequência exata de chamadas que levou ao problema. Isso transforma uma investigação de horas em minutos.

O custo real da ausência de observabilidade

Em 2023, o custo médio de um downtime para empresas de serviços financeiros ficou em torno de R$ 1,5 milhão por hora, segundo dados do setor. Para empresas de e-commerce em datas como Black Friday, esse número pode ser substancialmente maior. Mas o custo financeiro direto é apenas a superfície.

Existe o custo de engenharia: times de desenvolvimento que passam mais tempo investigando incidentes do que construindo features. Existe o custo regulatório: no Brasil, o Banco Central tem exigências cada vez mais específicas sobre disponibilidade e tempo de recuperação de sistemas financeiros — o BACEN Resolução 4.658 e mais recentemente as diretrizes de resiliência operacional tornam a observabilidade não apenas uma boa prática, mas uma necessidade regulatória. E existe o custo mais difícil de quantificar: a confiança perdida de um cliente que tentou fazer um Pix às 23h e o app travou.

Em projetos que conduzi em instituições financeiras de grande porte, a implementação estruturada de observabilidade reduziu o MTTR (Mean Time to Recovery) — o tempo médio de recuperação após um incidente — em mais de 70%. O que levava 4 horas para ser diagnosticado e corrigido passou a ser resolvido em menos de 45 minutos. Não porque as pessoas ficaram mais inteligentes. Porque finalmente tinham os dados certos, no lugar certo, na hora certa.

Como uma cultura de SRE transforma a observabilidade em vantagem competitiva

Observabilidade não é apenas tecnologia. É uma disciplina operacional, e é aqui que o conceito de SRE — Site Reliability Engineering entra como framework estruturante.

Originado no Google e hoje adotado pelas principais empresas de tecnologia do mundo, o SRE trata a confiabilidade como uma feature de produto, não como uma responsabilidade vaga da infraestrutura. Dentro desse modelo, a observabilidade é o alicerce sobre o qual todas as decisões de confiabilidade são tomadas.

Dois conceitos do SRE são particularmente relevantes aqui:

  • SLIs (Service Level Indicators): as métricas que realmente importam para o usuário — latência, disponibilidade, taxa de erros, throughput.
  • SLOs (Service Level Objectives): as metas que você se compromete a atingir para essas métricas — por exemplo, 99,9% das requisições respondidas em menos de 300ms.

Sem observabilidade, SLIs e SLOs são ficção. Você não tem como saber se está cumprindo seus objetivos se não consegue medir o que está acontecendo. Com observabilidade estruturada, eles se tornam instrumentos de gestão reais: você sabe exatamente onde está sua margem de erro, consegue tomar decisões data-driven sobre onde investir em melhorias, e consegue ter conversas honestas com o negócio sobre o que é tecnicamente viável.

Uma prática que recomendo para times que estão começando essa jornada: antes de implementar qualquer ferramenta, defina os cinco SLIs mais importantes para o seu negócio. Para um banco digital, podem ser: disponibilidade do Pix, latência do login, taxa de sucesso nas transferências, tempo de carregamento do extrato, disponibilidade do suporte via chat. Tudo o mais é secundário até que você consiga medir esses cinco com precisão.

Por onde começar: um roteiro pragmático

A pergunta que mais ouço de CTOs e líderes técnicos quando discutimos observabilidade é: "por onde começo sem paralisar tudo que está em andamento?" A resposta é: comece pelo que dói mais.

Um roteiro pragmático para empresas que estão saindo do zero em observabilidade estruturada:

  • Fase 1 — Instrumentação básica (semanas 1-4): Implemente coleta de métricas de sistema e de aplicação nos serviços mais críticos. Defina seus SLIs. Configure dashboards para os indicadores que o negócio realmente se importa. Ferramentas de entrada: Prometheus + Grafana, ou CloudWatch se você está na AWS.
  • Fase 2 — Gestão de logs (semanas 5-8): Centralize logs em uma plataforma com capacidade de busca e correlação. Estruture os logs dos sistemas principais (JSON estruturado é o mínimo). Defina retenção e políticas de acesso. Opensearch, Datadog ou CloudWatch Logs Insights são boas opções no contexto AWS.
  • Fase 3 — Rastreamento distribuído (semanas 9-16): Instrumente os serviços com tracing. Comece pelos serviços que estão na jornada crítica do usuário. Correlacione traces com logs e métricas. Essa fase é a mais trabalhosa, mas é onde o ROI se torna mais visível.
  • Fase 4 — Alertas inteligentes e resposta a incidentes (contínuo): Construa runbooks baseados nos dados que agora você tem. Configure alertas baseados em SLOs, não apenas em limiares estáticos. Implemente on-call com contexto — quando alguém acorda às 3h, deve receber não apenas o alerta, mas o dashboard relevante e o playbook de resposta.

O erro mais comum que vejo nessa jornada é pular para ferramentas sofisticadas sem ter resolvido o básico. Uma plataforma de APM de última geração não compensa logs não estruturados e ausência de SLOs definidos. Fundação primeiro, sofisticação depois.

Resiliência de plataforma começa com visibilidade

Existe um princípio que guia meu trabalho em resiliência de plataforma: você não pode proteger o que você não consegue enxergar.

Muitas empresas investem pesado em redundância, multi-região, circuit breakers e chaos engineering — e todas essas são práticas legítimas e importantes. Mas nenhuma delas substitui a capacidade de entender o comportamento do sistema em condições reais, com tráfego real, de usuários reais.

A observabilidade é o sistema nervoso da sua plataforma. Sem ela, você está operando no escuro, reagindo a sintomas em vez de tratar causas, gerenciando crises em vez de preveni-las. Com ela, você passa a ter uma conversa contínua com seus sistemas — e os sistemas começam a te dizer o que precisam antes de falhar.

Nos projetos que liderei em empresas como B3, BTG e outros players do mercado financeiro brasileiro, o padrão é consistente: as organizações que investiram em observabilidade estruturada não apenas resolvem incidentes mais rápido. Elas têm menos incidentes. Porque a visibilidade que permite detectar falhas também permite identificar degradações antes que se tornem falhas — e corrigi-las em silêncio, sem que o cliente jamais saiba que havia um problema.

Esse é o objetivo final. Não ser o melhor em gerenciar crises. Ser tão bom em preveni-las que as crises se tornam raras.

A maturidade operacional de uma empresa de tecnologia não se mede pelo que ela faz quando o sistema cai. Se mede pela frequência com que o sistema cai — e essa frequência é, em grande parte, uma consequência direta da sua capacidade de enxergar o que está acontecendo antes que seja tarde demais.

Se você é CTO, CIO ou fundador de uma empresa que ainda opera no modelo "esperamos o cliente reclamar para saber que algo quebrou", esse é o momento de mudar. Não porque é uma boa prática de mercado. Porque a competição está ficando melhor nisso, os clientes estão ficando mais exigentes, e a janela de tolerância para instabilidade está fechando.

Se você quer entender como estruturar observabilidade e resiliência de plataforma de forma pragmática no contexto do seu negócio, fale comigo. Tenho ajudado empresas a transformar operações reativas em plataformas que se auto-monitoram — e os resultados aparecem em semanas, não em anos.