Google Cloud divulga detalhes do incidente do GCVE

• O incidente de maio de 2024 no Google Cloud envolveu a exclusão de parte do ambiente GCVE da cliente australiana UniSuper; após uma revisão interna, a causa e as medidas de recuperação foram divulgadas
• O impacto ficou limitado a um cliente, uma região e um serviço, e a uma das várias GCVE Private Clouds do cliente; outros clientes e serviços do Google Cloud não foram afetados
• Durante a implantação inicial, um valor de entrada de uma ferramenta interna estava vazio, e o sistema o tratou como um período fixo de 1 ano, fazendo com que a Private Cloud fosse excluída automaticamente após o término desse período
• O cliente e as equipes do Google conduziram uma recuperação 24x7 durante vários dias; backups no GCS e software de backup de terceiros foram usados na restauração
• O Google Cloud adotou medidas para evitar a recorrência de incidentes do mesmo tipo, incluindo a desativação da ferramenta interna, a inspeção manual de todas as GCVE Private Clouds e a correção do comportamento de exclusão

---

Escopo do incidente

• Este incidente afetou a cliente do Google Cloud UniSuper, e o Google Cloud concluiu uma revisão interna após a recuperação dos sistemas do cliente
• O impacto foi limitado, do ponto de vista dos serviços gerenciados pelo Google, a:
  • Um cliente
  • Uma região de nuvem
  • O uso de Google Cloud VMware Engine(GCVE) pelo cliente
  • Uma Private Cloud distribuída por duas zonas entre as várias GCVE Private Clouds do cliente
• Também foram identificados itens não afetados:
  • Outros serviços do Google Cloud
  • Outros clientes que usam GCVE ou outros serviços do Google Cloud
  • Outras GCVE Private Clouds, Google Accounts, Orgs, Folders e Projects desse cliente
  • Backups de dados do Google Cloud Storage(GCS) na mesma região

Causa: parâmetro vazio em uma ferramenta interna

• No início de 2023, um operador do Google implantou uma das GCVE Private Clouds do cliente usando uma ferramenta interna para atender a um requisito específico de alocação de capacidade
• Essa ferramenta era usada em um processo de exceção para gestão de capacidade e, no 4º trimestre de 2023, foi desativada e totalmente automatizada, deixando de exigir intervenção humana
• O operador seguiu os procedimentos de controle interno, mas um dos parâmetros de entrada estava vazio durante o provisionamento da Private Cloud
• Por causa do parâmetro vazio, o sistema atribuiu a esse parâmetro um valor padrão até então desconhecido: um período fixo de 1 ano
• Quando o período de 1 ano atribuído pelo sistema terminou, a GCVE Private Cloud do cliente foi excluída

Por que não houve notificação ao cliente

• A exclusão não foi uma solicitação do cliente, mas resultou de um parâmetro vazio deixado quando um operador do Google usou uma ferramenta interna
• Se o próprio cliente tivesse solicitado a exclusão, haveria notificação prévia, mas nenhuma notificação ao cliente foi enviada para esta exclusão
• O Google Cloud explicou que corrigiu as condições que dispararam o incidente e o comportamento do subsistema para evitar que o mesmo aconteça novamente

Processo de recuperação

• O cliente e as equipes do Google colaboraram em regime 24x7 durante vários dias nas tarefas de recuperação
  • Recuperação da GCVE Private Cloud do cliente
  • Restauração das configurações de rede e segurança
  • Restauração de aplicações
  • Recuperação de dados para restabelecer toda a operação
• A abordagem arquitetural robusta e resiliente do cliente ajudou na recuperação
• Os backups de dados armazenados no Google Cloud Storage na mesma região não foram afetados pela exclusão
• Esses backups e o software de backup de terceiros tiveram papel importante na restauração rápida

Medidas para evitar recorrência

• O Google Cloud adotou várias medidas para impedir a repetição do incidente
  • Desativou a ferramenta interna que desencadeou o fluxo do incidente
  • Mesmo quando uma gestão específica de capacidade é necessária, agora ela é controlada pelo cliente por meio da interface de usuário, e as partes relacionadas foram totalmente automatizadas
  • Limpou o banco de dados do sistema e revisou manualmente todas as GCVE Private Clouds para confirmar que nenhuma outra implantação do GCVE estava exposta ao risco
  • Corrigiu o comportamento do sistema que, nesse fluxo de implantação, marcava GCVE Private Clouds para exclusão
