Uma política, toda região: Google Cloud e a responsabilidade de um plano de controle global

Resumo

• Em 12 de junho de 2025, campos em branco não intencionais em uma política de cota alcançaram os bancos de dados regionais do Service Control do Google Cloud quase simultaneamente. Um caminho de código previamente implantado não tinha tratamento de erro adequado nem proteção por feature flag; o processamento da política causou a falha dos binários do Service Control em todas as regiões. Muitas APIs do Google Cloud, Google Workspace e Google Security Operations retornaram erros 503. Os recursos existentes de streaming e infraestrutura como serviço em grande parte continuaram operando, mas os caminhos de gerenciamento e API necessários para inspecionar, modificar, escalar ou recuperar serviços foram amplamente prejudicados.
• O bug imediato foi específico, mas a falha de responsabilidade foi arquitetural. O Google tinha instâncias de serviço distribuídas regionalmente e uma implantação binária em etapas, mas a política desencadeadora foi replicada globalmente em segundos. O mecanismo de interrupção, portanto, contornou o aprendizado regional que a implantação deveria proporcionar. A recuperação então criou um efeito de manada contra o Spanner em regiões maiores, porque as tarefas de reinicialização não tinham backoff exponencial aleatório. A infraestrutura pública do Cloud Service Health também dependia do ambiente afetado, atrasando o primeiro aviso do Google por cerca de uma hora.
• Incidentes anteriores mostram causas diferentes, mas questões recorrentes sobre independência lógica. Em junho de 2019, a automação de manutenção desagendou clusters do plano de controle de rede em várias localidades físicas, as rotas BGP foram retiradas e as ferramentas necessárias para diagnóstico competiam pela rede congestionada. Em fevereiro de 2021, um bug latente desencadeado durante alterações de cota de peering bloqueou a programação global de rede. Em março de 2021, rotas inválidas expuseram um defeito conhecido de fornecedor e alguns locais do Cloud Interconnect não tinham diversidade suficiente de fornecedores de roteadores. Estes não são um defeito de software recorrente; são testes repetidos de contenção de modo comum, autoridade de mudança, recuperação de rede e visibilidade verdadeira.
• O Google é responsável por validar dados replicados globalmente, isolar funções do plano de controle, preservar comportamento de falha estática ou falha aberta quando seguro, manter comunicações de incidentes independentes e provar que as correções prometidas foram concluídas. Os clientes não podem reparar esses controles de plataforma, mas continuam responsáveis por identificar quais operações dependem de APIs do plano de controle, monitorar de fora do provedor, testar modos degradados e comprar diversidade de rota e provedor em vez de contar links nominais. A implantação multirregional reduz muitos riscos; por si só, não escapa de um plano de política global ou de um backbone compartilhado.

A interrupção foi uma decisão de controle tomada em todos os lugares ao mesmo tempo

Uma região de nuvem é fácil de imaginar. Tem prédios, energia, refrigeração, fibra, máquinas e zonas destinadas a isolar falhas físicas. Um plano de controle é mais difícil de ver. É a autoridade que decide se os recursos podem ser criados, qual política se aplica, como as rotas devem ser programadas, se uma solicitação de API está dentro da cota e para onde o tráfego deve ir.

Os aplicativos podem continuar processando o trabalho existente quando essa autoridade está temporariamente indisponível, mas tornam-se frágeis quando precisam de uma nova instância, uma alteração de configuração, uma decisão de credencial, uma atualização de rota ou uma failover que ela própria requer o plano de controle.

Essa distinção explica por que o incidente de 12 de junho de 2025 foi simultaneamente menos que um apagão total de infraestrutura e mais que um problema comum de API. Orelatório completo do incidente do Service Control do Googleafirma que os recursos existentes de streaming e infraestrutura como serviço não foram diretamente afetados pela falha primária. No entanto, uma longa lista de produtos experimentou erros de API externos, incluindo Identity and Access Management, Cloud Storage, BigQuery, Cloud Run, Cloud DNS, Cloud Load Balancing, Hybrid Connectivity, Network Connectivity Center, Spanner, produtos de monitoramento, o console e vários serviços de IA. A capacidade de continuar servindo a partir do estado já programado sobreviveu melhor do que a capacidade de pedir à plataforma para decidir ou mudar algo.

O mecanismo estava excepcionalmente claro no relato público do Google. Em 29 de maio, um novo recurso do Service Control para verificações adicionais de política de cota foi lançado região por região. A implantação binária foi concluída sem expor a falha porque o caminho de código com falha exigia uma alteração de política posterior. O recurso não estava protegido por uma flag que pudesse ativá-lo gradualmente para projetos selecionados, e seu tratamento de dados inválidos permitiu que um valor nulo causasse a falha do processo.

Em 12 de junho, por volta das 10h45, horário do Pacífico, uma política de cota contendo campos em branco não intencionais foi escrita nas tabelas regionais do Spanner usadas pelo Service Control. Como os metadados de cota foram projetados para se mover globalmente com consistência quase imediata, os dados apareceram em todas as regiões em segundos. Cada implantação regional do Service Control encontrou então a mesma entrada e entrou em um loop de falha.

Este não foi um caso de ausência de redundância. Existiam instâncias de serviço regionais e bancos de dados regionais. Tampouco foi simplesmente um caso de um engenheiro pressionar o botão errado. Um sistema de produção aceitou dados estruturalmente inseguros, um caminho crítico carecia de tratamento defensivo de erros, um recurso alcançou todas as regiões sem um caminho de ativação controlado independentemente e o sistema de propagação era mais rápido que o sistema de validação. A arquitetura converteu um objeto lógico inválido em um evento global.

