La pérdida de discos de Google Cloud en Bélgica mostró dónde la localidad deja de ser resiliencia

Resumen

• En agosto de 2015, los discos Persistent Disk estándar de Google Compute Engine en la zona europe-west1-b experimentaron errores de lectura después de que cuatro rayos sucesivos afectaran la red eléctrica local que abastecía a un centro de datos europeo. Google informó posteriormente que una pequeñísima fracción del espacio de Persistent Disk asignado en la zona sufrió escrituras recientes irrecuperables.
• El problema de rendición de cuentas no es si el porcentaje fue grande. Es si los clientes entendían que un Persistent Disk zonal, incluso con redundancia gestionada por el proveedor dentro de la zona, seguía estando dentro de un dominio de fallo físico y no era un sustituto de instantáneas independientes, replicación regional o copias de seguridad a nivel de aplicación.
• Google controlaba la resiliencia del sitio físico, la susceptibilidad del hardware de almacenamiento, el manejo de eventos de energía, el lenguaje de durabilidad de Persistent Disk, los informes de estado y la claridad de la guía de copias de seguridad. Los clientes controlaban la arquitectura de la carga de trabajo, las programaciones de instantáneas, los objetivos de recuperación, las opciones de replicación y si los requisitos de localidad se confundían con la recuperabilidad.
• El registro práctico de reparación debe distinguir entre servicio restaurado, datos irrecuperables, solución alternativa de instantáneas disponible, cambios de hardware y software, guía de copias de seguridad y evidencia del cliente. En un incidente en la nube que involucra pérdida de datos, una página de estado en verde no puede ser toda la prueba de recuperación.

Un pequeño porcentaje puede seguir siendo un fallo grave

El incidente de Google Cloud en Bélgica a veces se recuerda como una curiosidad porque el porcentaje de almacenamiento perdido permanentemente fue extremadamente pequeño. Esa es la lente equivocada. Para un cliente cuyo disco contenía la escritura reciente irrecuperable, el porcentaje no importaba. La pregunta relevante era si el cliente tenía una copia independiente recuperable, si la aplicación podía tolerar el punto de recuperación y si el lenguaje de durabilidad del proveedor había hecho suficientemente claro el riesgo físico del sitio antes del evento.

Elincidente #15056 de Compute Enginede Google comenzó el 13 de agosto de 2015 para los Persistent Disk en europe-west1-b. La página de estado informó primero de errores de lectura para los clientes con máquinas en esa zona, luego explicó que menos del 1% de los discos de la zona eran susceptibles a un rendimiento degradado, y luego que menos del 0,1% experimentaban fallos de lectura en algunos bloques. El registro del incidente también indicó a los clientes afectados que la restauración desde instantáneas era una solución alternativa, mientras que la creación de nuevos Persistent Disk y la restauración desde instantáneas no se veían afectados.

Los informes de los medios que capturaron la explicación posterior del incidente, incluido elinforme sobre rayos y pérdida de datosde centros de datos Dynamics y elrelato de la causa de la interrupciónde Silicon UK, registraron la declaración de Google de que cuatro rayos sucesivos en la red eléctrica local causaron una breve pérdida de energía en los sistemas de almacenamiento que albergaban la capacidad de disco para las instancias de GCE en europe-west1-b. Google dijo que casi todos los datos se confirmaron en almacenamiento estable, pero en muy pocos casos las escrituras recientes fueron irrecuperables, lo que resultó en una pérdida permanente de datos en Persistent Disk. La cifra ampliamente repetida fue menos del 0,000001% del espacio de Persistent Disk asignado en la zona afectada.

Ese registro respalda tanto la moderación como la seriedad. Sería incorrecto describir el evento como una destrucción generalizada de datos en Google Cloud. El servicio afectado fue Persistent Disk estándar en una zona; los índices de autopsia y la cobertura contemporánea informaron que SSD Persistent Disk, las instantáneas y los SSD locales estaban fuera de la población de pérdida permanente. También sería incorrecto descartar el incidente porque el denominador era enorme. La durabilidad de los datos es un hecho binario para el registro que importa. Un pequeño porcentaje irrecuperable sigue siendo una pérdida permanente para alguien.

La pregunta de rendición de cuentas no es, por tanto, "¿Por qué existió el rayo?" El rayo es un peligro externo. La pregunta es quién controlaba las decisiones de diseño que permitieron que un evento de energía repetido de la red eléctrica alcanzara el estado de disco recién escrito, quién controlaba la claridad de la durabilidad y la guía de copias de seguridad, y quién controlaba la arquitectura del cliente que tenía o no un punto de recuperación independiente. El desencadenante fue físico.

