A perda de disco do Google Cloud na Bélgica mostra onde a localidade deixa de ser resiliência

Resumo

• Em agosto de 2015, os discos persistentes padrão do Google Compute Engine na zona europe-west1-b apresentaram erros de leitura após quatro quedas de raios sucessivas que afetaram a rede elétrica local que alimenta um data center europeu. O Google posteriormente informou que uma fração muito pequena do espaço de disco persistente alocado na zona sofreu gravações recentes irrecuperáveis.
• A questão de responsabilidade não é se a porcentagem era alta. Trata-se de saber se os clientes entendiam que um disco persistente zonal, mesmo com redundância gerenciada pelo provedor na zona, permanecia em um domínio de falha física e não substituía snapshots independentes, replicação regional ou backup em nível de aplicativo.
• O Google controlava a resiliência do local físico, a sensibilidade do hardware de armazenamento, o gerenciamento de eventos elétricos, a linguagem de durabilidade dos discos persistentes, os relatórios de status e a clareza das orientações de backup. Os clientes controlavam a arquitetura da carga de trabalho, os cronogramas de snapshots, os objetivos de recuperação, as escolhas de replicação e a possível confusão entre requisitos de localidade e recuperabilidade.
• O registro prático de reparos deve distinguir serviço restaurado, dados irrecuperáveis, solução alternativa por snapshot, modificações de hardware e software, orientações de backup e evidências do cliente. Em um incidente de nuvem envolvendo perda de dados, uma página de status verde não pode ser a única prova de recuperação.

Uma pequena porcentagem ainda pode ser uma falha grave

O incidente do Google Cloud na Bélgica é às vezes visto como uma curiosidade porque a porcentagem de armazenamento permanentemente perdido era extremamente baixa. Essa é a perspectiva errada. Para um cliente cujo disco continha a gravação recente irrecuperável, a porcentagem não importava. A questão relevante era se o cliente tinha uma cópia independente recuperável, se o aplicativo podia tolerar o ponto de recuperação e se a linguagem de durabilidade do provedor havia tornado o risco residual do local físico suficientemente claro antes do evento.

O incidente público nº 15056 do Google Compute Engine começou em 13 de agosto de 2015 para discos persistentes em europe-west1-b. A página de status primeiro relatou erros de leitura para clientes com máquinas nessa zona, depois explicou que menos de 1% dos discos da zona estavam sujeitos a degradação de desempenho, e depois que menos de 0,1% encontravam falhas de leitura em alguns blocos. O relatório do incidente também informou aos clientes afetados que a restauração a partir de snapshots era uma solução alternativa, enquanto a criação de novos discos persistentes e a restauração a partir de snapshots não eram afetadas.

As reportagens da mídia que capturaram a explicação posterior do incidente, incluindo o relatório do Data Center Dynamics sobre os raios e a perda de dados e a matéria do Silicon UK sobre a causa da falha, registraram a declaração do Google de que quatro quedas de raios sucessivas na rede elétrica local causaram uma breve perda de energia dos sistemas de armazenamento que hospedavam a capacidade de disco para instâncias GCE em europe-west1-b.

O Google afirmou que quase todos os dados foram confirmados em armazenamento estável, mas em casos muito raros, gravações recentes eram irrecuperáveis, resultando em perda permanente de dados no disco persistente. O número amplamente repetido foi inferior a 0,000001% do espaço de disco persistente alocado na zona afetada.

Este relatório defende tanto a moderação quanto a seriedade. Seria errado descrever o evento como uma destruição generalizada de dados no Google Cloud. O serviço afetado foi o disco persistente padrão em uma única zona; discos persistentes SSD, snapshots e SSDs locais foram relatados pelos post-mortem e pela cobertura contemporânea como estando fora da população de perda permanente. Também seria errado descartar o incidente porque o denominador era enorme. A durabilidade dos dados é um fato binário para o caso que importa. Uma pequena porcentagem irrecuperável ainda é uma perda permanente para alguém.

Portanto, a questão de responsabilidade não é "Por que os raios existiam?" O raio é um perigo externo. A questão é quem controlava as escolhas de design que permitiram que um evento elétrico repetido na rede elétrica atingisse o estado de gravação recente do disco, quem controlava a clareza das diretrizes de durabilidade e backup, e quem controlava a arquitetura do cliente que tinha ou não um ponto de recuperação independente. O gatilho foi físico. O problema fundamental de responsabilidade era a fronteira entre a durabilidade local gerenciada pelo provedor e a recuperabilidade gerenciada pelo cliente.

