Em algum momento, toda empresa de SaaS em crescimento ouve que precisa de SRE. Talvez um cliente grande tenha perguntado sobre a sua meta de uptime, talvez um investidor tenha mencionado, talvez uma queda tenha provado o argumento sozinha. Site reliability engineering é uma disciplina de verdade, com ideias úteis, mas o cargo e as práticas não são a mesma coisa, e uma startup de 15 pessoas raramente precisa do primeiro. Este post explica o que é SRE, como ele se relaciona com o DevOps, onde os dois se sobrepõem e o que um time pequeno deve colocar em prática primeiro. Ele também faz uma análise honesta do “AI SRE”, a versão mais recente da pergunta.

O que é site reliability engineering e como o Google começou

O SRE nasceu no Google, e a definição do próprio Google é curta: “SRE é o que acontece quando você pede a um engenheiro de software que projete um time de operações.” Em vez de um grupo de operações separado rodando um software que os desenvolvedores jogam por cima do muro, o SRE trata a operação de produção como um problema de software, resolvido com código, medição e trade-offs explícitos.

O livro gratuito de Site Reliability Engineering do Google apresentou algumas ideias que se espalharam muito além do Google. Quatro delas importam mais.

SLIs e SLOs

Um service level indicator (SLI) é uma medição do que os usuários vivenciam, como a proporção de requisições que têm sucesso ou a proporção atendida em menos de 300 milissegundos. Um service level objective (SLO) é a meta para essa medição em uma janela de tempo, por exemplo 99,9% das requisições de checkout com sucesso em 30 dias. O SLA é a promessa contratual, com penalidades, que você faz aos clientes. Ele deve ser mais folgado que o seu SLO, para que você perceba o problema antes que ele custe dinheiro.

O objetivo de um SLO é definir o que é “confiável o bastante”. Sem um, todo incidente vira um debate sobre se foi grave ou não, e todo projeto de confiabilidade disputa com as funcionalidades na base do instinto.

Error budgets

Se o seu SLO é 99,9%, você tem direito a 0,1% de falha. Essa margem é o error budget. O Google o descreve como um recurso que desenvolvimento e operações gastam juntos: enquanto houver orçamento, entregue funcionalidades rápido; quando ele acabar, desacelere e dedique esforço à confiabilidade. Uma política de error budget registra esse acordo por escrito de antemão, o que transforma uma discussão política em uma regra que todos aceitaram com a cabeça fria.

Toil

O Google define toil como trabalho que é “manual, repetitivo, automatizável, tático, sem valor duradouro e que cresce de forma linear conforme o serviço cresce.” Reiniciar um worker travado na mão, rotacionar uma credencial pelo console, copiar um banco de dados para um cliente: se volta toda semana e uma máquina poderia fazer, é toil. O Google limita o trabalho operacional dos seus times de SRE a metade do tempo, de modo que a outra metade vai para a engenharia que elimina o toil.

Post-mortems sem culpados

Depois de um incidente, os times de SRE escrevem um post-mortem que se concentra nas causas contribuintes, não em quem cometeu o erro. Tratamos disso em detalhe no nosso post sobre gestão de incidentes para SaaS.

O que é DevOps

DevOps é mais antigo como termo e mais amplo como ideia. É um conjunto de práticas culturais e técnicas para fazer desenvolvedores e operações trabalharem como um só time, de modo que o software vá do commit à produção com rapidez e segurança. Na prática, isso significa integração e entrega contínuas, infraestrutura como código, testes automatizados, monitoramento e responsabilidade compartilhada pela produção. Nosso post sobre os princípios do DevOps cobre o básico.

O DevOps descreve como é o bom. De propósito, ele não prescreve como medir isso nem o que fazer quando velocidade e estabilidade entram em conflito.

Site reliability engineering vs. DevOps: onde se sobrepõem

O próprio Google vê os dois como complementares. O SRE workbook coloca assim: “class SRE implements interface DevOps”: o DevOps é a interface, um conjunto de princípios, e o SRE é uma implementação concreta e opinativa dele.

	DevOps	SRE
Pergunta central	Como entregamos mais rápido e com mais segurança, juntos?	Quão confiável isto deve ser, e como o mantemos assim?
Principais ferramentas	CI/CD, infraestrutura como código, automação, responsabilidade compartilhada	SLOs, error budgets, redução de toil, prática de incidentes
Medidas	Velocidade e estabilidade das entregas	Confiabilidade percebida pelo usuário em relação a uma meta
Quando velocidade e estabilidade entram em conflito	Cultura e bom senso	O error budget decide
Onde costuma morar	Todo mundo, muitas vezes com um papel de plataforma ou DevOps	Um time especializado, em empresas maiores

Os dois valorizam automação, medição e responsabilidade compartilhada pela produção. A diferença está na ênfase. O trabalho de DevOps é, na maior parte, sobre o caminho até a produção: pipelines, ambientes, infraestrutura. O trabalho de SRE é, na maior parte, sobre o que acontece depois que você chegou lá: disponibilidade, latência, capacidade e incidentes.

Do que um time pequeno de SaaS precisa primeiro

Para uma startup sem um time de operações dedicado, a resposta quase sempre é: primeiro as bases de DevOps, pegando emprestadas cedo algumas práticas de SRE. Contratar um time de SRE é algo para considerar bem mais tarde, se for o caso.

O motivo é a ordem das coisas. As práticas de SRE pressupõem que você consegue medir, fazer deploy e voltar atrás com confiabilidade. Se os deploys são manuais, os ambientes divergem e não há alertas além de clientes escrevendo para o suporte, um SLO é um número sobre o qual ninguém consegue agir. Resolva primeiro o caminho de entrega:

