SRE: O Que Faz e Como Migrar de DevOps para SRE (2026)

SRE, ou Site Reliability Engineering, é a disciplina que aplica engenharia de software para resolver problemas de operações — na prática, o profissional de SRE passa boa parte do tempo escrevendo código de automação, definindo métricas de confiabilidade e respondendo a incidentes, em vez de fazer operação manual de infraestrutura. Se você está pensando em migrar de DevOps para SRE, a primeira coisa importante de entender é que não é uma troca de ferramentas — é uma mudança de mentalidade sobre o que significa “manter um sistema saudável”.

SRE: O Que Faz e Por Que Migrar de DevOps para SRE Virou Tendência

Diferente de Platform Engineering, que constrói a plataforma que outros times usam como produto interno, o foco do SRE é a confiabilidade do sistema em produção: SLOs, orçamento de erro, gestão de incidentes e redução de trabalho manual repetitivo (o “toil”, no jargão da área). As três disciplinas convivem e se sobrepõem — não é incomum um profissional transitar entre DevOps, SRE e Platform Engineering ao longo da carreira, já que a base técnica é parecida.

O motivo de tanta gente com background em DevOps ou infraestrutura estar considerando migrar de DevOps para SRE agora é claro: a demanda por profissionais sênior está superando a oferta, e a faixa salarial reflete isso — no mercado americano, a variação fica entre 133 mil e 210 mil dólares por ano, dependendo de senioridade, empresa e criticidade do plantão de on-call. Ainda que os números brasileiros sejam outros, a tendência de valorização é a mesma.

Neste artigo explico os conceitos centrais que definem o trabalho de um SRE — SLO, error budget, toil e post-mortem sem culpa —, o roteiro prático de cinco passos para fazer essa transição vindo de DevOps, e o que realmente conta na hora de conseguir a vaga: certificação, portfólio, ou os dois.

Antes de entrar nos detalhes técnicos, vale deixar claro por que decidi estruturar este guia especificamente em torno de como migrar de DevOps para SRE, e não como uma introdução genérica à disciplina. A maioria de quem me pergunta sobre isso já tem anos de experiência prática com infraestrutura e automação — o que falta não é conhecimento técnico de base, é entender a mudança de mentalidade e o vocabulário específico que separa um DevOps de um SRE na prática do dia a dia.

SLOs e Error Budget: O Coração do Trabalho de SRE

O conceito mais fundamental de SRE, e o que mais separa a disciplina de um DevOps tradicional, é o SLO (Service Level Objective) e o error budget (orçamento de erro) que vem junto dele. Um SLO define, em número, qual nível de confiabilidade um serviço precisa entregar — por exemplo, “99,9% das requisições devem responder com sucesso em um mês”. O que sobra desse número, os 0,1% restantes, é o error budget: a margem de falha que o time tem permissão de gastar sem quebrar o combinado com o negócio.

Fazer as contas ajuda a entender o tamanho real disso: 99,9% de disponibilidade num mês de 30 dias significa um orçamento de erro de cerca de 43 minutos de indisponibilidade total. Parece pouco, mas é exatamente esse número que orienta decisões do dia a dia: se o time já gastou metade do orçamento de erro numa semana por causa de um deploy problemático, a resposta correta é desacelerar novos lançamentos até o orçamento se recompor — não simplesmente seguir lançando features no mesmo ritmo.

Essa é a virada de chave mais difícil para quem vem de DevOps: em vez de tratar confiabilidade como algo abstrato (“estamos indo bem” ou “tivemos um problema ruim”), SRE trata como um recurso finito e mensurável que precisa ser gerenciado com a mesma disciplina que se gerencia orçamento financeiro. Um erro comum de quem está começando a migrar de DevOps para SRE é confundir “zero incidente” com o objetivo — na prática, o objetivo é gastar o orçamento de erro de forma inteligente, priorizando confiabilidade quando o orçamento está apertado e liberando espaço para inovação mais arriscada quando ele está folgado.

Definir esse SLO por escrito, com a matemática do error budget explicitada, é hoje uma das evidências mais valorizadas em entrevistas para vagas de SRE — muito mais do que citar ferramentas que você já usou. Ter um SLO real que você definiu e acompanhou, mesmo que num projeto pessoal ou numa experiência anterior modesta, conta mais do que qualquer lista de tecnologias no currículo.