Localidade e durabilidade não são a mesma promessa

A localidade em nuvem resolve problemas reais. Um cliente pode escolher europe-west1 por latência para usuários belgas ou europeus, por razões de fornecimento, por características de carbono mais baixas ou por compromissos de localização de dados. A página atual de locais de nuvem do Google e a documentação sobre regiões e zonas do Compute Engine explicam que os recursos vivem em regiões e zonas, e que zonas e regiões são abstrações lógicas dos recursos físicos subjacentes. Essa abstração é útil porque os clientes não precisam gerenciar os prédios. É perigosa se os clientes deduzirem que um recurso zonal escapou do domínio de falha física.

A soberania dos dados e a localidade dizem respeito a onde os dados são armazenados ou processados. A recuperabilidade diz respeito à questão se outra cópia utilizável existe após uma falha. Um disco pode satisfazer um requisito de localização e ainda assim ser a arquitetura de durabilidade errada para um banco de dados se seu único estado recuperável estiver na mesma zona e na mesma classe de armazenamento. Um snapshot pode satisfazer a recuperação, mas pode ter suas próprias escolhas de localização. Um disco regional pode aumentar a disponibilidade entre zonas, mas pode não satisfazer cada objetivo de ponto de recuperação.

Um segundo provedor pode reduzir a dependência comum, mas pode aumentar a complexidade operacional e o risco de governança de dados. Essas são dimensões diferentes.

As condições atuais de residência de dados do Google e o material sobre compromissos europeus especificam onde os dados dos clientes podem residir para os serviços suportados. Eles não transformam cada recurso local em um backup independente. Da mesma forma, a página do produto Persistent Disk descreve um armazenamento de blocos durável, e a documentação do Persistent Disk do Compute Engine afirma que o Persistent Disk possui redundância integrada para proteger contra falhas de equipamento e manter a disponibilidade dos dados durante operações de manutenção. Esses são compromissos significativos do provedor.

Eles não garantem que qualquer perigo possível em todo o site deixará zero gravações recentes irrecuperáveis em todas as configurações.

O incidente de 2015 expôs a lacuna de interpretação. Um cliente poderia ler "persistente" como significando que o disco sobrevive a uma máquina virtual, o que é correto. Outro poderia ler como significando que o disco é imune à perda de dados, o que não é uma inferência segura. Um cliente poderia ler "Europa" ou "Bélgica" como a principal decisão de conformidade e parar por aí. O incidente mostra que a localização não é um plano de recuperação. O mesmo posicionamento local que ajuda a latência e a política pode concentrar o risco físico se nenhum backup independente existir.

A linguagem do provedor deve, portanto, ser explícita sobre os domínios de falha. Um disco persistente zonal é durável em seu design, mas permanece vinculado a uma zona. Snapshots, discos regionais, replicação e backup em nível de aplicativo alteram o modelo de falha. Os clientes precisam dessa distinção antes de um incidente, não apenas depois que uma página de status lhes disse para restaurar a partir de snapshots. A divulgação de maior valor é um mapeamento claro da escolha de armazenamento para o domínio de falha, o ponto de recuperação, o tempo de recuperação e o dever do cliente.

O gatilho físico pertence ao relatório de responsabilidade em nuvem. A nuvem pode fazer a infraestrutura física desaparecer do trabalho diário do cliente, mas não faz os perigos físicos desaparecerem. Sistemas de energia, baterias, controladores de armazenamento, firmware, racks, distribuição elétrica e eventos da rede elétrica continuam sendo parte integrante do serviço. O cliente paga o provedor para gerenciar essas camadas porque o provedor tem maior escala e experiência. Isso torna a resiliência física um dever do provedor, enquanto deixa a arquitetura de recuperação do aplicativo parcialmente com o cliente.

A explicação do incidente relatada por várias mídias indicava que os sistemas auxiliares automáticos restabeleceram rapidamente a energia e que os sistemas de armazenamento foram projetados com bateria de reserva, mas alguns dados recém-escritos estavam em sistemas mais sensíveis a falhas de energia prolongadas ou repetidas. Essa frase é importante porque distingue um único raio de um estresse físico repetido que encontrou um subconjunto vulnerável de armazenamento.

