Publicado originalmente em maturitylab.com. Este texto integra a trilha Maturidade.
Um modelo de maturidade em observabilidade descreve, em níveis, como uma organização evolui na capacidade de entender o comportamento dos próprios sistemas em produção: do alerta disparado pelo cliente que reclama até a investigação de falhas novas com dados coletados de forma planejada. O modelo serve para dois fins. Primeiro, mostra o nível atual com base em evidência. Segundo, indica as práticas que faltam para o próximo degrau. Este artigo apresenta os conceitos de referência, uma escala de níveis, os sinais de cada nível e um passo a passo para a avaliação.
Monitoramento e observabilidade não são a mesma coisa
O programa de pesquisa DORA, que estuda o desempenho de equipes de tecnologia, separa os dois conceitos. Monitoramento é a ferramenta que permite à equipe acompanhar e entender o estado dos sistemas a partir de condições definidas antes. Observabilidade é a ferramenta que permite depurar o sistema de forma ativa, explorando propriedades e padrões que não foram definidos antes (dora.dev).
A diferença decide o nível de maturidade. Monitoramento responde a perguntas conhecidas: o servidor está no ar, a fila passou do limite. Observabilidade responde a perguntas que ninguém previu: por que um grupo específico de clientes teve lentidão ontem às 15h.
O projeto OpenTelemetry, mantido pela Cloud Native Computing Foundation, descreve a mesma ideia: observabilidade permite entender um sistema de fora, fazendo perguntas sem conhecer o funcionamento interno. Para isso, a aplicação precisa estar instrumentada e emitir sinais como rastreamentos, métricas e registros (opentelemetry.io).
Os níveis de um modelo de maturidade em observabilidade
Não existe norma internacional única para maturidade em observabilidade. Os modelos publicados por fornecedores e comunidades usam escalas próprias. A escala abaixo é uma síntese do Maturity Lab, construída sobre os conceitos do DORA, do OpenTelemetry e do livro de engenharia de confiabilidade do Google. Ela segue a lógica de degraus usada nos modelos de maturidade em gestão.
| Nível | Nome | O que caracteriza o nível |
|---|---|---|
| 1 | Reativo | A falha é descoberta pelo usuário; cada equipe consulta registros no servidor quando algo quebra |
| 2 | Monitorado | Painéis e alertas para condições conhecidas, como disponibilidade e uso de recursos |
| 3 | Instrumentado | Rastreamentos, métricas e registros padronizados e correlacionados entre os serviços |
| 4 | Orientado a objetivos | Indicadores e objetivos de nível de serviço definidos com o negócio e usados para priorizar |
| 5 | Observável | A equipe investiga falhas novas sem nova instrumentação e usa o aprendizado para prevenir incidentes |
Cada nível pressupõe o anterior. Uma organização não define objetivos de nível de serviço confiáveis se ainda não coleta os dados de forma padronizada entre os serviços.
Você sabia? O livro de engenharia de confiabilidade do Google define os quatro sinais de ouro do monitoramento: latência, tráfego, erros e saturação. O mesmo capítulo recomenda que todo alerta enviado a uma pessoa exija ação (sre.google).
Sinais que indicam o nível atual
Alguns sinais observáveis já indicam o nível provável antes de qualquer questionário:
- Sinais de nível 1: o primeiro aviso de incidente chega pelo suporte ou pelo cliente; não existe painel compartilhado; a investigação depende de acesso direto ao servidor.
- Sinais de nível 2: existem painéis e alertas, mas cada equipe usa uma ferramenta; a equipe recebe alertas que não exigem ação e passa a ignorá-los.
- Sinais de nível 3: os serviços emitem dados no mesmo padrão; uma requisição pode ser seguida de ponta a ponta; a correlação entre registro, métrica e rastreamento leva minutos, não horas.
- Sinais de nível 4 e 5: cada serviço crítico tem indicador e objetivo de nível de serviço acordados com a área de negócio; o consumo da margem de erro define a prioridade entre correção e funcionalidade nova; a análise pós-incidente gera mudança registrada.
A compra de uma ferramenta não define o nível. Uma plataforma completa, sem padrão de instrumentação e sem dono dos alertas, mantém a organização no nível 2. O DORA lista como armadilha concentrar o monitoramento em uma única pessoa ou em uma equipe dedicada que responde sozinha pelo sistema (dora.dev).
Como avaliar a maturidade em observabilidade
A avaliação transforma a percepção das equipes em nota por dimensão e em plano de ação.
Na prática: 6 passos para a avaliação
- Definir o escopo. Escolher os serviços críticos para o negócio. Avaliar todos os sistemas na primeira rodada produz uma média sem utilidade.
- Definir as dimensões. Usar dimensões como instrumentação, coleta e armazenamento, alertas e resposta a incidentes, objetivos de nível de serviço, cultura e responsabilidades, e uso dos dados na decisão.
- Coletar respostas de papéis diferentes. Desenvolvimento, operação, suporte e gestão de produto respondem ao mesmo questionário. A divergência entre papéis é um achado.
- Exigir evidência. Toda resposta positiva aponta um painel, um alerta configurado, um relatório pós-incidente ou um objetivo documentado. Sem evidência, a prática conta como não implantada.
- Calcular a nota por dimensão. O nível global é limitado pela dimensão mais fraca. Instrumentação avançada sem dono dos alertas não sustenta o nível 3.
- Montar o plano do próximo nível. Selecionar de três a cinco práticas do degrau seguinte, com responsável e prazo, e repetir a avaliação depois que as práticas estiverem em uso.
Erros comuns na evolução da observabilidade
O primeiro erro é tratar observabilidade como projeto de ferramenta. A ferramenta coleta dados; o nível depende de quem usa os dados, com que pergunta e com que decisão.
O segundo erro é medir tudo. Excesso de alertas gera fadiga, e a equipe deixa de reagir ao alerta que importa. O critério do livro de engenharia de confiabilidade do Google ajuda: alerta que não exige ação humana não deve acordar ninguém.
O terceiro erro é avaliar a observabilidade isolada da gestão. Objetivo de nível de serviço depende de prioridade definida pela direção, e a análise pós-incidente depende de cultura sem busca de culpados. O mesmo raciocínio aparece no modelo de maturidade de testes: quando a avaliação técnica aponta lacunas de prioridade e de responsabilidade, um diagnóstico de maturidade empresarial ajuda a localizar a origem.
Perguntas frequentes
Observabilidade substitui o monitoramento?
Não. O monitoramento continua necessário para condições conhecidas, como disponibilidade e capacidade. A observabilidade amplia a capacidade da equipe de investigar falhas que ninguém previu.
É preciso usar OpenTelemetry para chegar ao nível 3?
Não. O nível 3 exige instrumentação padronizada e correlacionada entre os serviços. O OpenTelemetry é um padrão aberto que facilita esse requisito, mas a avaliação verifica a prática, não a marca da ferramenta.
Equipes pequenas precisam de modelo de maturidade em observabilidade?
Sim, em escala menor. Uma equipe pequena pode começar pelos quatro sinais de ouro nos serviços críticos e por uma regra simples de alertas acionáveis. O modelo indica a ordem das práticas e evita investimento em ferramenta antes da hora.