Esse é justamente o primeiro exercício prático que recomendo para quem quer migrar de DevOps para SRE: pegar um sistema que você já opera hoje, definir um SLO honesto para ele (nem otimista demais, nem conservador demais) e calcular o error budget resultante. Só de fazer esse exercício uma vez, a diferença de raciocínio entre “está tudo bem” e “gastamos 40% do orçamento de erro esta semana” fica muito mais concreta.

Toil, On-Call e Post-Mortems Sem Culpa

Outro pilar central do trabalho de SRE é a gestão do “toil” — o trabalho manual, repetitivo e que escala linearmente com o crescimento do serviço, sem agregar valor de engenharia de longo prazo. Reiniciar um serviço manualmente toda vez que ele trava, ou aplicar a mesma correção de configuração servidor por servidor, são exemplos clássicos de toil. Parte considerável do trabalho de um SRE é identificar esse tipo de tarefa e escrever automação que a elimina de vez, em vez de aceitar que “é assim que sempre foi feito”.

O plantão de on-call também tem um peso diferente dentro de SRE do que costuma ter em times de DevOps tradicionais. Não é só estar disponível para apagar incêndio — é fazer parte de um ciclo estruturado que inclui documentação de runbooks, critérios claros de escalonamento, e principalmente o post-mortem sem culpa (blameless postmortem) depois de cada incidente relevante. A ideia central do post-mortem sem culpa é simples de enunciar e difícil de praticar: o objetivo é entender o que falhou no sistema e no processo, nunca apontar quem “causou” o problema.

Essa cultura de post-mortem sem culpa é, segundo quem já fez a transição, o principal mecanismo de aprendizado da disciplina — mais até do que treinamento formal. Cada incidente vira uma oportunidade documentada de melhorar observabilidade, automação ou processo, e times de SRE maduros tratam essa documentação como um ativo de conhecimento tão importante quanto o próprio código. Quem ainda não tem essa base de monitoramento montada pode começar pelas ferramentas de observabilidade gratuitas mais usadas do mercado antes de pensar em qualquer ferramenta paga.

Vale um alerta honesto para quem está migrando de DevOps para SRE: subestimar a carga cognitiva do on-call é um dos erros mais citados por quem já passou por essa transição. Estar de plantão de verdade — com responsabilidade real sobre acordar de madrugada para resolver um incidente — é diferente de “estar disponível no Slack” como acontece em times menos maduros, e isso tem impacto real na rotina e no bem-estar que vale considerar antes de assumir a posição.

Recomendo conversar abertamente com pessoas que já fazem plantão de SRE na empresa ou área que você está mirando antes de migrar de DevOps para SRE só pelo salário ou pelo título — a realidade do on-call varia muito entre empresas, e entender isso de antemão evita uma frustração comum de quem entra na área achando que vai ser só “DevOps com nome mais bonito”.

O Roteiro de 5 Passos Para Migrar de DevOps para SRE

O roteiro mais recomendado para quem quer migrar de DevOps para SRE de forma estruturada segue cinco passos, nessa ordem — e a ordem importa mais do que parece. Primeiro: instrumentar antes de automatizar. Construir dashboards de SLI (indicadores de nível de serviço) e estabelecer uma linha de base de observabilidade antes de qualquer coisa, porque não dá para definir um SLO realista sem saber como o sistema realmente se comporta hoje.

Segundo: definir SLOs e o error budget correspondente por escrito, com a matemática explicitada — não basta ter uma meta vaga de “manter o sistema no ar”, é preciso o número exato e o cálculo de quanto de falha isso permite. Terceiro: automatizar o toil identificado, priorizando as tarefas manuais que mais escalam com o crescimento do serviço, não necessariamente as mais visíveis ou as mais fáceis de automatizar.

Quarto: disciplina de on-call, incluindo participar ativamente de post-mortems sem culpa como mecanismo central de aprendizado, não como formalidade burocrática depois do incidente. Quinto: chaos engineering — testar falhas deliberadas e documentadas (usando ferramentas como Chaos Monkey ou LitmusChaos) para descobrir lacunas de confiabilidade antes que um incidente real as exponha.

