La pérdida de disco 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 consecutivos afectaran la red eléctrica local que abastece un centro de datos europeo. Google informó más tarde que una fracción muy pequeña del espacio de Persistent Disk asignado en la zona sufrió escrituras recientes irrecuperables.
• La cuestión de responsabilidad no es si el porcentaje fue grande. Es si los clientes comprendieron que un Persistent Disk zonal, incluso con redundancia gestionada por el proveedor dentro de la zona, seguía dentro de un dominio de fallo físico y no era un sustituto de las instantáneas independientes, la replicación regional o las copias de seguridad a nivel de aplicación.
• Google controlaba la resiliencia del sitio físico, la susceptibilidad del hardware de almacenamiento, la gestión de eventos de energía, el lenguaje de durabilidad del Persistent Disk, los informes de estado y la claridad de las guías de copia de seguridad. Los clientes controlaban la arquitectura de la carga de trabajo, los programas 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 con instantáneas disponibles, cambios de hardware y software, orientación sobre copias de seguridad y evidencia del cliente. En un incidente de nube que implique pérdida de datos, una página de estado en verde no puede ser toda la prueba de recuperación.

Un porcentaje minúsculo puede ser aún un fallo grave

El incidente de Google Cloud en Bélgica se recuerda a veces como una curiosidad porque el porcentaje de almacenamiento perdido permanentemente fue extremadamente pequeño. Esa es la primera lectura 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 dejado suficientemente claro el riesgo físico restante del sitio antes del suceso.

El registro público delIncidente #15056 de Compute Enginede Google comenzó el 13 de agosto de 2015 para los discos 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 por ciento de los discos de la zona eran susceptibles de sufrir un rendimiento degradado, y después que menos del 0,1 por ciento experimentaban fallos de lectura en algunos bloques. El registro del incidente también indicaba a los clientes afectados que restaurar desde instantáneas era una solución temporal, mientras que la creación de nuevos discos Persistent Disk y la restauración desde instantáneas no se veían afectadas.

Los informes de prensa que recogieron la explicación posterior del incidente, incluido el reportaje de centros de datos Dynamics sobrerayos y pérdida de datosy el relato de Silicon UK sobrela causa de la interrupción, registraron la declaración de Google de que cuatro rayos sucesivos sobre la red eléctrica local causaron una breve pérdida de energía en los sistemas de almacenamiento que albergaban capacidad de disco para las instancias GCE en europe-west1-b. Google afirmó que casi todos los datos se habían confirmado en almacenamiento estable, pero en muy pocos casos las escrituras recientes eran irrecuperables, lo que provocó una pérdida permanente de datos en Persistent Disk. La cifra ampliamente repetida fue inferior al 0,000001 por ciento del espacio asignado de Persistent Disk en la zona afectada.

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

Por lo tanto, la cuestión de responsabilidad no es «¿Por qué existen los rayos?». El rayo es un peligro externo. La cuestión es quién controlaba las decisiones de diseño que permitieron que un evento repetido de la red eléctrica alcanzara el estado recién escrito del disco, quién controlaba la claridad de las guías de durabilidad y copia 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. El problema de responsabilidad fundamental fue la frontera 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 la latencia hacia usuarios belgas o europeos, por razones de contratación, por menores emisiones de carbono o por compromisos de ubicación de datos. Lapágina actual de ubicaciones de nubede Google y ladocumentación de regiones y zonasde Compute Engine explican que los recursos residen 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 de los datos y la localidad 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 satisfacer un requisito de ubicación y, sin embargo, ser la arquitectura de durabilidad equivocada 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 satisfacer 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. Son dimensiones diferentes.

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

El incidente de 2015 expuso la brecha interpretativa. Un cliente podría interpretar «persistente» como que el disco sobrevive a una máquina virtual, lo cual es correcto. Otro podría interpretarlo como que el disco es inmune a la pérdida de datos, lo cual no es una inferencia segura. Un cliente podría leer «Europa» o «Bélgica» como la decisión principal de cumplimiento y detenerse ahí. El incidente muestra que la ubicación no es un plan de recuperación. La misma colocación local que favorece 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 debe 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 la aplicación 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 diga que restauren desde instantáneas. La divulgación de mayor valor es un mapeo claro 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 responsabilidad en la nube

La nube puede hacer que la infraestructura física desaparezca del trabajo diario del cliente, pero no hace desaparecer los peligros físicos. Los sistemas de energía, 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 la arquitectura de recuperación de la aplicación queda en parte con el cliente.

