O que a SRE Resolve
Bem-vindo à Engenharia de Confiabilidade de Sites
A Engenharia de Confiabilidade de Sites (SRE) começou no Google em 2003. Ben Treynor Sloss assumiu uma pequena equipe de ops e a reconstruiu como se engenheiros, e não pagers humanos, gerenciassem a produção. O resultado se tornou o modelo padrão para operar grandes serviços de internet.
Equipes tradicionais de operações mantinham os serviços funcionando por meio de trabalho manual: reiniciar este servidor, chamar aquele engenheiro, escrever um runbook, torcer para que funcione. Esse modelo quebra em escala. Uma equipe de cinquenta operadores não consegue reiniciar manualmente cinco mil servidores. Além de certo tamanho, as operações manuais se tornam um imposto que consome todas as horas produtivas.
A SRE inverte o modelo. Em vez de contratar mais operadores quando os sistemas crescem, a SRE contrata engenheiros de software e diz a eles: escrevam código que faça o trabalho operacional por vocês. Seu trabalho é engenharia de software aplicada a problemas de operações. Seu resultado: automação, monitoramento e confiabilidade projetada, não intervenções manuais.
Três ideias fundamentais impulsionam a prática de SRE:
- Service Level Objectives (SLOs): metas numéricas de confiabilidade, acordadas previamente
- Error budgets: o inverso de um SLO, usado para assumir riscos
- Eliminação de toil: qualquer trabalho operacional que escala linearmente com o tamanho do sistema deve ser eliminado
Essas três ideias se desdobram em todas as práticas de SRE: postmortems, escalas de plantão, planejamento de capacidade, monitoramento e engenharia de releases.
Ops Tradicional versus SRE
Por que o Ops Tradicional Quebra em Escala
Uma equipe típica de ops cresce linearmente com os sistemas que gerencia. Dobrar o número de servidores significa dobrar o número de operadores. Isso faz sentido financeiro para implantações pequenas, mas é desastroso em escala: não é possível contratar para sair de um problema quadrático.
SRE limita o trabalho operacional a cinquenta por cento do tempo de um engenheiro. A outra metade deve ser dedicada à engenharia: construir ferramentas, automatizar processos e eliminar o toil que levou a esses cinquenta por cento. Se o toil exceder cinquenta por cento por muito tempo, a equipe deve devolver trabalho para o time de desenvolvimento ou contratar mais SREs. A regra dos cinquenta por cento impede que uma equipe de SRE se transforme em uma equipe tradicional de ops sob pressão sustentada.
Compare os modos de falha:
- Ops tradicional: mais incidentes levam a mais respostas manuais, que deixam menos tempo para prevenção, o que gera mais incidentes. Um ciclo vicioso.
- SRE: mais incidentes disparam postmortems, que revelam oportunidades de automação, que reduzem o tempo de resposta do próximo incidente. Um ciclo virtuoso, quando funciona.
SLI, SLO, SLA
Três Letras Que Regem a Produção
Confiabilidade sem medição é teatro. SRE transforma confiabilidade em um número, acordado previamente, que todos podem verificar.
Indicador de Nível de Serviço (SLI): uma medição do comportamento do serviço. Exemplos: latência de requisições, taxa de erros, throughput, profundidade da fila. Um SLI é algo que você pode representar em um gráfico.
Objetivo de Nível de Serviço (SLO): um valor-alvo ou intervalo para um SLI. Exemplo: '99,9% das requisições HTTP são bem-sucedidas em uma janela contínua de 28 dias.' Um SLO é uma promessa que você faz a si mesmo e aos seus usuários sobre a qualidade de serviço aceitável.
Acordo de Nível de Serviço (SLA): um compromisso contratual, geralmente com penalidades financeiras em caso de violação. Exemplo: 'Reembolsamos 10% se a disponibilidade mensal cair abaixo de 99,9%.' Um SLA é uma promessa reforçada por advogados.
Distinção crítica: seu SLA deve sempre ser mais flexível que seu SLO. Se você define internamente 99,9% e contrata externamente 99,9%, você não tem margem. Os SREs normalmente executam SLOs com um nove a mais que o SLA: meta de 99,95%, contrato de 99,9%. A diferença absorve a eventual semana ruim.
Error Budgets: O Inverso do SLO
Dos Objetivos de Confiabilidade às Decisões de Engenharia
Um SLO define um objetivo de confiabilidade. O error budget é o que resta: a quantidade de falhas que você pode gastar antes de perder o objetivo.
Se o seu SLO promete 99,9% de sucesso em 28 dias, seu error budget é 0,1% das requisições, ou cerca de 40 minutos de indisponibilidade total por mês. Esse orçamento é seu para gastar como quiser: em lançamentos planejados, em funcionalidades experimentais, em engenharia do caos ou tolerando uma dependência instável.
Error budgets transformam o conflito entre dev e ops. Sem um orçamento, toda indisponibilidade gera uma discussão sobre quem fez a mudança ruim e como evitar a próxima. Com um orçamento:
- Orçamento restante: lance mais rápido, assuma mais riscos, execute experimentos. O orçamento paga por isso.
- Orçamento esgotado: pare de lançar novas funcionalidades, congele mudanças arriscadas, foque em trabalho de confiabilidade até o orçamento se recompor.
Isso transforma a confiabilidade de uma discussão emocional em um recurso mensurável. Os engenheiros podem gastar o orçamento deliberadamente, como qualquer outro insumo de produção.
Definindo Toil
O que Conta como Toil
Nem toda tarefa operacional qualifica como toil. SRE define toil de forma precisa: trabalho que é manual, repetitivo, automatizável, tático, desprovido de valor duradouro e escala linearmente conforme o serviço cresce.
Todas as seis propriedades devem ser verdadeiras. Uma migração de dados única é manual, mas não repetitiva: isso não qualifica como toil. Um engenheiro sênior projetando uma nova arquitetura de serviço toma uma decisão tática, mas adiciona valor duradouro: isso não qualifica como toil.
Exemplos que qualificam como toil:
- Reiniciar manualmente um serviço após uma falha por vazamento de memória
- Colar fragmentos de log em um canal de chat durante a triagem de um incidente
- Preencher um formulário de ticket para provisionar um novo banco de dados
- Executar manualmente um relatório trimestral de capacidade
- Aprovar solicitações rotineiras de implantação uma a uma
A regra dos cinquenta por cento limita o toil a metade do tempo de um SRE. Acima de 50%, a equipe deve devolver responsabilidade ao time de produto ou contratar mais engenheiros, mas o objetivo permanece claro: reduzir o toil a zero, substituindo-o por sistemas automatizados que executam o mesmo trabalho sem intervenção humana.
A automação não apenas economiza tempo. Ela elimina completamente uma classe de erros humanos. Um script que provisiona um banco de dados não esquece etapas após um turno longo.
Raciocínio da Auditoria de Toil
Sua equipe acompanha como o tempo é gasto. No último trimestre a distribuição foi: 30% deploys, 25% resposta a incidentes, 20% trabalho de capacidade, 15% engenharia de funcionalidades, 10% solicitações pontuais de times de produto.
Higiene de On-Call
Engenheiros, Não Pagers
On-call traz um custo real. O sono é interrompido, os fins de semana são afetados e o estresse de problemas desconhecidos se acumula. SRE trata o on-call como um recurso finito que deve permanecer sustentável, não como um fardo heroico suportado por quem mais se importa.
Rotações saudáveis de on-call seguem vários princípios:
- Tempo compensado: as horas de on-call são convertidas em tempo de folga, pagamento adicional ou benefício equivalente. On-call gratuito causa burnout na equipe.
- Profundidade razoável da rotação: uma equipe de seis pessoas com plantão primário e secundário significa que cada engenheiro assume um turno a cada três semanas. Rotações de duas pessoas destroem carreiras.
- Orçamento de volume de páginas: o livro de SRE do Google sugere no máximo dois eventos de paging por turno de doze horas. Acima disso, a equipe deve investir tempo de engenharia para reduzir o volume de alertas, e não apenas suportá-lo.
- Apenas alertas acionáveis: toda página deve exigir ação humana. Se uma página seria ignorada, automatizada ou dispara repetidamente durante a operação normal, ela não deve existir. Fadiga de alertas é um defeito de confiabilidade.
- Transferências follow-the-sun: equipes distribuídas globalmente passam o plantão nos limites de fuso horário para que ninguém receba páginas às 3h da manhã, a menos que o sistema realmente não possa esperar até a manhã.
Postmortems sem Culpa
Como Incidentes se Tornam Melhorias
Todo incidente significativo recebe um postmortem: uma análise escrita do que aconteceu, por quê, o que o corrigiu e quais mudanças evitam a recorrência. O postmortem é o equivalente do SRE a juros compostos: cada um adiciona confiabilidade permanente ao sistema.
Sem Culpa significa que o documento atribui falhas a sistemas e processos, nunca a indivíduos. Se um engenheiro executou o comando errado, o postmortem pergunta: por que o sistema permitiu esse comando? Por que nenhuma salvaguarda o detectou? Que mudança no sistema, na documentação ou nas ferramentas impediria o próximo engenheiro de cometer o mesmo erro?
A ausência de culpa existe por uma única razão: as pessoas escondem erros quando temem punição. Erros ocultos tornam-se o próximo incidente. O custo de uma cultura sem culpa é barato em comparação com o custo de acumular defeitos não revelados.
Os postmortems normalmente cobrem:
- Resumo: descrição em um parágrafo do incidente e seu impacto
- Linha do Tempo: reconstrução minuto a minuto com carimbos de data/hora
- Análise de causa raiz: fatores técnicos e de processo que permitiram a falha
- Detecção: como a equipe tomou conhecimento do incidente e quanto tempo levou
- Resolução: as ações tomadas para restaurar o serviço
- Lições aprendidas: o que funcionou e o que não funcionou
- Itens de ação: tarefas de engenharia concretas, atribuídas e com prazo
Os itens de ação ficam em um rastreador. São priorizados como qualquer outro trabalho de engenharia. Postmortems sem itens de ação se reduzem a mera narrativa. O trabalho não muda nada.
Os Quatro Sinais de Ouro
O que Todo Serviço Deve Medir
O livro de SRE do Google propõe quatro sinais que todo serviço voltado ao usuário deve expor: latência, tráfego, erros e saturação. Juntos, eles descrevem a saúde do serviço sob a perspectiva do usuário. Monitorar com menos sinais deixa pontos cegos; monitorar com centenas de métricas sobrecarrega a equipe com fadiga de alertas.
Latência: quanto tempo as requisições levam. Acompanhe distribuições, não médias. p50 (mediana) descreve a experiência típica. p99 descreve o pior 1% dos usuários. A média sozinha esconde caudas longas: um serviço com mediana de 50 ms e p99 de 5.000 ms parece bom na média, mas prejudica um usuário em cada cem.
Tráfego: a demanda sobre o serviço. Para um serviço web, isso significa requisições por segundo. Para um serviço de streaming, conexões simultâneas. Para um job em lote, itens processados por minuto. O tráfego se correlaciona com decisões de capacidade e revela anomalias na carga de trabalho.
Erros: a taxa de requisições com falha. Falhas explícitas (HTTP 500), falhas implícitas (HTTP 200 com dados corrompidos) e falhas de política (resposta muito lenta para atender ao SLO) contam. Distinguir entre elas importa: um 200 com payload ruim costuma prejudicar mais os usuários do que um 500 honesto.
Saturação: o quão cheio o sistema está rodando. Utilização de CPU, profundidade de fila, pressão de memória, ocupação do pool de conexões. A saturação prevê latência futura: um sistema a 95% de CPU tem muito pouco espaço antes de picos de latência visíveis ao usuário.
A maioria dos alertas de SRE deriva desses quatro sinais. Alertas baseados em sintomas (alertar quando os usuários notariam) superam alertas baseados em causas (alertar quando a CPU excede 80%). Os quatro sinais dourados descrevem sintomas.
Caminhos de Carreira em SRE
Onde as Habilidades de SRE São Valorizadas
As carreiras em SRE divergem com base na parte da disciplina que o engenheiro mais gosta:
Infrastructure SRE: constrói as plataformas nas quais outras equipes executam. Kubernetes, service meshes, nuvem interna. Forte engenharia de sistemas, teoria de sistemas distribuídos e design de plataformas. Paga extremamente bem em grandes empresas porque o trabalho escala: um Infrastructure SRE dá suporte a centenas de engenheiros de produto.
Embedded SRE: faz par com uma equipe de engenharia de produto para melhorar a confiabilidade de um serviço específico. Metade engenheiro, metade coach. Fortes habilidades de comunicação e revisão de código são tão importantes quanto profundidade técnica. Frequentemente o melhor caminho para engenheiros que gostam de ensinar.
Reliability tooling: constrói a stack de observabilidade: monitoramento, alertas, dashboards, ferramentas de postmortem, plataformas de gerenciamento de incidentes. Trabalho pesado de frontend e engenharia de dados. O resultado é usado por todas as outras equipes.
Production engineering: o termo do Facebook/Meta para SRE focado em capacidade, implantação e gerenciamento de tráfego. Trabalho pesado em redes e sistemas.
Certificações técnicas que valem a pena ter: o Google Cloud Professional Cloud Architect, o AWS Solutions Architect Professional e as certificações da CNCF (Kubernetes Administrator, Kubernetes Application Developer) indicam fluência em cloud-native. As certificações da Linux Foundation indicam profundidade em sistemas. Nenhuma delas substitui um portfólio de projetos, mas ajudam a passar pelas triagens de recrutadores.
Concluindo
O Que Você Já Sabe
A engenharia de confiabilidade de sites surgiu como a resposta do Google a um problema de escalabilidade e se transformou em uma disciplina agora praticada em toda a indústria. Você cobriu:
- A transição de operações manuais para confiabilidade projetada
- SLIs, SLOs, SLAs e o conceito de orçamento de erros (inverse-SLO)
- Definição de toil, a regra dos 50% e a redução orientada por engenharia
- Rotações sustentáveis de plantão e a prática de postmortems sem culpa
- Os quatro sinais dourados como ponto de partida para o monitoramento de serviços
- Trilhas de carreira em SRE e as certificações que abrem portas
Duas ideias são as mais importantes. Confiabilidade é um número, acordado antecipadamente. E toil é um defeito, não uma descrição de cargo. Leve essas duas ideias adiante e o restante de SRE segue naturalmente.
Leitura recomendada: o livro SRE do Google (gratuito online: sre.google/books/), o SRE Workbook para exercícios práticos e os textos de Charity Majors sobre observabilidade. A lição complementar geometry-of aprofunda a estrutura visual por trás da prática de SRE: distribuições de latência, cones de orçamento de erro, grafos de dependência e layouts de dashboards.