O erro mais citado por quem já fez essa transição é inverter a ordem: automatizar antes de instrumentar. Sem visibilidade real do comportamento do sistema, a automação corre o risco de otimizar a coisa errada ou mascarar problemas que deveriam estar sendo medidos e discutidos abertamente. Profissionais que seguem essa sequência relatam alcançar marcos importantes da transição em cerca de três a seis meses de prática deliberada — não é uma mudança de fim de semana, mas também não é uma reformulação de carreira de anos.

Um detalhe que ajuda a manter o ritmo: trabalhar com um mentor ou alguém que já fez essa transição reduz bastante o tempo até os primeiros marcos, segundo relatos de quem passou pelo processo — não porque substitui a prática, mas porque ajuda a evitar o erro de ordem (automatizar antes de instrumentar) logo no início, quando esse erro é mais fácil de cometer sem perceber.

Certificações, Portfólio e Salário: O Que Realmente Pesa

Sobre certificações: as mais transferíveis para quem migra de DevOps para SRE continuam sendo as ligadas a Kubernetes (CKA e CKAD) e certificações de nuvem voltadas a operações, como AWS SysOps ou a certificação de DevOps Engineer profissional do Google Cloud. Elas ajudam principalmente no reconhecimento inicial do recrutador — a disciplina de SRE tem suas origens documentadas pelo próprio Google, e boa parte do vocabulário técnico usado em entrevista vem diretamente dessa fonte original. Se o seu ambiente é AWS, vale saber quanto custa uma certificação AWS antes de decidir qual delas vale o investimento.

Mas o que decide a entrevista, segundo quem recruta para essas vagas, são evidências práticas de portfólio, não certificação isolada: um SLO real que você definiu e acompanhou com a matemática do error budget calculada, um post-mortem sem culpa que você documentou e contribuiu, um experimento de chaos engineering completo com os achados registrados, e participação real em rotação de on-call com resultado mensurável. Certificação sem esse tipo de evidência prática deixa uma lacuna visível na entrevista — muitos profissionais com fluência em ferramentas não conseguem explicar a própria matemática de error budget quando perguntados diretamente.

Se você já tem experiência de DevOps ou infraestrutura e está avaliando essa transição, minha recomendação prática é começar pelo primeiro passo do roteiro — instrumentar e definir um SLO real, mesmo que seja para um projeto pessoal ou um sistema pequeno do trabalho atual — antes de investir em qualquer certificação nova. Esse SLO documentado, com a lógica de error budget por trás, vira a peça central do seu portfólio de SRE e a resposta mais forte que você pode dar quando perguntarem “me conta sobre uma vez que você geriu confiabilidade de um sistema”.

Se ainda está decidindo entre os caminhos de especialização depois de uma base em DevOps, vale comparar também com o que é Platform Engineering antes de escolher — as duas áreas competem pela mesma base de conhecimento técnico, mas pedem perfis de mentalidade bem diferentes.

Perguntas Frequentes

Preciso saber programar para migrar de DevOps para SRE?

Sim, conhecimento de programação (Python, Go ou similar) ajuda bastante, já que boa parte do trabalho de SRE é escrever automação para eliminar toil e instrumentar observabilidade. Não precisa ser um desenvolvedor full-stack, mas escrever scripts e ferramentas internas é parte central do dia a dia — quem já programa um pouco costuma achar mais simples migrar de DevOps para SRE do que quem vem de um perfil só operacional.

Quanto tempo leva para migrar de DevOps para SRE?

Profissionais com background de DevOps relatam alcançar marcos importantes da transição em cerca de três a seis meses de prática deliberada, seguindo o roteiro de instrumentar, definir SLOs, automatizar toil, praticar disciplina de on-call e chaos engineering, nessa ordem.

SRE ganha mais do que DevOps?

No mercado americano, a faixa salarial de SRE fica entre 133 mil e 210 mil dólares por ano, dependendo de senioridade e criticidade do plantão — geralmente um pouco acima da faixa de DevOps equivalente, refletindo a demanda maior por profissionais sênior na área.

Vale a pena tirar CKA antes de migrar de DevOps para SRE?

A CKA (Certified Kubernetes Administrator) é uma das certificações mais transferíveis para a transição e ajuda no reconhecimento inicial do recrutador, mas o que decide a entrevista são evidências práticas: um SLO real definido por você, um post-mortem documentado e participação efetiva em on-call.

Quer ver o mapa completo da área? Leia o guia de carreira em cloud computing.