Também mostra por que o enquadramento de "discos antigos" usado em algumas reportagens deve ser tratado com cautela: os artigos públicos descreviam a sensibilidade do hardware, mas o relatório de status público não publica cada componente, idade ou decisão interna de engenharia.

O Google teria declarado ter realizado uma ampla revisão da distribuição elétrica, hardware de computador e software que controla a camada Persistent Disk, e que estava atualizando o hardware de armazenamento para torná-lo menos sensível a esse tipo de falha de energia. O relatório atualizado do Data Center Knowledge registrou que o Google estava substituindo os sistemas de armazenamento por hardware mais resiliente e que a maior parte do armazenamento Persistent Disk já estava em hardware mais recente. Essas são medidas reativas.

Elas devem ser entendidas como controles do lado do provedor sobre a pilha física e de armazenamento, e não como ações de arquitetura do cliente.

O provedor também controlava o status do incidente. A página de status da nuvem forneceu atualizações repetidas, porcentagens de impacto e orientações de solução alternativa por snapshot. Este relatório é materialmente melhor que o silêncio. No entanto, passou de erros de leitura e desempenho degradado para perda permanente à medida que a investigação avançava. Os clientes precisavam saber quais discos tinham erros de leitura, se os snapshots eram utilizáveis, se novos discos podiam ser criados, quais gravações eram irrecuperáveis e se o armazenamento era seguro para novas cargas de trabalho.

Em um evento de perda de dados, a classificação do impacto não é apenas sobre a disponibilidade do serviço; é sobre o estado recuperável.

A página de status terminou quando o Google marcou o incidente como resolvido. Para os clientes que restauraram a partir de snapshots, a recuperação continuou pela validação do aplicativo, reconciliação de dados e possível perda de transações recentes. Essa distinção é essencial. A restauração do serviço pelo provedor significa que o serviço de armazenamento está funcionando. A recuperação pelo cliente significa que a carga de trabalho tem um conjunto de dados consistente e a empresa pode prestar contas do intervalo perdido. Esses momentos podem ser muito diferentes.

As orientações sobre snapshots tornam a responsabilidade compartilhada concreta

A atualização de status do Google durante o incidente informou aos clientes afetados que eles podiam restaurar a partir de snapshots. Essa recomendação só é útil para clientes que tinham snapshots utilizáveis. Um snapshot que não existe, é muito antigo, está no lugar errado, carece de consistência de aplicativo ou nunca foi testado não é um caminho de recuperação. O incidente, portanto, transformou uma frase comum em nuvem, responsabilidade compartilhada, em uma questão concreta: quem realmente havia criado e verificado um ponto de recuperação antes do evento físico?

O guia atual do Google sobre opções de proteção de dados para discos e instâncias enquadra a recuperação em torno do objetivo de tempo de recuperação, objetivo de ponto de recuperação, caso de uso e custo. A documentação sobre criação de snapshots explica os snapshots padrão e de arquivo. A visão geral dos snapshots descreve snapshots incrementais. O guia de snapshots programados recomenda cronogramas como prática de backup, e a página de melhores práticas para snapshots adiciona restrições práticas e dicas de confiabilidade. Essa documentação atual é mais clara do que muitas suposições da primeira era da nuvem.

A consistência do aplicativo continua sendo uma preocupação do cliente. Um snapshot de disco captura o estado dos blocos; um banco de dados pode exigir uma pausa, um dump ou operações de backup coordenadas para tornar o estado restaurado utilizável. A documentação do Google sobre snapshots Linux consistentes em nível de aplicativo explica os cronogramas de snapshots com dump convidado. O ponto importante não é o conjunto exato de recursos em 2015 em comparação com hoje. É o princípio de controle sustentável: a recuperabilidade requer um processo de backup alinhado ao aplicativo, não apenas uma promessa de armazenamento do provedor.

As pequenas equipes estão particularmente expostas a essa lacuna. Uma startup ou projeto municipal pode escolher uma única zona de nuvem para reduzir latência e custos. Pode executar um banco de dados em um disco persistente e confiar no nome do produto e na reputação do provedor como substituto para o design de backup. Pode não ter um engenheiro de armazenamento dedicado, processo de restauração testado ou análise de impacto nos negócios.

O incidente de 2015 mostra por que a documentação e os padrões dos produtos são importantes: clientes com menos experiência interna precisam de opções de armazenamento e avisos que tornem a fronteira do domínio de falha evidente.