La cuestión fundamental de rendición de cuentas era el límite entre la durabilidad local gestionada por el proveedor y la recuperabilidad gestionada por el cliente.

Localidad y durabilidad no son la misma promesa

La localidad en la nube resuelve problemas reales. Un cliente puede elegir europe-west1 por latencia hacia usuarios belgas o europeos, por razones de contratación, por características de menor carbono o por compromisos de ubicación de datos. Lapágina de ubicaciones en la nubede Google y ladocumentación sobre regiones y zonasde Compute Engine explican que los recursos viven en regiones y zonas, y que las zonas y regiones son abstracciones lógicas de los recursos físicos subyacentes. Esa abstracción es útil porque los clientes no necesitan gestionar edificios. Es peligrosa si los clientes infieren que un recurso zonal ha escapado del dominio de fallo físico.

La soberanía y la localidad de los datos se refieren a dónde se almacenan o procesan los datos. La recuperabilidad se refiere a si existe otra copia utilizable después de un fallo. Un disco puede cumplir un requisito de ubicación y seguir siendo la arquitectura de durabilidad incorrecta para una base de datos si su único estado recuperable reside en la misma zona y en la misma clase de almacenamiento. Una instantánea puede satisfacer la recuperación, pero puede tener sus propias opciones de ubicación. Un disco regional puede aumentar la disponibilidad entre zonas, pero puede no cumplir todos los objetivos de punto de recuperación.

Un segundo proveedor puede reducir la dependencia común, pero puede aumentar la complejidad operativa y el riesgo de gobernanza de datos. Estas son dimensiones diferentes.

Lostérminos de residencia de datosactuales de Google y el material de compromisos europeos abordan dónde pueden residir los datos del cliente para los servicios compatibles. No convierten cada recurso local en una copia de seguridad independiente. Del mismo modo, la página del producto Persistent Disk describealmacenamiento en bloque duradero, y ladocumentación de Persistent Diskde Compute Engine establece que Persistent Disk tiene redundancia integrada para proteger contra fallos de equipos y mantener la disponibilidad de los datos durante eventos de mantenimiento. Esos son compromisos significativos del proveedor. No son una garantía de que todos los peligros posibles a escala del sitio dejarán cero escrituras recientes irrecuperables en todas las configuraciones.

El incidente de 2015 expuso la brecha interpretativa. Un cliente podría leer "persistente" como que el disco sobrevive a una máquina virtual, lo cual es correcto. Otro podría leerlo como que el disco es inmune a la pérdida de datos, lo que no es una inferencia segura. Un cliente podría leer "Europa" o "Bélgica" como la principal decisión de cumplimiento y detenerse ahí. El incidente muestra que la ubicación no es un plan de recuperación. La misma ubicación local que ayuda a la latencia y la política puede concentrar el riesgo físico si no existe una copia de seguridad independiente.

Por lo tanto, el lenguaje del proveedor debería ser explícito sobre los dominios de fallo. Un Persistent Disk zonal es duradero dentro de su diseño, pero sigue ligado a una zona. Las instantáneas, los discos regionales, la replicación y la copia de seguridad de aplicaciones cambian el modelo de fallo. Los clientes necesitan esa distinción antes de un incidente, no solo después de que una página de estado les indique que restauren desde instantáneas. La divulgación de mayor valor es una asignación clara desde la elección de almacenamiento hasta el dominio de fallo, el punto de recuperación, el tiempo de recuperación y el deber del cliente.

El desencadenante físico pertenece al registro de rendición de cuentas en la nube

La nube puede hacer que la infraestructura física desaparezca del trabajo diario del cliente, pero no hace que los peligros físicos desaparezcan. Los sistemas de alimentación, las baterías, los controladores de almacenamiento, el firmware, los racks, la distribución eléctrica y los eventos de la red eléctrica siguen siendo parte del servicio. El cliente paga al proveedor para gestionar esas capas porque el proveedor tiene mayor escala y experiencia. Eso hace que la resiliencia física sea un deber del proveedor, mientras que deja la arquitectura de recuperación de aplicaciones parcialmente en manos del cliente.

La explicación del incidente reportada por múltiples medios dijo que los sistemas auxiliares automáticos restauraron la energía rápidamente y que los sistemas de almacenamiento estaban diseñados con respaldo de batería, pero algunos datos recién escritos se encontraban en sistemas más susceptibles a fallos de energía por agotamiento prolongado o repetido de la batería. Esa frase es importante porque distingue un solo rayo de un estrés físico repetido que encontró un subconjunto vulnerable de almacenamiento.

