Existe um padrão que se repete em empresas de tecnologia de médio porte: o time cresce, a base de código cresce, os clientes chegam — e cada sprint vira uma combinação de feature nova mais incêndio do que saiu na semana passada. O on-call vira sinônimo de pesadelo, o MTTR cresce junto com o churn, e a sensação de que nunca há tempo para fazer as coisas direito se instala de vez.
Site Reliability Engineering (SRE) é a disciplina que resolve isso. Não com mais ferramentas. Não com mais pessoas de operações. Mas com uma mudança de como o time pensa sobre confiabilidade como produto — e sobre quanto erro é aceitável.
Este guia é para CTOs e Heads de Engenharia que querem implementar SRE de forma pragmática: entendendo os conceitos, sabendo por onde começar e adaptando para a realidade de um time que não é Google.
A síndrome do incêndio crônico tem características bem reconhecíveis. Deploys que causam regressões em produção com frequência. Alertas que disparam fora do horário comercial sem processo claro de resposta. Postmortems que nunca acontecem — ou que viram reunião de culpa. Métricas de disponibilidade que ninguém monitora até o cliente reclamar.
O custo não é só técnico. Times em modo reativo perdem foco, entregam features com mais bugs, e desenvolvem uma cultura de medo de deploy que nega justamente a agilidade que justificou a contratação de todos aqueles engenheiros.
Times Elite vs. times de baixo desempenho: 182× mais deploys por mês · 6.570× MTTR mais rápido · 2.604× lead time de mudança menor · 7× menor taxa de falha em mudanças.
A diferença não é de esforço — é de processo e cultura de confiabilidade.
SRE não elimina incidentes. Incidentes são inevitáveis em sistemas distribuídos. O que SRE faz é criar o framework para que o time saiba como responder, aprenda com o que aconteceu e reduza a frequência e o impacto ao longo do tempo.
SRE foi criado no Google em 2003 por Ben Treynor Sloss. A premissa original era simples: contratar engenheiros de software para fazer o trabalho de operações, com a expectativa de que eles automatizariam qualquer tarefa que se repetisse mais de uma vez por trimestre.
DevOps e SRE se complementam, mas têm focos distintos:
DevOps é uma cultura e conjunto de práticas que busca remover o atrito entre desenvolvimento e operações. Foco em colaboração, CI/CD, entrega contínua.
SRE é uma implementação específica dessa cultura com engenharia de software aplicada a operações. Foco em SLOs, error budgets, e redução de toil. Se DevOps resolve como os times trabalham juntos, SRE define o quão confiável o sistema precisa ser — e quantifica isso.
A diferença que mais importa para um CTO: DevOps melhora a velocidade de entrega, SRE define o contrato de confiabilidade que essa velocidade deve respeitar. Times que praticam ambos — e essa combinação tem nome, se chama Platform Engineering — entregam mais rápido e com menos incidentes simultaneamente.
Um SLI é uma métrica quantitativa de algum aspecto do comportamento do serviço. Latência de resposta, taxa de erros, disponibilidade, taxa de acerto de cache. É o dado bruto. A pergunta que define um bom SLI é: o que o usuário experimenta?
Um SLO é o alvo que você quer atingir para um SLI. "99,9% das requisições em menos de 200ms nos últimos 30 dias." É o contrato interno do time com ele mesmo — não com o cliente. É o SLO que define quando o time tem capacidade de lançar features e quando precisa focar em confiabilidade.
apiVersion: openslo/v1
kind: SLO
metadata:
name: api-availability
displayName: API de Pedidos — Disponibilidade
spec:
service: orders-api
timeWindow:
- duration: 30d
isRolling: true
objectives:
- displayName: Alta disponibilidade
target: 0.999 # 99.9%O SLA é o contrato externo — com o cliente, com o negócio. Geralmente mais tolerante que o SLO interno. Se o SLO é 99,9%, o SLA com o cliente pode ser 99,5%. A diferença é a margem de segurança. Quando o SLO já está violado, o time tem sinal de alerta antes de comprometer o SLA contratual.
O Error Budget é a consequência mais importante do SLO. Se o SLO é 99,9% de disponibilidade em 30 dias, o error budget é 0,1% de "erro permitido" — equivalente a aproximadamente 43 minutos de downtime por mês. Enquanto o error budget tiver saldo, o time tem autonomia para fazer deploys, experimentar e inovar. Quando o budget se esgota, deploys param até o saldo se recuperar.
O error budget transforma a conversa de "dev quer lançar, ops não quer" em "quanto budget temos? Se temos, vamos. Se não temos, não vamos." A decisão vira objetiva, não política. Time de produto e SRE passam a ter o mesmo objetivo: manter o budget saudável.
Toil é trabalho operacional manual, repetitivo, que não escala e que não contribui com valor duradouro. Reiniciar um serviço manualmente toda manhã é toil. Processar tickets de acesso manualmente é toil. A regra do Google SRE: se um engenheiro gasta mais de 50% do tempo em toil, algo está errado. Times com alto toil não evoluem — ficam presos em tarefas que deveriam ser automatizadas.
Implementar SRE não precisa de uma reestruturação organizacional. Os primeiros 30 dias têm um objetivo claro: instrumentar, medir e estabelecer os primeiros SLOs.
Semana 1 — Inventário e instrumentação. Mapeie os serviços críticos (os que o usuário experimenta diretamente). Para cada um: qual é a latência P95 atual? Qual é a taxa de erros HTTP 5xx? O que já está sendo monitorado? O objetivo não é ter um dashboard bonito — é ter dados confiáveis.
Semana 2 — Definição dos primeiros SLOs. Escolha 2–3 serviços e defina SLOs simples. Disponibilidade e latência são os mais naturais para começar. Documente em um arquivo versionado no repositório — não num slide.
Semana 3 — Error Budget e política de deploy. Com SLOs definidos, calcule o error budget atual. Crie uma política simples: com >50% de budget disponível, deploys seguem normalmente. Com <25%, nenhum novo deploy até recuperação.
Semana 4 — Runbook para os 3 alertas mais comuns. Mapeie os 3 alertas que mais acordam o time à noite. Para cada um, escreva um runbook: o que o alerta significa, como verificar a causa, os primeiros passos de mitigação, quando escalar.
groups:
- name: slo-alerts
rules:
- alert: AvailabilitySLOBurn
expr: |
(1 - rate(http_requests_total{status=~"2.."}[1h])
/ rate(http_requests_total[1h])
) > (14.4 * 0.001)
for: 2m
labels:
severity: critical
annotations:
summary: "SLO de disponibilidade queimando rápido"
description: "Error budget esgotará em ~1h. Ação imediata necessária."
- alert: LatencySLOBreach
expr: |
histogram_quantile(0.95,
rate(http_request_duration_seconds_bucket[5m])
) > 0.2 # 200ms
for: 5m
labels:
severity: warning
annotations:
summary: "P95 de latência acima do SLO (200ms)"Post-mortem é a ferramenta mais poderosa de SRE — e a mais mal implementada. O formato típico que não funciona: uma reunião onde todos ficam constrangidos e ninguém escreve o documento. O resultado? Nenhum aprendizado, mesmo incidente dois meses depois.
Post-mortems eficazes têm duas regras inegociáveis: blameless (sem culpar pessoas) e escrito (não pode ser só oral). O foco é sempre no sistema, no processo e na ausência de salvaguardas — não nas ações de um indivíduo.
1. Resumo executivo — o que aconteceu em 2–3 linhas
2. Timeline do incidente — sequência de eventos com timestamps
3. Causa raiz — o "5 porquês" até a causa sistêmica
4. Impacto — usuários afetados, SLO consumido, receita impactada
5. O que funcionou bem — detecção, resposta, comunicação
6. O que não funcionou — gaps de processo ou ferramenta
7. Action items — cada item com dono e data. Se não tem dono, não vai acontecer.
Uma prática que acelera a cultura: tornar os post-mortems públicos dentro da empresa. Quando engenheiros veem que um incidente sério foi tratado sem punição mas com action items claros, a confiança para reportar problemas cresce substancialmente.
As DORA metrics são o framework de referência para medir desempenho de engenharia. Quatro métricas cobrem o que mais importa:
Deployment Frequency — com que frequência o time faz deploy para produção. Elite: múltiplos por dia. Low: menos de 1 por mês.
Lead Time for Changes — tempo entre um commit e o código em produção. Elite: menos de 1 hora. Low: 1–6 meses.
Change Failure Rate — % de deploys que causam degradação. Elite: 0–15%. Low: 46–60%.
MTTR — tempo para restaurar o serviço após incidente. Elite: menos de 1 hora. Low: 1 semana a 1 mês.
MTBF (Mean Time Between Failures) — frequência com que incidentes ocorrem. Quanto maior, melhor. Times com SRE maduro veem MTBF crescer ao longo dos trimestres.
Error Budget Burn Rate — com que velocidade o budget está sendo consumido. Burn rate de 14,4x significa que o budget se esgota em 2 dias — sinal de alerta crítico que exige ação imediata.
O livro do Google SRE pressupõe uma equipe SRE separada do time de produto. Para a maioria dos times de 5 a 40 engenheiros, isso não é realista. O que funciona em times menores:
SRE está funcionando quando as métricas são discutidas naturalmente no planning, quando o error budget é parte da decisão de priorização e quando ninguém acorda com medo do on-call.
Implementar SRE é um processo de meses, não de semanas. A dificuldade não está nos conceitos — está em adaptar o framework para a realidade do time, escolher as métricas certas para o estágio atual e criar a cultura de blameless que transforma post-mortems em aprendizado real.
A FuncCloud trabalha com times de produto que querem deixar o modo reativo para trás. O diagnóstico começa com uma conversa: quais são seus SLOs hoje? Com que frequência vocês fazem post-mortems? Qual é o MTTR médio dos últimos 6 incidentes? As respostas já indicam onde estão os maiores ganhos.
Fale com a FuncCloud sobre diagnóstico de maturidade de SRE e implementação prática para o seu time.
Falar com a FuncCloud →