Os deveres do provedor e do cliente devem ser declarados em linguagem operacional. O Google deve projetar o sistema de armazenamento para sobreviver aos perigos físicos esperados, publicar informações claras sobre o domínio de falha, fornecer ferramentas de snapshot e replicação, preservar evidências do incidente e identificar os recursos afetados. O cliente deve selecionar um objetivo de recuperação, programar backups, validar restaurações, colocar snapshots ou réplicas fora do domínio de falha relevante e decidir se as restrições de localidade permitem cópias fora da zona ou fora da região.

Nenhuma das partes pode fazer inteiramente o trabalho da outra.

Discos regionais e replicação alteram o modelo de falha, não a necessidade de reflexão sobre recuperação

O Google agora oferece opções de alta disponibilidade de disco persistente regional e Hyperdisk. A documentação sobre discos regionais explica discos replicados entre zonas em uma região para maior disponibilidade, e o guia de failover de discos regionais descreve a anexação forçada em caso de falha da zona primária. O blog do Google sobre discos persistentes regionais para cargas de trabalho de alta disponibilidade torna explícito o caso de uso de disponibilidade.

Esses recursos são melhorias significativas para muitas cargas de trabalho, mas não eliminam o julgamento sobre a arquitetura. A replicação regional pode proteger contra indisponibilidade zonal ou erros de armazenamento em uma zona. Pode não proteger contra corrupção em nível de aplicativo que é replicada, exclusão pelo cliente, credenciais comprometidas, um problema de controle em toda a região ou um ponto de recuperação muito recente para ser útil. Um cliente ainda precisa de backups para corrupção, retenção e reversão.

Um disco replicado é um mecanismo de alta disponibilidade; não é automaticamente um programa completo de proteção de dados.

A mesma cautela se aplica aos snapshots. Um snapshot pode ser independente do disco com falha e pode ser restaurado em outra zona. Ainda pode ser muito antigo, inconsistente em nível de aplicativo, indisponível para o projeto correto, criptografado com uma chave que o ambiente de recuperação não pode acessar ou armazenado em um local que entra em conflito com a política. A documentação do Google sobre criptografia de discos lembra os clientes de que discos e snapshots podem envolver diferentes escolhas de chaves.

A estratégia de backup deve incluir acesso, chaves, retenção, localização e testes de restauração, não apenas a existência de uma entrada de snapshot.

O SLA atual do Compute Engine e a versão histórica do SLA de 2015 mostram outra distinção. Os SLAs tratam da disponibilidade do serviço e créditos sob condições definidas. Eles não são uma declaração completa de recuperabilidade ou perda comercial. Um crédito pode compensar uma fração das taxas de serviço, enquanto o cliente ainda precisa restaurar dados, reconciliar transações, notificar usuários ou reconstruir confiança. O fato de a página de status ter informado aos clientes afetados para restaurar a partir de snapshots mostra que a recuperação operacional estava fora da questão do crédito SLA.

Para os proprietários de soberania de dados, as escolhas de replicação exigem um trabalho político cuidadoso. Um cliente pode exigir que os dados permaneçam na Europa ou na Bélgica. Isso não significa que todas as cópias devem estar em uma única zona. Pode permitir snapshots em uma multirregião europeia ou outra região europeia, dependendo das condições do serviço, expectativas dos reguladores e apetite ao risco. Por outro lado, um requisito rigoroso de localização pode impedir alguns backups inter-regionais e exigir um design de disponibilidade local mais alto. O ato responsável é tornar essa compensação explícita antes da perda de dados.

As evidências de recuperação do cliente fazem parte do incidente

Os relatórios de incidentes dos provedores geralmente terminam na restauração do serviço. Eventos de perda de dados exigem um segundo registro: as evidências de recuperação do cliente. Quais discos tiveram erros de leitura? Quais gravações eram irrecuperáveis? Quais clientes restauraram a partir de snapshots? Quais snapshots falharam ou eram muito antigos? Quais aplicativos exigiram reconciliação manual? Quais cargas de trabalho do cliente não tinham backup? Quais mensagens foram enviadas aos clientes sobre perda permanente e etapas de solução alternativa? Parte dessas evidências é privada, mas as categorias importam publicamente.