También muestra por qué el marco de "discos viejos" utilizado en algunos informes debe tratarse con cuidado: los artículos públicos describían la susceptibilidad del hardware, pero el registro público de estado no publica todos los componentes, la edad o las decisiones internas de ingeniería.

Google dijo haber realizado una amplia revisión de la distribución eléctrica, el hardware informático y el software que controla la capa de Persistent Disk, y que estaba actualizando el hardware de almacenamiento para que fuera menos susceptible a este tipo de fallo de energía. Elinforme actualizadode centros de datos Knowledge registró que Google estaba reemplazando los sistemas de almacenamiento con hardware más resistente a la energía y que gran parte del almacenamiento de Persistent Disk ya estaba en hardware más nuevo. Esas son medidas de respuesta. Deben entenderse como controles del lado del proveedor sobre la pila física y de almacenamiento, no como acciones de arquitectura del cliente.

El proveedor también controlaba el estado del incidente. La página de estado de Cloud proporcionó actualizaciones repetidas, porcentajes de impacto y orientación sobre la solución alternativa de instantáneas. Ese registro es materialmente mejor que el silencio. Sin embargo, pasó de errores de lectura y rendimiento degradado a pérdida permanente a medida que avanzaba la investigación. Los clientes necesitaban saber qué discos tenían errores de lectura, si las instantáneas eran utilizables, si se podían crear nuevos discos, qué escrituras eran irrecuperables y si el almacenamiento era seguro para nuevas cargas de trabajo.

En un evento de pérdida de datos, la clasificación del impacto no se trata solo de la disponibilidad del servicio; se trata del estado recuperable.

La página de estado finalizó cuando Google marcó el incidente como resuelto. Para los clientes que restauraron desde instantáneas, la recuperación continuó mediante la validación de aplicaciones, la conciliación de datos y la posible pérdida de transacciones recientes. Esa distinción es esencial. La restauración del servicio del proveedor significa que el servicio de almacenamiento está operativo. La recuperación del cliente significa que la carga de trabajo tiene un conjunto de datos coherente y la empresa puede dar cuenta del intervalo faltante. Esos pueden ser momentos muy diferentes.

La guía de instantáneas es donde la responsabilidad compartida se vuelve concreta

La actualización de estado de Google durante el incidente indicó a los clientes afectados que podían restaurar desde instantáneas. Esa recomendación es útil solo para los clientes que tenían instantáneas utilizables. Una instantánea que no existe, es demasiado antigua, está en la ubicación incorrecta, carece de consistencia de aplicación o nunca se ha probado no es una ruta de recuperación. Por lo tanto, el incidente convirtió una frase común en la nube, responsabilidad compartida, en una pregunta concreta: ¿quién había creado y verificado realmente un punto de recuperación antes del evento físico?

La guía actual deopciones de protección de datos para discos e instanciasde Google enmarca la recuperación en torno al objetivo de tiempo de recuperación, el objetivo de punto de recuperación, el caso de uso y el costo. Ladocumentación de creación de instantáneasexplica las instantáneas estándar y de archivo. Ladescripción general de instantáneasdescribe las instantáneas incrementales. Laguía de instantáneas programadasrecomienda programaciones como práctica de copia de seguridad, y lapágina de mejores prácticas de instantáneasañade restricciones prácticas y consejos de fiabilidad. Esa documentación actual es más clara que muchas suposiciones de la era temprana de la nube.

La consistencia de la aplicación sigue siendo una preocupación del cliente. Una instantánea de disco captura el estado del bloque; una base de datos puede necesitar operaciones de puesta en reposo, vaciado o copia de seguridad coordinada para que el estado restaurado sea utilizable. Ladocumentación de instantáneas coherentes con aplicaciones Linuxde Google explica las programaciones de instantáneas con vaciado del invitado. El punto importante no es el conjunto exacto de funciones en 2015 versus ahora. Es el principio de control duradero: la recuperabilidad requiere un proceso de copia de seguridad alineado con la aplicación, no meramente una promesa de almacenamiento del proveedor.

Los equipos pequeños están especialmente expuestos a esta brecha. Una startup o un proyecto municipal puede elegir una sola zona en la nube para reducir la latencia y el costo. Puede ejecutar una base de datos en un Persistent Disk y confiar en el nombre del producto y la reputación del proveedor como sustituto del diseño de copia de seguridad. Puede que no tenga un ingeniero de almacenamiento dedicado, un proceso de restauración probado o un análisis de impacto empresarial.

