O que SRE é, e o que não é

SRE nasceu no Google com uma premissa simples e incômoda: confiabilidade é um problema de engenharia de software, não de plantão heroico. Em vez de contratar mais gente para operar manualmente conforme o sistema cresce, escreve-se software que opera o sistema — e mede-se o resultado com números acordados antes.

O que se perde ao traduzir SRE como “o nome novo de sysadmin” é justamente a parte que funciona: objetivos explícitos de confiabilidade que mudam decisões de produto.

SRE e DevOps: mesma coisa?

Não são sinônimos, e também não competem. DevOps é um conjunto de princípios sobre derrubar o muro entre quem constrói e quem opera. SRE é uma implementação opinativa desses princípios, com práticas concretas: SLI e SLO, orçamento de erro, limite de toil, postmortem sem culpa, revisão de produção.

Na prática brasileira, poucos times têm SRE dedicado — e não precisam ter. As práticas funcionam dentro de um time de produto que assume a operação do que escreve.

Toil: definindo e reduzindo

Toil é trabalho operacional manual, repetitivo, automatizável, sem valor duradouro e que cresce junto com o sistema. Reiniciar serviço toda segunda, criar usuário à mão, liberar acesso por chamado, rodar migração passo a passo.

Não é toil: investigar um incidente novo, projetar arquitetura, escrever automação, revisar capacidade. Trabalho chato e trabalho de operação também não são sinônimos de toil.

A regra prática do livro original é um teto de 50% do tempo do time em toil; acima disso, o time nunca sai do lugar, porque toda a capacidade vira manutenção. Meça antes de discutir:

Registre por duas semanas, em uma planilha simples:
tarefa | quantas vezes | minutos por vez | automatizável? (s/n)

Ordene por vezes × minutos. O topo da lista é o seu backlog de automação — e o argumento objetivo para reservar tempo de engenharia para ele.

O orçamento de erro como contrato

Um SLO de 99,9% mensal não significa “queremos perfeição”. Significa que 43 minutos e 50 segundos de indisponibilidade por mês são aceitáveis — e que esse tempo é um recurso a ser gasto, não um fracasso a ser evitado a qualquer custo.

Isso resolve a briga clássica entre entregar rápido e manter estável, porque transforma opinião em política combinada antes do incidente:

• Com orçamento sobrando: libere mudanças, aumente a frequência de deploy, experimente.
• Com orçamento estourado: congela funcionalidade nova até a confiabilidade voltar; o trabalho vira correção, teste e automação.

O acordo só vale se produto e engenharia assinarem antes, quando ninguém está no meio de um incidente. Depois é negociação, não política.

O que muda no dia a dia

• Toda mudança relevante tem forma de reverter, e alguém já testou essa reversão.
• Alerta existe só onde há ação e impacto no usuário — o resto é painel.
• Incidente termina em postmortem escrito, com ações que têm dono e prazo.
• Trabalho de confiabilidade entra no mesmo backlog que funcionalidade, priorizado com os mesmos critérios.
• Ninguém é responsabilizado por apertar o botão que o sistema permitiu apertar.

O que SRE não é

Não é um time que recebe o sistema pronto para “cuidar” dele — isso é a operação separada de novo, com nome melhor. Não é buscar 100% de disponibilidade: cada nove adicional custa mais que o anterior e, acima de certo ponto, o usuário nem percebe, porque o celular e a operadora dele já falham mais que o seu serviço. E não é um cargo que se resolve com certificação; é um jeito de trabalhar que precisa de acordo com quem prioriza.

Próximo passo: transforme “queremos ser confiáveis” em número acordado em SLO na prática.