La actualización del software de Snowflake provocó una interrupción de 13 horas en 10 regiones

Una actualización de software dejó fuera de servicio la plataforma de datos en la nube de Snowflake en 10 de sus 23 regiones globales durante 13 horas el pasado 16 de diciembre, lo que impidió a los clientes ejecutar consultas o importar datos.

Según el informe de incidentes de Snowflake, los clientes veían mensajes de “error interno de ejecución de SQL” cuando intentaban consultar sus almacenes de datos. La interrupción también afectó a la importación de archivos mediante Snowpipe y Snowpipe Streaming, y la agrupación de datos no terminaba de funcionar del todo.

Tal y como se puede leer en el informe, “nuestra investigación inicial ha identificado que nuestra versión más reciente introdujo una actualización del esquema de la base de datos incompatible con versiones anteriores”, para añadir: “Como resultado, los paquetes de la versión anterior hacían referencia de forma incorrecta a los campos actualizados, lo que provocaba errores de incompatibilidad de versiones y hacía que las operaciones fallaran o tardaran mucho tiempo en completarse”.

Según el informe, la interrupción afectó a clientes de Azure East US 2 en Virginia, AWS US West en Oregón, AWS Europe en Irlanda, AWS Asia Pacific en Bombay, Azure Switzerland North en Zúrich, Google Cloud Platform Europe West 2 en Londres, Azure Southeast Asia en Singapur, Azure Mexico Central y Azure Sweden Central.

Snowflake estimó inicialmente que el servicio se restablecería a las 15:00 UTC de ese día, pero más tarde revisó la previsión a las 16:30 UTC, ya que la región de Virginia tardó más de lo previsto en recuperarse.

La empresa no ofreció soluciones alternativas durante la interrupción, más allá de recomendar la conmutación por error a regiones no afectadas para los clientes que tenían habilitada la replicación.

Entonces, comunicó que compartiría un documento de análisis de la causa raíz (RCA, por sus siglas en inglés) en un plazo de cinco días laborables, pero como ha afirmado recientemente, “por ahora no tenemos nada más que compartir”.

Por qué la arquitectura multirregional no protegió a los clientes

Sanchit Vir Gogia, analista jefe de Greyhound Research, defiende que el tipo de fallo que afectó a Snowflake —un cambio de esquema incompatible con versiones anteriores que provocó interrupciones en varias regiones— representa una clase de fallo que se subestima de manera continua en las plataformas modernas de datos en la nube.

A su juicio, el esquema y los metadatos residen en la capa del plano de control, que gobierna cómo los servicios interpretan el estado y coordinan el comportamiento en diferentes geografías.

Para Gogia, “la redundancia regional funciona cuando el fallo es físico o infraestructural. No funciona cuando el fallo es lógico y compartido. Cuando los contratos de metadatos cambian de forma incompatible con versiones anteriores, todas las regiones que dependen de ese contrato compartido se vuelven vulnerables, independientemente de dónde residan físicamente los datos”.

En opinión de este analista, la interrupción puso de manifiesto una desalineación entre la forma en que las plataformas realizan las pruebas y el comportamiento real en producción. La producción implica versiones cambiantes de clientes, planes de ejecución almacenados en caché y trabajos de larga duración que atraviesan límites de versiones. De ahí que afirme que “los fallos de compatibilidad con versiones anteriores suelen aparecer solo cuando estas realidades se cruzan, algo que resulta difícil de simular de forma exhaustiva antes del lanzamiento”.

La situación también plantea dudas sobre el proceso de implementación por etapas de Snowflake. Las implementaciones por etapas se interpretan ampliamente como garantías de contención, cuando en realidad son mecanismos probabilísticos de reducción de riesgos, según Gogia. Los cambios de esquema incompatibles con versiones anteriores suelen degradar la funcionalidad de forma gradual a medida que interactúan componentes incompatibles, lo que permite que el cambio se propague por todas las regiones antes de que se superen los umbrales de detección.

La documentación de lanzamiento de Snowflake describe un enfoque de implementación en tres etapas que permite a la compañía “supervisar la actividad a medida que se trasladan las cuentas y responder a cualquier problema que pueda surgir”. La documentación también afirma que “si se detectan problemas durante el traslado de las cuentas a una versión completa o a una versión de parche, el lanzamiento podría detenerse o revertirse”, y que el seguimiento suele completarse en un plazo de 24 a 48 horas. Sin embargo, la interrupción del 16 de diciembre afectó a 10 regiones simultáneamente y se prolongó mucho más allá de ese plazo.

Por eso, Gogia cree que “cuando una plataforma depende de servicios de metadatos coordinados a nivel mundial, el aislamiento regional es condicional, no absoluto”. Y añade: “Cuando los síntomas se hacen evidentes, la reversión ya no es una opción sencilla”.

Para este analista, la reversión presenta retos porque, aunque el código puede revertirse con rapidez, eso no es posible con el estado. Los cambios en el esquema y los metadatos interactúan con las cargas de trabajo en tiempo real, los servicios en segundo plano y el estado almacenado en caché, lo que requiere tiempo, una secuenciación cuidadosa y validaciones para evitar daños colaterales durante el proceso de reversión.

Las brechas de seguridad y las interrupciones comparten una debilidad común

Según Gogia, tanto la interrupción del pasado 16 diciembre como los problemas de seguridad de Snowflake a principios de 2024 deberían cambiar de forma fundamental la manera en que los directores de informática definen la resiliencia operativa. A mediados de 2024, aproximadamente 165 clientes de Snowflake fueron objetivo de delincuentes que utilizaron credenciales robadas mediante infecciones de infostealer.

En opinión de Gogia, “no se trata de incidentes aislados pertenecientes a diferentes silos de riesgo. Son manifestaciones del mismo problema subyacente: la madurez del control bajo presión. En los incidentes de seguridad, las credenciales robadas explotaron una débil gobernanza de la identidad. En la interrupción del servicio, un cambio incompatible con versiones anteriores explotó una débil gobernanza de la compatibilidad”.

Por consiguiente, defiende que los directores de informática deben ir más allá del lenguaje del cumplimiento normativo y de los promedios de tiempo de actividad para plantear preguntas sobre el comportamiento real de las plataformas cuando fallan las hipótesis. “Las preguntas correctas son las relacionadas con el comportamiento: ¿cómo se comporta la plataforma cuando fallan las hipótesis?, ¿cómo detecta los riesgos emergentes?, ¿con qué rapidez puede limitarse el radio de impacto?”, dice para concluir.

(computerworld.es)

Les estaremos informando con mucho más detalle, en el marco del informe especial: “Ciberseguridad basada en AI, Ciberseguridad convencional, (Data centers, redes y dispositivos). Ciberseguridad multinube, Ciberseguridad en universo hiperconectado, Arquitecturas de Ciberseguridad basadas en AI», que estamos preparando para nuestra edición 217 y publicaremos en el mes de enero.

Mantente conectado a nuestra revista Channel News Perú, haciendo clic aquí y suscribiéndote a nuestro newsletter para contenido de valor diario.