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 discos permanentes padrão do Google Compute Engine na zona europe-west1-b apresentaram erros de leitura após quatro raios consecutivos afetarem a rede elétrica local que atende um data center europeu. O Google informou posteriormente que uma fração muito pequena do espaço de disco permanente alocado na zona sofreu perdas irrecoveráveis de gravações recentes.
• A questão de responsabilidade não é se a porcentagem foi grande. É se os clientes entenderam que um disco permanente 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 substituía 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 disco permanente, os relatórios de status e a clareza das orientações de backup. Os clientes controlavam a arquitetura da carga de trabalho, os agendamentos de snapshot, os objetivos de recuperação, as escolhas de replicação e se os requisitos de localidade eram confundidos com recuperabilidade.
• 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 pergunta relevante era se o cliente tinha uma cópia independente recuperável, se a aplicação conseguia tolerar o ponto de recuperação e se a linguagem de durabilidade do provedor havia tornado claro o risco restante do local físico antes do evento.

O relatório público doIncidente nº 15056 do Compute Enginecomeçou em 13 de agosto de 2015 para discos permanentes 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 na zona estavam suscetíveis a desempenho degradado, e então que menos de 0,1% estavam enfrentando falhas de leitura em alguns blocos. O registro do incidente também informou aos clientes afetados que restaurar a partir de snapshots era uma solução alternativa, enquanto criar novos discos permanentes e restaurar a partir de snapshots não era afetado.

Relatos da mídia que capturaram a explicação posterior do incidente, incluindo orelatório do Data Center Dynamics sobre raios e perda de dadose orelato do 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 hospedam a capacidade de disco para instâncias do GCE em europe-west1-b. O Google disse que quase todos os dados foram comprometidos com armazenamento estável, mas em alguns casos raros, gravações recentes foram irrecuperáveis, resultando em perda permanente de dados no disco permanente. O número amplamente repetido foi menos de 0,000001% do espaço de disco permanente 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 no Google Cloud. O serviço afetado foi o Disco Permanente Padrão em uma zona; o Disco Permanente SSD, snapshots e SSDs Locais foram relatados por índices de necropsia e cobertura contemporânea como 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 registro que importa. Uma porcentagem pequena irrecuperável ainda é uma perda permanente para alguém.

Portanto, a questão de responsabilidade não é "Por que o raio existiu?" O raio é um perigo externo. A questão é quem controlava as escolhas de design que permitiram que um evento de energia repetido da rede elétrica atingisse o estado do disco recém-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 de responsabilidade raiz era o limite 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 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 carbono mais baixas ou por compromissos de localização de dados. A página atual do Google sobrelocais de nuveme a documentação do Compute Engine sobreregiões e zonasexplicam 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 edifícios. É perigoso 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. Recuperabilidade é 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 do Google sobreresidência de dadose 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 Disco Permanente descrevearmazenamento em bloco durável, e a documentação do Compute Engine sobreDiscos Permanentesafirma que o Disco Permanente tem redundância integrada 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 em escala de local 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 domínios de falha. Um disco permanente zonal é durável dentro de seu design, mas permanece vinculado a uma zona. Snapshots, discos regionais, replicação e backup de aplicação 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 diz para restaurar a partir de snapshots. A divulgação de maior valor é um mapeamento simples da escolha de armazenamento para o 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 sendo 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 da aplicação parcialmente com o cliente.

A explicação do incidente relatada por vários veículos 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 de "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 disse que realizou uma ampla revisão na distribuição elétrica, hardware de computação e software que controla a camada de Disco Permanente, e que estava atualizando o hardware de armazenamento para ser menos suscetível a esse tipo de falha de energia. Orelatório atualizado do Data Center Knowledgeregistrou que o Google estava substituindo sistemas de armazenamento por hardware mais resiliente a energia e que grande parte do armazenamento em Disco Permanente já estava em hardware mais novo. Essas são medidas responsivas. 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 snapshot como solução alternativa. Esse registro é materialmente melhor que o silêncio. No entanto, ele 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 de impacto não é apenas sobre disponibilidade do 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 pelo 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 ausente. 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, carece de consistência de aplicação ou nunca foi testado não é um caminho de recuperação. O incidente, portanto, transformou uma frase comum da nuvem, responsabilidade compartilhada, em uma pergunta concreta: quem realmente criou e verificou um ponto de recuperação antes do evento físico?

O guia atual do Google sobreopções de proteção de dados para discos e instânciasenquadra a recuperação em torno do objetivo de tempo de recuperação, objetivo de ponto de recuperação, caso de uso e custo. Adocumentação de criação de snapshotexplica snapshots padrão e de arquivo. Avisão geral de snapshotdescreve snapshots incrementais. Oguia de snapshots agendadosrecomenda agendamentos como prática de backup, e apágina de melhores práticas de snapshotadiciona restrições práticas e conselhos de confiabilidade. Essa documentação atual é mais clara do que muitas suposições antigas da era da nuvem.