As porcentagens de impacto repetidas na página de status foram úteis porque evitavam uma reasseguração vaga. Menos de 1% suscetível, menos de 0,1% com falhas de leitura e menos de 0,000001% de perda permanente descrevem categorias decrescentes. Elas não devem ser fundidas em uma única declaração. Discos suscetíveis, discos com falha ativa e dados irrecuperáveis são estados diferentes. Um cliente em cada estado precisa de uma ação diferente.

O cliente também precisa de um aviso específico ao recurso. Uma página de status geral informa ao mercado que algo está errado. Não diz a um operador de banco de dados se um disco específico é afetado. O Google tinha a maior capacidade de identificar os recursos afetados, correlacionar sistemas de armazenamento e fornecer avisos em nível de conta. Os clientes tinham a maior capacidade de verificar a consistência do aplicativo, restaurar a partir de seus próprios snapshots e decidir quais dados comerciais recentes podem estar faltando. Ambos os tipos de evidências são necessários.

Essa divisão é particularmente importante para auditores. Um auditor examinando uma carga de trabalho em nuvem após tal evento não deve perguntar apenas se o provedor relatou uma pequena porcentagem. As perguntas certas são se a organização conhecia seu objetivo de ponto de recuperação, se os snapshots existiam antes do incidente, se os testes de restauração foram bem-sucedidos, se os locais de backup correspondiam à política, se os proprietários do aplicativo aceitaram a perda residual e se o aviso do provedor forneceu detalhes suficientes para classificar os recursos afetados.

Se a resposta for não, a falha não foi apenas um incidente do provedor; foi também uma lacuna de governança de arquitetura.

As compras devem fazer as mesmas perguntas com antecedência. Qual domínio de falha este disco ocupa? Que cópia independente existe? Quem possui os cronogramas de snapshots? Como as restaurações são testadas? Qual é o intervalo máximo tolerável de perda de gravação? A política de localidade permite uma réplica em outro lugar? Que aviso o provedor dará se a mídia de armazenamento, energia ou sistemas de controle ameaçarem a durabilidade dos dados? Qual é o caminho de suporte durante um evento de perda de dados? Essas perguntas transformam a "durabilidade em nuvem" de um slogan em uma decisão de risco.

As compras não devem comprar uma região como se fosse um backup

O incidente belga é particularmente útil para compras porque expõe um atalho comum. Um comprador pergunta onde os dados viverão. O provedor responde com uma região ou zona. O comprador trata essa resposta como resiliência. Mas a resposta de localização e a resposta de recuperação são questões contratuais diferentes. Uma descreve o posicionamento; a outra descreve o que acontece após uma perda, corrupção ou indisponibilidade. Um contrato que garante a localidade dos dados, mas deixa o design de backup indefinido, resolveu apenas metade do problema.

Um relatório de compra sólido identificaria o ponto de recuperação e o tempo de recuperação exigidos pela carga de trabalho antes de escolher o armazenamento. Uma carga de trabalho de registro pode tolerar algum atraso, mas não uma perda silenciosa. Um banco de dados transacional pode precisar de backups consistentes em nível de aplicativo a cada poucos minutos. Um registro público pode precisar de backups imutáveis e restaurações testadas. Um pequeno projeto de análise pode aceitar snapshots diários.

O produto de armazenamento, o cronograma de snapshots, o local da réplica, o design da chave de criptografia e o exercício de restauração devem seguir o requisito da missão, e não o contrário.

As compras também devem exigir um modelo de notificação do provedor. Durante um incidente de armazenamento, o provedor pode saber que um disco está na população afetada antes que o cliente possa diagnosticá-lo a partir de erros do aplicativo. O contrato ou plano de suporte deve especificar como os recursos afetados são identificados, como os clientes são informados se uma restauração é recomendada, como a perda permanente é relatada, como os logs são mantidos e como o suporte técnico é priorizado. Uma página de status de serviço genérico não é suficiente para um evento de perda de dados, pois a ação do cliente é específica ao recurso.

O comprador também deve evitar uma falsa escolha entre soberania e resiliência. Para muitas cargas de trabalho europeias, uma cópia independente em outra região europeia pode satisfazer a política enquanto reduz o risco de zona única. Para cargas de trabalho mais rigorosas, replicação regional dentro de um país ou locais de backup cuidadosamente governados podem ser necessários. Para alguns dados, o custo e a complexidade de cópias adicionais podem ser desproporcionais. O ponto de responsabilidade não é que toda carga de trabalho precise do mesmo design.