La explicación del incidente reportada por múltiples medios afirmó que los sistemas auxiliares automáticos restauraron la energía rápidamente y que los sistemas de almacenamiento estaban diseñados con batería de respaldo, pero algunos datos recién escritos se encontraban en sistemas más susceptibles a fallos de energía por drenaje 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 encuadre de «discos antiguos» utilizado en algunos reportajes debe tratarse con cuidado: los artículos públicos describían la susceptibilidad del hardware, pero el registro de estado público no publica cada componente, antigüedad o decisión interna de ingeniería.

Según los informes, Google afirmó que realizó 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 actualizado de centros de datos Knowledgeregistró que Google estaba reemplazando sistemas de almacenamiento con hardware más resistente a los fallos de energía y que gran parte del almacenamiento de Persistent Disk ya estaba en hardware más nuevo. Esas son medidas reactivas. 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 controló el estado del incidente. La página de estado de la nube 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 discos nuevos, 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 refiere solo a la disponibilidad del servicio, sino al estado recuperable.

La página de estado terminó cuando Google marcó el incidente como resuelto. Para los clientes que restauraron desde instantáneas, la recuperación continuó a través de la validación de la aplicación, 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 consistente y la empresa puede dar cuenta del intervalo faltante. Pueden ser momentos muy diferentes.

La orientación sobre 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 ha sido probada no es una vía de recuperación. Por lo tanto, el incidente convirtió una frase común en la nube, la responsabilidad compartida, en una pregunta concreta: ¿quién había creado y verificado realmente un punto de recuperación antes del evento físico?

Laguía actual de opciones 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 las 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 los primeros tiempos 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 quiescencia, volcado o operaciones de copia de seguridad coordinadas para que el estado restaurado sea utilizable. Ladocumentación de instantáneas coherentes con la aplicación para Linuxde Google explica los programas de instantáneas con volcado del sistema invitado. El punto importante no es el conjunto exacto de características en 2015 frente a ahora. Es el principio de control duradero: la recuperabilidad requiere un proceso de copia de seguridad alineado con la aplicación, no simplemente una promesa de almacenamiento del proveedor.

Los equipos pequeños están especialmente expuestos a esta brecha. Una startup o un proyecto municipal pueden elegir una sola zona de 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 copias 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 importan: 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 debe diseñar el sistema de almacenamiento para sobrevivir a los peligros físicos esperados, publicar información clara sobre los dominios de fallo, proporcionar herramientas de instantáneas y replicación, preservar la evidencia del incidente e identificar los recursos afectados. El cliente debe seleccionar un objetivo de recuperación, programar copias de seguridad, validar las restauraciones, colocar las 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 de la región.

Ninguna de las partes puede hacer todo el trabajo 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 ofrece ahora opciones de alta disponibilidad con Persistent Disk regional e Hyperdisk. Ladocumentación de discos regionalesexplica los discos replicados entre zonas de 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 disponibilidadexplicita el caso de uso de disponibilidad.

Esas características son mejoras significativas para muchas cargas de trabajo, pero no eliminan el juicio arquitectónico. La replicación regional puede proteger contra la indisponibilidad zonal o los 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, las credenciales comprometidas, un problema de control a nivel de región o un punto de recuperación demasiado reciente para ser útil. El cliente sigue necesitando copias de seguridad para la corrupción, la retención y la reversión.

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 en otra zona. Puede ser demasiado antigua, inconsistente con la aplicación, no estar disponible para el proyecto correcto, estar cifrada con una clave a la que el entorno de recuperación no puede acceder o estar almacenada en una ubicación que contradice la política. Ladocumentación de cifrado de discosde Google recuerda a los clientes que los discos y las instantáneas pueden implicar diferentes elecciones de claves. La estrategia de copia de seguridad debe incluir el acceso, las claves, la retención, la ubicación y las 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 en condiciones definidas. No son una declaración completa de la recuperabilidad o la pérdida empresarial. Un crédito puede compensar una fracción de los cargos del servicio mientras el cliente aún debe restaurar los datos, conciliar las 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 de los créditos del SLA.

Para los propietarios de soberanía de datos, las opciones de replicación requieren un trabajo cuidadoso de políticas. 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 de los reguladores y el apetito de riesgo. Por el contrario, un requisito de ubicación estricto puede impedir algunas copias de seguridad entre regiones y exigir un diseño de mayor disponibilidad local.

El acto responsable es hacer explícita esa compensación antes de que se pierdan los 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 libro de contabilidad: la evidencia de recuperación del cliente. ¿Qué discos tuvieron 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 porcentajes de impacto repetidos en la página de estado fueron útiles porque evitaron una tranquilidad vaga. Menos del 1 por ciento susceptibles, menos del 0,1 por ciento con fallos de lectura y menos del 0,000001 por ciento 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 que fallan activamente y los datos irrecuperables son estados diferentes. Un cliente en cada estado necesita una acción diferente.

