São 2 da manhã e o seu telefone toca. Não é uma feature quebrada: é latência no percentil 99, que vem subindo há três horas e ninguém percebeu até um cliente grande escrever para o suporte. Você abre o dashboard, correlaciona três serviços, descobre que um deploy de dois dias atrás saturou uma conexão de banco de dados que só se nota sob carga real. Você conserta em quarenta minutos. Na manhã seguinte você não escreve um postmortem para culpar ninguém: escreve um para que esse tipo de falha fique estruturalmente menos provável.
Isso é um dia de trabalho normal para um site reliability engineer. E cada vez tem mais devs sêniores na América Latina que, ao ver esse dia completo, dizem "eu quero isso" em vez de "que pesadelo".
Site reliability engineer não é um rebranding de DevOps
Essa é a confusão mais comum e a que precisa ser tirada do caminho mais rápido. DevOps é uma cultura e um conjunto de práticas: aproximar desenvolvimento e operações, automatizar o pipeline, quebrar silos. Não é um cargo com uma definição operacional rígida, e por isso acabou significando coisas diferentes em cada empresa que usa o termo.
Site reliability engineering, por outro lado, nasceu no Google como uma disciplina com métricas concretas e regras de decisão explícitas. Um site reliability engineer não "ajuda dev e ops a se darem melhor". Ele gerencia a confiabilidade de um sistema como se fosse uma feature com orçamento próprio, com números que determinam quando o trabalho de produto para e quando não para.
A diferença não é cosmética. Um engenheiro de DevOps pode passar o dia escrevendo Terraform e montando pipelines de CI/CD sem nunca tocar num error budget. Um SRE com o mesmo stack nas mãos toma decisões diferentes porque o trabalho dele é medido de forma diferente. Você pode ter o título de "DevOps engineer" e fazer trabalho de SRE, e vice-versa. O título importa menos do que a lógica de decisão por trás dele.
O error budget é o que muda como você pensa o trabalho
Aqui está o conceito que realmente separa um site reliability engineer de um backend dev tradicional, e é mais simples (e mais incômodo) do que parece.
Define-se um SLO (service level objective): por exemplo, 99,9% de disponibilidade mensal. Isso deixa uma margem de falha permitida, o error budget: nesse caso, 0,1% do tempo você pode ficar fora do ar sem quebrar a promessa. Esse orçamento não é um acidente contábil, é uma ferramenta de decisão.
Se o error budget está intacto, o time de produto pode lançar features de forma agressiva, correr riscos, iterar rápido. Se o error budget acabou, a conversa muda: os novos lançamentos são pausados e o foco se volta para a estabilidade, sem precisar de uma discussão política sobre "quem está certo". O número decide.
Isso é genuinamente bom porque tira a ideologia da sala. Não existe uma guerra eterna entre "queremos velocidade" e "queremos estabilidade": existe um dado que indica como o sistema está agora. Onde isso falha é quando uma empresa adota o vocabulário (diz "temos SLOs") sem adotar a disciplina real de pausar os lançamentos quando o orçamento acaba. Aí o error budget é só uma frase num slide, não uma ferramenta.
Isso também se reflete na remuneração. As empresas que operam uma prática de SRE madura costumam pagar um adicional acima do que paga um título genérico de backend ou operações, justamente porque o cargo combina engenharia de software com tolerância real ao risco de produção, uma combinação que é rara. Se você está negociando uma proposta para uma vaga de site reliability engineer, a conversa sobre o error budget também é uma conversa de poder de negociação: uma equipe que leva a confiabilidade a sério, a ponto de construir um orçamento real em torno dela, geralmente também leva a sério pagar pelo critério necessário para geri-lo.
Os plantões de um site reliability engineer não são os de qualquer equipe
Toda equipe de backend com produção ao vivo tem algum tipo de plantão. O que muda com um site reliability engineer é o volume e a natureza do que te acorda de madrugada.
Numa equipe de produto bem montada, o plantão deveria ser majoritariamente silencioso: alertas raros, bem calibrados, que correspondem a problemas reais. Na prática, muitas equipes acabam com alertas barulhentos, plantões que interrompem o sono por coisas que se resolvem sozinhas, e "vamos consertar isso no próximo sprint", que nunca chega. Um site reliability engineer que faz bem o trabalho ataca justamente isso: todo alerta que dispara e não exige ação humana é um alerta mal configurado, e é tratado como dívida técnica real, não como ruído de fundo aceitável.
A parte que precisa ser dita sem rodeios: se a sua organização não investe em reduzir o ruído dos alertas, ser SRE ali é plantão noturno com nome bonito. O cargo não te protege de uma cultura de incidentes disfuncional. Pelo contrário, te coloca no centro dela. Antes de aceitar uma vaga de site reliability engineer, pergunte especificamente quantas vezes o plantão toca por semana e que porcentagem desses alertas resultou numa ação real. Se ninguém tem esse número, é um sinal.
As métricas de sucesso são outras, e isso muda o dia a dia
Um backend dev sênior costuma ser medido (formal ou informalmente) por features entregues, qualidade de código, velocidade de desenvolvimento. Um site reliability engineer é medido por coisas que, quando o trabalho está bem feito, se notam pela ausência: tempo médio de detecção, tempo médio de resolução, número de incidentes recorrentes, tendência do error budget ao longo do tempo.
Isso tem uma consequência psicológica real que pouca gente antecipa. Como backend dev, o trabalho bem feito gera algo visível: uma feature que as pessoas usam, um PR que é mergeado, uma demo. Como SRE, o trabalho bem feito muitas vezes significa que nada aconteceu. Ninguém percebe um incidente que jamais ocorreu porque o failover foi automatizado corretamente seis meses atrás. Se a sua satisfação profissional depende de um reconhecimento visível e imediato, isso pode ser frustrante. Se o que te motiva é a elegância de um sistema que não cai, é exatamente esse o tipo de recompensa que você vai buscar.
Outra métrica que muda o terreno: toil, o trabalho operacional manual e repetitivo que não escala. Um SRE sério mede quanto do seu tempo é toil e trabalha ativamente para reduzir isso por meio da automação. Se no seu cargo a maior parte do tempo consiste em reiniciar serviços na mão e responder tickets repetidos sem nunca automatizar a causa, você não está fazendo site reliability engineering. Está fazendo suporte técnico com acesso à produção.
Onde o cargo é um bom salto de carreira e onde não é
Aqui vai a opinião, sem maquiagem.
É um excelente encaixe se você gosta de pensar em sistemas completos em vez de features isoladas, se te motiva a elegância de resolver uma classe de problema em vez de um ticket pontual, e se você tem tolerância real (não aspiracional) à pressão de um incidente em andamento. Também é um bom caminho se você quer diversificar de "sei escrever features" para "sei manter sistemas complexos vivos", que é uma habilidade bem paga e mais rara do que parece no mercado sênior.
Não é um bom encaixe se você busca o cargo para escapar da ansiedade dos prazos de produto. Você vai trocar deadlines de sprint por incidentes que não escolhem horário, e para muita gente isso é objetivamente pior, não melhor. Também não é um bom encaixe se o seu interesse real é automação e infraestrutura mas você não se importa com a disponibilidade do sistema em si: esse perfil é melhor atendido por um cargo de platform engineering, que compartilha ferramentas com SRE mas não compartilha o mesmo compromisso com SLOs e plantões.
Existe uma versão mais sutil desse erro que é fácil de passar despercebida: assumir o cargo de SRE numa empresa que leva o SRE a sério no discurso, mas que ainda está construindo a prática real. Isso não é automaticamente um mau sinal: alguém precisa construir essa prática do zero, e fazer isso é um tipo de trabalho interessante em si. O erro é aceitar essa vaga esperando encontrar a versão madura do cargo desde o primeiro dia, e se queimar quando os primeiros seis meses são dedicados sobretudo a construir ferramentas e convencer o resto da organização, em vez do trabalho profundo de sistemas que você buscava.
E existe uma armadilha específica do mercado atual: muitas empresas publicam vagas de "site reliability engineer" que na prática são "sysadmin com Kubernetes e sem orçamento de error budget real". Antes de aceitar, peça para ver (ou pelo menos que te descrevam) o dashboard de SLOs atual da equipe. Se ele não existe, você não está entrando num cargo de SRE. Está entrando num cargo de operações com um título mais atraente no LinkedIn.
O site reliability engineering de verdade é uma disciplina com regras, não uma vibe. Se a empresa tem essas regras e as respeita, é um dos cargos técnicos mais interessantes que existem hoje para um sênior que já se cansou de escrever features. Se não tem, é plantão sem limites com um nome melhor. A diferença entre essas duas coisas não está no título do cargo. Está em se alguém, em algum lugar da organização, consegue te mostrar um número.
