Por onde começar?

É comum ainda encontrar cenários em que equipes focam exclusivamente em análises técnicas, enquanto a jornada até perguntas estratégicas ainda é longa. Questões como impacto no negócio, experiência do usuário e correlação com receita muitas vezes ficam em segundo plano.

Como correlacionar latência com perda de receita? Por que o tempo do produto deveria ser importado com seus dashboards?
Neste artigo posso te ajudar a fazer e responder essas perguntas.

Passos iniciais

Passo 01

Para iniciar a jornada, é preciso levantar os problemas conhecidos e mapear o parque de equipamentos e aplicativos, incluindo linguagens, dependências e integrações existentes.

Passo 02

Fazer o uso da técnica dos 5 porquês para mapear os processos de monitoramento e seu impacto, permitindo entender e desenhar a regra de negócio que guiará alertas e dashboards.

Exemplo prático — aplicando os 5 porquês

1. Por que o sistema de autenticação está lento e falhando?
“Porque o servidor responsável pela autenticação está sobrecarregado e não responde a todas as requisições dentro do tempo esperado.”
2. Por que o servidor está sobrecarregado?
“Porque há um aumento inesperado no número de requisições simultâneas, acima da capacidade do servidor atual.”
3. Por que houve esse aumento inesperado nas requisições?
“Porque foi lançada uma nova funcionalidade que exige autenticação mais frequente, e a equipe de infraestrutura não ajustou a capacidade para esse aumento.”
4. Por que a equipe de infraestrutura não ajustou a capacidade do servidor?
“Porque não houve comunicação clara entre o time de desenvolvimento e o time de infraestrutura sobre o impacto da nova funcionalidade.”
5. Por que não houve essa comunicação clara?
“Porque não existe um processo formal para planejamento conjunto entre desenvolvimento e infraestrutura em lançamentos que impactem recursos críticos.”

Da análise à prática

Somente após esse mapeamento é que se inicia o hands-on para a decisão de ferramentas e o levantamento das pilhas de monitoramento e observabilidade (caso ainda não existam).

Impacto do problema

A lentidão e as falhas no sistema de autenticação prejudicam a experiência do usuário, causando perda de clientes e, consequentemente, redução na receita.

Regras de negócio

Monitore a latência e as taxas de erros do serviço de autenticação para garantir que o tempo de resposta esteja dentro do limite de 200 ms e as taxas de falhas abaixo de 1%, especialmente após o lançamento de novas funcionalidades.

Sugestão de alertas

Alerta 01: Latência média do serviço de autenticação acima de 200 ms por mais de 5 minutos.

Alerta 02: Taxa de erros no serviço de autenticação acima de 1% em 5 minutos consecutivos.

Alerta 03: Aumento súbito no volume de requisições (+30% em 10 minutos) sem ajuste na capacidade.

Sugestão de painel

  • Gráfico de latência média do serviço de autenticação ao longo do tempo
  • Monitoramento da taxa de erros em percentual
  • Volume de requisições por minuto
  • Indicadores de capacidade do servidor (CPU, memória, conexões ativas)
  • Eventos recentes, como lançamentos de funcionalidades e mudanças na infraestrutura

Tudo é processo: foco no impacto e na regra de negócio

O ponto crucial consiste em identificar requisitos que permitam compreender o impacto daquela métrica no problema e refletir sobre a próxima questão: como evitar que esse problema, que causa indisponibilidade e prejuízos, volte a ocorrer?

Obs

Por isso, o caminho sempre é:

Obs

Métrica técnica → Regra de negócio → Impacto, dashboard e alerta!

Caso 01: Recursos ( FinOps ama! )

Obs

Caso 02: Datas comemorativas

Obs

Ao abordar a visualização de dados, destaco sempre a importância de estruturar a forma de ações proativas, garantindo que uma equipe responsável pela análise das métricas compreenda claramente seu significado dentro do contexto de sua atuação.

Você sabia que existem documentos explicando a funcionalidade de cada parte de um dashboard para que todos aprendam o processo?

A visão operacional deve ser simples, utilizando núcleos, informações intuitivas e fontes de fácil leitura, de modo a facilitar o trabalho diário do suporte técnico. Por outro lado, a visão gerencial deve possibilitar a análise da métrica ao longo do tempo, associando seus componentes e correlacionando-os com indicadores financeiros, como o faturamento.

Aqui está uma visão de equipe operacional e gerencial.

Obs

Nesse processo, os conceitos apresentados no livro de Engenharia de Confiabilidade do Google são amplamente utilizados e práticos para realizar uma análise proativa, evoluindo gradualmente para a visualização dos dados.

USE x RED x 4 Sinais DE OURO: Você sabe qual usar para responder sua pergunta?

Entre esses conceitos, destacam-se os modelos USE e RED, que frequentemente aparecem no escopo das interferências. Apesar das siglas semelhantes, eles possuem focos distintos em sua aplicação.

Obs

O USE é composto por Utilização, Saturação e Erros. Esses indicadores aparecem no escopo da solicitação e têm seu foco em recursos (hardware e infraestrutura), sendo utilizados para identificar gargalos.

Exemplo: Uso de CPU, Fila de processos, Erro de leitura no disco.

Já o RED composto por Taxa, Erros e Duração também aparece no escopo, mas são voltados para serviços e APIs para garantir a qualidade do serviço.

Exemplo: Requisições HTTP, Requisições retorando HTTP 5xx, latência média p99 de 1,2 segundos.

Os 4 sinais de ouro são vistos na saída da solicitação.

Obs

Indicadores fundamentais

  • Latência: Tempo de resposta para atender a uma requisição.
  • Erros: Taxa de falhas ou respostas inválidas nas requisições.
  • Tráfego: Volume de requisições recebidas ou dados processados.
  • Saturação: Nível de utilização dos recursos, afetando o impacto próximo do sistema está de sua capacidade máxima.

Ao partir de análises técnicas e de direção estruturadas, como os 5 motivos, conseguimos não apenas detectar falhas, mas entender seu impacto real e construir regras de negócios eficazes para alertas e visualizações.

Compreender frameworks como USE, RED e os Quatro Sinais de Ouro permite que equipes técnicas e de produto falem a mesma língua: a do impacto no cliente e no faturamento. Isso transforma painéis em ferramentas de decisão, não apenas em painéis de monitoramento.

O caminho que propus — da identificação dos problemas, passando pela demonstração com o negócio, até a criação de alertas e dashboards direcionados — é uma prática base para sair da observabilidade puramente técnica e caminhar rumo à observabilidade orientada ao valor.

Agora que você viu exemplos, frameworks e boas práticas, fica o convite: revise seus indicadores atuais.

Eles estão ajudando você a responder às perguntas certas?