É que a compensação deve ser documentada e aceita pelo proprietário do negócio que entende a consequência das gravações perdidas.

Os auditores devem desconfiar de respostas de checklist. "Os dados estão armazenados na Europa" não responde se eles podem ser restaurados. "O disco persistente é durável" não responde se o aplicativo pode tolerar uma perda de gravação recente. "Snapshots estão disponíveis" não responde se eles foram configurados, recentes, completos e testados. "O provedor tem um SLA" não responde se o cliente tem uma cópia utilizável. A evidência de auditoria deve incluir resultados de teste de restauração, idade do backup, local do backup, acesso a chaves e um registro de quem aceitou o risco residual.

Pequenas equipes precisam de padrões que tornem a recuperabilidade visível

Os clientes mais propensos a entender mal a fronteira são muitas vezes os menos equipados para se recuperar de uma violação. Grandes empresas podem ter equipes de armazenamento, plataformas de backup, comitês de auditoria e exercícios de simulação. Pequenas equipes podem ter um engenheiro, um projeto, uma região e um painel que torna o disco durável porque a máquina virtual pode ser excluída sem excluir o volume. Seu risco não é ignorância em um sentido pejorativo; é a consequência normal da abstração que funciona bem demais.

Os provedores de nuvem podem reduzir esse risco por meio de padrões e avisos. Quando um cliente cria um disco zonal único para uma carga de trabalho do tipo banco de dados, a interface pode solicitar cronogramas de backup, recomendar políticas de snapshot, mostrar o domínio de falha e avisar que snapshots são necessários para recuperação independente. A documentação pode colocar tabelas de domínio de falha próximas aos fluxos de trabalho de criação, em vez de guias profundos de confiabilidade. As páginas de preços podem mostrar o custo da falta de backup como uma aceitação de risco, não apenas o custo de um snapshot como um adicional.

Os clientes podem reduzir o risco com rotinas simples. Cada armazenamento de dados persistente deve ter um proprietário nomeado, um objetivo de ponto de recuperação, um cronograma de snapshot ou backup, uma data de teste de restauração, um local de backup e um plano de acesso a chaves. O primeiro teste de restauração deve ocorrer antes do lançamento em produção, não durante o primeiro incidente. O teste deve restaurar para um ambiente separado, verificar a consistência do aplicativo e confirmar que a equipe pode autenticar, descriptografar e reconectar a carga de trabalho.

Se a equipe não puder arcar com o design de recuperação, isso deve ser uma decisão de negócio consciente.

O evento de 2015 é um bom caso de ensino porque a perda não foi espetacular. Não houve um colapso geral para tornar a lição inevitável. A porcentagem foi ínfima. No entanto, uma pequena equipe com um disco afetado e nenhum snapshot recente ainda pode enfrentar perda permanente. A educação em resiliência geralmente se concentra em desastres gigantes; este incidente mostra que falhas raras e estreitas são suficientes para punir suposições de backup não testadas.

A mesma lógica se aplica a plataformas internas construídas por empresas. Uma equipe de plataforma empresarial pode oferecer "modelos de nuvem aprovados" para equipes de produto. Esses modelos não devem apenas criar um disco zonal e deixar as escolhas de backup para proprietários de aplicativos que podem não entender a camada de armazenamento. A plataforma deve exigir ou orientar fortemente cronogramas de snapshot, opções de replicação, períodos de retenção e testes de restauração. A responsabilidade compartilhada dentro de uma empresa reflete a responsabilidade compartilhada com o provedor de nuvem.

A perda de dados muda o peso moral da linguagem de status

Muitos status de falha podem ser escritos em termos de erros elevados, desempenho degradado ou restauração. A perda de dados requer um vocabulário diferente. Os clientes precisam saber se os dados estão atrasados, indisponíveis, corrompidos, restaurados, parcialmente irrecuperáveis ou permanentemente perdidos. Essas categorias produzem deveres diferentes. Dados atrasados podem exigir processamento em fila. Dados indisponíveis podem exigir failover. Dados corrompidos podem exigir validação e reversão. Perda permanente pode exigir notificação, reconciliação, compensação ou revisão legal.