• O Google Cloud avaliou que não houve incidente anterior dessa natureza e que não se tratou de um problema sistêmico
• Os serviços do Google Cloud contam, conforme necessário, com salvaguardas como soft delete, notificações prévias e combinações com human-in-the-loop, e foi confirmado que essas proteções continuam mantidas
• A colaboração estreita com o cliente foi importante para a recuperação rápida, e gestão de risco resiliente e mecanismos fail-safe para incidentes inesperados são essenciais para uma recuperação rápida
• O Google Cloud afirmou que, apesar deste incidente pontual, seu uptime e sua resiliência foram verificados de forma independente como estando entre os melhores das principais nuvens

[GN⁺]

Comentários do Hacker News

• Considerando a escala do impacto deste incidente, é surpreendente que as melhorias não sejam mais profundas. Tudo que fizeram foi impedir que o mesmo problema se repetisse da mesma forma; se no futuro surgir uma falha equivalente em algum lugar, os resultados podem ser parecidos ou piores.
  Por exemplo, ao encerrar um serviço, não deveriam apagar tudo imediatamente: deveriam manter os dados por alguns dias em um estado recuperável com um único botão; ou auditar os fluxos de exclusão de todos os serviços para avisar o cliente antes do encerramento por qualquer motivo; ou inserir uma revisão manual para o encerramento de serviços ativos acima de certo porte.
  Sem medidas amplas como essas, essa análise pós-incidente não tranquiliza em nada. Para um incidente tão absurdo, qualquer provedor que tenha um mínimo de orgulho do próprio serviço ou queira proteger sua reputação deveria ter demonstrado, até em excesso, que algo assim nunca mais aconteceria; mas o Google Cloud parece ter feito apenas o mínimo.

  • Não apagar os dados imediatamente ao encerrar um serviço é um fundamento de software empresarial tão óbvio que o fato de o Google não ter isso em 2024 diz muita coisa.
    Desde meus tempos de iniciante, a ideia de excluir imediatamente dados que não eram mais necessários já não fazia sentido. Em bancos de dados, o básico era usar soft delete, com uma coluna para marcar exclusão; para dados em disco, movê-los ou renomeá-los até ter certeza de que podiam mesmo ser apagados; e, ainda assim, manter backups.
  • Concordo fortemente. Pareceu que os operadores do GCP estavam mais interessados em enfatizar que não havia problemas sistêmicos na forma como gerenciam a plataforma, e justamente isso fez a leitura passar uma impressão forte e inquietante de que há, sim, problemas sistêmicos. A ausência de medidas de bom senso na análise pós-incidente parece indicar que eles não pretendem corrigir isso.
  • Trocar a exclusão real por uma flag de exclusão poderia gerar outro bug divertido, tipo “Google Cloud violou regulamentos da UE por não conseguir excluir dados de clientes”. Imagino que o Google prefira a exclusão acidental à não exclusão acidental; pelo menos na UE, parece plausível.
  • Parece piada que eles não façam isso. Não faz sentido um grande provedor de nuvem não pensar em colocar salvaguardas na exclusão de dados. Na prática, provavelmente pensaram nisso várias vezes, mas não implementaram porque custa dinheiro.
  • Eu realmente não entendo a “análise pós-incidente” do Google. Quem já operou serviços online consegue ver que ela é claramente insuficiente; além disso, a conclusão é cheia de arrogância. É algo como “foi um incidente isolado, não vai acontecer de novo, sentimos muito, mas somos excelentes e continuamos excelentes”, e não compensa em nada aquele momento de vergonha alheia que o Google Cloud protagonizou.

