SRE Site Reliability Engineering é a disciplina que trata operações como um problema de engenharia de software. Em vez de contratar mais gente para apertar botões, a ideia é escrever código que resolva a operação. O conceito nasceu no Google, no começo dos anos 2000, quando a empresa percebeu que times de desenvolvimento e infraestrutura viviam em pé de guerra. Uma equipe queria lançar features rápido, a outra queria que nada quebrasse.
A solução foi juntar as duas coisas numa só: engenheiros de software cuidando da confiabilidade dos sistemas. Eles definem metas claras de disponibilidade, automatizam tarefas repetitivas e usam dados para decidir quando é seguro arriscar. Se você quer entender como aplicar isso na sua equipe, sem precisar de um exército de engenheiros, este guia responde as perguntas mais comuns.
O que é SRE e de onde veio?
SRE é uma abordagem de operações de TI que usa engenharia de software para resolver problemas de infraestrutura. O termo foi cunhado por Ben Treynor Sloss, engenheiro do Google, que descreveu a função como "o que acontece quando você pede a um engenheiro de software para projetar uma equipe de operações". A ideia surgiu para acabar com a separação clássica entre desenvolvimento e operações, que gerava atrito e lentidão.
Na prática, um SRE passa boa parte do tempo codando: ferramentas de automação, scripts de monitoramento, sistemas de deploy. O trabalho manual é visto como um problema a ser eliminado. O Google inclusive estabeleceu um limite: nenhum SRE deve gastar mais de 50% do tempo em tarefas operacionais manuais. O resto é projeto e desenvolvimento.
Como o SRE se diferencia do DevOps?
DevOps é uma cultura e um conjunto de práticas para integrar desenvolvimento e operações. SRE é uma implementação específica dessa cultura, com regras e métricas bem definidas. Enquanto DevOps fala em colaboração, SRE traz números: metas de nível de serviço (SLOs), orçamento de erro e automação como prioridade.
Podemos dizer que DevOps é o "o quê" e SRE é o "como". Um time DevOps pode adotar práticas de SRE para medir confiabilidade de forma objetiva. Por exemplo, em vez de discutir se o sistema está "lento", o SRE define que 99,9% das requisições devem responder em menos de 200 milissegundos. A conversa muda de tom.
Quais são os conceitos-chave do SRE?
SLI, SLO e SLA: o que significam?
SLI (Indicador de Nível de Serviço) é a métrica que você escolhe para medir a saúde do serviço. Pode ser latência, taxa de erro, disponibilidade. SLO (Objetivo de Nível de Serviço) é a meta para esse indicador. SLA (Acordo de Nível de Serviço) é o contrato com o cliente, com consequências caso a meta não seja atingida.
A diferença crucial: SLO é interno e serve para guiar decisões. SLA é externo e envolve multas ou compensações. O Google, por exemplo, costuma definir SLOs mais rígidos que os SLAs, para ter margem de manobra. Se o SLO é 99,95% e o SLA é 99,9%, a equipe tem um colchão de 0,05% antes de descumprir o contrato.
O que é error budget?
Error budget é a quantidade de falhas que um serviço pode ter dentro de um período sem violar o SLO. Se o SLO é 99,9% de disponibilidade mensal, o error budget é 0,1%, o que dá cerca de 43 minutos de indisponibilidade por mês. Enquanto o orçamento não estoura, a equipe pode lançar novas features e assumir riscos. Se estoura, o foco volta para estabilidade.
Essa mecânica resolve um impasse comum: dev quer inovar, ops quer estabilidade. Com o error budget, a decisão deixa de ser política e vira matemática. Se ainda tem orçamento, arrisca. Se acabou, segura a onda. É simples e brutalmente eficaz.
Como implementar SRE na sua equipe?
1. Comece medindo o que importa
Antes de definir metas, descubra quais métricas refletem a experiência do usuário. Latência de requisição, taxa de erros 5xx, tempo de resposta do banco. Não precisa ser perfeito. Escolha dois ou três indicadores que doem quando pioram. O Google sugere começar pelo "teste do usuário irritado": se a métrica piorar, o usuário reclama? Se sim, é um bom SLI.
2. Defina SLOs realistas
Não caia na tentação de mirar 100% de disponibilidade. Isso é caro e impossível. Comece com metas modestas, tipo 99,5% para serviços internos e 99,9% para os críticos. Ajuste com o tempo. O importante é ter um número acordado entre todos. Sem SLO, ninguém sabe quando está bom ou ruim.
3. Automatize o que for repetitivo
Toda tarefa manual que se repete vira script. Deploy, rollback, escalonamento, coleta de logs. A meta é reduzir o trabalho operacional a quase zero. No Google, essa é uma regra: se uma tarefa manual consome mais de 5% do tempo de um SRE, ela deve ser automatizada. Na sua equipe, pode começar pelo deploy, que costuma ser o maior ladrão de tempo.
4. Estabeleça um error budget e respeite
Com o SLO definido, calcule o error budget. Comunique a equipe: "temos 43 minutos de falha por mês". Crie um painel visível para todos. Quando o orçamento estourar, acione um congelamento de lançamentos. Isso força a equipe a priorizar estabilidade sem drama. E quando sobrar orçamento, incentive a inovação.
5. Crie uma cultura de postmortem sem culpa
Quando algo quebrar, faça uma análise pós-incidente focada em sistemas, não em pessoas. O objetivo é entender o que falhou e como evitar. O Google chama isso de "postmortem sem culpa". Documente o que aconteceu, o impacto, a causa raiz e as ações corretivas. Compartilhe com toda a equipe. Erros são oportunidades de aprendizado, não de punição.
Quais ferramentas são usadas em SRE?
Não existe um kit oficial, mas algumas ferramentas aparecem com frequência. Prometheus e Grafana para monitoramento e dashboards. Kubernetes para orquestração de contêineres. Terraform para infraestrutura como código. Jenkins ou GitLab CI para automação de deploy. A escolha depende do seu stack. O importante é que as ferramentas permitam medir, automatizar e alertar.
SRE é só para empresas grandes?
Não. Startups e times pequenos também podem adotar princípios de SRE, adaptando à realidade. Você não precisa de um time dedicado. Pode começar com uma pessoa responsável por definir SLOs e automatizar o deploy. O erro budget pode ser uma planilha simples. A cultura de postmortem sem culpa cabe em qualquer equipe. O que não pode faltar é a vontade de tratar operação como engenharia.
Resumo rápido
SRE é aplicar engenharia de software à operação, com metas claras (SLOs), orçamento de erro e automação. Não é uma ferramenta, é uma disciplina. Comece medindo, defina metas realistas, automatize o repetitivo e aprenda com as falhas. Sua equipe não precisa ser do Google para colher os benefícios.
FAQ
O que é SRE em poucas palavras?
SRE (Site Reliability Engineering) é uma abordagem que usa engenharia de software para garantir que sistemas fiquem confiáveis e escaláveis. Em vez de separar desenvolvimento e operações, a mesma equipe cuida de tudo, com automação e métricas.
Qual a diferença entre SRE e DevOps?
DevOps é uma cultura de colaboração entre dev e ops. SRE é uma implementação prática dessa cultura, com regras como SLOs, error budget e automação. DevOps é o guarda-chuva, SRE é uma das ferramentas dentro dele.
O que é error budget na prática?
É o tempo de indisponibilidade permitido por um SLO. Se o SLO é 99,9% ao mês, o error budget é de cerca de 43 minutos. Enquanto não estourar, a equipe pode lançar novas features. Se estourar, prioriza estabilidade.
Quem pode implementar SRE?
Qualquer equipe de tecnologia, independente do tamanho. Startups podem começar com uma pessoa dedicada a definir SLOs e automatizar deploys. O essencial é adotar a mentalidade de tratar operações como código.
Quais métricas um SRE acompanha?
Latência, taxa de erros, disponibilidade e saturação. Essas são as quatro métricas de ouro. Elas refletem a experiência do usuário e ajudam a definir SLIs e SLOs. Ferramentas como Prometheus e Grafana facilitam a coleta.
SRE substitui o time de operações?
Não substitui, transforma. A ideia é que o time de operações passe a atuar como engenharia, automatizando tarefas manuais e usando dados para decisões. O objetivo é reduzir o trabalho braçal e aumentar a confiabilidade.