A página de status do Google passou cautelosamente por erros de leitura, desempenho degradado e soluções alternativas por snapshot. Os relatórios contemporâneos posteriormente registraram perda permanente para uma fração ínfima do armazenamento. O encolhimento das populações afetadas foi útil, mas a lição pública é que a perda permanente deve ser nomeada claramente uma vez conhecida. Uma página de status que permanece muito tempo com linguagem de disponibilidade pode levar os clientes a tratar um evento de perda de dados como um problema de repetição.

Uma página de status que nomeia a perda permanente de forma muito ampla pode causar pânico desnecessário. A precisão não é decorativa; ela controla a resposta do cliente.

Uma boa linguagem de status para incidentes de armazenamento deve indicar o produto afetado, a zona, a faixa de horário, a classe de recurso, o sintoma, a ação atual do cliente e o estado das evidências. Deve separar os recursos em risco dos recursos com falhas de leitura conhecidas e dos recursos com dados irrecuperáveis confirmados. Deve indicar se snapshots, novos discos, discos regionais ou outros produtos de armazenamento são afetados. Deve indicar se o provedor pode identificar diretamente os recursos afetados e como os clientes serão contatados.

Deve ser atualizado quando o provedor passa da reparação do serviço para a reconciliação dos dados.

Essa precisão também ajuda os clientes a prestar contas às suas próprias partes interessadas. Um encarregado de proteção de dados, um auditor, um conselho de administração ou um proprietário de pequena empresa precisa saber se o evento alterou a confidencialidade, integridade, disponibilidade ou recuperabilidade. O evento de 2015 dizia respeito à disponibilidade e recuperabilidade para uma população restrita de discos. Não foi uma evidência de acesso não autorizado. Tratar todo incidente de nuvem como uma violação é errado; tratar todo incidente de armazenamento como um problema de disponibilidade transitória também é errado.

As categorias devem corresponder aos fatos.

As decisões de localidade devem incluir uma história de saída

Cada decisão de localidade deve incluir uma história de saída: se esta zona, região ou escolha de armazenamento local falhar, para onde vai a carga de trabalho e quais dados a seguem? Um cliente escolhendo europe-west1-b em 2015 precisava saber se um disco com falha podia ser restaurado em outra zona, se o snapshot existia fora do sistema com falha, se o aplicativo podia anexar o disco restaurado e se o DNS, credenciais e operadores podiam trazer o serviço de volta. Essas perguntas continuam relevantes mesmo que os nomes dos produtos e recursos tenham mudado.

Uma história de saída tem várias partes. A primeira são os dados: que cópia existe, sua idade e onde está. A segunda é a computação: que ambiente pode executar os dados restaurados. A terceira é a identidade e chaves: quem pode acessá-los e descriptografá-los. A quarta é a rede e roteamento: como os usuários alcançam o serviço recuperado. A quinta é a validação: como a equipe sabe que o aplicativo restaurado está correto. A sexta é a comunicação: como os usuários e partes interessadas são informados sobre o que aconteceu e o intervalo de dados que pode estar faltando.

As restrições de localidade tornam a história de saída mais complexa, mas não opcional. Se os dados devem permanecer na Bélgica, o design pode exigir resiliência local multi-zona, snapshots mais frequentes e controles de backup no local mais robustos. Se os dados podem permanecer na Europa, o design pode usar outra região europeia ou armazenamento de snapshot multirregional. Se a política permitir backup global para recuperação de desastres, o design ainda deve gerenciar privacidade, criptografia e controles de acesso. A chave é decidir explicitamente em vez de deixar o posicionamento padrão do disco decidir silenciosamente.

O provedor pode facilitar isso apresentando os domínios de falha na linguagem do cliente. Em vez de apenas nomes de produtos, a interface pode descrever "sobrevive à exclusão de VM", "sobrevive a uma classe de falha de hardware zonal", "sobrevive a uma falha de zona por meio de replicação regional" e "suporta restauração a um ponto no tempo por meio de snapshots". Nenhuma frase curta cobrirá todos os casos, mas uma linguagem simples de domínio de falha é mais difícil de interpretar mal do que adjetivos vagos de durabilidade.

Incógnitas e limites cautelosos

O registro público não nomeia cada cliente afetado, cada gravação perdida, cada modelo de hardware interno ou cada mudança de engenharia pós-incidente. Não prova que a falha de backup de um cliente específico causou sua perda. Não estabelece violação legal, constatação de negligência, danos ou violação de conformidade. Também não prova que todos os produtos atuais de armazenamento do Google Cloud apresentam o mesmo risco de 2015. A infraestrutura de nuvem e os recursos dos produtos mudaram significativamente desde então.