• Se você é cliente do GCP e tem um TAM, fazer esta pergunta vai deixá-lo em uma situação difícil: pergunte quais proteções existem para impedir que grandes quantidades de recursos da sua conta sejam apagadas por engano quando o GCP cometer um erro administrativo.
  Eles provavelmente responderão que o problema específico foi mitigado com a desativação daquela ferramenta e mais automação; então você pode continuar: “Eu sei que isso foi corrigido. Então há revisão humana antes de exclusões em grande escala?”
  Como alguém que já trabalhou no GCP e usou a AWS de forma ativa por mais tempo, a impressão é que as proteções baseadas em pessoas do GCP são quase inexistentes e muito menores que as da AWS. De qualquer forma, vale muito a pena perguntar ao TAM sobre esse risco real.

  • É só pressionar de verdade. Assim os TAMs aprendem a lidar melhor com os sistemas internos. Eles não conseguirão mudar isso sozinhos, mas às vezes dá para conseguir uma promessa de caminho de escalonamento ou um acordo informal.
    Se um número suficiente de TAMs reclamar, talvez um dia alguém lá em cima se mexa.
  • Se isso for embalado internamente como uma oportunidade para um funcionário do Google entrar em contato quando os ativos de um cliente estiverem marcados para exclusão e tentar reter o cliente, talvez funcione melhor. Como efeito colateral, também deixaria claro para todo mundo que algo está prestes a ser destruído.

• Eles dizem que “a equipe do Google trabalhou 24x7 por vários dias”, mas parecem não saber o que significa esse 7.

  • Deve querer dizer que 24 engenheiros trabalharam 7 horas por dia. Com massagens e comida grátis de refeitório preparada por chefs incluídas.
  • Se levarmos totalmente ao pé da letra, realmente fica meio sem sentido. Mas “x7” obviamente quer dizer trabalhar 7 dias por semana, então dá para trabalhar 24x7 de uma tarde de quinta até uma manhã de terça. Significa que não folgaram no fim de semana.
  • Devem ter trabalhado tanto que alguns dias pareceram semanas.
  • Se o trabalho de mitigação pegou o fim de semana, então ainda pode fazer sentido.
  • Também pode significar que os membros da equipe se revezaram para continuar trabalhando sem interrupção à noite ou no fim de semana. Pessoalmente, acho que isso deveria ser o padrão em grandes projetos desse tipo.

• Uau, eu estava errado. Achei que, em algo como Terraform, a exclusão imediata sem período de recuperação fosse o padrão, e que alguém da UniSuper tivesse testado algo e definido mal o escopo da exclusão. Ainda seria um problema de padrão, mas eu achava que seria erro de uma ferramenta de terceiros e da UniSuper.
  O fato de que, na verdade, foi um problema do Google é insano. A UniSuper deve ter pensado: “Que diabos?”

  • O texto explica o que aconteceu, e não tem relação com a UniSuper. O Google implantou uma nuvem privada usando uma ferramenta interna, e essa ferramenta interna do Google a configurou para ser excluída automaticamente um ano depois.
  • Imagino que o Google tenha dado créditos enormes na fatura do GCP ou até pago uma compensação separada.

• Posts relacionados: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
  [0]: https://news.ycombinator.com/item?id=40304666
  [1]: https://news.ycombinator.com/item?id=40313171

• O fato de não terem parado na investigação de uma ferramenta ou procedimento específico e também terem verificado se o restante não tinha problemas de exclusão automática, além de conferir o comportamento de soft delete, soa como uma revisão bastante minuciosa.
  Indo um passo além, também poderiam ter analisado todos os casos de valores padrão para ver se havia algum comportamento padrão surpreendente. Mas pode ser difícil julgar o que é “surpreendente”, já que muitas vezes quem menos conhece a ferramenta ou a API é justamente quem usa os valores padrão como estão.

  • Onde exatamente aparece a parte de que “também verificaram o comportamento de soft delete”? Eles só dizem que garantiram que esse cenário específico de exclusão automática não volte a ocorrer, e o principal motivo parece ser que “agora o deployment foi automatizado”.
    Antes já era automatizado e agora ficou mais automatizado; isso não dá nenhuma tranquilidade de que o mecanismo de exclusão seja consistentemente seguro. Só quer dizer que não há mais um operador no banco do motorista.
  • Um incidente desses é um ótimo motivo para simplesmente usar AWS, então imagino que internamente tenham tomado um belo susto.
    “Após o fim do período de 1 ano concedido pelo sistema, o GCVE Private Cloud do cliente foi excluído. A exclusão foi acionada porque um operador do Google, usando uma ferramenta interna, deixou um parâmetro em branco; como não foi uma solicitação de exclusão feita pelo cliente, nenhuma notificação foi enviada ao cliente. Se a exclusão tivesse sido iniciada pelo próprio cliente, teria havido um aviso prévio.”
    Tcharam! Somos incompetentes a ponto de permitir que uma exclusão enorme aconteça sem revisão humana. Felizmente esse cliente não confiava em nós e tinha backups fora do GCP, então não se deu completamente mal.
    “Não houve antes no Google Cloud um incidente dessa natureza. Não é um problema sistêmico.”
    Traduzindo: “Meu Deus, os vendedores da AWS e da Azure citaram nosso fracasso colossal e mandaram três e-mails para cada prospect.”

