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

Resumo

• Em agosto de 2015, os Persistent Disks Standard do Google Compute Engine na zona europe-west1-b apresentaram erros de leitura após quatro raios consecutivos atingirem a rede elétrica local que servia um data center europeu. O Google informou posteriormente que uma fração muito pequena do espaço de Persistent Disk alocado na zona sofreu gravações recentes irrecuperáveis.
• A questão da responsabilidade não é se a porcentagem foi grande. É se os clientes entenderam que um Persistent Disk zonal, mesmo com redundância gerenciada pelo provedor dentro da zona, ainda estava dentro de um domínio de falha física e não era um substituto para snapshots independentes, replicação regional ou backup em nível de aplicação.
• O Google controlava a resiliência do local físico, a suscetibilidade do hardware de armazenamento, o tratamento de eventos de energia, a linguagem de durabilidade do Persistent Disk, a comunicação de status e a clareza das orientações de backup. Os clientes controlavam a arquitetura da carga de trabalho, os agendamentos de snapshots, os objetivos de recuperação, as escolhas de replicação e se os requisitos de localidade eram confundidos com capacidade de recuperação.
• O registro prático de reparo deve distinguir serviço restaurado, dados irrecuperáveis, solução alternativa de snapshot disponível, alteraçõ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 prova completa de recuperação.

Uma porcentagem pequena ainda pode ser uma falha grave

O incidente do Google Cloud na Bélgica é às vezes lembrado como uma curiosidade porque a porcentagem de armazenamento permanentemente perdido era extremamente pequena. Essa é a lente 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 poderia tolerar o ponto de recuperação e se a linguagem de durabilidade do provedor havia tornado claro o risco residual do local físico antes do evento.

O Incidente #15056 do Compute Engine público do Google começou em 13 de agosto de 2015 para Persistent Disks na zona 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 na zona eram suscetíveis a desempenho degradado, e depois que menos de 0,1% estavam experimentando falhas de leitura em alguns blocos. O registro 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 Persistent Disks e a restauração a partir de snapshots não eram afetadas.

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

O Google disse que quase todos os dados foram comprometidos com armazenamento estável, mas em alguns poucos casos, gravações recentes eram irrecuperáveis, resultando em perda permanente de dados no Persistent Disk. O número amplamente repetido foi menos de 0,000001% do espaço de Persistent Disk alocado na zona afetada.

Esse registro apoia tanto a moderação quanto a seriedade. Seria errado descrever o evento como destruição generalizada de dados em todo o Google Cloud. O serviço afetado foi o Persistent Disk Standard em uma zona; o Persistent Disk SSD, snapshots e SSDs locais foram relatados pelos índices de autópsia e pela cobertura contemporânea como fora da população com perda permanente. Também seria errado descartar o incidente porque o denominador era enorme. A durabilidade dos dados é um fato binário para o registro que importa. Uma porcentagem irrecuperável pequena ainda é uma perda permanente para alguém.

A questão da responsabilidade, portanto, não é "Por que os raios existiram?" O raio é um perigo externo. A questão é quem controlava as escolhas de design que permitiram que um evento de energia repetido na rede elétrica atingisse o estado do disco recentemente gravado, quem controlava a clareza das orientações 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. A questão central de responsabilidade era o limite entre a durabilidade local gerenciada pelo provedor e a capacidade de recuperação gerenciada pelo cliente.

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

A localidade na nuvem resolve problemas reais. Um cliente pode escolher europe-west1 por latência para usuários belgas ou europeus, por razões de aquisição, por características de baixo carbono ou por compromissos de localização de dados. A página atual de localizações da nuvem do Google e a documentação de 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 de recursos físicos subjacentes. Essa abstração é útil porque os clientes não precisam gerenciar edifícios. É perigosa se os clientes inferirem que um recurso zonal escapou do domínio de falha física.

Soberania e localidade de dados são sobre onde os dados são armazenados ou processados. Capacidade de recuperação é sobre se existe outra cópia utilizável após uma falha. Um disco pode satisfazer um requisito de localização e ainda ser a arquitetura de durabilidade errada para um banco de dados se seu único estado recuperável viver 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 todos os objetivos 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.

Os termos atuais de residência de dados do Google e o material de compromissos europeus abordam onde os dados do cliente podem residir para 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 armazenamento em bloco durável, e a documentação do Persistent Disk do Compute Engine afirma que o Persistent Disk tem redundância embutida para proteger contra falhas de equipamento e manter a disponibilidade de dados durante eventos de manutenção. Esses são compromissos significativos do provedor.

