SRE na prática: softwares, métricas e dashboards para confiabilidade mensurável

SRE (Site Reliability Engineering) é o modelo de gestão técnica que trata confiabilidade como produto — com metas explícitas, métricas orientadas ao usuário e rotinas operacionais repetíveis. A confiabilidade deixou de ser um problema de infraestrutura e virou parte direta do valor entregue. O desafio mais comum não é falta de monitoramento, mas excesso de sinal ruim: alertas demais, dashboards bonitos e pouca decisão concreta.

Pense na sua operação como um cockpit. Ele não existe para ter gráficos, mas para permitir decisões rápidas sob pressão. O cenário mais comum é um pico de tráfego que pressiona latência e capacidade. Sem SLOs claros e sinais certos, sua equipe dirige no escuro. Este artigo organiza um stack de softwares, um conjunto de métricas e um modelo de dashboard para tornar SRE executável.

O que muda quando você trata confiabilidade como produto

SRE não é um cargo, nem apenas um time. O ponto de virada é trocar metas vagas como "99,9% de uptime" por metas verificáveis via SLIs e SLOs, com impacto direto em priorização.

O vocabulário mínimo:

• SLI (Service Level Indicator): o que você mede. Exemplo: porcentagem de requisições HTTP abaixo de 300 ms.
• SLO (Service Level Objective): o alvo. Exemplo: 99% das requisições abaixo de 300 ms no mês.
• SLA (Service Level Agreement): contrato externo, geralmente com penalidade financeira.

Uma referência clássica para esse modelo é o livro do Google sobre Site Reliability Engineering. A sacada operacional é o error budget: se você está dentro do SLO, você ganha orçamento para mudança — lançar, refatorar, experimentar. Se você estoura o SLO, você paga com foco em estabilidade.

Regra de decisão aplicável amanhã:

• Se o serviço consumiu mais de 50% do error budget até a metade do ciclo (dia 15 de 30), congele mudanças de risco alto e priorize correções.
• Se o error budget está saudável, aumente a cadência de deploy — mas só se testes e rollback forem automáticos.

No cockpit da operação, confiabilidade vira um número que o time de produto entende. Em vez de "o sistema está instável", você passa a dizer "nosso SLO de latência está 0,3% abaixo do alvo e isso ameaça conversão no checkout". Essa ponte é o que torna SRE útil fora da engenharia.

Como montar um stack de SRE sem virar colcha de retalhos

O stack de SRE precisa cobrir quatro funções sem sobreposição confusa: instrumentação, observabilidade, resposta a incidentes e automação. O erro comum é escolher ferramentas por hype e depois tentar colar processos.

Uma arquitetura prática começa pela instrumentação padronizada com OpenTelemetry. Isso reduz lock-in e dá consistência a métricas, logs e traces. A partir daí, você escolhe o caminho: open-source com mais engenharia interna ou SaaS com mais velocidade.

Stack open-source, custo-eficiente e escalável:

• Métricas com Prometheus
• Visualização com Grafana
• IaC com Terraform

Stack comercial para visibilidade rápida e times grandes:

• Observabilidade full-stack com Datadog
• APM e automação orientada por IA com Dynatrace

Resposta a incidentes (independente do stack):

• On-call, escalonamento e roteamento com PagerDuty

Antes de contratar ou padronizar qualquer ferramenta, passe por esta matriz de decisão:

• Tempo até valor: você precisa reduzir incidentes este trimestre ou construir base para o próximo ano?
• Integrações críticas: Kubernetes, cloud, banco, fila, CDN, pagamentos.
• Modelo de custo: por host, por ingestão, por usuário, por evento.
• Capacidade de correlação: a ferramenta conecta sintoma (latência) a causa (deploy, saturação, dependência)?

Cada ferramenta do cockpit deve alimentar o mesmo objetivo: reduzir tempo de detecção e tempo de recuperação, com metas mensuráveis. Se o stack produz mais alertas do que decisões, ele está mal desenhado.

Métricas de SRE que viram decisão: SLIs, SLOs e Golden Signals

Métricas de SRE não são todas as métricas disponíveis. São as métricas que mudam prioridade, reduzem risco e melhoram experiência. Um caminho seguro é começar pelos Golden Signals: latência, tráfego, erros e saturação.

Workflow de definição de SLIs e SLOs em 60 minutos:

1. Liste as 3 jornadas que pagam a conta (login, busca, checkout).
2. Para cada jornada, defina um SLI de experiência.
3. Só depois, defina SLIs técnicos de suporte (CPU, pool de conexões, fila).

Exemplos prontos para copiar e adaptar:

API de checkout:

• SLI de latência: p95 < 300 ms
• SLI de erros: taxa 5xx < 0,1%
• SLO mensal: 99% das requisições p95 abaixo de 300 ms

Front-end:

• SLI de experiência: LCP p75 < 2,5 s
• SLI de erros: taxa de falhas JS < 1%

Para operacionalizar, implemente queries e alertas com PromQL no Prometheus e organize as visões no Grafana. O objetivo não é ter um alerta por métrica, mas um alerta por risco real de violar SLO.

Regra de decisão para alertas (evita fadiga):

• Alertas de página (page) só para sintomas que ameaçam SLO em minutos.
• Alertas de ticket para degradações que podem esperar o horário comercial.
• Qualquer alerta sem ação clara vira candidato a remoção ou reclassificação.

