Pare de fazer Cosplay de Big Tech: O SRE do Google não é a Bíblia

Se eu entrar em qualquer escritório de engenharia ou call de Zoom hoje, há uma grande chance de ver o livro “Site Reliability Engineering” do Google na estante ao fundo. Ele virou o símbolo de status da nossa área. O problema é que a maioria trata aquilo como uma escritura sagrada imutável, e não como o que realmente é: um manual de “memórias de guerra” de uma empresa que opera em uma escala que você não tem, usando ferramentas que você não possui (Borg), para resolver problemas que você não enfrenta.

O Google escreveu o “way to do” deles. Copiar isso cegamente na sua empresa, que roda um cluster Kubernetes gerenciado com meia dúzia de gatos pingados na operação, é a definição clássica de Cargo Cult. Você implementa o ritual (chama o Sysadmin de SRE), mas não obtém o resultado (confiabilidade), é porque ignorou o contexto. O SRE do Google é uma disciplina de engenharia fantástica, mas não é o único cookbook na prateleira.

Para sair dessa bolha, você precisa olhar para o lado. Outras empresas documentaram suas culturas e, muitas vezes, as soluções delas são mais aplicáveis à realidade de quem não tem um orçamento infinito.

O cardápio de cookbooks (além de Mountain View)

Cada gigante de tecnologia resolveu seus gargalos de um jeito. Aqui está o que você deveria roubar de cada um, em vez de tentar replicar o Google:

1. Amazon: The Builders' Library

Se o livro do Google é a teoria acadêmica, a Builders' Library da Amazon é o manual de trincheira.
Escrito por Principal Engineers, o foco aqui é arquitetura distribuída na prática. Eles explicam como evitam o thundering herd, como fazem shuffle sharding e como lidam com deployments sem derrubar a AWS inteira.

• A lição: Esqueça a teoria de sistemas complexos por um minuto e aprenda padrões de resiliência práticos para o seu dia a dia.

2. GitLab: The Handbook

Sua empresa diz que é remote-first mas você passa 6 horas por dia em reuniões síncronas? Então largue o livro do Google e leia o Handbook do GitLab. Eles operam com transparência radical e comunicação assíncrona.

• A lição: Documentação não é burocracia, é a única forma de escalar times distribuídos sem enlouquecer.

3. Netflix: Freedom and Responsibility & Chaos

Todo CEO quer a cultura da Netflix (“liberdade”), mas poucos querem pagar o preço (densidade de talento absurda e demissões rápidas de quem é somente “médio”). Eles nos deram a Engenharia do Caos, mas cuidado: rodar o Chaos Monkey na sua infraestrutura frágil na sexta-feira à tarde não é engenharia, é masoquismo.

• A lição: Autonomia exige contexto. Só dê liberdade se você tiver ferramentas de observabilidade para ver quem quebrou o quê.

4. Spotify: O “Modelo” (que nem eles usam mais)

Tribos, Squads, Chapters e Guilds. O mercado de consultoria ágil vendeu isso como a solução final. A realidade? O Spotify evoluiu e abandonou a rigidez desse modelo anos atrás. Muitas empresas implementaram isso e criaram silos verticais que não conversam entre si.

• A lição: Estrutura deve seguir a estratégia. Não reorganize sua empresa baseada em um PDF de 2012.

5. Basecamp: Shape Up

Enquanto o “Agile Industrial Complex” te obriga a fazer dailies eternas e manter backlogs infinitos no Jira, o Basecamp trabalha com ciclos de 6 semanas e escopo variável.

• A lição: Se o seu time de SRE/DevOps está afogado em tickets, talvez o problema seja o processo de gestão, não a tecnologia.

6. Meta (Facebook) e Duolingo

A Meta opera sob o mantra “Move Fast with Stable Infra”. Eles investem pesado em ferramentas internas (monorepo, build systems) para que o dev full-stack não dependa de ninguém.

Já o Duolingo é uma aula de SRE aplicado ao negócio: a infraestrutura existe para suportar testes A/B massivos.

• A lição: A confiabilidade do servidor deve servir para validar hipóteses de produto (Duolingo), e não ser um fim em si mesma.

A “Cola” que falta: Team Topologies

O grande erro ao tentar “implantar SRE” é achar que é somente uma mudança técnica. “Agora temos SLOs e Error Budgets, somos o Google!”. Não, vocês não são.

O SRE é uma disciplina de engenharia e operações. Ele define o como (observabilidade, automação). Mas ele falha em definir onde isso se encaixa na organização. É aqui que entra o Team Topologies (de Matthew Skelton e Manuel Pais).

Empresas maduras entenderam que o SRE precisa de um design organizacional compatível. O Team Topologies organiza os times baseados no fluxo de valor e na Carga Cognitiva.

Se você joga SRE dentro de um time sem estrutura, eles viram o “Time de Tudo Que Deu Errado”. Pelo prisma do Team Topologies, o SRE deve atuar geralmente em dois modos:

1. Platform Team: Constrói a estrada pavimentada (K8s, CI/CD, Monitoramento) como produto (X-as-a-Service), para que os times de desenvolvimento (Stream-aligned) consumam infraestrutura de forma autônoma.

2. Enabling Team: Atua como consultoria interna (Facilitating), ensinando os times de produto a definirem seus próprios SLOs e a realizarem post-mortems decentes.

Resumo da Ópera

Pare de procurar a resposta mágica em um único livro.

• Use SRE (Google/Amazon) para as táticas de combate: como monitorar, como automatizar, como responder a incidentes.

• Use Team Topologies para o mapa do terreno: como organizar os times para que o SRE não vire um suporte de luxo.

Se você só renomear seus Sysadmins para SREs e mantiver a mesma estrutura de tickets e silos, parabéns: você só aumentou a folha de pagamento e manteve o caos.