Chamar o incidente de interrupção por política malformada é preciso, mas incompleto. A política foi o gatilho. As causas maiores foram a quantidade de autoridade atribuída a ela e a ausência de contenção entre aceitação, replicação, interpretação e serviço. A questão de responsabilidade não é meramente por que um campo em branco existia. É por que qualquer política poderia se tornar um estado de falha executável em todos os lugares antes que uma região, um coorte de projeto ou um validador sombra tivesse tempo de rejeitá-la.

Um gatilho curto produziu uma recuperação longa e desigual

A linha do tempo do Google contém duas histórias muito diferentes. A detecção e o diagnóstico foram rápidos. A recuperação total não foi.

O caminho mais lento em us-central1 é central para a análise de risco. Conforme as tarefas do Service Control reiniciavam, elas colocavam uma demanda concentrada na tabela do Spanner subjacente. As tarefas não tinham o backoff exponencial aleatório necessário para evitar repetições sincronizadas. O Google teve que limitar a criação de tarefas e direcionar o tráfego para bancos de dados multirregionais. Em outras palavras, a primeira falha foi a interpretação insegura de dados globais; a segunda foi o comportamento de recuperação que sobrecarregou uma dependência compartilhada.

A própria literatura de SRE do Google há muito descreve esse perigo. Seu capítulo sobrecomo lidar com falhas em cascataexplica como repetições e reinicializações podem manter um backend sobrecarregado e como backoff exponencial aleatório, degradação graciosa e controle de descarga de carga podem evitar que um problema de capacidade local se torne uma cascata. O relatório de 2025 se compromete explicitamente a auditar sistemas para esse backoff. A importância não é que o Google falhou em seguir uma frase em um livro. É que uma classe conhecida de perigo de sistemas distribuídos permaneceu em um serviço crítico cuja população de reinicialização era regional e cujos dados subjacentes eram globais.

Os planos de recuperação devem, portanto, ser avaliados como arquiteturas de produção, não como parágrafos de manual. Um sistema que pode ser desabilitado com segurança precisa de um mecanismo de interrupção cujas próprias dependências sejam compreendidas. Uma frota que pode falhar em conjunto precisa de um governador de reinicialização, controle de admissão, jitter e uma taxa máxima de recuperação testada. Um banco de dados que se espera absorver a recuperação da frota precisa de capacidade reservada ou um caminho de leitura degradado.

Se os engenheiros precisam rotear para um banco de dados multirregional durante o evento, essa rota deve ser ensaiada e observável antes do incidente, com evidências de que não moverá a sobrecarga para outro lugar.

A cauda longa também importa para a comunicação com o cliente. O relatório preliminar do Google descreveu um evento global de três horas, enquanto a página do incidente continuou listando a recuperação do produto até as 18h18. Alguns produtos tinham pendências após o retorno do serviço de API. Um cliente cuja solicitação falhou durante a janela principal pode ter tido repetições, trabalhos enfileirados, fluxos de trabalho parciais, caches desatualizados ou um serviço de terceiros que demorou mais para se recuperar.

O estado verde do provedor é o início da reconciliação do cliente, não a prova de que todos os processos de negócios estão íntegros.

A implantação regional não criou aprendizado regional

A entrega progressiva deve transformar distância em evidência. Uma mudança atinge uma pequena população; os operadores observam seu comportamento; só então ela avança. O Google usou uma implantação binária região por região para o novo código do Service Control, mas a implantação nunca exerceu o caminho de código que mais tarde falhou. A política ativadora seguiu um mecanismo de distribuição diferente, otimizado para tornar o estado de cota global em segundos. O código foi gradual; o significado do código não foi.

Esta é uma falha sutil, mas consequente, no controle de mudanças. As equipes frequentemente revisam binários, configuração, esquema, política e dados como objetos separados. O comportamento de produção, no entanto, vem de sua combinação. Um recurso adormecido pode passar por todos os portões regionais até que um valor de configuração o ative em todos os lugares. Um esquema pode ser válido para o escritor, mas inválido para um leitor mais antigo. Uma política replicada globalmente pode tornar os canários regionais irrelevantes. Um botão vermelho pode existir, mas ainda depender do plano de controle quebrado para fazer efeito.

A orientação atual de infraestrutura do Google reconhece esse risco. Oguia de blocos de construção da confiabilidadediz que os recursos globais são resilientes a incidentes de infraestrutura zonais e regionais, mas podem se tornar pontos únicos de falha quando um erro crítico de configuração tem escopo global. Ele recomenda controle cuidadoso de mudanças e, para cargas de trabalho excepcionalmente exigentes, alternativas regionais de defesa em profundidade. Oguia de gerenciamento e monitoramentocomplementar aconselha implantação progressiva e escrutínio extra para recursos globais. O incidente de 2025 aplica a mesma lógica dentro do provedor: o alcance global é um benefício de confiabilidade contra falhas físicas e um perigo de raio de explosão para estado lógico ruim.

Uma correção completa precisa de um modelo de lançamento unificado. O binário, o esquema de política, os valores da política, a replicação do banco de dados, as versões do leitor, o comportamento de fallback e os controles de emergência devem ser tratados como uma superfície de mudança. Novos leitores devem aceitar com segurança valores antigos, novos, ausentes e corrompidos. Uma nova política deve ser lida em modo sombra antes de se tornar autoritativa. A ativação deve começar com projetos internos ou uma região limitada e parar automaticamente em limites de falha, latência ou erro.

A replicação deve ser incremental o suficiente para preservar um intervalo de detecção, mesmo que o estado final do negócio deva se tornar globalmente consistente.

