Você já ouviu falar de Site Reliability Engineering (SRE) e pensou: “Isso é coisa do Google. Nós somos uma empresa de médio porte, não temos time dedicado, não temos orçamento para isso.” Essa percepção é comum, mas equivocada.
A verdade é que os princípios de SRE podem – e devem – ser aplicados em empresas de qualquer tamanho. Você não precisa de uma equipe separada de SRE para começar a pensar em confiabilidade. Precisa, sim, de uma mudança de mentalidade: tratar a confiabilidade como uma disciplina de engenharia, não como um subproduto do acaso.
Neste post, vamos desmistificar o SRE, apresentar os conceitos essenciais (SLIs, SLOs, Error Budget, toil reduction, post-mortems sem culpa) e mostrar como começar pequeno, com métricas simples, sem sobrecarregar seu time.
O que é SRE (e o que não é)
Site Reliability Engineering é uma disciplina que aplica princípios de engenharia de software à gestão de operações de TI. Foi popularizada pelo Google (que tem um livro famoso sobre o tema), mas hoje é praticada por empresas de todos os portes.
O que SRE NÃO é
| Mito | Realidade |
|---|---|
| “SRE é só para Google e Netflix” | Princípios funcionam em qualquer escala |
| “SRE é um time separado de operações” | Começa como um conjunto de práticas, não um cargo |
| “SRE significa 99,999% de disponibilidade” | Confiabilidade deve ser um trade-off consciente |
| “SRE é caro” | Muitas práticas custam só tempo de reflexão |
O que SRE realmente é
- Uma forma de medir confiabilidade de forma objetiva
- Um mecanismo para equilibrar velocidade de entrega com estabilidade
- Um processo de aprendizado contínuo com incidentes
- Uma maneira de reduzir trabalho manual repetitivo (toil)
Os conceitos fundamentais do SRE
Conceito 1: SLI (Service Level Indicator)
SLI é uma métrica quantitativa que mede algum aspecto da confiabilidade do serviço.
Exemplos de SLIs:
| Serviço | SLI | O que mede |
|---|---|---|
| API de pagamentos | Latência (p99) | Tempo de resposta do 1% mais lento |
| API de catálogo | Taxa de sucesso | % de requisições com status 2xx |
| Fila de mensagens | Taxa de entrega | % de mensagens entregues sem retry |
| Worker de processamento | Taxa de falha | % de tarefas que falharam após 3 tentativas |
Regras para bons SLIs:
- Devem ser mensuráveis automaticamente
- Devem refletir a experiência real do usuário (não métricas internas irrelevantes)
- Devem ser agregáveis (percentis, médias, contagens)
Conceito 2: SLO (Service Level Objective)
SLO é a meta para um SLI. É o valor alvo que você promete internamente (ou para seus clientes).
Exemplos de SLOs:
| SLI | SLO (meta) | Significado |
|---|---|---|
| Latência p99 da API | < 500ms | 99% das requisições devem responder em até 500ms |
| Taxa de sucesso | > 99,9% | No máximo 0,1% das requisições podem falhar |
| Disponibilidade | > 99,9% | Menos de 43 minutos de downtime por mês |
Como definir SLOs realistas:
- Comece com o que você já tem – meça o desempenho atual por algumas semanas.
- Defina um alvo alcançável – se seu p95 atual é 200ms, não prometa 100ms de imediato.
- Seja mais exigente com o crítico – pagamento merece SLO mais rigoroso que relatório.
- Evolua gradualmente – aperte os SLOs conforme o sistema amadurece.
Conceito 3: SLA (Service Level Agreement)
SLA é o compromisso legal com o cliente. Geralmente tem consequências financeiras se não cumprido (ex: créditos na fatura).
Diferença prática:
- SLO: meta interna que você define para si mesmo. Ex: “99,9% de disponibilidade”
- SLA: promessa contratual ao cliente. Ex: “99,5% de disponibilidade, com crédito de 10% se violado”
Regra de ouro: SLA deve ser menos rigorosa que o SLO. Você não quer violar um SLA porque seu SLO era muito apertado. Ex: SLO = 99,9%, SLA = 99,5%.
Conceito 4: Error Budget (Orçamento de Erros)
O Error Budget é o quanto de “erro” você pode tolerar dentro do seu SLO. É a métrica mais importante para equilibrar inovação e estabilidade.
Fórmula:
text
Error Budget = 100% - SLO
Exemplo: SLO de 99,9% → Error Budget de 0,1% do tempo (ou requisições). Em um mês de 30 dias (2.592.000 segundos), 0,1% equivale a cerca de 43 minutos de downtime ou 2.592 falhas em 1 milhão de requisições.
Como usar o Error Budget na prática:
| Saldo do Error Budget | O que fazer |
|---|---|
| Verde (> 50% disponível) | Liberado para deploys e inovação. Use o orçamento para experimentar. |
| Amarelo (10-50% disponível) | Deploys com cautela. Priorize correções de estabilidade. |
| Vermelho (< 10% disponível) | Congelamento de deploys. Foco total em restaurar confiabilidade. |
Isso tira a subjetividade da decisão: “podemos fazer deploy?” vira uma resposta objetiva baseada em dados.
Conceito 5: Toil (Trabalho Manual Repetitivo)
Toil é o trabalho manual, repetitivo, sem valor estratégico que consome o tempo do time de operações.
Características de toil:
- Manual (exige intervenção humana)
- Repetitivo (mesmo tipo de tarefa várias vezes)
- Sem valor duradouro (resolve o problema de agora, não a causa raiz)
- Escala linear com o crescimento (mais serviço = mais toil)
Exemplos de toil:
- Reiniciar manualmente um serviço que caiu
- Responder o mesmo tipo de alerta falso repetidamente
- Ajustar manualmente configurações de scaling
- Rodar scripts de manutenção sem automação
Meta SRE: Reduzir toil a menos de 50% do tempo do time. Idealmente, abaixo de 25%.
Conceito 6: Post-Mortem sem culpa
Um post-mortem é uma análise documentada de um incidente. A cultura sem culpa é essencial: o objetivo não é achar um culpado, mas entender as causas e evitar recorrência.
Estrutura de um post-mortem (modelo):
# Post-Mortem: [Título do incidente]
**Data:** YYYY-MM-DD
**Duração:** HH:MM
**Impacto:** [clientes afetados, funcionalidades comprometidas]
## Linha do tempo
- HH:MM – Evento inicial
- HH:MM – Alerta disparado
- HH:MM – Time acionado
- HH:MM – Ação de mitigação aplicada
- HH:MM – Serviço restaurado
## Causa raiz
[Descrição técnica da causa]
## Por que não detectamos antes?
[Falhas nos alertas, monitoramento, testes]
## Ações corretivas
- [ ] Curto prazo (dias)
- [ ] Médio prazo (semanas)
- [ ] Longo prazo (meses)
## Lições aprendidas
[O que faremos diferente da próxima vez]Regras do post-mortem sem culpa:
- Não nomear pessoas (a menos que para elogiar)
- Assumir que todos fizeram o melhor com a informação disponível
- Perguntar “o que permitiu que isso acontecesse?” não “quem fez isso?”
- As ações corretivas devem focar em processos e sistemas, não em punições
Como começar com SRE (sem contratar ninguém)
Você não precisa de um time dedicado de SRE. Comece com passos pequenos.
Fase 1 (primeiras 2-4 semanas): Defina seus primeiros SLOs
- Escolha um serviço crítico (ex: API de checkout, login, pagamento)
- Defina 2-3 SLIs simples (latência p95, taxa de erro, disponibilidade)
- Meça o baseline atual (olhe dados existentes de monitoramento)
- Defina um SLO alcançável (ex: 99,5% se você já tem 99,8%)
- Documente em local acessível
Exemplo mínimo:
| Serviço | SLI | Baseline | SLO inicial |
|---|---|---|---|
| API de checkout | Taxa de sucesso | 99,7% | 99,5% |
| API de checkout | Latência p95 | 180ms | 300ms |
Fase 2 (mês 1-2): Implemente monitoramento dos SLOs
- Configure dashboards com os SLIs escolhidos
- Crie alertas quando o SLO estiver ameaçado (ex: error rate > 0,5% em 10 minutos)
- Comece a acompanhar o Error Budget
Ferramentas para começar:
- Prometheus + Grafana (open source, qualquer linguagem)
- Datadog / New Relic / AWS CloudWatch (comerciais, mais simples)
Fase 3 (mês 2-3): Implemente post-mortens para incidentes relevantes
- Todo incidente que violou um SLO ou durou mais que X minutos merece post-mortem.
- Faça reunião de 30-60 minutos com envolvidos.
- Documente causas e ações.
- Divulgue o aprendizado (sem culpa).
Fase 4 (mês 3-6): Reduza toil ativamente
- Liste as tarefas manuais repetitivas que seu time faz.
- Classifique cada uma como “automatizável” ou “não”.
- Para cada tarefa automatizável, estime esforço e priorize.
- Dedique 20% do tempo do sprint para automação de toil.
Fase 5 (mês 6-12): Expanda para mais serviços
- Repita o processo para o segundo serviço crítico.
- Refine seus SLOs com base em aprendizado.
- Considere criar um “capítulo” ou “guilda” de SRE (pessoas interessadas de diferentes times).
SRE adaptado para equipes pequenas
| Prática SRE | Versão para time pequeno |
|---|---|
| Time SRE dedicado | Responsabilidade rotativa de “plantão de confiabilidade” |
| SLOs complexos (ex: por região, por cliente) | Comece com um SLO global simples |
| Error Budget avançado | Use planilha simples para acompanhar |
| Post-mortens formais | Reunião de 30 min, documento de 1 página |
| Toil reduction com meta <15% | Meta inicial <50% |
Ferramentas gratuitas/open source para começar
| Funcionalidade | Ferramenta gratuita | Alternativa paga |
|---|---|---|
| Métricas | Prometheus | Datadog |
| Dashboards | Grafana | Datadog, New Relic |
| Logs | Loki | Datadog, Splunk |
| Tracing | Jaeger | Datadog, Honeycomb |
| Alertas | Alertmanager | PagerDuty (gratuito para poucos contatos) |
| On-call rotativo | Grafana OnCall (gratuito) | Opsgenie, PagerDuty |
Erros comuns ao implementar SRE
| Erro | Consequência | Correção |
|---|---|---|
| Começar com SLOs irrealistas (ex: 99,999%) | Time frustrado, metas nunca atingidas | Comece com baseline + margem realista |
| SLOs complexos demais | Ninguém monitora, orçamento não usado | Máximo 3 SLIs por serviço crítico |
| Não agir quando SLO é violado | Time para de acreditar | Use Error Budget para decisões (deploy freeze, priorizar bugs) |
| Post-mortens que apontam culpados | Time esconde erros | Cultura de “falha é oportunidade de aprendizado” |
| Automatizar toil ruim | Você automatiza processos ruins antes de melhorá-los | Redesenhe processo antes de automatizar |
Caso real: startup de logística adota SRE minimalista
Uma startup de entregas (40 engenheiros, serviço crítico: API de rastreamento) tinha:
- Incidentes frequentes não documentados
- Sem métricas de confiabilidade (“achamos que está bom”)
- Time on-call sobrecarregado (toil excessivo)
Implementação Jacobus (em 3 meses):
- SLOs definidos: Disponibilidade > 99,5%, Latência p95 < 2s
- Dashboard com taxa de erro e latência (Prometheus + Grafana)
- Error Budget tracking semanal (planilha compartilhada)
- Post-mortens para todo incidente > 5 minutos (reunião de 30 min)
- Automação: IaC para criar novos ambientes, bot de Slack para comandos comuns
Resultados após 6 meses:
- Incidentes fatais: redução de 65%
- Tempo médio de recuperação (MTTR): de 45min para 12min
- Toil reduction: de 40% do tempo para 15%
- Time on-call: de 3 pessoas sempre sobrecarregadas para 1 pessoa com rotina de 7 dias
Conclusão
SRE não é um destino – é uma jornada. Você não precisa ser o Google para colher os frutos de SLIs, SLOs, Error Budget, post-mortens e redução de toil. Comece pequeno: um serviço crítico, duas métricas, um SLO realista. A partir daí, evolua.
Na Jacobus Software, aplicamos princípios de SRE em todos os projetos que entregamos – independentemente do tamanho do cliente. O resultado: sistemas mais confiáveis, times menos sobrecarregados e decisões baseadas em dados.
Seu sistema pode ser mais confiável. E o primeiro passo não custa dinheiro – custa apenas uma mudança de mentalidade.
📊 Quer começar sua jornada SRE?
Nossos especialistas ajudam a definir SLOs, implementar monitoramento e estabelecer post-mortens sem culpa – adaptados à sua realidade.