Quando o cockpit usa SLIs e SLOs, dados e insights deixam de ser relatório e viram comando. Você cria um loop: observar, decidir, agir, revisar. Sem isso, SRE vira apenas mais monitoramento.

Dashboard, relatórios e KPIs: como transformar dados em decisões

Um dashboard de SRE falha quando é genérico. Um bom cockpit precisa de camadas: visão executiva, visão de operação e visão de diagnóstico. Cada camada responde perguntas diferentes, com menos gráficos e mais decisões.

Modelo de dashboard em 3 níveis:

• Nível 1 (Executivo): SLO atingido? Error budget saudável? Top 3 serviços em risco.
• Nível 2 (Operação): Golden Signals por serviço, com comparação semana a semana.
• Nível 3 (Diagnóstico): traces, logs correlacionados, dependências e mudanças recentes.

No Grafana você estrutura pastas por domínio (checkout, catálogo, auth) e padroniza painéis. Em ambientes mais complexos, o Datadog ajuda na correlação de métricas, logs e traces em uma única interface.

KPIs que valem o esforço:

• SLO compliance por serviço (mensal e por release)
• MTTR — tempo médio de recuperação
• MTTD — tempo médio de detecção
• Taxa de rollback e tempo até rollback
• Toil — percentual do tempo em trabalho repetitivo

Ritual de relatório que funciona:

• Semanal: 30 minutos, focado em serviços que consumiram mais error budget.
• Mensal: revisão de SLOs e ajuste de metas com produto.
• Pós-incidente: relatório curto com causa, impacto e ações preventivas.

Relatórios existem para mudar comportamento. Se ninguém decide nada depois do relatório, o cockpit está exibindo instrumentos, mas ninguém está pilotando.

Runbooks, automação e resposta a incidentes: o workflow que reduz toil

SRE vira realidade quando incidentes deixam de ser improviso. O objetivo é reduzir toil e variabilidade, padronizando triagem, escalonamento e correção.

Workflow operacional de incidentes:

1. Detectar: alerta baseado em SLO, não em CPU isolada.
2. Triar: classificar severidade e impacto em jornadas.
3. Mitigar: rollback, feature flag, rate limit, escala.
4. Comunicar: status page e updates em intervalos fixos.
5. Aprender: postmortem sem culpados, com ações rastreáveis.

O PagerDuty roteiriza escalonamentos, deduplica alertas e registra timeline. A automação de infraestrutura com Terraform reduz correção manual e acelera recuperação.

Exemplo de impacto com runbooks estruturados:

• Antes: incidentes recorrentes com MTTR de 90 minutos, correção manual e pouca padronização.
• Depois: runbook com rollback automatizado e alerta por SLO, MTTR cai para 35 a 45 minutos.

Regra de decisão para runbooks:

• Se uma ação foi executada manualmente 2 vezes em incidentes similares, ela vira passo automatizado.
• Se a automação puder causar dano, inclua guardrails: aprovação, limite, simulação.

No cockpit, incidentes deixam de ser pânico e viram sequência conhecida. Você troca heroísmo por previsibilidade, e previsibilidade é o que sustenta crescimento.

Plano de implementação de SRE em 90 dias

Implementar SRE não exige reestruturar a empresa. Exige escolher poucos serviços críticos, definir SLOs e instalar um cockpit que permita tomada de decisão. Um plano de 90 dias reduz risco e cria prova interna.

Dias 0 a 30 — Fundação:

• Padronize instrumentação com OpenTelemetry.
• Escolha 3 serviços críticos e defina 1 SLI e 1 SLO por serviço.
• Crie um dashboard Nível 1 e Nível 2 no Grafana.

Dias 31 a 60 — Operação:

• Configure on-call, escalonamento e severidades.
• Reduza alertas até sobrar somente o que ameaça SLO.
• Comece postmortems consistentes e um backlog de ações preventivas.

Dias 61 a 90 — Otimização:

• Automatize os 3 runbooks mais usados.
• Ajuste SLOs com base em dados e capacidade real.
• Faça revisão mensal com produto e engenharia usando error budget.

Para benchmark externo e tendências, vale acompanhar o SRE Report 2025 da Catchpoint, que traz sinais sobre prioridades, instrumentação e maturidade de times.

Critério de sucesso:

• Você consegue explicar, em 2 minutos, se a experiência do usuário está dentro do esperado.
• Você consegue provar redução de MTTR, queda de incidentes repetidos ou redução de toil.
• Seu time decide com base em SLO, não em opinião.

Quando o cockpit está certo, o pico de tráfego deixa de ser um evento de sobrevivência e vira teste controlado de engenharia.

SRE como rotina: próximos passos concretos

SRE funciona quando vira rotina: metas claras com SLOs, métricas que representam experiência real e um cockpit com sinais acionáveis. O stack de softwares importa, mas só gera valor quando está alinhado a decisões, alertas bem classificados e workflows de incidentes repetíveis.

O próximo passo direto: escolha uma jornada crítica, defina um SLI de experiência e implemente um dashboard em três níveis. Conecte alertas a SLOs e padronize o processo de incidentes. Em 90 dias, você terá dados suficientes para provar impacto, priorizar automação e transformar confiabilidade em vantagem competitiva.