Google Cloud publica detalles del incidente de GCVE

• El incidente de Google Cloud de mayo de 2024 consistió en la eliminación de parte del entorno GCVE del cliente australiano UniSuper; tras una revisión interna, se publicaron la causa y las medidas de recuperación
• El alcance del impacto se limitó a un cliente, una región y un servicio, y a una de las varias GCVE Private Cloud del cliente; otros clientes y servicios de Google Cloud no se vieron afectados
• Durante la implementación inicial, uno de los valores de entrada de una herramienta interna estaba vacío, y el sistema lo trató como un plazo fijo de 1 año, lo que provocó que la Private Cloud se eliminara automáticamente al finalizar ese período
• El cliente y los equipos de Google realizaron una recuperación 24x7 durante varios días; se usaron copias de seguridad en GCS y software de respaldo de terceros para la restauración
• Google Cloud tomó medidas para evitar que se repita un incidente del mismo tipo: retiró esa herramienta interna, revisó manualmente todas las GCVE Private Cloud y corrigió el comportamiento de eliminación

---

Alcance del incidente

• Este incidente afectó al cliente de Google Cloud UniSuper, y Google Cloud completó una revisión interna después de restaurar los sistemas del cliente
• El impacto estuvo limitado en términos de los servicios administrados por Google
  • Un cliente
  • Una región de la nube
  • El uso de Google Cloud VMware Engine (GCVE) por parte del cliente
  • Una Private Cloud distribuida en dos zonas entre las varias GCVE Private Cloud del cliente
• También se distinguieron los elementos no afectados
  • Otros servicios de Google Cloud
  • Otros clientes que usan GCVE u otros servicios de Google Cloud
  • Otras GCVE Private Cloud, Google Account, Orgs, Folders y Projects de ese cliente
  • Copias de seguridad de datos en Google Cloud Storage (GCS) dentro de la misma región

Causa: un parámetro vacío en una herramienta interna

• A comienzos de 2023, un operador de Google implementó una de las GCVE Private Cloud del cliente con una herramienta interna para cumplir con ciertos requisitos de colocación de capacidad
• Esta herramienta se usaba en un proceso de excepción para la gestión de capacidad y fue retirada y completamente automatizada en el cuarto trimestre de 2023, por lo que ya no requiere intervención humana
• El operador siguió los procedimientos internos de control, pero durante el aprovisionamiento de la Private Cloud uno de los parámetros de entrada quedó vacío
• Debido al parámetro vacío, el sistema asignó a ese parámetro un valor predeterminado que en ese momento no se conocía: un plazo fijo de 1 año
• Cuando terminó el período de 1 año asignado por el sistema, se eliminó la GCVE Private Cloud del cliente

Por qué no hubo notificación al cliente

• La eliminación no fue solicitada por el cliente, sino que se originó en el parámetro vacío dejado cuando un operador de Google usó la herramienta interna
• Si el cliente hubiera solicitado directamente la eliminación, habría recibido una notificación previa, pero en esta eliminación no se envió ninguna notificación al cliente
• Google Cloud explicó que corrigió las condiciones que dispararon el incidente y el comportamiento de los subsistemas para evitar que vuelva a ocurrir

Proceso de recuperación

• El cliente y los equipos de Google colaboraron durante varios días en modalidad 24x7 para realizar la recuperación
  • Recuperación de la GCVE Private Cloud del cliente
  • Restauración de la configuración de red y seguridad
  • Restauración de aplicaciones
  • Recuperación de datos para restablecer toda la operación
• El enfoque de arquitectura sólida y resiliente del cliente ayudó a la recuperación
• Las copias de seguridad de datos almacenadas en Google Cloud Storage en la misma región no se vieron afectadas por la eliminación
• Esas copias de seguridad y el software de respaldo de terceros desempeñaron un papel importante en la restauración rápida

Medidas para evitar recurrencia

