DevOps, SRE e Engenharia de Plataforma: qual é a diferença.
Os três aparecem na mesma vaga, na mesma proposta e no mesmo slide. Resolvem problemas diferentes, e trocar um pelo outro custa um time inteiro fazendo a coisa errada com competência.
A resposta curta.
DevOps é uma forma de trabalhar. SRE é uma disciplina de engenharia com um número no meio. Engenharia de Plataforma é um produto interno. Um diz como o time entrega, o outro diz quanta falha é aceitável, o terceiro diz o que o time não precisa mais construir sozinho.
A confusão tem uma causa concreta: as três coisas usam as mesmas ferramentas. Pipeline, contêiner, infraestrutura como código e monitoramento aparecem nos três. Só que ferramenta igual não quer dizer problema igual, e a pergunta que separa os três não é "que ferramenta usa" — é "o que essa pessoa é cobrada por melhorar".
Os três, um por vez.
Como o time entrega
A AWS define DevOps como a combinação de filosofias culturais, práticas e ferramentas que aumenta a capacidade de uma organização entregar aplicações e serviços em alta velocidade. O ponto central é derrubar a parede entre quem desenvolve e quem opera.
Práticas nomeadas: integração contínua, entrega contínua, microsserviços, infraestrutura como código, monitoramento e registro, e comunicação entre times.
Cobrado por: tempo entre escrever o código e ele estar em produção, e por quanto disso é automático.
Quanta falha é aceitável
O livro do Google resume a origem numa frase: SRE é o que acontece quando você pede a uma pessoa engenheira de software que projete um time de operações. Não é operação com nome novo — é operação escrita como software.
Duas regras concretas: o Google limita em 50% o trabalho operacional agregado de quem faz SRE, e trata 100% como a meta de confiabilidade errada para basicamente tudo.
Cobrado por: o sistema ficar dentro da meta de disponibilidade acordada, e o orçamento de erro ser gasto de propósito.
O que ninguém precisa refazer
A CNCF define uma plataforma para computação nativa em nuvem como uma coleção integrada de capacidades, definida e apresentada de acordo com as necessidades de quem a usa. A citação que a própria CNCF adota descreve o resultado: uma base de APIs de autoatendimento, ferramentas, serviços, conhecimento e suporte, organizada como um produto interno.
Os atributos que ela nomeia incluem plataforma como produto, autoatendimento, documentação e integração de novas pessoas, menos carga cognitiva, oferta opcional e componível, e segurança por padrão.
Cobrado por: adoção interna. Uma plataforma que os times contornam é um custo, não um produto.
Lado a lado.
| Pergunta | DevOps | SRE | Plataforma |
|---|---|---|---|
| O que é | Cultura, práticas e ferramentas | Disciplina de engenharia | Produto interno |
| Unidade de medida | Frequência e tempo de entrega | Meta de disponibilidade e orçamento de erro | Adoção pelos times internos |
| Quando entra | Desde o primeiro deploy | Quando a queda custa dinheiro | Quando vários times repetem o mesmo trabalho |
| Sinal de que deu errado | Virou o nome do time que cuida do pipeline | Virou plantão sem meta escrita | Os times contornam a plataforma |
Qual deles a sua empresa precisa agora.
Três perguntas, na ordem. A primeira que você responder "não" é onde está o seu problema.
Uma correção de uma linha chega em produção no mesmo dia?
Se não, o problema é DevOps e nenhuma contratação de SRE resolve. Pipeline, teste automatizado e infraestrutura como código vêm antes de qualquer discussão sobre confiabilidade.
Você sabe dizer, em número, quanto o sistema pode ficar fora do ar por mês?
Se não, o problema é SRE — e começa por escrever a meta, não por contratar alguém. Sem meta não existe orçamento de erro, e sem orçamento de erro a prioridade entre lançar e estabilizar vira discussão de opinião.
Times diferentes estão resolvendo o mesmo problema de infraestrutura de jeitos diferentes?
Se sim, e se são vários times, aí faz sentido plataforma. Com um time só, uma plataforma interna é um produto com um usuário — custo de manutenção sem ganho de escala.
O erro que a gente mais encontra.
Empresa contrata plataforma antes de ter DevOps. O resultado é sempre o mesmo: um portal interno bonito por cima de um processo de entrega manual. Os times continuam abrindo chamado, agora com uma tela no meio, e a plataforma vira mais uma coisa para manter.
O segundo mais comum: chamar de SRE o plantão que já existia. Muda o cartão de visita e não muda o trabalho — porque não existe meta de disponibilidade escrita, ninguém derivou orçamento de erro nenhum, e o limite de metade do tempo em trabalho operacional que o Google usa nunca foi aplicado. A pessoa apaga incêndio com um título melhor.
A ordem que funciona é a mais chata: automatize a entrega, escreva a meta de disponibilidade, meça, e só depois construa caminho pronto para o que já se repete. Cada etapa dessa se paga sozinha, o que é exatamente o argumento para não pular nenhuma.
Perguntas sobre DevOps, SRE e plataforma.
Qual a diferença entre DevOps e SRE?
DevOps é uma combinação de cultura, práticas e ferramentas para entregar software com velocidade, derrubando a parede entre desenvolvimento e operação. SRE é uma disciplina de engenharia que coloca um número nisso: define uma meta de disponibilidade, deriva dela um orçamento de erro e usa esse orçamento para decidir quando lançar e quando parar. DevOps diz como trabalhar; SRE diz quanto de falha é aceitável e o que fazer quando o limite estoura.
O que é orçamento de erro?
É o oposto da meta de disponibilidade. O livro de SRE do Google define o orçamento de erro como um menos a meta de disponibilidade: uma meta de 99,99% deixa 0,01% de indisponibilidade para gastar no período medido. Enquanto sobra orçamento, o time lança. Quando o orçamento acaba, a prioridade vira confiabilidade até ele se recompor.
Por que 100% de disponibilidade é a meta errada?
Porque o Google escreve exatamente isso: 100% é a meta de confiabilidade errada para basicamente tudo. Cada nove a mais custa muito mais caro que o anterior, e acima de certo ponto o usuário não percebe diferença, porque a rede, o celular e o provedor dele já falham mais do que o seu sistema.
O que é Engenharia de Plataforma?
É tratar a infraestrutura interna como produto. A CNCF define uma plataforma para computação nativa em nuvem como uma coleção integrada de capacidades, definida e apresentada de acordo com as necessidades de quem a usa. Na prática: autoatendimento, documentação, caminhos prontos e menos carga cognitiva para quem desenvolve.
Minha empresa precisa dos três?
Quase nunca ao mesmo tempo. DevOps vem primeiro porque é prática de trabalho e não exige time novo. SRE entra quando existe algo em produção cuja queda custa dinheiro e alguém precisa responder por isso com número. Plataforma entra quando há times suficientes repetindo o mesmo trabalho de infraestrutura para que valer a pena construir o caminho pronto uma vez.
Dá para contratar SRE sem ter meta de disponibilidade definida?
Dá para contratar a pessoa, mas ela vira plantão com nome novo. Sem meta de disponibilidade não existe orçamento de erro, sem orçamento de erro não existe critério para priorizar confiabilidade contra funcionalidade, e a disciplina inteira vira apagar incêndio. A meta vem antes da contratação.
Não sabe em qual das três você está travado?
O diagnóstico responde isso com evidência: onde a entrega para, quanto o sistema cai, e o que já se repete o suficiente para virar caminho pronto. Duas semanas, um documento, uma cotação fechada.
Fontes
As definições e os dois números citados — o limite de 50% e o orçamento de erro — vêm destas três fontes primárias, abertas em 9 de agosto de 2026.