A evolução do SRE no Google
(usenix.org)- O SRE do Google tem reduzido falhas mesmo com o crescimento da escala dos serviços, mas concluiu que os métodos existentes não bastam para lidar com perdas que precisam ser absolutamente evitadas, como violações de privacidade e perda de dados, e por isso adotou o STAMP
- O STAMP foca em interações do sistema e falhas de controle em vez de falhas individuais de componentes; o CAST é usado para investigação de incidentes, e o STPA para análise de riscos
- Modelos de fluxo de dados e cadeias lineares de causa encontram limites analíticos diante de diagramas RPC com mais de 100 nós, modelos de arquitetura desatualizados e requisitos ausentes
- No incidente interno do quota rightsizer em 2021, feedback incorreto de uso de recursos e uma pending change não comunicada criaram um estado de risco por semanas, que acabou levando a uma falha
- O Google está investindo esforço na escala de engineer-weeks em análises STPA para encontrar centenas de cenários e ampliar o escopo do SRE para o projeto seguro do Google Cloud, de redes internas e de vários produtos
Limites que a abordagem tradicional de SRE passou a enfrentar
- Os produtos do Google são usados diariamente por dezenas de bilhões de pessoas no mundo todo, e embora a escala dos serviços tenha crescido muito nos últimos 25 anos, as falhas se tornaram mais raras
- Ao longo desse período, o SRE expandiu a confiabilidade com SLO, orçamento de erro, estratégias de isolamento, postmortems rigorosos e rollout gradual
- Agora, o desafio não é apenas reduzir a frequência das falhas, mas lidar com perdas cuja própria ocorrência precisa ser evitada
- violação de privacidade
- perda de dados
- falha de conformidade regulatória
- O orçamento de erro tradicional funcionava relativamente bem para serviços web com pouco estado, mas não é suficiente para lidar com perdas que exigem algo próximo de orçamento de erro 0
- À medida que AI e ML se tornam centrais em quase todos os produtos, e a automação viabiliza escalabilidade, custo e eficiência energética passam a importar tanto quanto funcionalidades para o usuário
A estrutura da forma tradicional de pensar em SRE
- A análise de risco tradicional é composta, em linhas gerais, por três elementos
- uma forma de modelar o sistema
- uma teoria causal para explicar como os problemas surgem
- um algoritmo de busca para encontrar riscos
- A abordagem anterior do SRE no Google não foi formalizada como uma teoria explícita, mas analisava riscos com foco em arquitetura de software e modelos de fluxo de dados
- O modelo de fluxo de dados mostra como requisições de rede ou dados se movem entre diferentes partes do sistema
- Esse modelo naturalmente leva a um raciocínio linear de causa e efeito
- observar o SLO de cada componente para entender as garantias de confiabilidade
- verificar se ele atende ou supera os requisitos do chamador
- Em postmortems, usa-se raciocínio indutivo para extrair padrões gerais a partir de eventos individuais
- não se trata apenas de corrigir um evento específico, mas de encontrar formas de evitar toda a categoria daquele tipo de evento
- tenta-se transformar alertas recorrentes em soluções de engenharia para eliminar a causa do problema
Limites dos modelos de fluxo de dados e da análise causal linear
- Com o aumento anual da complexidade dos sistemas, os modelos de fluxo de dados passaram a ter dificuldade para lidar com a complexidade na escala do Google
- Diagramas RPC e modelos de arquitetura de software ficam excessivamente complexos quando abstrações não são usadas de forma consistente, e em geral acabam incompletos ou desatualizados
- Esses modelos não mostram de forma suficiente a dinâmica do sistema
- quais RPCs podem iniciar um fluxo
- como erros se propagam
- quais componentes podem causar falhas graves e quais causam apenas problemas pequenos
- por que certa interação pode ser segura em um contexto e insegura em outro
- quais são os objetivos do sistema como um todo
- que responsabilidade cada componente tem em relação ao objetivo geral
- Um diagrama de fluxo de dados com mais de 100 nós já é esmagador como ponto de partida para buscar defeitos
- Se requisitos de segurança forem omitidos ou definidos incorretamente na fase de definição de requisitos, a segurança do sistema pode ser comprometida mesmo que o projeto implemente perfeitamente esses requisitos
- Aprender a partir de dados de falhas ainda tem limitações para prever e evitar perdas que nunca aconteceram antes
Como o STAMP muda a forma de pensar
- O SRE do Google passou a adotar teoria de sistemas e teoria de controle, escolhendo o framework STAMP, desenvolvido por Nancy Leveson, do MIT
- O STAMP vê acidentes não como uma sequência de falhas de componentes, mas como resultado de um controle de sistema insuficiente
- O CAST é usado para investigação após incidentes, e o STPA para análise de riscos
- O STAMP trata segurança não como propriedade de componentes individuais, mas como propriedade emergente em nível de sistema
- As perguntas da análise também mudam
- pergunta anterior: qual serviço de software falhou?
- pergunta do STAMP: quais interações entre as partes do sistema não foram controladas de forma suficiente?
- Muitos acidentes em sistemas complexos podem ocorrer mesmo quando cada componente funciona como projetado, mas juntos produzem um estado inseguro
As quatro condições da teoria de controle
- As condições de controle descritas por W.R. Ashby em 『An Introduction to Cybernetics』 foram integradas à metodologia STAMP de Leveson
- Para controlar um processo, são necessárias quatro condições
- condição de objetivo: o controlador precisa ter um objetivo
- condição de ação: o controlador precisa conseguir influenciar o estado do sistema
- condição de modelo: o controlador precisa ter um modelo do sistema
- condição de observabilidade: o controlador precisa conseguir perceber o estado do sistema
- Na prática de SRE, essas condições podem ser usadas como critério para verificar os elementos necessários para controlar sistemas complexos de forma eficaz
A margem de resposta criada pelos estados de risco
- O modelo de cadeia causal linear normalmente mostra apenas dois estados: operação normal e operação com perda
- A transição de operação normal para operação com perda costuma ser súbita, deixando pouco tempo para reação
- O motivo de o SRE usar SLOs de burn rápido e burn lento em conjunto também é detectar problemas antes do dano real, mas esses SLOs normalmente são propriedades de componentes individuais
- O STAMP formaliza isso como estado de risco em nível de sistema
- um estado de risco é um estado do sistema ou conjunto de condições que, quando combinado com certas condições ambientais mais severas, produz perda para um ou mais stakeholders
- Um estado de risco não é um evento isolado nem um fenômeno no nível de um único componente
- O sistema pode permanecer em estado de risco por bastante tempo antes de um incidente ocorrer
- um bug foi introduzido, mas ainda não foi acionado
- um alerta foi disparado, mas ninguém o recebeu
- um servidor foi subprovisionado, mas de repente recebe tráfego de uma funcionalidade popular
- O objetivo de engenharia não é eliminar toda falha única, mas impedir que o sistema entre em estado de risco ou trazê-lo de volta à operação normal quando isso acontecer
O caso do quota rightsizer em 2021
- O Google define e aplica quotas de recursos para parte dos softwares de sua infraestrutura interna
- Para aumentar a eficiência, monitora quanto de cada quota um serviço realmente usa e, se o uso ficar continuamente baixo, reduz automaticamente essa quota
- Na perspectiva do STPA, o quota rightsizer tem a ação de controle de reduzir a quota de um serviço
- Essa ação se torna insegura quando o rightsizer reduz a quota para abaixo da necessidade real do serviço
- o serviço entra em estado de falta de recursos
- no STPA, isso é chamado de ação de controle insegura, ou UCA
- Há quatro tipos de UCA
- a ação de controle necessária não é fornecida
- uma ação de controle incorreta ou insuficiente é fornecida
- a ação de controle é fornecida no momento ou na ordem errados
- a ação de controle é interrompida cedo demais ou aplicada por tempo demais
- Reduzir a quota para abaixo da necessidade real corresponde ao segundo tipo de UCA
Vulnerabilidades reveladas no caminho de feedback
- O requisito de segurança pode ser resumido como: “o quota rightsizer não deve reduzir a quota para abaixo da necessidade atual do serviço”
- Esse requisito é útil para projetos futuros, planos de teste e entendimento do sistema
- O STPA estrutura a análise para encontrar cenários concretos que possam violar esse requisito de segurança
- No caso do rightsizer, quatro cenários representativos podem ser investigados
- o próprio rightsizer funciona incorretamente
- o rightsizer recebe feedback incorreto ou não recebe feedback algum
- o rightsizer tenta enviar uma ação, mas o sistema de quota não a recebe
- o próprio sistema de quota funciona incorretamente
- O cenário que de fato se destacou foi quando o feedback sobre o uso atual de recursos foi calculado abaixo do valor real
- o cálculo do uso de recursos envolvia vários coletores de dados e lógica de agregação complexa
- se o resultado do cálculo fica abaixo do real, o rightsizer, mesmo funcionando como projetado, reduz a quota de forma errada
- Antes, havia muita atenção sobre o algoritmo de ajuste de quota e a precisão da saída, mas o caminho de feedback era menos compreendido
- O STPA ajuda a encontrar problemas não só no caminho de controle, mas também no caminho de feedback, e em análises de vários sistemas do Google o caminho de feedback frequentemente se mostrou menos entendido
O fluxo que transformou o incidente em perda
- No incidente de 2021, foi enviado ao rightsizer um feedback incorreto sobre os recursos em uso por um serviço importante da infraestrutura do Google
- O rightsizer calculou uma nova quota e passou a alocar muito menos recursos do que o uso real exigia
- Como medida preventiva, a redução de quota não foi aplicada imediatamente e ficou em espera por algumas semanas, para dar tempo de alguém intervir
- Porém, o feedback sobre a pending change não foi comunicado a ninguém
- O sistema permaneceu por semanas em estado de risco, mas como ninguém estava procurando esse estado, perdeu-se a chance de evitar a perda
- Algumas semanas depois, a redução de quota foi aplicada e causou uma falha significativa
- O Google tem usado o STPA para prever antecipadamente problemas semelhantes em vários sistemas
Para onde o Google SRE está indo
- O SRE do Google deixou de tratar complexidade como simples bug e está migrando, com teoria de controle, STPA e CAST, para uma abordagem de confiabilidade mais abrangente e proativa
- O objetivo não é apenas reagir a falhas, mas projetar sistemas mais seguros desde o início
- O Google já analisou com STPA alguns de seus sistemas mais complexos e, com esforço na escala de engineer-weeks por análise, encontrou centenas de cenários com diferentes alcances de impacto
- Os cenários identificados foram mitigados antes de se transformarem em falhas
- correções temporárias rápidas
- engenharia de software planejada com mais cuidado
- uso do processo regular de planejamento do Google para minimizar custo e interrupção
- O trabalho atual está focado em sistemas muito complexos do Google Cloud, grandes sistemas de rede interna e vários produtos do Google
- A mudança do SRE para uma metodologia de segurança de sistemas oferece uma nova forma de os engenheiros entenderem os sistemas que constroem e busca fornecer garantias mais fortes sobre como eles funcionam
Ainda não há comentários.