A consistência da 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, liberação ou operações de backup coordenadas para tornar o estado restaurado utilizável. A documentação do Google sobresnapshots de disco permanente consistentes com aplicação Linuxexplica agendamentos de snapshot com liberação de convidado. O ponto importante não é o conjunto exato de recursos em 2015 versus agora. É o princípio de controle durável: a recuperabilidade requer um processo de backup alinhado à aplicação, não apenas uma promessa de armazenamento do provedor.

Equipes pequenas sã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 Disco Permanente 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 são importantes: 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 sobre 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 Disco Permanente Regional e Hyperdisk. Adocumentação de disco regionalexplica discos replicados entre zonas em uma região para maior disponibilidade, e oguia de failover de disco regionaldescreve a anexação forçada quando uma zona primária falha. O blog do Google sobreDiscos Permanentes Regionais para cargas de trabalho de alta disponibilidadetorna 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 zonal ou erros de armazenamento em uma zona. Pode não proteger contra corrupção em nível de aplicação 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.

O mesmo cuidado se aplica a snapshots. Um snapshot pode ser independente do disco falho e pode ser restaurado em outra zona. Pode ainda 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. Adocumentação de criptografia de disco do Googlelembra 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.

OSLA atualdo Compute Engine e aversão do SLA de 2015mostram outra distinção. 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 de negócios. Um crédito pode compensar uma fração dos custos 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 dito aos clientes afetados para restaurar a partir de snapshots mostra que a recuperação operacional estava fora da questão de crédito do SLA.

Para proprietários de soberania de dados, as escolhas de replicação exigem trabalho cuidadoso de política. 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 do serviço, expectativas regulatórias 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

Relatórios de incidentes de provedores 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 estavam 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? Parte dessa evidência é privada, 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 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 informa a um operador de banco de dados se um disco específico é afetado. O Google tinha a maior capacidade de identificar recursos afetados, correlacionar sistemas de armazenamento e fornecer notificações em nível de conta. Os clientes tinham a maior capacidade de verificar a consistência da aplicação, restaurar a partir de seus próprios snapshots e decidir quais dados comerciais recentes podem estar faltando. Ambos os tipos de evidência 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 existiam snapshots antes do incidente, se os testes de restauração foram aprovados, se os locais de backup correspondiam à política, se os proprietários da aplicação 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 antecipadamente. Qual domínio de falha esse 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 da 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 na Bélgica é especialmente útil para aquisição porque expõe um atalho comum. Um comprador pergunta onde os dados vão viver. 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 necessários da 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 snapshot, 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 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 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 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 rígidas, 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.

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 Disco Permanente é 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, 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 recuperabilidade visível

Os clientes com maior probabilidade de entender mal o limite são frequentemente os menos equipados para se recuperar de atravessá-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 fazer seu trabalho 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 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 da 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ócio 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 minúscula. 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 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ção 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 reflete 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 fração minúscula 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 na linguagem de disponibilidade por muito tempo pode deixar os clientes tratando um evento de perda de dados como um problema de repetição.

Uma página de status que nomeia perda permanente muito amplamente pode causar pânico desnecessário. A precisão não é, portanto, 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 com falhas de leitura conhecidas 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 recursos afetados diretamente e como os clientes serão contatados. Deve atualizar quando o provedor passar do reparo do serviço para a reconciliação de dados.

Essa precisão também ajuda os clientes a relatar para suas próprias partes interessadas. Um encarregado de proteção de dados, auditor, conselho ou proprietário de pequena empresa precisa saber se o evento alterou a confidencialidade, integridade, disponibilidade ou recuperabilidade. O evento de 2015 foi disponibilidade mais recuperabilidade 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ória também é errado. As categorias devem caber nos 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 vai a carga de trabalho e quais dados a seguem? Um cliente escolhendo europe-west1-b em 2015 precisava saber se um disco falho poderia ser restaurado em outra zona, se o snapshot existia fora do sistema falho, 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, quantos anos tem 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.

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 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 multirregião. Se a política permitir um backup global para recuperação de desastres, 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 facilitar isso apresentando 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 classe de falha de hardware zonal", "sobrevive a interrupção de zona através de replicação regional" e "suporta restauração pontual através de snapshots". Nenhuma frase curta cobrirá todas as arestas, 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 de hardware internos 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 do produto mudaram substancialmente desde então.

O registro público suporta várias conclusões firmes. O evento afetou Discos Permanentes em 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 disco permanente alocado. O Google disse que revisaria a pilha e atualizaria o hardware de armazenamento.

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

A inferência mais importante é suportada, mas deve ser marcada como inferência: uma divulgação mais clara do 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 único 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 com a 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 prático de evidência é 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 notificação específico do recurso, as categorias de status do incidente e o caminho de suporte para clientes enfrentando perda permanente.

Se algum dos lados não puder responder a essas perguntas antes de um evento raro de armazenamento, a arquitetura está confiando na 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 em 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 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 dentro de uma abreviação de infraestrutura. Deve ser um proprietário de serviço nomeado que entenda 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 na Bélgica continua útil porque é pequeno o suficiente para estudar 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 limpo, 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; 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.