Isso não significa que toda política global deva se tornar lentamente inconsistente. Decisões de cota e autorização podem exigir estado oportuno e coerente. A questão de design é se a validação pode ser separada da autoridade. Uma política candidata pode replicar como dados inertes, ser analisada e avaliada contra tráfego semelhante ao de produção e tornar-se efetiva somente após as verificações serem bem-sucedidas. As regiões podem reter uma política de último conhecido válido quando um novo objeto é inválido. Os leitores podem distinguir corrupção de uma negação legítima.

A consistência global não é incompatível com a segurança em etapas; exige simplesmente mais do que replicação rápida.

Falha aberta é uma decisão de negócio e segurança, não um slogan

O Google se comprometeu a modularizar o Service Control para que uma função de política afetada pudesse ser isolada e falhar aberta, permitindo que as solicitações de API continuassem se a verificação correspondente falhasse. Essa é uma correção significativa, mas a frase "falha aberta" precisa de limites. Uma verificação de cota, uma decisão de autenticação, um controle de faturamento e um controle de prevenção de abuso não carregam a mesma consequência quando indisponíveis.

Para uma verificação de cota de baixo risco, o serviço permissivo temporário pode ser mais seguro do que rejeitar todas as solicitações de API do cliente. O provedor pode reconciliar o uso posteriormente, limitar a exposição por projeto e preservar a disponibilidade principal. Para uma verificação de autorização, permitir solicitações cegamente poderia criar um incidente de segurança pior que a inatividade. Para criação de recursos, um cache local limitado de política recente pode ser mais seguro do que negação universal ou permissão universal.

O comportamento degradado correto depende do propósito do controle, da atualidade do estado confiável, da reversibilidade das ações e do potencial de fraude, perda de dados ou gastos descontrolados.

Aarquitetura de infraestrutura de serviçodo Google separa os planos de gerenciamento, controle e dados, ao mesmo tempo que mostra a amplitude das funções da plataforma: autenticação, autorização, cota, limitação de taxa, auditoria, faturamento, registro e monitoramento. Essa amplitude é precisamente por que o comportamento de falha modular é importante. Um analisador ou caminho de política não deve ser capaz de transformar todos os tipos de decisão na mesma resposta 503.

Um design responsável publicaria princípios em vez de detalhes de implementação sensíveis. Quais classes de verificação usam dados de último conhecido válido? Quais podem falhar abertas temporariamente? Quais falham fechadas porque a consequência de segurança domina? Quais limites permanecem durante o serviço degradado? Como o uso excepcional é reconciliado? Os clientes podem escolher um comportamento mais restritivo para cargas de trabalho regulamentadas? Como a plataforma distingue uma política de provedor inválida de uma negação legítima de cota do cliente?

Isso também muda os testes. Não basta confirmar que uma boa política retorna a resposta correta. Os testes devem injetar campos em branco, campos desconhecidos, versões desatualizadas, replicação parcial, objetos corrompidos, bancos de dados indisponíveis, leituras lentas e políticas conflitantes. Eles devem provar que um módulo pode ser contornado sem contornar salvaguardas não relacionadas. Eles devem medir o comportamento visível ao cliente durante a operação degradada e verificar se a recuperação não reproduz alterações rejeitadas ou duplicadas de forma imprevisível.

O sistema de status compartilhou a interrupção que deveria descrever

Por aproximadamente a primeira hora, os clientes não receberam um relatório público de incidente do Cloud Service Health porque essa infraestrutura estava inativa. Alguns clientes também executavam monitoramento no Google Cloud, então tanto o serviço quanto sua evidência do serviço falharam juntos. A interrupção prejudicou não apenas a produção, mas o controle epistêmico: a capacidade de saber o que estava acontecendo, decidir se deveria fazer failover e explicar a situação aos usuários.

Isso não foi inédito. Durante a interrupção global de autenticação do Google em 14 de dezembro de 2020, orelatório do incidentediz que as ferramentas internas do Cloud Support foram afetadas, os clientes não podiam criar ou visualizar casos de suporte no console e a comunicação do painel foi adiada até após o impacto principal terminar. Esse evento veio do gerenciamento automatizado de cota reduzindo a capacidade do sistema de identidade central. As configurações existentes do plano de dados de rede permaneceram operacionais, mas os serviços autenticados, acesso à API, consoles e muitas ferramentas internas não. O mecanismo difere de 2025; a preocupação recorrente é que identidade, suporte, monitoramento e comunicação podem compartilhar o destino com os serviços que deveriam diagnosticar.

O Google desde então documentou um modelo de comunicação mais explícito. Suaorientação de comunicação de incidentesdistingue o Personalized Service Health, que usa contexto de projeto e pode se integrar com alertas e APIs, do painel público Cloud Service Health. A mesma orientação reconhece que o Personalized Service Health depende de serviços como IAM e recomenda um fallback para o painel público e feed RSS quando os sistemas personalizados estão indisponíveis. Esse é um conselho sólido, mas junho de 2025 mostra que o canal público também precisa de independência operacional.

A obrigação do provedor é manter um caminho de publicação externamente acessível, alimentado e administrado independentemente, com modelos de incidente pré-autorizados e entradas fora de banda do comando de incidente. Não deve exigir o console normal, o plano de identidade do cliente, a pilha de monitoramento primária ou o serviço de controle sob investigação. O primeiro aviso não precisa conter uma causa raiz. Deve declarar sintomas observados, escopo conhecido, horário de início, se as operações do plano de controle ou cargas de trabalho existentes são afetadas, soluções alternativas disponíveis e o próximo horário de atualização.

Os clientes têm uma obrigação paralela. Oguia de integração do Personalized Service Healthdo Google diz explicitamente que o serviço não pode saber se cada produto é crítico para um determinado aplicativo ou se o aplicativo continua quando uma dependência falha. Os operadores precisam de suas próprias verificações de jornada do usuário, métricas de aplicativo, telemetria de rede e alarmes de processo de negócios. Pelo menos um caminho deve ser executado fora do Google Cloud e entregue a um canal de incidente que não dependa da identidade do Google. O status do provedor é corroboração, não o primeiro e único detector.