Eles não são uma garantia de que todo perigo possível no local do site deixará zero gravações recentes irrecuperáveis em todas as configurações.

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

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

O gatilho físico pertence ao registro de responsabilidade da 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 fazendo parte do serviço. O cliente paga ao provedor para gerenciar essas camadas porque o provedor tem maior escala e expertise. Isso torna a resiliência física um dever do provedor, enquanto deixa a arquitetura de recuperação de aplicação parcialmente com o cliente.

A explicação do incidente relatada por várias fontes disse que sistemas auxiliares automáticos restauraram a energia rapidamente e os sistemas de armazenamento foram projetados com backup de bateria, mas alguns dados recentemente gravados estavam localizados em sistemas mais suscetíveis a falhas de energia devido a drenagem prolongada ou repetida da bateria. 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 "discos antigos" usado em algumas reportagens deve ser tratado com cuidado: artigos públicos descreveram suscetibilidade de hardware, mas o registro público de status não publica todos os componentes, idades ou decisões internas de engenharia.

O Google teria dito que realizou uma ampla revisão na distribuição elétrica, hardware de computação e software que controla a camada de Persistent Disk e que estava atualizando o hardware de armazenamento para ser menos suscetível a esse tipo de falha de energia. O relatório atualizado do Data Center Knowledge registrou que o Google estava substituindo sistemas de armazenamento por hardware mais resiliente a energia e que muito armazenamento de Persistent Disk já estava em hardware mais novo. Essas são medidas de resposta.

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

O provedor também controlou o status do incidente. A página de status da nuvem forneceu atualizações repetidas, porcentagens de impacto e orientação de solução alternativa de snapshot. Esse registro é materialmente melhor do que silêncio. No entanto, ele passou de erros de leitura e desempenho degradado para perda permanente à medida que a investigação progredia. 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 de impacto não é apenas sobre disponibilidade de serviço; é sobre estado recuperável.

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

Orientação de snapshot é onde a responsabilidade compartilhada se torna concreta

A atualização de status do Google durante o incidente disse aos clientes afetados que eles poderiam restaurar a partir de snapshots. Essa recomendação é útil apenas para clientes que tinham snapshots utilizáveis. Um snapshot que não existe, é muito antigo, está no local errado, não tem consistência de aplicação 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 criou e verificou 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 estrutura 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 de criação de snapshots explica snapshots padrão e de arquivo. A visão geral de snapshots descreve snapshots incrementais. O guia de snapshots agendados recomenda agendamentos como uma prática de backup, e a página de melhores práticas de snapshot adiciona restrições práticas e conselhos de confiabilidade. Essa documentação atual é mais clara do que muitas suposições da era inicial da nuvem.

A consistência de aplicação continua sendo uma preocupação do cliente. Um snapshot de disco captura o estado do bloco; um banco de dados pode precisar de quiescência, descarga ou operações de backup coordenadas para tornar o estado restaurado utilizável. A documentação de snapshot consistente com aplicação Linux do Google explica snapshots agendados com descarga de convidado. O ponto importante não é o conjunto exato de recursos em 2015 versus agora. É o princípio de controle durável: a capacidade de recuperação exige um processo de backup alinhado à aplicação, não meramente uma promessa de armazenamento do provedor.

Equipes pequenas estão especialmente expostas a essa lacuna. Uma startup ou projeto municipal pode escolher uma única zona de nuvem para reduzir latência e custo. Pode executar um banco de dados em um Persistent Disk 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, um processo de restauração testado ou uma análise de impacto nos negócios.

O incidente de 2015 mostra por que a documentação e os padrões do produto importam: clientes com menos experiência interna precisam de opções de armazenamento e avisos que tornem óbvio o limite do domínio de falha.

Os deveres do provedor e do cliente devem ser declarados em linguagem operacional. O Google deve projetar o sistema de armazenamento para sobreviver a perigos físicos esperados, publicar informações claras de domínio de falha, fornecer ferramentas de snapshot e replicação, preservar evidências de incidentes e identificar recursos afetados. O cliente deve selecionar um objetivo de recuperação, agendar 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 da região. Nenhum dos lados pode fazer o trabalho completo do outro.

Discos regionais e replicação mudam o modelo de falha, não a necessidade de pensar em recuperação