Deploys automatizados e repetíveis, com rollback testado.
Infraestrutura como código, para que os ambientes possam ser reconstruídos e revisados.
Monitoramento e alertas sobre o que os usuários percebem: erros, latência, disponibilidade.
Um esquema de plantão que não dependa de uma única pessoa.

Depois, pegue emprestadas as ideias de SRE que custam pouco e dão retorno rápido:

Um ou dois SLOs para as jornadas que mais importam, como login e checkout. Comece com metas folgadas e aperte-as conforme aprende.
Alertas baseados no impacto para o usuário, não em cada pico de CPU. Alerte quando o SLO estiver em risco.
Post-mortems sem culpados para qualquer incidente visível aos clientes.
Uma lista de toil. Anote as tarefas manuais que não param de voltar e automatize uma por mês.

Por enquanto, deixe de lado o aparato completo: políticas formais de error budget em vários serviços, headcount dedicado de SRE e planejamento de capacidade elaborado. Volte a eles quando houver vários times entregando no mesmo ambiente de produção e as disputas sobre confiabilidade começarem a atrasar você. Nossos posts sobre escalar sua startup com DevOps e quando contratar um time de DevOps em tempo integral tratam da parte de equipe.

E o AI SRE?

“AI SRE” costuma descrever um software que usa modelos de linguagem e os seus dados de observabilidade para investigar alertas: puxa logs, métricas e traces, correlaciona com os deploys recentes e propõe causas prováveis. É uma categoria real e útil. Também é fácil de superestimar.

O que a IA faz bem hoje em operações:

Vigiar o tempo todo e notar padrões em mais sinais do que um humano cansado às 3 da manhã.
Reunir contexto rápido: o deploy recente, os alertas relacionados, o runbook, o último incidente parecido.
Redigir: linhas do tempo, comunicados de status, primeiros rascunhos de post-mortem e resumos.
Rotear: decidir quem deve ver um alerta e com que urgência.

O que ela não faz de forma confiável:

Encontrar causas-raiz sozinha. Em um experimento da ClickHouse em agosto de 2025, cinco modelos de ponta investigaram falhas injetadas em uma aplicação de demonstração com acesso total à telemetria, e os autores concluíram que a análise autônoma de causa-raiz “ainda não chegou lá”. Os modelos evoluem rápido, mas o padrão seguro continua sendo tratar uma conclusão da IA como uma hipótese.
Tomar decisões de julgamento. Fazer rollback, failover ou avisar os clientes sobre uma queda envolve contexto de negócio e responsabilidade que pertencem a uma pessoa.
Substituir as práticas. Um agente de IA sem SLOs, runbooks e alertas limpos está investigando ruído.

O jeito honesto de enxergar é que a IA assume boa parte da vigilância e da primeira análise, e os humanos continuam tomando as decisões e entregando as correções.

Perguntas frequentes

O que exatamente faz um site reliability engineer?

Um site reliability engineer opera sistemas de produção usando engenharia de software. Na prática, isso significa definir SLIs e SLOs com os times de produto, usar error budgets para equilibrar funcionalidades e estabilidade, automatizar o toil até eliminá-lo, carregar o pager e liderar a resposta a incidentes e os post-mortems sem culpados. No Google, o trabalho operacional é limitado a metade do tempo de um SRE, para que o restante vá para a engenharia que torna o sistema mais fácil de operar.

O que é SRE vs. DevOps?

DevOps é um conjunto amplo de práticas culturais e técnicas para entregar software com rapidez e segurança como um só time. SRE é uma forma específica e opinativa de implementar essas práticas, construída em torno de metas de confiabilidade e error budgets. O workbook de SRE do Google resume assim: “class SRE implements interface DevOps”.

A IA vai substituir o SRE?

Hoje, não. As ferramentas de IA são boas em vigiar sinais continuamente, reunir contexto, redigir linhas do tempo e rotear alertas, mas no experimento da ClickHouse de 2025 os modelos de ponta ainda não conseguiram encontrar causas-raiz sozinhos. Decisões como fazer rollback, failover ou avisar os clientes ainda exigem uma pessoa, então a IA muda a carga de trabalho do SRE mais do que elimina o papel.

Como a Webera encara isso

É assim que a Webera trabalha. A Webera é uma assinatura de DevOps para times de SaaS na AWS, operada por engenheiros seniores que trabalham com nove agentes de IA. O Sentinel cuida da observabilidade, incluindo o acompanhamento de SLOs e das tendências de capacidade. O Dispatcher desenha as escalas de plantão e roteia os incidentes por severidade. O Conductor constrói os pipelines de CI/CD e os procedimentos de rollback que vêm primeiro na lista acima. Os agentes vigiam, roteiam e fazem a primeira análise 24 horas por dia; os engenheiros tomam as decisões.

Todo plano inclui monitoramento 24/7 e resposta a incidentes, solicitações ilimitadas e os nove agentes. O Pro custa US$ 4.999 por mês, o Elite US$ 9.999 e o Platform US$ 14.999, com mínimo de três meses e, depois, mês a mês. Todo o código é seu.

Se você quer as bases de DevOps e as partes úteis do SRE sem montar um time para cada um, compare os planos. E se o custo é a outra coisa que tira o seu sono, leia o nosso playbook de otimização de custos na AWS.

Site Reliability Engineering vs. DevOps: o que uma startup de SaaS precisa primeiro?