O registro público apoia várias conclusões firmes. O evento afetou discos persistentes em europe-west1-b. Os clientes encontraram erros de leitura. O Google direcionou os clientes afetados para restauração a partir de snapshots. Relatórios contemporâneos baseados no relato do Google descreviam quatro quedas de raios sucessivas na rede elétrica local, uma breve perda de energia dos sistemas de armazenamento, sensibilidade de hardware em um subconjunto do armazenamento e perda permanente de uma fração ínfima do espaço de disco persistente alocado. O Google afirmou que revisaria a pilha e atualizaria o hardware de armazenamento.

A documentação atual do Google torna explícitos snapshots, backups programados, discos regionais e escolhas de proteção de dados.

A inferência mais importante é apoiada, mas deve ser marcada como inferência: informações mais claras sobre o domínio de falha e backups independentes testados reduzem a probabilidade de um perigo físico se transformar em perda permanente de aplicativo. Isso não é o mesmo que dizer que todo cliente sem snapshot foi negligente ou que o Google falhou com uma obrigação legal. É uma conclusão prática de controle. O provedor pode tornar a fronteira visível e construir infraestrutura mais resiliente. O cliente pode escolher um design de recuperação que não dependa de um único disco local.

O incidente também alerta contra dois erros opostos. O primeiro é o fatalismo em nuvem: concluir que, porque um provedor de hiperescala perdeu uma quantidade ínfima de dados uma vez, o armazenamento em nuvem não pode ser confiável. O segundo é a complacência em nuvem: concluir que, porque a porcentagem era ínfima, ninguém precisa de backups independentes. A posição madura é mais exigente e mais útil. Use a durabilidade do provedor, mas não a confunda com um ponto de recuperação. Use a localidade, mas não a confunda com resiliência. Use SLAs, mas não confunda créditos com estado restaurado.

O teste de evidência prática é bastante simples de executar antes da conclusão de uma compra. Um comprador deve ser capaz de apontar para o disco ativo, o último ponto de recuperação independente, o alvo de restauração, o caminho de identidade e chave, a pessoa responsável por uma restauração e o teste bem-sucedido mais recente. Um provedor deve ser capaz de apontar para o domínio de falha, o caminho de notificação específico ao recurso, as categorias de status do incidente e o caminho de suporte para clientes enfrentando perda permanente.

Se qualquer uma das partes não conseguir responder a essas perguntas antes de um evento de armazenamento raro, a arquitetura se baseia na esperança escondida atrás de nomes de produtos respeitáveis.

É por isso que um pequeno evento de 2015 ainda pertence a um programa de responsabilidade de 2026. Ele transforma um modelo abstrato de responsabilidade compartilhada em um contrato operacional visível. A pilha do provedor pode ser mais sólida agora, e os clientes têm mais ferramentas, mas a lógica de decisão permanece a mesma: a localidade deve ser associada a uma cópia recuperável, uma cópia recuperável deve ser testada, e uma recuperação testada deve ser compreendida pelo proprietário do negócio que enfrentará os usuários quando os dados estiverem faltando.

O proprietário final dessa decisão não deve estar escondido em um atalho de infraestrutura. Deve ser um proprietário de serviço nomeado que entende o custo de uma hora perdida, de um dia perdido ou de um intervalo de transação perdido.

Esse proprietário também deve ter a autoridade para financiar o backup.

O caso de perda de disco belga continua útil porque é pequeno o suficiente para ser estudado e sério o suficiente para mudar práticas. Ele mostra que a redundância gerenciada pelo provedor pode falhar no limite de um perigo físico, que as porcentagens de status devem ser lidas por categoria, que os snapshots só são importantes se existirem e se restaurarem corretamente, e que a localidade não é um substituto para a recuperabilidade independente.

O Google controlava o data center e a pilha de armazenamento; os clientes controlavam sua arquitetura de recuperação; os auditores e as equipes de compras controlavam se essas duas responsabilidades eram examinadas antes do próximo evento raro. O resultado responsável é um plano de armazenamento que pode dizer onde os dados vivem, onde vive uma cópia recuperável, quão recente ela é, quem pode restaurá-la e quais evidências provarão a recuperação quando a zona local não puder mais fazê-lo.