O Google agora oferece opções de alta disponibilidade de Persistent Disk regional e Hyperdisk. A documentação de disco regional explica discos replicados entre zonas em uma região para maior disponibilidade, e o guia de failover de disco regional descreve a anexação forçada quando uma zona primária falha. O blog do Google sobre Persistent Disks 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 de arquitetura. A replicação regional pode proteger contra indisponibilidade de zona ou erros de armazenamento em uma zona. Pode não proteger contra corrupção em nível de aplicação que é replicada, exclusão do 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 para outra zona. Ainda pode ser muito antigo, inconsistente com a aplicação, indisponível para o projeto certo, criptografado com uma chave que o ambiente de recuperação não pode acessar ou armazenado em um local que conflita com a política. A documentação de criptografia de disco do Google lembra os clientes de que discos e snapshots podem envolver diferentes escolhas de chave. 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 abordam a disponibilidade do serviço e créditos sob condições definidas. Eles não são uma declaração completa de capacidade de recuperação ou perda de negócios. Um crédito pode compensar uma fração dos encargos de serviço enquanto o cliente ainda precisa restaurar dados, reconciliar transações, notificar usuários ou reconstruir a confiança. O fato de a página de status ter dito aos clientes afetados para restaurar a partir de snapshots mostra que a recuperação operacional vivia fora da questão do crédito do SLA.

Para proprietários de soberania de dados, as escolhas de replicação exigem trabalho de política 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 zona. Pode permitir snapshots em uma multirregião europeia ou em outra região europeia, dependendo dos termos de serviço, expectativas do regulador e apetite ao risco. Por outro lado, um requisito estrito de localização pode impedir alguns backups entre regiões e exigir um design de disponibilidade local mais alto. O ato responsável é tornar essa compensação explícita antes que os dados sejam perdidos.

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

Os relatórios de incidentes do provedor geralmente terminam na restauração do serviço. Eventos de perda de dados precisam de um segundo registro: evidências de recuperação do cliente. Quais discos tiveram erros de leitura? Quais gravações foram irrecuperáveis? Quais clientes restauraram a partir de snapshots? Quais snapshots falharam ou eram muito antigos? Quais aplicações precisaram de 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? Algumas dessas evidências são privadas, mas as categorias importam publicamente.

As porcentagens de impacto repetidas na página de status foram úteis porque evitaram garantias vagas. Menos de 1% suscetível, menos de 0,1% com falhas de leitura e menos de 0,000001% de perda permanente descrevem categorias de redução. Elas não devem ser mescladas 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 informa a um operador de banco de dados se um disco específico está afetado. O Google tinha a capacidade mais forte de identificar recursos afetados, correlacionar sistemas de armazenamento e fornecer avisos no nível da conta. Os clientes tinham a capacidade mais forte de verificar a consistência da aplicação, restaurar a partir de seus próprios snapshots e decidir quais dados de negócios recentes podem estar faltando. Ambos os tipos de evidências são necessários.

Essa divisão é especialmente importante para auditores. Um auditor revisando 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 aprovados, se os locais de backup correspondiam à política, se os proprietários de aplicações 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.

A aquisição deve fazer as mesmas perguntas com antecedência. Qual domínio de falha este disco ocupa? Que cópia independente existe? Quem é responsável pelos agendamentos de snapshot? Como as restaurações são testadas? Qual é o intervalo máximo tolerável de gravação perdida? 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 "durabilidade na nuvem" de um slogan em uma decisão de risco.

A aquisição não deve comprar uma região como se fosse um backup

O incidente da Bélgica é especialmente útil para aquisição 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 perguntas contratuais diferentes. Uma descreve a colocação; a outra descreve o que acontece após 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 registro de aquisição forte 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 perda silenciosa. Um banco de dados transacional pode precisar de backups consistentes com a aplicação 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 agendamento 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, não o contrário.

A aquisição também deve exigir um modelo de aviso 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 de aplicação. 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 preservados e como o suporte técnico é priorizado. Uma página de status de serviço genérica não é suficiente para um evento de perda de dados porque 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, a 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 extras 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 de gravações perdidas.

Os auditores devem desconfiar de respostas de lista de verificação. "Os dados estão armazenados na Europa" não responde se eles podem ser restaurados. "O Persistent Disk é durável" não responde se a aplicação pode tolerar uma perda de gravação recente. "Snapshots estão disponíveis" não responde se eles foram configurados, são 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, localização do backup, acesso à chave e um registro de quem aceitou o risco residual.