• Google Cloud implementó varias medidas para impedir que el incidente se repita
  • Retiró la herramienta interna que desencadenó el flujo del incidente
  • Aunque se requiera gestión específica de capacidad, ahora queda bajo control del cliente mediante una interfaz de usuario, y las partes relacionadas están completamente automatizadas
  • Ordenó la base de datos del sistema y revisó manualmente todas las GCVE Private Cloud para confirmar que otras implementaciones de GCVE no estuvieran expuestas al riesgo
  • Corrigió el comportamiento del sistema que, en ese flujo de implementación, configuraba las GCVE Private Cloud como objetivo de eliminación
• Google Cloud evaluó que no había ocurrido antes un incidente de esta naturaleza y que no se trata de un problema sistémico
• Los servicios de Google Cloud cuentan, según sea necesario, con protecciones como soft delete, notificaciones previas y combinaciones de human-in-the-loop, y se confirmó que esas protecciones siguen vigentes
• La colaboración estrecha con el cliente fue importante para la recuperación rápida, y una gestión de riesgos resiliente y mecanismos fail-safe para incidentes inesperados son esenciales para una recuperación ágil
• Google Cloud afirmó que, pese a este incidente puntual, su uptime y resiliencia se han verificado de forma independiente como de los niveles más altos entre las principales nubes

[GN⁺]

Comentarios de Hacker News

• Viendo el alcance del impacto de este incidente, sorprende que las mejoras no sean más profundas. Parece que solo llegaron al punto de evitar que el mismo problema se repita de la misma manera, así que si más adelante aparece una falla equivalente en otro lugar, podría tener resultados similares o peores.
  Por ejemplo, al dar de baja un servicio, en vez de borrar de inmediato, debieron conservar los datos durante varios días y dejarlos en un estado recuperable con un solo botón; o auditar los flujos de eliminación de todos los servicios para notificar al cliente antes de la baja por cualquier motivo; o incorporar una revisión manual para la baja de servicios activos por encima de cierto tamaño.
  Sin medidas amplias como estas, este post mortem no tranquiliza en absoluto. Ante un incidente tan absurdo, cualquier proveedor con un mínimo de orgullo por su servicio o interés en proteger su reputación debería haber demostrado, incluso de forma exagerada, que esto no volverá a ocurrir; Google Cloud parece haber hecho solo lo mínimo.

  • No borrar los datos de inmediato al dar de baja un servicio es un fundamento del software empresarial tan obvio que dice mucho que Google no lo tuviera en 2024.
    Incluso desde mis tiempos de recién llegado, la idea de borrar de inmediato datos que ya no se necesitan no tenía sentido. En bases de datos, lo básico era usar soft delete, con una columna para marcar la eliminación; y con los datos en disco, moverlos o renombrarlos hasta estar seguros de que realmente se podían borrar, dejando copias de seguridad de todos modos.
  • Totalmente de acuerdo. Parecía que les interesaba más enfatizar que no hay problemas sistémicos en la forma en que los operadores de GCP administran la plataforma, y justamente por eso la lectura deja una sensación fuerte e inquietante de que sí hay un problema sistémico. Que el post mortem no incluya medidas de sentido común parece indicar que no tienen intención de corregirlo.
  • Si cambian la eliminación real por un flag de eliminación, podría aparecer otro bug divertido del tipo “Google Cloud violó las normas de la UE al no poder borrar datos de clientes”. Creo que Google preferiría una eliminación accidental antes que una no eliminación accidental, al menos en la UE.
  • Parece un chiste que no hagan esto. No tiene sentido que un gran proveedor de nube ni siquiera piense en poner salvaguardas para la eliminación de datos. Siendo realistas, probablemente lo pensaron varias veces, pero no lo implementaron porque costaba dinero.
  • De verdad no entiendo el “post mortem” de Google. Cualquiera que haya operado servicios en línea puede ver que es claramente insuficiente, y además las conclusiones están llenas de arrogancia. Suena a “fue un incidente aislado, no volverá a pasar, lo sentimos mucho, pero somos excelentes y seguiremos siendo excelentes”, lo que no compensa en absoluto ese momento de llevarse la mano a la cara por Google Cloud.