El incidente de 2015 muestra por qué la documentación y los valores predeterminados del producto son importantes: los clientes con menos experiencia interna necesitan opciones de almacenamiento y advertencias que hagan evidente el límite del dominio de fallo.

Los deberes del proveedor y del cliente deben expresarse en lenguaje operativo. Google debería diseñar el sistema de almacenamiento para que sobreviva a los peligros físicos esperados, publicar información clara sobre el dominio de fallo, proporcionar herramientas de instantáneas y replicación, preservar la evidencia del incidente e identificar los recursos afectados. El cliente debería seleccionar un objetivo de recuperación, programar copias de seguridad, validar restauraciones, colocar instantáneas o réplicas fuera del dominio de fallo relevante y decidir si las restricciones de localidad permiten copias fuera de la zona o región.

Ninguna de las partes puede hacer el trabajo completo de la otra.

Los discos regionales y la replicación cambian el modelo de fallo, no la necesidad de pensar en la recuperación

Google ahora ofrece Persistent Disk regional y opciones de alta disponibilidad de Hyperdisk. Ladocumentación de discos regionalesexplica los discos replicados entre zonas en una región para una mayor disponibilidad, y laguía de conmutación por error de discos regionalesdescribe la conexión forzada cuando falla una zona primaria. El blog de Google sobrediscos Persistent Disk regionales para cargas de trabajo de alta disponibilidadhace explícito el caso de uso de disponibilidad.

Esas características son mejoras significativas para muchas cargas de trabajo, pero no eliminan el juicio de arquitectura. La replicación regional puede proteger contra la falta de disponibilidad zonal o errores de almacenamiento en una zona. Puede no proteger contra la corrupción a nivel de aplicación que se replica, la eliminación por parte del cliente, credenciales comprometidas, un problema de control en toda la región o un punto de recuperación demasiado reciente para ser útil. Un cliente todavía necesita copias de seguridad para corrupción, retención y retroceso.

Un disco replicado es un mecanismo de alta disponibilidad; no es automáticamente un programa completo de protección de datos.

La misma precaución se aplica a las instantáneas. Una instantánea puede ser independiente del disco fallido y puede restaurarse a otra zona. Puede que aún sea demasiado antigua, inconsistente con la aplicación, no disponible para el proyecto correcto, cifrada con una clave a la que el entorno de recuperación no puede acceder, o almacenada en una ubicación que entra en conflicto con la política. Ladocumentación de cifrado de discosde Google recuerda a los clientes que los discos y las instantáneas pueden implicar diferentes opciones de clave. La estrategia de copia de seguridad debe incluir acceso, claves, retención, ubicación y pruebas de restauración, no solo la existencia de una entrada de instantánea.

ElSLA actualde Compute Engine y laversión histórica del SLA de 2015muestran otra distinción. Los SLA abordan la disponibilidad del servicio y los créditos bajo condiciones definidas. No son una declaración completa de recuperabilidad o pérdida empresarial. Un crédito puede compensar una fracción de los cargos del servicio mientras el cliente aún debe restaurar datos, conciliar transacciones, notificar a los usuarios o reconstruir la confianza. El hecho de que la página de estado indicara a los clientes afectados que restauraran desde instantáneas muestra que la recuperación operativa estaba fuera de la cuestión del crédito del SLA.

Para los responsables de la soberanía de datos, las opciones de replicación requieren un trabajo de políticas cuidadoso. Un cliente puede exigir que los datos permanezcan en Europa o Bélgica. Eso no significa que todas las copias deban estar en una sola zona. Puede permitir instantáneas en una multirregión europea u otra región europea, dependiendo de los términos del servicio, las expectativas del regulador y el apetito de riesgo. Por el contrario, un requisito estricto de ubicación puede impedir algunas copias de seguridad entre regiones y requerir un diseño de disponibilidad local más alto.

El acto responsable es hacer explícito ese equilibrio antes de que se pierdan datos.

La evidencia de recuperación del cliente es parte del incidente

Los informes de incidentes de los proveedores a menudo terminan con la restauración del servicio. Los eventos de pérdida de datos necesitan un segundo registro: la evidencia de recuperación del cliente. ¿Qué discos tenían errores de lectura? ¿Qué escrituras fueron irrecuperables? ¿Qué clientes restauraron desde instantáneas? ¿Qué instantáneas fallaron o eran demasiado antiguas? ¿Qué aplicaciones necesitaron conciliación manual? ¿Qué cargas de trabajo de clientes no tenían copia de seguridad? ¿Qué mensajes se enviaron a los clientes sobre la pérdida permanente y los pasos de solución alternativa?