Há uma razão de governança para essa separação. Uma página de status atrasada muda o comportamento do cliente. As equipes podem perder tempo investigando suas próprias implantações, emitir rollbacks arriscados, escalar para um plano de controle quebrado ou adiar uma failover enquanto aguardam confirmação. O silêncio do suporte também pode levar provedores downstream a publicar especulações. A disponibilidade de comunicação é, portanto, um controle de risco com objetivos mensuráveis de detecção e publicação, não uma cortesia adicionada após o início do trabalho de engenharia.

Cargas de trabalho existentes sobreviveram melhor do que as ações destinadas a salvá-las

A declaração do relatório de 2025 de que os recursos existentes de streaming e infraestrutura como serviço não foram afetados deve ser lida com cuidado. Ela demonstra uma separação útil entre partes do plano de dados e o caminho de gerenciamento. Não significa que um aplicativo estava seguro apenas porque suas máquinas virtuais em execução permaneceram ativas.

Os sistemas de nuvem são dinâmicos. Os autoscaling criam instâncias. Os orquestradores substituem nós não saudáveis. Os sistemas de implantação buscam artefatos e emitem chamadas de API. Os bancos de dados fazem failover. Certificados e tokens são rotacionados. Os serviços serverless invocam caminhos de controle do provedor por trás de uma solicitação aparentemente simples. Os respondedores de incidentes alteram regras de firewall, balanceadores de carga, DNS, rotas, cotas e permissões. Um plano de dados estático pode continuar encaminhando enquanto o processo de negócios ao seu redor perde a capacidade de se adaptar.

A interrupção de rede de fevereiro de 2021 torna esse limite concreto. Orelatório de incidente do Google sobre falha de programação de redediz que um bug latente foi acionado quando o plano de controle de rede global reprocessou operações associadas a alterações de cota de peering. VMs e endpoints de rede novos, atualizados, excluídos ou migrados não puderam ser programados corretamente, enquanto muitas instâncias inalteradas continuaram operando. O Google pausou migrações ao vivo globalmente; cerca de 1.000 clusters GKE foram afetados pela incapacidade de provisionar nós ou clusters; algumas criações de instância e atualizações de balanceador de carga falharam em taxas muito altas. Um servidor existente saudável não ajudou um grupo de autoscaling que precisava de um novo servidor em rede.

Este é o paradoxo do plano de controle na recuperação de desastres. As ações no plano de recuperação são frequentemente menos testadas e mais dependentes do plano de controle do que o serviço comum. Um runbook pode dizer "criar capacidade na segunda região" ou "alternar o balanceador de carga", mas essas são operações de API. Se a interrupção inicial prejudica a criação de recursos ou as atualizações globais do balanceador de carga, a etapa de recuperação fica indisponível exatamente quando é necessária.

Oguia de arquitetura de recuperação de desastresdo Google distingue ações do plano de dados de atualizações do plano de controle e explica a resiliência específica do serviço. Seuguia de design de infraestrutura confiávelrecomenda evitar ou minimizar dependências de ações fora do plano de dados durante falhas, como criar um novo balanceador de carga. A lição prática é pré-provisionar o caminho de recuperação. A capacidade pode estar morna em vez de hipotética. Os endpoints regionais podem existir antes que o frontend global falhe. Registros DNS, credenciais, rotas, imagens e runbooks podem estar disponíveis sem uma operação administrativa de última hora.

Para cada etapa de recuperação, um operador deve ser capaz de nomear a API, provedor de identidade, caminho de rede, resolvedor DNS, repositório de artefatos, segredo e aprovação humana necessários. Em seguida, o exercício deve remover essas dependências uma de cada vez. Um plano que só é bem-sucedido enquanto o console, IAM, Service Control, programação de rede global e região primária estão todos saudáveis é um procedimento de expansão, não recuperação de desastres.

A interrupção de 2019 mostrou que a separação física pode compartilhar um limite de automação

Em 2 de junho de 2019, projetos do Google Cloud em várias regiões dos EUA experimentaram perda elevada de pacotes por mais de três horas. Alguns serviços do Google não conseguiram redirecionar totalmente os usuários para regiões não afetadas. Orelatório do incidente de rededescreveu múltiplas falhas que se combinaram em uma grande interrupção: trabalhos do plano de controle de rede foram configurados para parar para um evento de manutenção; várias instâncias de gerenciamento de cluster eram elegíveis para o mesmo tipo raro de evento; e um bug de software permitiu que a automação desagendasse clusters de software independentes mesmo quando estavam em localizações físicas diferentes.

A rede inicialmente continuou em "modo de falha estática" sem seu plano de controle. Vários minutos depois, as rotas BGP entre locais afetados foram retiradas, reduzindo a capacidade da rede e tornando algumas regiões inacessíveis. A falha das ferramentas de diagnóstico na rede congestionada atrasou a investigação. Quando os engenheiros restauraram as instâncias do plano de controle, a configuração teve que ser reconstruída e redistribuída, prolongando a recuperação.

Há uma notável semelhança estrutural com 2025. Em 2019, existiam localizações físicas e múltiplos gerenciadores de cluster, mas uma abstração de manutenção os selecionou juntos. Em 2025, existiam instâncias regionais do Service Control, mas uma política global as alcançou juntas. Ambos os incidentes envolveram um período de segurança que se mostrou muito curto ou muito dependente: roteamento de falha estática em 2019 e um bypass de botão vermelho em 2025. Ambos prejudicaram as ferramentas usadas para entender ou comunicar a interrupção.

Ambos os caminhos de recuperação tiveram que reconstruir ou redistribuir o estado de controle sob condições degradadas.