• Si eres cliente de GCP y tienes un TAM, pregúntale esto y lo vas a poner en aprietos: qué protecciones existen para impedir que, cuando GCP cometa un error administrativo, elimine por accidente una gran cantidad de recursos de mi cuenta.
  Probablemente responda que el problema específico se mitigó retirando esa herramienta y agregando más automatización; entonces puedes seguir con: “sé que eso ya lo arreglaron. Entonces, ¿hay revisión humana antes de una eliminación a gran escala?”.
  Habiendo trabajado antes en GCP y usado AWS de forma activa durante más tiempo, me parece que las protecciones basadas en personas de GCP son casi inexistentes y mucho menores que las de AWS. En cualquier caso, vale mucho la pena preguntarle al TAM por este riesgo real.

  • Hay que presionar bien. Así los TAM aprenden a manejar mejor los sistemas internos. No podrán cambiarlo solos, pero a veces se puede obtener una promesa de ruta de escalamiento o algún acuerdo informal.
    Si suficientes TAM hacen ruido, quizá algún día alguien de arriba se mueva.
  • Si lo presentan internamente como una oportunidad para que un empleado de Google contacte al cliente e intente retenerlo cuando sus activos estén programados para eliminación, probablemente funcione mejor. Como efecto secundario, también deja claro para todos que algo está por desaparecer.

• Dicen que “el equipo de Google trabajó 24x7 durante varios días”, pero parece que no saben qué significa ese 7.

  • Debe querer decir que 24 ingenieros trabajaron 7 horas al día. Incluyendo masajes y comida gratis del comedor hecha por chefs.
  • Si lo tomas completamente literal, sí, no tiene mucho sentido. Pero x7 obviamente significa trabajar 7 días a la semana, así que desde un jueves por la tarde hasta un martes por la mañana también se puede trabajar 24x7. Significa que no descansaron el fin de semana.
  • Parece que trabajaron tanto que los días se sintieron como semanas.
  • Si el trabajo de mitigación cayó durante el fin de semana, igual podría tener sentido.
  • También podría significar que los miembros del equipo se turnaron para seguir trabajando sin interrupciones por la noche ni durante el fin de semana. Personalmente, creo que en un proyecto grande de este tipo eso debería ser siempre lo estándar.

• Vaya, estaba equivocado. Pensé que en algo como Terraform la eliminación inmediata sin periodo de recuperación era el valor predeterminado, y que alguien de UniSuper había estado probando y configuró mal el alcance de eliminación. Seguiría siendo un problema de valores predeterminados, pero pensé que sería un error de una herramienta de terceros y de UniSuper.
  Que en realidad haya sido un problema de Google es una locura. UniSuper debe haber pensado: “¿pero qué demonios?”.

  • El artículo explica qué pasó y no tuvo nada que ver con UniSuper. Google desplegó una nube privada con una herramienta interna, y esa herramienta interna de Google la configuró para eliminarse automáticamente un año después.
  • Supongo que Google les habrá dado créditos enormes en la factura de GCP, o incluso algún pago de compensación aparte.

• Artículos 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

• No se quedaron solo en investigar una herramienta o procedimiento específico: también revisaron el resto para ver si no había problemas de eliminación automática y verificaron el comportamiento de eliminación temporal, así que suena como una revisión bastante exhaustiva.
  Podrían haber ido un paso más allá y revisar todos los casos de valores predeterminados para ver si había comportamientos predeterminados sorprendentes. Aunque puede ser difícil juzgar qué es “sorprendente”, porque quienes menos conocen una herramienta o API suelen ser quienes usan los valores predeterminados tal cual.

  • ¿Dónde aparece exactamente la parte de que “también verificaron el comportamiento de eliminación temporal”? Solo dicen que garantizaron que este escenario específico de eliminación automática no vuelva a ocurrir, y la razón principal también parece ser que “ahora el despliegue está automatizado”.
    Antes ya estaba automatizado y ahora está más automatizado, pero eso no da ninguna tranquilidad de que el mecanismo de eliminación sea consistentemente seguro. Solo significa que ya no hay un operador en el asiento del conductor.
  • Este tipo de incidente es una excelente razón para simplemente usar AWS, así que internamente deben haberse llevado un buen susto.
    “El GCVE Private Cloud del cliente se eliminó después de que terminara el período de un año asignado por el sistema. La eliminación se activó porque un operador de Google que usaba una herramienta interna dejó un parámetro vacío y, como no fue una solicitud de eliminación del cliente, no se envió ninguna notificación al cliente. Si la eliminación la hubiera iniciado el cliente directamente, habría habido una notificación previa.”
    ¡Tarán! Somos tan incompetentes que permitimos que ocurra una eliminación enorme sin revisión humana. Por suerte, este cliente no confiaba en nosotros y tenía respaldos fuera de GCP, así que no quedó completamente arruinado.
    “Google Cloud no había tenido antes un incidente de esta naturaleza. No es un problema sistémico.”
    Traducción: “Dios mío, los vendedores de AWS y Azure citaron nuestro fracaso monumental y les mandaron tres correos a cada uno de nuestros prospectos”.

