A evolução do SRE no Google

• Os produtos do Google são usados por bilhões de pessoas em todo o mundo, e é fundamental que funcionem de forma confiável. A equipe de SRE do Google desenvolveu diversas abordagens para aumentar a confiabilidade dos serviços.
• As técnicas tradicionais de SRE (orçamento de erro, postmortem etc.) contribuíram significativamente para a expansão da escala dos serviços web do Google.
• Com o recente avanço de IA/ML etc., a complexidade dos sistemas aumentou drasticamente, tornando necessária uma nova abordagem.
• A teoria de sistemas e a teoria de controle são úteis para compreender de forma sistemática interações complexas.
• É essencial adotar uma abordagem que garanta segurança desde o design fundamental em nível de sistema, em vez de apenas “resolver após a ocorrência do problema”.

Visão geral do STAMP

• O professor Nancy Leveson do MIT propôs o STAMP (System-Theoretic Accident Model and Processes), que analisa incidentes a partir da perspectiva de interações de sistemas complexos, em vez de falha de componentes individuais.
• Em vez da causalidade tradicional (“há um bug, então há uma falha”), ele prioriza “em que fluxo de controle incorreto o sistema inteiro caiu”.
• Reconstrói acidentes com a análise Causal Analysis based on Systems Theory (CAST) e identifica fatores de risco antecipadamente com a System-Theoretic Process Analysis (STPA).

Base da teoria de controle – quatro condições

• A teoria de controle requer 4 pontos para um controle eficaz:
  • Condição de objetivo: deve existir um objetivo (por exemplo, manter uma métrica específica).
  • Condição de ação: é necessário que o sistema possa afetar seu estado para atingir o objetivo.
  • Condição de modelo: é necessário um modelo para entender o sistema (interno e externo).
  • Condição de observabilidade: é necessário um sistema de observação, como sensores, para identificar o estado atual do sistema.

Tratar a interrupção (outage) como um problema de controle

• Antes, havia forte tendência de descrever uma interrupção como “falhas em cascata”.
• O STAMP interpreta isso como uma perspectiva de “controle e interação inadequados”, garantindo segurança no nível de sistema.
• Em vez de apenas descobrir “onde a primeira falha começou”, analisa-se de forma abrangente “qual fluxo de controle/feedback estava anômalo”.

Ganhar tempo a partir do estado de risco (hazard)

• O modelo causal tradicional pula do estado normal para o estado de acidente de uma vez, por isso o tempo de resposta é muito curto.
• No STAMP, ao introduzir o conceito de “estado de risco”, é possível localizar o ponto de entrada no risco antes de um acidente completo.
• Após detectar o estado de risco e intervir ativamente, surge a chance de prevenção antes de evoluir para um acidente real.

Vendo casos reais

• O “Rightsizer” interno do Google realoca recursos com base no uso do serviço.
• Pela perspectiva do STPA, é possível identificar antecipadamente situações como “receber informações de uso incorretas e reduzir recursos abaixo da necessidade real”.
• Na fase de design, o foco era principalmente em “lógica de controle correta”, mas ao aplicar STPA foi possível descobrir problemas no caminho de feedback (como o processo de cálculo de uso de recursos).
• Em 2021, houve um caso real em que feedback incorreto se acumulou e levou a um grande problema, permanecendo em estado de risco por algumas semanas sem que fosse percebido.

Direção futura

• O SRE do Google busca maior segurança e controle da complexidade por meio de abordagens baseadas em teoria de sistemas, como STAMP, STPA e CAST.
• Mesmo com um investimento de engenharia relativamente pequeno (algumas semanas), é possível identificar muitos cenários de risco potencial em sistemas de grande porte.
• Com a análise baseada em teoria de controle além da cultura de confiabilidade existente, a possibilidade de oferecer serviços estáveis também aumenta na era de IA/ML.

[GN⁺]

Opinião do Hacker News

• A abordagem de engenharia do Google pode ser prejudicial para startups. SREs tendem a sofrer de síndrome do herói e a tentar refazer o desenho técnico das outras equipes

  • Isso é parecido com uma equipe jurídica assumindo a operação da empresa

• Há semelhanças com os livros de Sidney Dekker

  • Analisa por que os participantes dos incidentes chegam a acreditar que tomaram decisões corretas, avaliando o sistema como um todo e entendendo seu estado mental
  • Explica como mudanças independentes em sistemas complexos podem afetar a segurança

• A abordagem CAST parece promissora

  • Exige muita análise de falhas e falhas próximas, e o maior desafio para implementá-la é o fator humano

• Há uma similaridade interessante entre CAST e o trabalho de análise mecânica

  • Fornece uma estrutura para analisar como os componentes do sistema interagem entre si

• Fico curioso para saber se há casos de aplicação de uma estrutura formal de engenharia de segurança a análises de redes neurais

  • Rastrear causalidades complexas e comportamentos em nível de sistema pode ser muito útil

• O exemplo do "rightsizer" pode ter chegado ao mesmo resultado mesmo se analisado de forma tradicional

  • A nova abordagem é mais fácil e mais viável de executar

• A razão para não gostar de testes de software é a falha causada por fatores externos

  • Esta abordagem pode ajudar a resolver isso

• CAST é semelhante à análise de causa raiz de múltiplos fatores

  • Apoia o CAST de Nancy Leveson, da MIT

• Há a questão de SRE/DevOps fazer parte de uma função cotidiana

  • Em muitos casos, acredito que isso seja apenas um rebrand de uma função operacional existente

• A característica mais marcante do SRE do Google é a necessidade de ajuda do SRE quando um novo produto é lançado

  • Ter poucos SREs faz boas ideias ficarem melhores

• O artigo é longo demais e é difícil pegar o ponto principal

  • A menção ao CAST e ao STPA é a mais importante e valiosa

• Fico curioso para saber se essa abordagem ainda tem valor em escala fora do FAANG

  • Há uma tendência de investir fortemente em prevenção de riscos

• Assim como no DevOps, o escopo do SRE está se expandindo

  • SREs desempenham uma variedade de funções, desde escrever software até lidar com falhas de sistema