As causas não são intercambiáveis. O incidente de 2019 foi uma falha de controle de rede e automação de manutenção; o incidente de 2025 foi uma falha de dados de política e controle de API. A responsabilidade não deve nivelá-los em "Google teve outra interrupção." O valor da comparação é testar se a organização descobre repetidamente que componentes nominalmente independentes ainda compartilham um domínio administrativo, um mecanismo de propagação, uma ferramenta de emergência ou uma dependência de recuperação.

Os compromissos do Google em 2019 incluíram rejeitar as solicitações de manutenção implicadas, persistir a configuração local do plano de controle, estender a duração da operação de rede em modo de falha estática, endurecer as ferramentas de emergência e expandir os testes de recuperação de desastres. A questão atual de responsabilidade não é se essas ações teriam evitado o ponteiro nulo não relacionado de 2025. É se o método de governança por trás delas se tornou padrão: mapear autoridade comum, persistir estado seguro, manter controles de emergência fora do domínio de falha primário e testar falhas correlacionadas catastróficas.

Um programa de correção tem valor institucional apenas quando seu padrão de controle viaja além da equipe que escreveu o postmortem.

Diversidade de peering e trânsito é sobre destino, não contagem de circuitos

A disponibilidade da nuvem alcança os clientes através de redes. Uma carga de trabalho pode estar saudável dentro de uma região enquanto os usuários não conseguem alcançá-la porque uma borda, rota de backbone, sessão de peering, provedor de trânsito, caminho DNS ou interconexão híbrida falhou. Por outro lado, dois circuitos de acesso podem parecer diversos em uma ordem de compra, enquanto convergem em uma metrópole, um provedor, um modelo de roteador, uma borda do Google ou um sistema de controle.

Orelatório do incidente de backbonede 17 de março de 2021 do Google ilustra essa diferença. A conexão de novos roteadores alterou quais rotas certas funções de roteador recebiam. Essas rotas expuseram um defeito conhecido em um modelo específico de roteador, causando falha nos processos de roteamento. O redirecionamento automático reduziu o risco de uma cascata mais ampla, mas produziu perda de pacotes durante a convergência. Uma mitigação manual causou outro período de congestionamento, e alguns locais do Cloud Interconnect tiveram impacto prolongado porque a redundância de fornecedores de roteadores era insuficiente. O tráfego IP privado interregional, tráfego IP público, balanceadores de carga, túneis VPN e conectividade externa foram afetados em diferentes proporções.

É por isso que uma revisão de resiliência deve ir além de "temos dois links." A revisão deve perguntar quem possui cada caminho de fibra, qual edifício e domínio de disponibilidade de borda ele usa, qual fornecedor de roteador e versão de software o termina, qual Cloud Router controla suas sessões BGP, como as rotas reconvergem, se a capacidade de failover pode suportar toda a carga e se ambos os caminhos dependem do mesmo plano de controle do provedor. Ela deve observar as mudanças reais de rota e executar retiradas planejadas, não aceitar um diagrama de topologia como prova.

Avisão geral do Cloud Interconnectdo Google oferece configurações de 99,9% e 99,99% e explica que uma única conexão não tem SLA de disponibilidade. Aorientação do Partner Interconnectpede quatro anexos VLAN em duas metrópoles e domínios de disponibilidade de borda para sua topologia recomendada de 99,99%; também observa que o segmento do provedor fora da rede do Google precisa de sua própria garantia. Usar múltiplos provedores de serviço pode melhorar a disponibilidade, mas apenas se seus caminhos subjacentes forem realmente separados e tiverem capacidade suficiente durante o failover.

O peering dentro da nuvem não é trânsito por padrão. Adocumentação do VPC Network Peeringdo Google afirma que o peering não é transitivo: se a rede A faz peering com B e A também faz peering com C, B não ganha conectividade com C. Essa restrição pode ser um limite de contenção útil, mas surpreende equipes que assumem que uma VPC central atua automaticamente como um hub de trânsito. Durante uma interrupção, uma rota de recuperação improvisada pode falhar porque a topologia anunciada nunca foi suportada. Onde o trânsito é necessário, ele deve ser projetado explicitamente, com troca de rotas, política, capacidade, inspeção de segurança e comportamento de falha testados de ponta a ponta.

O trânsito da Internet merece a mesma precisão. O acesso público através de dois ISPs ainda pode entrar na rede do Google através de um local de peering comum. Uma interconexão privada e uma VPN de Internet podem oferecer melhor diversidade administrativa, mas ambas ainda podem depender do backbone do Google ou da mesma identidade e DNS do cliente. Uma segunda nuvem pode reduzir a concentração de provedores apenas se o aplicativo, dados, identidade, ferramentas de implantação, observabilidade e failover de DNS puderem operar lá independentemente. Uma contagem de logotipos não é uma arquitetura.

Multirregião é uma proteção forte contra a classe errada de falha

O design multirregional continua valioso. Pode proteger contra um evento de energia, uma perda de capacidade local, uma falha de hardware zonal e muitos problemas regionais de software. O erro não é usar várias regiões; é tratar a frase como uma declaração completa de independência.

O evento de rede de 2019 afetou várias regiões porque um limite de automação do plano de controle cruzou localizações físicas. O incidente de cota de peering de 2021 afetou a programação de rede globalmente porque o controlador relevante e os recursos VPC tinham escopo global. O evento do Service Control de 2025 afetou todas as regiões porque o plano de política era global. Em cada caso, mais réplicas de aplicativos dentro do domínio administrativo afetado não poderiam remover a causa comum.