Equipes pequenas precisam de padrões que tornem a capacidade de recuperação visível

Os clientes com maior probabilidade de entender mal o limite são frequentemente os menos equipados para se recuperar de cruzá-lo. Grandes empresas podem ter equipes de armazenamento, plataformas de backup, comitês de auditoria e exercícios de mesa. Equipes pequenas podem ter um engenheiro, um projeto, uma região e um painel que faz o disco parecer 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 fazendo seu trabalho muito bem.

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 com formato de banco de dados, a interface pode perguntar sobre agendamentos 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 perto dos fluxos de criação, em vez de profundamente em guias de confiabilidade. As páginas de preços podem mostrar o custo de não ter backup como uma aceitação de risco, não apenas o custo de um snapshot como um extra.

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 agendamento de snapshot ou backup, uma data de teste de restauração, um local de backup e um plano de acesso à chave. O primeiro teste de restauração deve acontecer 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 da aplicação 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ócios consciente.

O evento de 2015 é um bom caso de ensino porque a perda não foi espetacular. Não houve colapso global para tornar a lição inevitável. A porcentagem era pequena. No entanto, uma pequena equipe com um disco afetado e nenhum snapshot recente ainda poderia enfrentar perda permanente. A educação em resiliência muitas vezes 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 corporativa pode oferecer "modelos de nuvem aprovados" para equipes de produto. Esses modelos não devem simplesmente criar um disco zonal e deixar as escolhas de backup para proprietários de aplicações que podem não entender a camada de armazenamento. A plataforma deve exigir ou orientar fortemente agendamentos de snapshot, opções de replicação, períodos de retenção e testes de restauração. A responsabilidade compartilhada dentro de uma empresa espelha a responsabilidade compartilhada com o provedor de nuvem.

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

Muitos status de interrupção 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, revertidos, parcialmente irrecuperáveis ou permanentemente perdidos. Essas categorias produzem deveres diferentes. Dados atrasados podem exigir processamento de fila. Dados indisponíveis podem exigir failover. Dados corrompidos podem exigir validação e reversão. A perda permanente pode exigir notificação, reconciliação, compensação ou revisão legal.

A página de status do Google moveu-se cuidadosamente através de erros de leitura, desempenho degradado e solução alternativa de snapshot. Relatos contemporâneos posteriormente registraram perda permanente para uma pequena fração de armazenamento. O estreitamento 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 com linguagem de disponibilidade por muito tempo 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 muito amplamente pode causar pânico desnecessário. A precisão, portanto, não é decorativa; ela controla a resposta do cliente.

Uma boa linguagem de status para incidentes de armazenamento deve declarar o produto afetado, zona, intervalo de tempo, classe de recurso, sintoma, ação atual do cliente e status da evidência. Deve separar recursos em risco de recursos conhecidos por terem falhas de leitura e recursos com dados irrecuperáveis confirmados. Deve dizer se snapshots, novos discos, discos regionais ou outros produtos de armazenamento são afetados. Deve declarar se o provedor pode identificar diretamente os recursos afetados e como os clientes serão contatados. Deve ser atualizada quando o provedor passa de reparo de serviço para reconciliação de dados.

Essa precisão também ajuda os clientes a relatar a suas próprias partes interessadas. Um diretor de proteção de dados, auditor, conselho ou proprietário de pequena empresa precisa saber se o evento alterou confidencialidade, integridade, disponibilidade ou capacidade de recuperação. O evento de 2015 foi disponibilidade mais capacidade de recuperação para uma população estreita de discos. Não foi 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ório também é errado. As categorias devem se adequar aos fatos.

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

Toda 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 a carga de trabalho vai e quais dados a seguem? Um cliente escolhendo europe-west1-b em 2015 precisava saber se um disco com falha poderia ser restaurado em outra zona, se o snapshot existia fora do sistema com falha, se a aplicação poderia anexar o disco restaurado e se DNS, credenciais e operadores poderiam trazer o serviço de volta. Essas perguntas permanecem atuais, embora 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, quão antiga é e onde vive. A segunda é a computação: que ambiente pode executar os dados restaurados. A terceira é identidade e chaves: quem pode acessá-los e descriptografá-los. A quarta é rede e roteamento: como os usuários alcançam o serviço recuperado. A quinta é validação: como a equipe sabe que a aplicação restaurada está correta. A sexta é comunicação: como os usuários e partes interessadas são informados sobre o que aconteceu e qual intervalo de dados pode estar faltando.

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 multizona, snapshots mais frequentes e controles de backup no local mais fortes. 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 um backup global para recuperação de desastre, o design ainda deve lidar com privacidade, criptografia e controles de acesso. O segredo é decidir explicitamente, em vez de permitir que a colocação padrão do disco decida silenciosamente.