• É difícil acreditar que o primeiro alvo de um incidente desses tenha sido um fundo mútuo de bilhões de dólares. Fico feliz que o problema da UniSuper tenha sido resolvido, mas provavelmente houve outros casos pequenos o bastante para serem ignorados.
  Só espero que isso sirva como o empurrão de que o GCP precisava.

  • GCVE, ou seja, VMware gerenciado, é um serviço bem obscuro. É algo usado basicamente por empresas de bilhões de dólares que querem levantar e migrar para a nuvem um conjunto existente de VMware sem mexer muito.
  • O ponto central desse incidente é que havia uma configuração personalizada especial que a maioria dos clientes não tem nem usa, e ela contornou algumas verificações de segurança. Por isso, não poderia afetar um cliente pequeno “comum”.
  • Mesmo um cliente pequeno teria levado isso à imprensa, e a imprensa certamente teria coberto, então é difícil ver dessa forma.
    “O Google apagou nosso serviço de nuvem” é uma grande notícia para uma empresa de qualquer porte.

• Dizem que “o CIO e a equipe técnica do cliente merecem elogios por trabalhar em estreita colaboração com a equipe do Google Cloud e realizar a recuperação 24x7 de forma rápida e precisa”; fico curioso se receberam só elogios no post do blog ou se conseguiram arrancar uma montanha de créditos do Google Cloud.

  • Se o cliente for competente, não existe realidade em que ele não faça o Google pagar por esse custo. Eu não ficaria surpreso se a fatura deste ano fosse simplesmente zero.
  • Também deveria ter havido indenização punitiva.

• Sou cliente da UniSuper na Austrália. Na época eu não sabia o que estava acontecendo, mas recebia e-mails todos os dias enquanto eles tentavam resolver. Fiquei sabendo pelo noticiário o que de fato tinha acontecido. A sensação foi de que reduziram tudo a algo como indisponibilidade de sistemas.
  Dá até vertigem imaginar que algo realmente aconteceu com bilhões de dólares em dinheiro das pessoas e fundos de aposentadoria.

  • Você recebeu os mesmos e-mails que os outros? Chegavam e-mails quase todos os dias e palavras como “disruption”, “apologies” e “frustration” eram usadas várias vezes.
    Alguns dias depois também veio um e-mail com o assunto “A letter from the CEO”.
    “Gostaríamos de trazer uma atualização sobre a interrupção dos serviços.”
    “Em primeiro lugar, peço desculpas pessoalmente por esta falha e agradeço pela paciência enquanto nossas equipes trabalham dia e noite para restaurar nossos sistemas online, de forma gradual.”
    Naquelas circunstâncias, acho difícil exigir uma comunicação mais clara ou uma explicação mais explícita sobre o que estava acontecendo dentro do Google Cloud.

• O anúncio inicial sobre esse incidente foi bastante enganoso. Dava a entender que o Google tinha apagado por engano a conta inteira do GCP. Lendo este texto, fiquei um pouco mais tranquilo. Parece que o que se perdeu foi apenas um conjunto de máquinas virtuais do tamanho de uma região, e algo assim pode de fato acontecer; acredito que meus sistemas conseguiriam lidar com isso sem grandes problemas.
  O texto original soava como se buckets do GCS de todas as regiões, bancos de dados SQL etc. tivessem desaparecido todos de uma vez, o que é um problema completamente diferente, e espero poder confiar que o Google não fará algo assim.

  • Quando a UniSuper disse que não foi a conta, mas a assinatura que foi excluída, isso já era um sinal de alerta. Muita gente tirou conclusões precipitadas a partir daí.