A documentação de confiabilidade do Google faz uma distinção útil entre escopo de localização e confiabilidade do aplicativo. Recursos globais podem ser altamente resilientes a uma interrupção regional de infraestrutura, mas ainda se tornam pontos únicos de falha através da configuração. Recursos multirregionais podem sobreviver à perda de uma região, mas permanecem dependentes de identidade global, gerenciamento de API, controle de rede ou um frontend global. Os clientes precisam de um gráfico de dependências que marque tanto a geografia quanto a autoridade.

Esse gráfico deve incluir pelo menos cinco camadas. Primeiro, execução: onde processos e dados realmente são executados. Segundo, controle: quais APIs criam, roteiam, autorizam, escalam e fazem failover desses recursos. Terceiro, acesso: quais caminhos DNS, peering, trânsito, interconexão, VPN e backbone conectam usuários e operadores. Quarto, observação: onde logs, métricas, feeds de status, paginação e suporte residem. Quinto, recuperação: quais repositórios, credenciais, humanos e serviços externos são necessários para restaurar a operação.

Uma dependência é independente apenas se o mesmo evento crível não puder desativá-la junto com a primária. Duas regiões controladas por uma política global inválida não são independentes para esse evento. Duas pilhas de monitoramento entregues através do mesmo sistema de identidade não são independentes para uma interrupção de autenticação. Dois circuitos no mesmo software de roteador não são independentes para o defeito relevante do fornecedor. Um serviço morno em outra nuvem não é independente se o único controle de DNS, repositório de artefatos ou login do operador reside no Google Cloud.

Esta análise não deve se tornar uma exigência cara de que toda pequena carga de trabalho opere em três provedores. Os controles devem ser proporcionais. Um site de informações públicas pode aceitar algumas horas de inatividade e manter uma página de status externa. Um serviço de autorização de pagamento pode precisar de capacidade pré-provisionada, trânsito independente, monitoramento externo e um provedor secundário testado. O ato responsável é saber quais dependências permanecem comuns, precificar a consequência e obter aceitação explícita do proprietário do negócio.

Cloudflare transformou um incidente de provedor em uma lição de dependência para outro

O evento de junho de 2025 atravessou uma fronteira corporativa de maneira particularmente instrutiva. Opróprio relatório de interrupção da Cloudflarediz que o Workers KV dependia parcialmente de um provedor de nuvem terceirizado. Quando essa dependência falhou, o Workers KV ficou indisponível e um amplo conjunto de produtos Cloudflare que o utilizavam foram prejudicados, incluindo Access, Gateway, WARP, Turnstile, Images, Stream, partes do painel e outros serviços. O CDN principal e os serviços de segurança da Cloudflare não estavam uniformemente inativos, mas a dependência tornou uma falha do plano de controle do Google Cloud visível através de produtos vendidos sob o nome de outro provedor.

Isso não é evidência de que terceirizar seja inerentemente irresponsável. Os provedores sensatamente compram serviços uns dos outros. É evidência de que a distância comercial de uma dependência não reduz sua consequência operacional. Um cliente pode acreditar que diversificou ao comprar Google Cloud para infraestrutura e Cloudflare para segurança de borda, mas um serviço de controle da Cloudflare pode depender do Google Cloud. A cadeia resultante pode ser Google Cloud para Workers KV para Access para o login do operador do cliente.

Sem divulgação e testes, o cliente não pode ver que o controle secundário compartilha o domínio de falha primário.

A Cloudflare aceitou sua parte na responsabilidade. Seu relatório descreveu quais serviços dependiam do Workers KV, observou que o serviço principal não fez failover inicialmente do caminho de armazenamento de terceiros e delineou trabalhos para reduzir ou remover dependências para produtos críticos. O Google continua responsável pela falha da plataforma upstream; a Cloudflare continua responsável por decidir que um serviço interno crítico poderia depender dela sem continuidade adequada; o cliente final continua responsável por avaliar se o acesso aos seus próprios sistemas tem uma rota de emergência.

Esses deveres são concorrentes, não mutuamente exclusivos.

Acobertura contemporânea da Associated Pressregistrou interrupção visível em serviços online populares e dezenas de milhares de relatos de usuários. Essa cobertura é útil para demonstrar alcance público, mas as contagens de relatos de interrupção não são um censo de pessoas afetadas, solicitações ou perda financeira. A evidência mais forte vem dos relatórios técnicos dos provedores e dos dados de transação dos clientes. A responsabilidade deve resistir tanto à subestimação quanto ao espetáculo: uma ampla cascata de dependências é importante mesmo quando nenhum total preciso de perda global está disponível.

Contratos e revisões de arquitetura devem, portanto, pedir aos provedores que identifiquem dependências materiais de quarta parte para funções de controle, identidade, configuração, status e recuperação. Eles devem especificar deveres de notificação quando um evento upstream for responsável, preservar logs que permitam aos clientes reconciliar o impacto e definir se o provedor tem uma alternativa testada.

O cliente pode não receber um mapa completo de fornecedores por razões de segurança e comerciais, mas deve receber segurança suficiente para entender a concentração por nuvem, plataforma de identidade, operadora de rede e plano de controle geográfico.

Um crédito de SLA não prova que a dependência é aceitável

Os acordos de nível de serviço são úteis porque definem um compromisso mensurável e uma reparação. Eles não são uma avaliação de risco completa. Uma porcentagem mensal de disponibilidade calcula a média do tempo e frequentemente se aplica a um produto específico ou topologia configurada. Pode excluir configuração do cliente, segmentos terceirizados, cotas, recursos de pré-visualização ou falhas fora do serviço coberto. A reparação é geralmente um crédito contra gastos futuros, não uma compensação por receita perdida, trabalho de emergência, exposição regulatória ou danos aos usuários do cliente.