Parte de esa evidencia es privada, pero las categorías importan públicamente.

Los repetidos porcentajes de impacto de la página de estado fueron útiles porque evitaron un tranquilizador vago. Menos del 1% susceptible, menos del 0,1% con fallos de lectura y menos del 0,000001% de pérdida permanente describen categorías cada vez más reducidas. No deben fusionarse en una sola declaración. Los discos susceptibles, los discos con fallos activos y los datos irrecuperables son estados diferentes. Un cliente en cada estado necesita una acción diferente.

El cliente también necesita un aviso específico del recurso. Una página de estado general le dice al mercado que algo está mal. No le dice a un operador de base de datos si un disco específico está afectado. Google tenía la mayor capacidad para identificar los recursos afectados, correlacionar los sistemas de almacenamiento y proporcionar avisos a nivel de cuenta. Los clientes tenían la mayor capacidad para verificar la consistencia de la aplicación, restaurar desde sus propias instantáneas y decidir qué datos comerciales recientes podrían faltar. Ambos tipos de evidencia son necesarios.

Esta división es especialmente importante para los auditores. Un auditor que revisa una carga de trabajo en la nube después de un evento de este tipo no debería preguntar solo si el proveedor informó un pequeño porcentaje.

Las preguntas correctas son si la organización conocía su objetivo de punto de recuperación, si existían instantáneas antes del incidente, si las pruebas de restauración habían pasado, si las ubicaciones de las copias de seguridad coincidían con la política, si los propietarios de las aplicaciones aceptaron la pérdida residual y si el aviso del proveedor proporcionó suficientes detalles para clasificar los recursos afectados. Si la respuesta es no, el fallo no fue solo un incidente del proveedor; también fue una brecha de gobernanza de la arquitectura.

Las adquisiciones deberían hacer las mismas preguntas de antemano. ¿Qué dominio de fallo ocupa este disco? ¿Qué copia independiente existe? ¿Quién es dueño de las programaciones de instantáneas? ¿Cómo se prueban las restauraciones? ¿Cuál es el intervalo máximo tolerable de escrituras perdidas? ¿Permite la política de localidad una réplica en otro lugar? ¿Qué aviso dará el proveedor si los medios de almacenamiento, la energía o los sistemas de control amenazan la durabilidad de los datos? ¿Cuál es la ruta de soporte durante un evento de pérdida de datos?

Estas preguntas convierten la "durabilidad en la nube" de un eslogan a una decisión de riesgo.

Las adquisiciones no deberían comprar una región como si fuera una copia de seguridad

El incidente de Bélgica es especialmente útil para las adquisiciones porque expone un atajo común. Un comprador pregunta dónde vivirán los datos. El proveedor responde con una región o zona. El comprador trata esa respuesta como resiliencia. Pero la respuesta de ubicación y la respuesta de recuperación son preguntas contractuales diferentes. Una describe la colocación; la otra describe lo que sucede después de una pérdida, corrupción o falta de disponibilidad. Un contrato que asegura la localidad de los datos pero deja el diseño de la copia de seguridad indefinido ha resuelto solo la mitad del problema.

Un registro de adquisiciones sólido identificaría el punto de recuperación y el tiempo de recuperación requeridos por la carga de trabajo antes de elegir el almacenamiento. Una carga de trabajo de registro puede tolerar cierto retraso pero no una pérdida silenciosa. Una base de datos transaccional puede necesitar copias de seguridad coherentes con la aplicación cada pocos minutos. Un registro público puede necesitar copias de seguridad inmutables y restauraciones probadas. Un pequeño proyecto de análisis puede aceptar instantáneas diarias.

El producto de almacenamiento, la programación de instantáneas, la ubicación de la réplica, el diseño de la clave de cifrado y el ejercicio de restauración deben seguir el requisito de la misión, no al revés.

Las adquisiciones también deberían exigir un modelo de notificación del proveedor. Durante un incidente de almacenamiento, el proveedor puede saber que un disco está en la población afectada antes de que el cliente pueda diagnosticarlo a partir de errores de aplicación. El contrato o plan de soporte debe especificar cómo se identifican los recursos afectados, cómo se informa a los clientes si se recomienda una restauración, cómo se reporta la pérdida permanente, cómo se conservan los registros y cómo se prioriza el soporte técnico.