O provedor pode tornar isso mais fácil apresentando domínios de falha em linguagem do cliente. Em vez de apenas nomes de produtos, a interface pode descrever "sobrevive à exclusão de VM", "sobrevive à classe de falha de hardware zonal", "sobrevive à interrupção de zona por meio de replicação regional" e "suporta restauração pontual por meio de snapshots". Nenhuma frase curta cobrirá todas as bordas, mas a linguagem simples de domínio de falha é mais difícil de interpretar mal do que adjetivos amplos de durabilidade.

Desconhecidos e limites cuidadosos

O registro público não nomeia todos os clientes afetados, todas as gravações perdidas, todos os modelos internos de hardware ou todas as mudanças 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, concessão de danos ou violação de conformidade. Também não prova que todos os produtos atuais de armazenamento do Google Cloud carregam o mesmo risco de 2015. A infraestrutura de nuvem e os recursos dos produtos mudaram substancialmente desde então.

O registro público suporta várias conclusões firmes. O evento afetou Persistent Disks na zona europe-west1-b. Os clientes experimentaram erros de leitura. O Google orientou os clientes afetados a restaurar a partir de snapshots. Relatos contemporâneos baseados no relato do Google descreveram quatro raios consecutivos na rede elétrica local, uma breve perda de energia para sistemas de armazenamento, suscetibilidade de hardware em um subconjunto de armazenamento e perda permanente de uma fração minúscula do espaço de Persistent Disk alocado. O Google disse que revisaria a pilha e atualizaria o hardware de armazenamento.

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

A inferência mais importante é suportada, mas deve ser marcada como inferência: divulgação mais clara de domínio de falha e backups independentes testados reduzem a chance de que um perigo no local físico se torne perda permanente de aplicação. Isso não é o mesmo que dizer que todo cliente sem um snapshot foi negligente ou que o Google falhou em um dever legal. É uma conclusão prática de controle. O provedor pode tornar o limite visível e construir infraestrutura mais resiliente. O cliente pode escolher um design de recuperação que não dependa de um disco local.

O incidente também adverte contra dois erros opostos. O primeiro é o fatalismo da nuvem: concluir que, porque um provedor de hiperescala perdeu uma quantidade minúscula de dados uma vez, o armazenamento em nuvem não pode ser confiável. O segundo é a complacência da nuvem: concluir que, porque a porcentagem era minúscula, 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 é simples o suficiente para ser executado antes do fechamento da aquisição. Um comprador deve ser capaz de apontar para o disco ativo, o ponto de recuperação independente mais recente, o destino da 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 aviso específico ao recurso, as categorias de status de incidente e o caminho de suporte para clientes que enfrentam perda permanente.

Se algum dos lados não puder responder a essas perguntas antes de um evento raro de armazenamento, a arquitetura está contando com esperança escondida dentro 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 forte agora, e os clientes têm mais ferramentas, mas a lógica de decisão permanece a mesma: a localidade deve ser emparelhada com uma cópia recuperável, uma cópia recuperável deve ser testada e uma recuperação testada deve ser entendida 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 dentro de uma abreviação de infraestrutura. Deve ser um proprietário de serviço nomeado que entende o custo de uma hora perdida, um dia perdido ou um intervalo de transação perdido.

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

O registro de perda de disco da Bélgica continua útil porque é pequeno o suficiente para ser estudado e sério o suficiente para mudar a prática. Mostra que a redundância gerenciada pelo provedor pode falhar na borda de um perigo físico, que as porcentagens de status devem ser lidas por categoria, que os snapshots importam apenas se existirem e restaurarem corretamente, e que a localidade não é um substituto para a capacidade de recuperação independente. O Google controlava a pilha de data center e armazenamento; os clientes controlavam sua arquitetura de recuperação;

auditores e equipes de aquisição 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 uma cópia recuperável vive, quão recente ela é, quem pode restaurá-la e que evidência provará a recuperação quando a zona local não puder mais.