OSLA atual do Cloud Interconnect, por exemplo, diferencia topologias de nível de produção de conexões únicas e exige evidência do cliente para reivindicações. Esse quadro pode incentivar uma topologia sólida, mas não pode dizer a um conselho se uma perda de quatro horas de acesso híbrido é tolerável. Nem um SLA específico de produto descreve a falha correlacionada entre a API usada para alterar um serviço, o monitoramento usado para observá-lo e o canal de suporte usado para reportá-lo.

O cliente precisa de um objetivo de nível de serviço para sua própria jornada do usuário. Esse objetivo deve incluir os produtos de nuvem, caminhos de rede, serviços internos e fornecedores necessários para completar a jornada. Deve medir tanto o serviço em estado estacionário quanto as ações de recuperação. Um fluxo de checkout que permanece ativo, mas não pode adicionar capacidade, pode estar saudável agora e em risco imediato. Um banco de dados que serve leituras, mas não pode promover uma réplica, pode ter recuperabilidade degradada mesmo antes de os usuários verem erros.

Os termos de responsabilidade e crédito do Google são alocações legais, não evidência de engenharia. Por outro lado, um pedido público de desculpas do provedor não é prova de negligência ou uma admissão legal. Este artigo atribui responsabilidade operacional e de governança com base no controle: quem projetou o caminho de propagação, quem aceitou a dependência, quem poderia testá-la e quem deve verificar a correção. A responsabilidade legal depende de contrato, jurisdição, fatos e adjudicação fora do escopo de um relatório técnico de incidente.

Os conselhos devem, portanto, pedir exposição quantificada além da disponibilidade do fornecedor. Quanta receita ou serviço público depende de uma operação do plano de controle? Por quanto tempo os recursos já em execução podem servir sem escalar ou sem credenciais? Qual é o tempo para mover usuários através de um caminho de trânsito alternativo? Quais recuperações exigem o provedor com falha? Que evidência existe do último exercício? Um crédito de serviço pertence ao registro financeiro; nunca deve ser confundido com continuidade.

A lista de correções do Google é crível apenas quando se torna evidência

O relatório do incidente de 2025 contém um conjunto forte de compromissos. O Google congelou as alterações do Service Control e os pushes manuais de política após a recuperação.

Disse que modularizaria o serviço e falharia aberto quando apropriado, auditaria sistemas que consomem dados replicados globalmente, propagaria esses dados incrementalmente com tempo de validação, exigiria que binários críticos fossem protegidos por feature flags desabilitadas por padrão, melhoraria a análise estática e os testes de dados inválidos, auditaria o backoff exponencial aleatório, melhoraria as comunicações externas e manteria o monitoramento e a comunicação disponíveis quando o Google Cloud estivesse inativo.

Essas ações correspondem excepcionalmente bem à cadeia de falhas observada. A questão restante é a garantia. Uma promessa pode fechar uma ação de postmortem em um sistema de rastreamento sem provar que o risco diminuiu na produção. O Google deve publicar o status de conclusão, o método de validação e os limites residuais para as ações de maior impacto, mesmo que a arquitetura detalhada permaneça confidencial.

Para a segurança de políticas globais, as evidências poderiam incluir a porcentagem de consumidores críticos de política por trás de ativação em etapas; taxas de rejeição automatizada para dados candidatos malformados; intervalos mínimos de observação antes da autoridade global; e exercícios bem-sucedidos em que um objeto ruim é interrompido em um coorte. Para o isolamento de falhas, poderia incluir testes mostrando que um módulo de cota pode falhar enquanto verificações de API não relacionadas continuam e que decisões sensíveis à segurança retêm seu limite pretendido.

Para a recuperação, o Google deve mostrar limites de reinicialização da frota, conformidade de backoff, capacidade reservada do banco de dados e resultados de teste de carga para recuperação regional simultânea. Para a comunicação, deve publicar o tempo desde o primeiro impacto no cliente até a detecção interna, o primeiro aviso público, a primeira declaração de impacto com escopo e a disponibilidade do caminho de status independente durante os exercícios. Para o aprendizado institucional, deve relatar se consumidores globais semelhantes fora do Service Control foram encontrados e corrigidos.

Incidentes anteriores aumentam a necessidade desse acompanhamento. Após 2019, o Google prometeu operação de rede em modo de falha estática mais longa, configuração de controle persistente, ferramentas de emergência robustas e testes expandidos de catástrofe. Após fevereiro de 2021, prometeu maior regionalização dos componentes globais do plano de controle de rede, pausas automáticas para migrações e melhor resiliência do plano de dados quando os controladores estivessem inativos. Após março de 2021, prometeu domínios funcionais para aplicação de política de rota e testes melhorados de construção de roteadores.

Cada compromisso pode ter sido concluído dentro de seu próprio programa; o registro público não fornece uma visão de garantia contínua que mostre como o risco de modo comum da plataforma mudou ao longo do tempo.

O livro de SRE do Google descrevepostmortems como um sistema de aprendizado, com itens de ação vinculados a causas e sem reduzir incidentes complexos a culpa individual. O mesmo princípio apoia a responsabilidade externa. O objetivo de publicar evidências não é expor um funcionário ou convidar os clientes a administrar a rede do Google. É permitir que os clientes distingam uma solução alternativa temporária de um controle durável, vejam o que permanece em aberto e decidam se seu próprio tratamento de risco é adequado.

Uma revisão independente agregaria valor para os controles mais globais. Poderia amostrar documentos de design, registros de implantação, resultados de injeção de falhas, independência do botão vermelho e fechamento de ações. A saída pública poderia declarar escopo, exceções e conclusões sem revelar internos exploráveis. O auto-relato fornece profundidade técnica; a garantia independente fornece confiança de que os critérios de fechamento não foram definidos apenas pela equipe responsável pela entrega.

O que os clientes devem testar antes do próximo incidente global