Una página de estado de servicio genérica no es suficiente para un evento de pérdida de datos porque la acción del cliente es específica del recurso.

El comprador también debería evitar una falsa elección entre soberanía y resiliencia. Para muchas cargas de trabajo europeas, una copia independiente en otra región europea puede satisfacer la política mientras reduce el riesgo de una sola zona. Para cargas de trabajo más estrictas, puede ser necesaria la replicación regional dentro de un país o ubicaciones de copia de seguridad cuidadosamente gobernadas. Para algunos datos, el costo y la complejidad de las copias adicionales pueden ser desproporcionados. El punto de rendición de cuentas no es que cada carga de trabajo necesite el mismo diseño.

Es que la compensación debe ser documentada y aceptada por el propietario del negocio que comprende la consecuencia de las escrituras perdidas.

Los auditores deberían desconfiar de las respuestas de lista de verificación. "Los datos se almacenan en Europa" no responde si se pueden restaurar. "Persistent Disk es duradero" no responde si la aplicación puede tolerar una pérdida de escritura reciente. "Las instantáneas están disponibles" no responde si estaban configuradas, eran recientes, completas y probadas. "El proveedor tiene un SLA" no responde si el cliente tiene una copia utilizable.

La evidencia de auditoría debe incluir resultados de pruebas de restauración, antigüedad de la copia de seguridad, ubicación de la copia de seguridad, acceso a claves y un registro de quién aceptó el riesgo residual.

Los equipos pequeños necesitan valores predeterminados que hagan visible la recuperabilidad

Los clientes con más probabilidades de malinterpretar el límite a menudo son los menos equipados para recuperarse de cruzarlo. Las grandes empresas pueden tener equipos de almacenamiento, plataformas de copia de seguridad, comités de auditoría y ejercicios de simulación. Los equipos pequeños pueden tener un ingeniero, un proyecto, una región y un panel que hace que el disco parezca duradero porque la máquina virtual se puede eliminar sin eliminar el volumen. Su riesgo no es ignorancia en un sentido peyorativo; es la consecuencia normal de que la abstracción haga su trabajo demasiado bien.

Los proveedores de la nube pueden reducir ese riesgo mediante valores predeterminados y advertencias. Cuando un cliente crea un disco de una sola zona para una carga de trabajo con forma de base de datos, la interfaz puede preguntar sobre las programaciones de copia de seguridad, recomendar políticas de instantáneas, mostrar el dominio de fallo y advertir que se requieren instantáneas para la recuperación independiente. La documentación puede colocar tablas de dominios de fallo cerca de los flujos de trabajo de creación en lugar de profundamente en las guías de fiabilidad.

Las páginas de precios pueden mostrar el costo de no tener copia de seguridad como una aceptación de riesgo, no solo el costo de una instantánea como un extra.

Los clientes pueden reducir el riesgo con rutinas sencillas. Cada almacén de datos persistente debe tener un propietario designado, un objetivo de punto de recuperación, una programación de instantáneas o copia de seguridad, una fecha de prueba de restauración, una ubicación de copia de seguridad y un plan de acceso a claves. La primera prueba de restauración debería realizarse antes del lanzamiento a producción, no durante el primer incidente. La prueba debería restaurar a un entorno separado, verificar la consistencia de la aplicación y confirmar que el equipo puede autenticarse, descifrar y reconectar la carga de trabajo.

Si el equipo no puede permitirse el diseño de recuperación, esa debería ser una decisión empresarial consciente.

El evento de 2015 es un buen caso de enseñanza porque la pérdida no fue espectacular. No hubo un colapso global que hiciera la lección inevitable. El porcentaje fue minúsculo. Sin embargo, un equipo pequeño con un disco afectado y sin instantánea reciente aún podría enfrentar una pérdida permanente. La educación en resiliencia a menudo se centra en desastres gigantes; este incidente muestra que fallos raros y estrechos son suficientes para castigar las suposiciones de copia de seguridad no probadas.

La misma lógica se aplica a las plataformas internas construidas por empresas. Un equipo de plataforma corporativa puede ofrecer "plantillas de nube aprobadas" a los equipos de producto. Esas plantillas no deberían simplemente crear un disco zonal y dejar las opciones de copia de seguridad a los propietarios de las aplicaciones que quizás no entiendan la capa de almacenamiento. La plataforma debería exigir o guiar firmemente las programaciones de instantáneas, las opciones de replicación, los períodos de retención y las pruebas de restauración.

