Por que SRE?

Para mim, um sistema confiável é um produto que continua entregando valor para quem o usa. Disponibilidade e latência importam na medida em que mostram isso. O que me atrai em SRE é a racionalidade que ela traz para a cultura de engenharia e para as decisões de produto, com critérios combinados no lugar de opiniões e urgências.

Confiabilidade do ponto de vista de quem usa

Um SLO só é útil quando está ligado à realidade do negócio. Uma meta escolhida porque o número parece bom, sem relação com o que as pessoas esperam do serviço, vira só um número a cumprir e não diz nada sobre a experiência de quem usa. Prefiro começar perguntando o que quem usa o serviço precisa dele e quanto custa ficar aquém disso.

A abordagem de risco em SRE parte de uma ideia simples: nenhum serviço precisa ser 100% confiável, e cada ponto a mais de confiabilidade custa tempo e dinheiro e deixa as mudanças mais lentas. Com um SLO combinado com produto, “o sistema está instável” vira uma pergunta que dá para responder: quanto do error budget já consumimos? Se ainda há margem, o time pode acelerar entregas e experimentos. Se a margem acabou, estabilidade vira prioridade, e isso já estava combinado antes do incidente.

Quando decidimos aceitar um risco, deixo claras as incertezas e combino quem responde pela decisão e quando vamos revisá-la, com uma análise do tamanho do problema. Os anos em que atuei como advogado me acostumaram a esse tipo de decisão, em que alguém escolhe sabendo o que está aceitando.

Segurança entra na conversa desde o desenho da solução, porque segurança e confiabilidade têm muito em comum. Além de disponibilidade e latência, olho para proteção de dados, controle de acesso e possibilidades de abuso, e procuro critérios que reflitam as consequências para o negócio e para as pessoas. Escrevi mais sobre isso em Aceitando o Risco.

Falhas como aprendizado

Falhas fazem parte de operar software, e vejo cada uma como um passo de um aprendizado contínuo de engenharia. Quando um erro passa por um processo de engenharia, a pergunta útil é o que no processo permitiu que ele chegasse até ali. Culpar pessoas por um erro de processo deixa o processo como estava.

Por isso vejo o postmortem como uma necessidade. Ele serve para reduzir falhas e riscos e para aumentar a capacidade operacional do time, desde que as ações que saem dele virem trabalho de engenharia: automações, testes, alertas melhores ou mudanças no desenho. Com isso, intervenções manuais recorrentes viram código que pode ser testado, revisado e mantido.

Plataformas construídas com os times

Não acredito em plataforma imposta de forma unilateral. Prefiro tratar a plataforma como produto: entender quem vai usá-la, que problema ela resolve e se vale o esforço de manutenção. Self-service e padrões reutilizáveis só se pagam quando as pessoas de fato os adotam.

O objetivo é que quem desenvolve consiga colocar o software em produção e corrigir problemas sem esperar numa fila de pedidos, com contexto e observabilidade para entender o sistema e caminhos seguros para mudá-lo. Padrões e automações valem a pena quando diminuem a carga cognitiva sem esconder o sistema.

A solução mais sofisticada nem sempre é a certa. Cada componente a mais é algo que alguém precisa operar e manter, e em muitos contextos uma plataforma com menos complexidade serve melhor aos times. Nas escolhas de plataforma, pesam o resultado técnico e também as condições de quem vai trabalhar com ela todos os dias.

IA, um novo desafio para SRE

O desenvolvimento assistido por IA é um desafio novo para quem cuida de confiabilidade. Os times conseguem produzir mais código e testar mais ideias, o que aumenta o volume de mudanças chegando à produção. Para acompanhar esse ritmo, ganham peso as permissões limitadas, as verificações automatizadas, a implantação gradual e a recuperação rápida, que dão retorno cedo e reduzem a dependência de aprovações manuais.

A pesquisa DORA de 2025 descreve a IA como algo que amplifica tanto as forças quanto as fragilidades de uma organização. Vejo aí um trabalho claro para SRE: preparar a plataforma e os processos para que a velocidade extra não venha acompanhada de mais incidentes. A própria IA também pode ajudar, em testes e na investigação de falhas.

SRE, DevOps e Platform Engineering

Os limites entre esses cargos mudam de uma organização para outra, e uso ideias dos três. Entendo DevOps como cultura e colaboração entre quem desenvolve e quem opera software, junto com práticas de engenharia que os dois lados compartilham. SRE oferece formas concretas de aplicar esses princípios, com objetivos mensuráveis e responsabilidade compartilhada. De Platform Engineering vem a visão de produto aplicada à plataforma.

SRE surgiu quando Ben Treynor Sloss assumiu uma equipe de produção no Google em 2003 e passou a tratar a operação como um problema de engenharia de software. Boa parte das ideias desta página vem dos livros de SRE que o Google disponibiliza gratuitamente, que uso como referência e adapto ao contexto de cada organização.