Nenhum cliente pode fazer feature flag do binário interno do Service Control do Google ou alterar como suas tabelas de política se replicam. Conselhos que dizem aos clientes apenas "arquitetar melhor" após uma falha generalizada do provedor transferem a responsabilidade injustamente. Ainda assim, os clientes fazem escolhas consequentes sobre quanta autoridade uma interrupção do provedor tem sobre seus negócios.

Comece pelo caminho de serviço. Identifique quais transações do usuário continuam se todas as APIs de gerenciamento do Google Cloud estiverem indisponíveis por três horas. Teste com novas implantações pausadas, autoscaling congelado, alterações de IAM indisponíveis, modificações de balanceador de carga bloqueadas e suporte inacessível. Meça quando capacidade, credenciais, certificados, filas ou trabalhos agendados se tornam o fator limitante. O resultado será frequentemente uma curva em vez de uma resposta binária: o serviço continua na carga atual por um período, depois degrada à medida que as ações de controle de rotina se acumulam.

Em seguida, teste o acesso do operador. Mantenha credenciais de emergência cuja recuperação e verificação não exijam o caminho de identidade principal da nuvem. Mantenha um espaço de trabalho mínimo de incidentes, lista de contatos, runbooks, diagramas de arquitetura e editor de status fora do Google Cloud. Garanta que a equipe possa alcançar operadoras de rede e fornecedores críticos sem o conjunto de colaboração corporativa se ele compartilhar a identidade do Google. Audite toda ferramenta de emergência em busca de dependências ocultas de DNS, e-mail, login único e segredos.

Depois, teste os caminhos de rede. Retire cada sessão BGP e anexo de interconexão durante um exercício controlado. Confirme que o tráfego se move através da metrópole e provedor pretendidos, meça a perda de convergência e verifique se a alternativa tem capacidade de carga total. Verifique se o fallback da Internet pública não está bloqueado por firewall, roteamento ou suposições de endereço de origem. Para peering VPC, prove as rotas exatas importadas e exportadas e não assuma transitividade. Para trânsito multi-nuvem, teste a consistência dos dados e a identidade, bem como os pacotes.

Pré-provisione o que não pode ser criado durante uma interrupção do plano de controle. Isso pode incluir balanceadores de carga regionais, registros DNS, clusters secundários, bancos de dados em espera, cotas, contas de serviço, artefatos e túneis de rede. Mantenha as alterações pequenas o suficiente para que uma configuração de último conhecido válido permaneça utilizável. Pratique um modo degradado que elimine recursos não essenciais em vez de emitir uma rajada de repetições ou solicitações de escala para um provedor prejudicado.

Finalmente, reconcilie após o exercício. Determine quais transações falharam, quais foram repetidas, quais duplicadas, quais permaneceram na fila e quais clientes precisam de notificação. A restauração do provedor não garante a correção do aplicativo. Os objetivos de recuperação devem incluir a limpeza da pendência e a validação dos dados, não apenas uma verificação de saúde HTTP.

Para organizações menores, a versão proporcional pode ser modesta: uma verificação de disponibilidade externa, uma página de status em outro provedor, detalhes de contato e runbooks exportados, backups testados, procedimentos manuais conhecidos e uma decisão documentada sobre se o custo multi-nuvem é justificado. Responsabilidade não é sinônimo de arquitetura máxima. É a capacidade de mostrar que uma decisão de risco consciente substituiu uma dependência acidental.

Um scorecard para responsabilidade do plano de controle e rede

Um conselho, regulador ou grande cliente não precisa de código-fonte proprietário para fazer perguntas precisas. Precisa de evidências que correspondam aos modos de falha observados.

O scorecard deve ser lido em todas as linhas. Uma feature flag sem status independente não é suficiente. Quatro anexos de interconexão sem diversidade de provedor e roteador podem não ser suficientes. Um aplicativo multirregional sem recuperação pré-provisionada ainda pode depender do controlador global. A confiabilidade vem da composição dos controles e da evidência de que a composição funciona sob falha.

O sinal duradouro é a velocidade da autoridade compartilhada

As plataformas de nuvem criam valor ao centralizar decisões. Uma política pode governar milhares de projetos. Uma rede pode transportar tráfego entre continentes. Uma API pode criar infraestrutura em segundos. A mesma alavancagem determina o raio de explosão do erro.

A interrupção de junho de 2025 não é, portanto, melhor lembrada como um ponteiro nulo. Ponteiros nulos são defeitos de software comuns. O que tornou este globalmente consequente foi que código adormecido, política inválida, replicação rápida, leitores regionais, reinicialização sincronizada, monitoramento compartilhado e provedores downstream formaram uma única cadeia. O sistema era distribuído, mas a autoridade não estava suficientemente particionada.

A resposta do Google identificou os temas certos: propagação incremental, feature flags, falha modular, backoff e comunicação independente. Os clientes devem esperar prova de que essas mudanças funcionam, ao mesmo tempo que são honestos sobre os riscos que ainda possuem. Uma carga de trabalho pode estar espalhada por regiões e ainda depender de uma decisão global. Uma empresa pode comprar duas redes e ainda usar uma rota para o destino. Uma página de status pode ser pública e ainda viver dentro do incidente.

O padrão de responsabilidade adequado não é que uma nuvem global nunca deve falhar. É que a autoridade global não deve se mover mais rápido do que os controles que a validam; que os sistemas regionais devem ser capazes de rejeitar ou sobreviver a estado comum inseguro; que os caminhos de rede e recuperação devem ser independentes na operação, não apenas nos nomes; e que os clientes devem ser capazes de ver a falha enquanto ainda há tempo para agir. Em um plano de controle de nuvem, velocidade é poder. A resiliência começa colocando limites onde esse poder pode viajar.