El cliente también necesita una notificación específica del recurso. Una página de estado general le dice al mercado que algo va 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 comprobar la consistencia de la aplicación, restaurar desde sus propias instantáneas y decidir qué datos empresariales recientes podían faltar. Ambos tipos de evidencia son necesarios.

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

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 sido superadas, 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, sino también una brecha en la gobernanza de la arquitectura.

El departamento de compras debería hacer las mismas preguntas por adelantado. ¿Qué dominio de fallo ocupa este disco? ¿Qué copia independiente existe? ¿Quién es el propietario de los programas de instantáneas? ¿Cómo se prueban las restauraciones? ¿Cuál es el intervalo máximo tolerable de pérdida de escritura? ¿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 en una decisión de riesgo.

El departamento de compras no debería comprar una región como si fuera una copia de seguridad

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

Un expediente de compras 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 algún 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, el programa 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.

El departamento de compras también debería 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 los errores de la aplicación. El contrato o el plan de soporte deben especificar cómo se identifican los recursos afectados, cómo se informa a los clientes si se recomienda una restauración, cómo se notifica la pérdida permanente, cómo se conservan los registros y cómo se prioriza el soporte técnico.

Una página genérica de estado del servicio 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 debe 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 y reducir 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 responsabilidad no es que cada carga de trabajo necesite el mismo diseño, sino que la compensación debe estar documentada y aceptada por el propietario de la empresa que comprende las consecuencias de las escrituras perdidas.

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

La evidencia de auditoría debe incluir los resultados de las pruebas de restauración, la antigüedad de la copia de seguridad, su ubicación, el acceso a la clave 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 son a menudo 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 simulacros. Los equipos pequeños pueden tener un ingeniero, un proyecto, una región y un panel de control que hace que el disco parezca duradero porque la máquina virtual se puede eliminar sin eliminar el volumen. Su riesgo no es la ignorancia en un sentido peyorativo, sino la consecuencia normal de que la abstracción haga demasiado bien su trabajo.

Los proveedores de nube pueden reducir ese riesgo mediante valores predeterminados y advertencias. Cuando un cliente crea un disco zonal único para una carga de trabajo con forma de base de datos, la interfaz puede preguntar sobre los programas de copia de seguridad, recomendar políticas de instantáneas, mostrar el dominio de fallo y advertir que se requieren instantáneas para una 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 en lo profundo de 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 simples. Cada almacén de datos persistente debe tener un propietario designado, un objetivo de punto de recuperación, un programa de instantáneas o copias 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 debe realizarse antes del lanzamiento en producción, no durante el primer incidente. La prueba debe restaurar en un entorno separado, comprobar 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, eso debe 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 inevitable la lección. El porcentaje fue minúsculo. Sin embargo, un equipo pequeño con un disco afectado y sin una instantánea reciente podría enfrentarse a una pérdida permanente. La educación sobre resiliencia a menudo se centra en grandes desastres; este incidente muestra que los 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 las empresas. Un equipo de plataforma corporativa puede ofrecer «plantillas de nube aprobadas» a los equipos de producto. Esas plantillas no deberían limitarse a crear un disco zonal y dejar las opciones de copia de seguridad a los propietarios de la aplicación, que pueden no entender la capa de almacenamiento. La plataforma debe exigir u orientar firmemente los programas 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 permanentemente perdidos. Esas categorías producen diferentes deberes. Los datos retrasados pueden requerir procesamiento de colas. 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ó con cuidado a través de errores de lectura, rendimiento degradado y solución alternativa de instantáneas. Los informes contemporáneos registraron más tarde la pérdida permanente de una fracción minúscula del 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 el 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 forma demasiado amplia puede causar pánico innecesario. La precisión, por lo tanto, 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 intervalo 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 que se sabe que tienen fallos de lectura y los recursos con datos irrecuperables confirmados. Debe decir si las instantáneas, los discos nuevos, los discos regionales u otros productos de almacenamiento se ven 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 responsable de protección de datos, un auditor, un consejo de administración 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 de disponibilidad más recuperabilidad para una población reducida de discos. No fue evidencia de acceso no autorizado. Tratar cada incidente de nube como una violación es un error; tratar cada incidente de almacenamiento como un problema transitorio de disponibilidad también es un error.

Las categorías deben ajustarse a los hechos.

Las decisiones de localidad deben incluir una historia de salida