La responsabilidad compartida dentro de una empresa refleja la responsabilidad compartida con el proveedor de la nube.

La pérdida de datos cambia el peso moral del lenguaje de estado

Muchos estados de interrupción pueden redactarse en términos de errores elevados, rendimiento degradado o restauración. La pérdida de datos requiere un vocabulario diferente. Los clientes necesitan saber si los datos están retrasados, no disponibles, corruptos, revertidos, parcialmente irrecuperables o perdidos permanentemente. Esas categorías producen diferentes deberes. Los datos retrasados pueden requerir procesamiento en cola. Los datos no disponibles pueden requerir conmutación por error. Los datos corruptos pueden requerir validación y reversión.

La pérdida permanente puede requerir notificación, conciliación, compensación o revisión legal.

La página de estado de Google avanzó cuidadosamente a través de errores de lectura, rendimiento degradado y solución alternativa de instantáneas. Los informes contemporáneos registraron posteriormente una pérdida permanente para una pequeña fracción de almacenamiento. La reducción de las poblaciones afectadas fue útil, pero la lección pública es que la pérdida permanente debe nombrarse claramente una vez conocida. Una página de estado que permanece demasiado tiempo con lenguaje de disponibilidad puede hacer que los clientes traten un evento de pérdida de datos como un problema de reintento.

Una página de estado que nombra la pérdida permanente de manera demasiado amplia puede causar pánico innecesario. Por lo tanto, la precisión no es decorativa; controla la respuesta del cliente.

Un buen lenguaje de estado para incidentes de almacenamiento debe indicar el producto afectado, la zona, el rango de tiempo, la clase de recurso, el síntoma, la acción actual del cliente y el estado de la evidencia. Debe separar los recursos en riesgo de los recursos con fallos de lectura conocidos y de los recursos con datos confirmados como irrecuperables. Debe decir si las instantáneas, los discos nuevos, los discos regionales u otros productos de almacenamiento están afectados. Debe indicar si el proveedor puede identificar los recursos afectados directamente y cómo se contactará a los clientes.

Debe actualizarse cuando el proveedor pase de la reparación del servicio a la conciliación de datos.

Esta precisión también ayuda a los clientes a informar a sus propias partes interesadas. Un delegado de protección de datos, un auditor, un consejo o el propietario de una pequeña empresa necesita saber si el evento cambió la confidencialidad, la integridad, la disponibilidad o la recuperabilidad. El evento de 2015 fue disponibilidad más recuperabilidad para una población de discos estrecha. No fue evidencia de acceso no autorizado. Tratar cada incidente en la nube como una violación está mal; tratar cada incidente de almacenamiento como un problema de disponibilidad transitorio también está mal. Las categorías deben ajustarse a los hechos.

Las decisiones de localidad deben incluir una historia de salida

Toda decisión de localidad debe incluir una historia de salida: si esta zona, región o elección de almacenamiento local falla, ¿a dónde va la carga de trabajo y qué datos la siguen? Un cliente que eligió europe-west1-b en 2015 necesitaba saber si un disco fallido podía restaurarse en otra zona, si la instantánea existía fuera del sistema fallido, si la aplicación podía adjuntar el disco restaurado y si el DNS, las credenciales y los operadores podían recuperar el servicio. Esas preguntas siguen siendo actuales aunque los nombres de productos y las funciones hayan cambiado.

Una historia de salida tiene varias partes. La primera son los datos: qué copia existe, qué antigüedad tiene y dónde reside. La segunda es la computación: qué entorno puede ejecutar los datos restaurados. La tercera es la identidad y las claves: quién puede acceder y descifrarlos. La cuarta es la red y el enrutamiento: cómo los usuarios llegan al servicio recuperado. La quinta es la validación: cómo sabe el equipo que la aplicación restaurada es correcta. La sexta es la comunicación: cómo se informa a los usuarios y partes interesadas de lo sucedido y qué intervalo de datos puede faltar.

Las restricciones de localidad hacen que la historia de salida sea más compleja, pero no opcional. Si los datos deben permanecer en Bélgica, el diseño puede requerir resiliencia local multizona, instantáneas más frecuentes y controles de copia de seguridad in situ más sólidos. Si los datos pueden permanecer dentro de Europa, el diseño puede utilizar otra región europea o almacenamiento de instantáneas multirregión. Si la política permite una copia de seguridad global para la recuperación ante desastres, el diseño aún debe manejar la privacidad, el cifrado y los controles de acceso.

La clave es decidir explícitamente en lugar de permitir que la colocación predeterminada del disco decida en silencio.

