Observabilidade como cultura, não ferramenta

Observabilidade não é instalar o Datadog. É mudar como o time pensa sobre produção.

Essa distinção, defendida consistentemente por Charity Majors, cofundadora da Honeycomb, resume bem por que tantas empresas investem em ferramentas de monitoramento e ainda assim ficam acordadas às 3h tentando entender o que aconteceu. A ferramenta sem a cultura é só um painel a mais que ninguém sabe interpretar.

O que diferencia observabilidade de monitoramento?

Monitoramento parte de perguntas conhecidas. Você configura alertas para as métricas que já sabe que importam: CPU acima de 80%, latência acima de 500ms, taxa de erro acima de 1%. O sistema vigia o que você decidiu vigiar.

Observabilidade parte de um princípio diferente: você não sabe todas as perguntas que vai precisar fazer. O objetivo é que o sistema exponha dados ricos o suficiente para que, diante de um comportamento inesperado, você consiga formular uma nova hipótese e testá-la em tempo real, sem precisar de um novo deploy ou de logs adicionais.

Majors descreve essa diferença como a transição de vigiar a saúde do sistema agregado para entender a experiência de cada evento individual: cada requisição, cada carrinho de compras, cada usuário específico. Não “a API está lenta”, mas “por que esses 0,3% de usuários da região Nordeste têm p99 três vezes maior desde o deploy das 14h?”

Essa pergunta só é respondível com alta cardinalidade e rastreabilidade por evento. Ela também exige que o engineer que fez aquele deploy esteja interessado em respondê-la.

Por que o problema é cultural antes de ser técnico?

Times bem instrumentados com OpenTelemetry e com dashboards lindos ainda falham quando ninguém tem o hábito de olhar para esses dados com curiosidade antes de um incidente. A instrumentação resolve a camada técnica. A cultura resolve a camada humana.

Dois sinais de que a cultura ainda não chegou:

Ownership fragmentado. O engineer sobe o código, passa para QA, e considera o trabalho encerrado. Se algo quebra em produção, o problema “é de ops”. A lógica “you build it, you run it”, popularizada pela Amazon em meados dos anos 2000, inverte esse fluxo: quem escreve o código mantém responsabilidade pelo seu comportamento em produção. Isso não é punição, é informação. Ninguém entende melhor os trade-offs de uma feature do que quem a construiu.

On-call sem rotatividade ou contexto. Quando só um ou dois engineers cobrem plantão por tempo indeterminado, o conhecimento sobre o que está em produção fica concentrado, o burnout aumenta, e os demais perdem o senso de urgência. Dados de 2024 mostram que 83% dos profissionais de DevOps relatam burnout, com o on-call citado como principal fator. On-call rotativo, com handoff documentado e escalação clara, distribui tanto a carga quanto o aprendizado.

Como times maduros tratam incidentes?

A diferença entre um time que apaga fogo e um time que aprende com incidentes está no que acontece depois que o sistema volta ao normal.

Times que apenas apagam o fogo fecham o ticket, marcam como resolvido e seguem em frente. Times que aprendem conduzem um post-mortem, e o fazem de forma estruturada e sem culpa.

O conceito de blameless post-mortem vem da cultura SRE do Google: o objetivo não é encontrar quem errou, mas entender o conjunto de condições que tornaram o erro possível. A premissa é que engenheiros competentes cometem erros em sistemas complexos. Punir a pessoa não remove a condição sistêmica que permitiu o erro.

Um post-mortem bem conduzido responde: o que aconteceu? Qual foi o impacto? Qual foi a linha do tempo? O que contribuiu para o problema? O que funcionou bem durante a resposta? O que pode ser melhorado?

Times com cultura de segurança psicológica são 64% mais propensos a reportar quase-falhas, o que significa que problemas são identificados antes de virarem incidentes maiores. A cultura blameless cria esse ambiente.

Que métricas devem estar nos dashboards?

Um sintoma comum de observabilidade imatura é o dashboard cheio de métricas de infraestrutura e vazio de métricas de negócio.

Saber que o uso de CPU está em 40% não responde se os usuários estão conseguindo completar o fluxo de pagamento. Métricas de negócio nos dashboards de engenharia, taxa de conversão, pedidos por minuto, tempo até o primeiro resultado, criam um elo direto entre o que o time monitora e o que o produto entrega.

A prática recomendada é definir SLIs (Service Level Indicators) alinhados com o que o usuário final percebe, e SLOs (Service Level Objectives) como limites acordados de degradação aceitável. O relatório de observabilidade de 2025 da Grafana Labs aponta que times ainda lutam para definir SLIs e SLOs relevantes mesmo quando a instrumentação técnica já está em lugar. A dificuldade não é medir, é saber o que mede.

Uma forma de começar: para cada feature nova, o time define qual métrica de negócio indica que ela está funcionando. Essa métrica entra no dashboard antes do deploy, não depois de um incidente.

O que uma cultura de observabilidade parece na prática?

Não há uma lista universal, mas alguns padrões aparecem em times que avançaram nessa direção:

• Engineers revisam métricas de produção da própria feature nos dias após o deploy, não como obrigação, mas como parte do fluxo normal de trabalho.
• Post-mortems são documentados e acessíveis a todo o time de engenharia, não apenas aos envolvidos no incidente.
• Alertas são revisados periodicamente para eliminar os que ninguém age quando disparam (alert fatigue é um sinal de que o sistema de monitoramento perdeu confiabilidade).
• Há uma distinção clara entre “o serviço está no ar” e “o serviço está funcionando para os usuários”, e o time monitora os dois.

A adoção de padrões como OpenTelemetry ajuda a garantir portabilidade da instrumentação entre ferramentas, mas o passo mais difícil continua sendo cultural: criar o hábito de questionar o sistema em produção antes que ele quebre.

Vale observar que ferramentas, custos de infraestrutura e escolhas de plataforma fazem parte de um conjunto maior de decisões que envolvem escala. Esse lado técnico-econômico está coberto no post DevOps, observabilidade e custos: o tripé da escala.

O que permanece específico da cultura de observabilidade é mais simples de enunciar e mais difícil de praticar: tratar produção como um ambiente a ser compreendido continuamente, não como um destino onde o código chega e desaparece.