Cada 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 conectar el disco restaurado y si el DNS, las credenciales y los operadores podían recuperar el servicio. Esas preguntas siguen vigentes aunque los nombres y las características de los productos 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 el cómputo: qué entorno puede ejecutar los datos restaurados. La tercera es la identidad y las claves: quién puede acceder y descifrar. La cuarta es la red y el enrutamiento: cómo llegan los usuarios 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 a las partes interesadas de lo sucedido y del intervalo de datos que 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 en múltiples zonas, instantáneas más frecuentes y controles de copia de seguridad in situ más sólidos. Si los datos pueden permanecer en 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 debe seguir ocupándose de 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 silenciosamente.

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 una clase de fallo de hardware zonal», «sobrevive a una interrupción de zona mediante replicación regional» y «admite restauración a un punto en el tiempo mediante instantáneas». Ninguna frase corta cubrirá todos los casos extremos, pero un lenguaje sencillo sobre dominios de fallo es más difícil de malinterpretar que los amplios adjetivos sobre durabilidad.

Incógnitas y límites cuidadosos

El registro público no nombra a todos los clientes afectados, todas las escrituras perdidas, todos los modelos de hardware internos ni todos los cambios de ingeniería posteriores al incidente. No prueba que el fallo de la copia de seguridad de un cliente concreto causara su pérdida. No establece una violación legal, una constatación de negligencia, una indemnización por daños o una infracció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 de los productos han cambiado sustancialmente desde entonces.

El registro público sí respalda varias conclusiones firmes. El evento afectó a los discos 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 el relato de Google describieron cuatro rayos sucesivos en la red eléctrica local, una breve pérdida de energía en los sistemas de almacenamiento, la susceptibilidad del hardware en un subconjunto del almacenamiento y la pérdida permanente de una fracción minúscula del espacio asignado de Persistent Disk.

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 de los dominios de fallo y las copias de seguridad independientes probadas reducen la posibilidad de que un peligro en el sitio físico se convierta en una pérdida permanente de la aplicación. Eso no es lo mismo que decir que todos los clientes sin una instantánea fueron negligentes o que Google incumplió un deber legal. Es una conclusión práctica de control. El proveedor puede hacer visible el límite y construir una infraestructura más resistente. El cliente puede elegir un diseño de recuperación que no dependa de un único disco local.

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

Utilice los SLA, pero no confunda los créditos con el estado restaurado.

La prueba práctica de evidencia es lo suficientemente sencilla como para realizarla antes de cerrar la compra. Un comprador debería poder señalar el disco activo, el último punto de recuperación independiente, el destino de la restauración, la identidad y la ruta de la clave, la persona responsable de la 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 se enfrentan a una pérdida permanente.

Si alguna de las partes no puede responder a esas preguntas antes de un evento de almacenamiento poco común, la arquitectura se basa en la esperanza oculta tras nombres de productos respetables.

Es por eso que un pequeño evento de 2015 sigue perteneciendo a un programa de responsabilidad de 2026. Convierte un modelo abstracto de responsabilidad compartida en un contrato operativo visible. La pila del proveedor puede ser más sólida 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, la copia recuperable debe probarse y la recuperación probada debe ser comprendida por el propietario de la empresa que se enfrentará a los usuarios cuando falten los datos.

El propietario final de esa decisión no debe ocultarse en la jerga de la infraestructura. Debe ser un propietario de servicio designado que comprenda 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.

La tipografía es el arte y la técnica de organizar los tipos para que el lenguaje escrito sea legible, legible y visualmente atractivo. Implica la selección de tipos de letra, tamaños de punto, longitudes de línea, interlineado y espaciado entre letras.

• La tipografía se originó con la invención de los tipos móviles por Johannes Gutenberg en el siglo XV.
• Los elementos clave incluyen la selección de la fuente, el kerning, el tracking y el interlineado.
• Una buena tipografía mejora la legibilidad y transmite el estado de ánimo o el tono en el diseño.

El registro de la pérdida de discos en Bélgica sigue siendo útil porque es lo suficientemente pequeño para estudiarlo y lo suficientemente grave para cambiar las prácticas. Muestra que la redundancia gestionada por el proveedor puede fallar al borde de un peligro físico, que los porcentajes de estado deben leerse por categorías, que las instantáneas solo importan si existen y se restauran limpiamente, y que la localidad no es un sustituto de la recuperabilidad independiente.

Google controlaba el centro de datos y la pila de almacenamiento; los clientes controlaban su arquitectura de recuperación; los auditores y los equipos de compras controlaban si esas dos responsabilidades se examinaban antes del próximo evento poco común. El resultado responsable es un plan de almacenamiento que pueda decir dónde residen los datos, dónde reside una copia recuperable, qué tan reciente es, quién puede restaurarla y qué evidencia demostrará la recuperación cuando la zona local ya no pueda.