El proveedor puede facilitar esto presentando los dominios de fallo en el lenguaje del cliente. En lugar de solo nombres de productos, la interfaz puede describir "sobrevive a la eliminación de la VM", "sobrevive a la clase de fallo de hardware zonal", "sobrevive a la interrupción de la zona mediante replicación regional" y "admite restauración a un momento dado mediante instantáneas". Ninguna frase corta cubrirá todos los casos, pero el lenguaje simple del dominio de fallo es más difícil de malinterpretar que los adjetivos amplios de durabilidad.

Incógnitas y límites cuidadosos

El registro público no nombra a cada cliente afectado, cada escritura perdida, cada modelo de hardware interno o cada cambio de ingeniería posterior al incidente. No prueba que la falla de copia de seguridad de un cliente específico causara su pérdida. No establece un incumplimiento legal, una conclusión de negligencia, una concesión de daños o una violación de cumplimiento. Tampoco prueba que todos los productos de almacenamiento actuales de Google Cloud conlleven el mismo riesgo de 2015. La infraestructura en la nube y las características del producto han cambiado sustancialmente desde entonces.

El registro público sí respalda varias conclusiones firmes. El evento afectó a los Persistent Disk en europe-west1-b. Los clientes experimentaron errores de lectura. Google indicó a los clientes afectados que restauraran desde instantáneas. Los informes contemporáneos basados en la declaración de Google describieron cuatro rayos sucesivos en la red eléctrica local, una breve pérdida de energía en los sistemas de almacenamiento, susceptibilidad del hardware en un subconjunto de almacenamiento y pérdida permanente de una pequeña fracción del espacio de Persistent Disk asignado.

Google dijo que revisaría la pila y actualizaría el hardware de almacenamiento. La documentación actual de Google hace explícitas las instantáneas, las copias de seguridad programadas, los discos regionales y las opciones de protección de datos.

La inferencia más importante está respaldada pero debe marcarse como inferencia: una divulgación más clara del dominio de fallo y copias de seguridad independientes probadas reducen la probabilidad de que un peligro en el sitio físico se convierta en una pérdida permanente de aplicación. Eso no es lo mismo que decir que todo cliente sin una instantánea fue negligente o que Google incumplió un deber legal. Es una conclusión de control práctico. El proveedor puede hacer visible el límite y construir una infraestructura más resiliente. El cliente puede elegir un diseño de recuperación que no dependa de un solo disco local.

El incidente también advierte contra dos errores opuestos. El primero es el fatalismo en la nube: concluir que porque un proveedor de hiperescala perdió una pequeña cantidad de datos una vez, no se puede confiar en el almacenamiento en la nube. El segundo es la complacencia en la nube: concluir que porque el porcentaje fue minúsculo, nadie necesita copias de seguridad independientes. La posición madura es más exigente y más útil. Use la durabilidad del proveedor, pero no la confunda con un punto de recuperación. Use la localidad, pero no la confunda con resiliencia. Use los SLA, pero no confunda los créditos con el estado restaurado.

La prueba práctica de evidencia es lo suficientemente simple como para realizarla antes de cerrar la adquisición. Un comprador debería poder señalar el disco en vivo, el punto de recuperación independiente más reciente, el destino de la restauración, la ruta de identidad y clave, la persona responsable de una restauración y la prueba exitosa más reciente. Un proveedor debería poder señalar el dominio de fallo, la ruta de notificación específica del recurso, las categorías de estado del incidente y la ruta de soporte para los clientes que enfrentan pérdida permanente.

Si alguna de las partes no puede responder esas preguntas antes de un evento de almacenamiento poco común, la arquitectura está confiando en la esperanza oculta dentro de nombres de productos respetables.

Por eso un pequeño evento de 2015 todavía pertenece a un programa de rendición de cuentas de 2026. Convierte un modelo abstracto de responsabilidad compartida en un contrato operativo visible. La pila del proveedor puede ser más fuerte ahora, y los clientes tienen más herramientas, pero la lógica de decisión sigue siendo la misma: la localidad debe ir acompañada de una copia recuperable, una copia recuperable debe ser probada, y una recuperación probada debe ser entendida por el propietario del negocio que se enfrentará a los usuarios cuando falten datos.

El propietario final de esa decisión no debe estar oculto dentro de una abreviatura de infraestructura. Debe ser un propietario de servicio designado que entienda el costo de una hora perdida, un día perdido o un intervalo de transacciones perdido.

Ese propietario también debe tener autoridad para financiar la copia de seguridad.