• Cuesta creer que el primer caso en que ocurrió algo así haya sido un fondo mutuo de miles de millones de dólares. Me alegra que el problema de UniSuper se haya resuelto, pero probablemente hubo otros casos lo suficientemente pequeños como para ser ignorados.
  Solo espero que esto sea el impulso que GCP necesitaba.

  • GCVE, es decir VMware administrado, es un servicio bastante oscuro. Lo usan básicamente empresas de miles de millones de dólares que quieren levantar y trasladar tal cual sus entornos VMware existentes a la nube.
  • El punto clave de este incidente fue que había una configuración personalizada especial que la mayoría de los clientes no tienen ni usan, y eso evitó algunas comprobaciones de seguridad. Por eso no podía afectar a un cliente pequeño “común”.
  • Aunque fuera un cliente pequeño, lo habría llevado a la prensa, y la prensa sin duda lo habría cubierto, así que es difícil verlo así.
    “Google eliminó nuestro servicio en la nube” es una noticia grande para una empresa de cualquier tamaño.

• Dicen que “el CIO del cliente y el equipo técnico merecen reconocimiento por haber trabajado estrechamente con el equipo de Google Cloud para ejecutar la recuperación 24x7 de forma rápida y precisa”, pero me pregunto si solo recibieron elogios en la publicación del blog o si también consiguieron una montaña de créditos de Google Cloud.

  • Si el cliente es competente, no hay realidad en la que no logre que Google pague ese costo. No me sorprendería que este año no tenga factura.
  • También debió haber daños punitivos.

• Soy cliente de UniSuper en Australia. En ese momento no sabía qué estaba pasando, pero recibía correos todos los días mientras intentaban resolverlo. Me enteré por las noticias de lo que realmente había ocurrido. Sentí que lo redujeron todo a algo como tiempo de inactividad del sistema.
  Da vértigo imaginar que algo le hubiera pasado de verdad a los miles de millones de dólares reunidos en dinero y fondos de pensión de la gente.

  • ¿Recibiste los mismos correos que los demás? Llegaban casi todos los días y usaban varias veces palabras como “disruption”, “apologies” y “frustration”.
    Unos días después también llegó un correo titulado “A letter from the CEO”.
    “Queremos darles una actualización sobre la interrupción del servicio.”
    “En primer lugar, quisiera disculparme personalmente por esta interrupción y agradecerles por su paciencia mientras nuestros equipos trabajan día y noche para volver a poner nuestros sistemas en línea de manera progresiva.”
    Dada la situación en ese momento, creo que sería difícil exigir una comunicación más clara o una explicación más explícita de lo que había ocurrido dentro de Google Cloud.

• El anuncio inicial sobre este incidente fue bastante confuso. Sonaba como si Google hubiera eliminado por error toda la cuenta de GCP. Después de leer este texto me siento algo más tranquilo. Parece que lo que se perdió fue solo una región de máquinas virtuales, y algo así puede ocurrir en la práctica; creo que mi sistema podría soportarlo sin mayores problemas.
  El texto original sonaba como si hubieran desaparecido todos los buckets de GCS de todas las regiones, las bases de datos SQL, etc., pero eso es un problema completamente distinto, y espero poder confiar en que Google no haría algo así.

  • Cuando UniSuper dijo que se había eliminado una suscripción y no una cuenta, eso fue una señal de alerta. Mucha gente sacó conclusiones apresuradas a partir de ahí.