Resumen

  • Cloudflare informó que el plano de control y la analítica sufrieron una interrupción desde el 2 de noviembre de 2023, aunque el tráfico edge principal continuó [1].
  • El disparador descrito públicamente fue una secuencia de fallo eléctrico en PDX-04, un centro de datos de Oregón que alojaba dependencias críticas [1][3].
  • El incidente expuso dependencias en Kafka, ClickHouse, identidad, herramientas internas y sistemas necesarios para observar o recuperar servicios [1].
  • Una segunda falla eléctrica en el mismo sitio en 2024 puso a prueba la preparación Code Orange y redujo el impacto sobre el plano de control [2].
  • Un cierre creíble debe probar configuración, analítica, identidad, herramientas internas y acciones visibles para clientes durante una pérdida completa de sitio.

Qué ocurrió

Cloudflare sitúa el inicio en las 11:43 UTC del 2 de noviembre. La capa afectada fue el plano de control y los servicios de analítica [1]. Eso implica que clientes y operadores podían tener problemas para cambiar reglas, consultar métricas o usar funciones administrativas, aunque el tráfico distribuido que no requería una nueva decisión siguiera funcionando.

El punto físico fue PDX-04. Cloudflare describe un evento de mantenimiento no planificado de Portland General Electric que afectó una alimentación independiente, seguido por agotamiento de baterías, dificultades para reiniciar generadores, acceso al edificio, sustitución de interruptores y arranque ordenado de servidores [1]. Baxtel también vincula la interrupción con un fallo eléctrico en un centro Flexential en Hillsboro, Oregón, y cita la misma explicación sobre la alimentación eléctrica [3].

La lección para el lector no experto es directa: un servicio cloud puede seguir transportando tráfico ya configurado mientras pierde parte de la superficie que permite modificar, diagnosticar o confirmar el estado. Cuando esa superficie depende de un sitio único, la continuidad de clientes queda ligada a una dependencia física y organizativa que debe ser probada.

La dependencia no era una sola máquina

El postmortem no describe un servidor aislado. Nombra componentes del plano de control y analítica, Kafka, ClickHouse, identidad y autorización, herramientas internas y mecanismos para reiniciar o reconstruir servicios [1]. Algunas dependencias se conocían; otras aparecieron con más claridad sólo cuando el sitio completo dejó de estar disponible.

Por eso el caso pertenece a infraestructura de red. El plano de control es una superficie de autoridad. Allí una modificación se convierte en configuración, una alerta se convierte en acción y un cliente entiende si su servicio está sano. Si esa autoridad depende de un lugar no probado bajo pérdida total, el riesgo no es sólo tiempo de caída: es pérdida de visibilidad y de capacidad de cambio.

Cloudflare también separa lo que siguió funcionando de lo que falló. El edge siguió sirviendo gran parte del tráfico [1]. Eso no convierte el evento en menor; muestra que la resiliencia debe medirse por capas. Un plano de datos sano no demuestra que el plano de control pueda recuperarse.

La recuperación debe demostrarse con sistemas reales

Cloudflare dice que tenía planes de recuperación, pero el evento mostró que algunos servicios no estaban listos para la pérdida total de la instalación y que ciertos procedimientos no se habían probado en las condiciones correctas [1]. Un plan puede nombrar una ubicación alternativa. Sólo la replicación, las colas, la identidad, los paneles y las herramientas en ejecución prueban la recuperación.

Además existió presión de demanda. Al volver los servicios, usuarios y sistemas internos reintentaron en masa. El postmortem describe un efecto de avalancha que puede convertir el retorno en un segundo incidente si el plano de control no absorbe el backlog [1].

El informe de 2024 aporta una comparación. Cuatro meses después hubo otra falla eléctrica importante en la misma instalación; Cloudflare activó Code Orange y dijo que cambios previos redujeron el impacto [2]. No prueba que todo esté resuelto, pero sí ofrece el patrón correcto de evidencia: evento similar, preparación nueva y resultado diferente.

La propiedad física sigue importando

Los planos de control cloud parecen abstractos, pero el incidente incluye alimentaciones eléctricas, baterías, generadores, acceso físico, intervención del operador del sitio y orden de arranque de servidores [1][3]. Esos elementos están debajo de la API, pero gobiernan el resultado visible.

Depender de un centro de datos externo no es un fallo automático. La pregunta es qué puede probar el operador: quién puede activar el plan alternativo, qué funciones de cliente permanecen disponibles, qué degradación es intencional y qué registros muestran que el escenario se ensayó.

Baxtel añade el contexto del operador de instalación y una respuesta pública de Flexential sobre escenarios de red eléctrica [3]. El artículo no debe convertir eso en juicio completo de causa. Sí muestra que la cadena de recuperación cruzó fronteras organizativas, justo donde los registros de responsabilidad suelen ser débiles.

Superficie Heng.lu: continuidad del operador

La superficie Heng.lu es continuidad operativa e identidad de hosting/red. Un directorio o una página de estado puede nombrar al operador y al sitio; no prueba que configuración, analítica, identidad y herramientas sobrevivan a la pérdida de un edificio. La capa real es la evidencia de recuperación.

La prueba pública debe evitar el teatro de culpabilidad. La cuestión es qué dependencia estaba en el camino crítico, si Cloudflare lo sabía antes, y qué ejercicio demuestra ahora que esa dependencia no puede retirar otra vez la autoridad de control.

Qué observar

El primer indicador es que Cloudflare mantenga separada la salud del tráfico edge de la salud del plano de control y la analítica. Un estado global verde no basta si los clientes no pueden cambiar u observar su configuración.

El segundo indicador es la repetición del patrón Code Orange: pérdida completa de sitio, prueba de failover, backlog medido, identidad disponible, acciones de cliente exitosas y comparación con el incidente anterior. La lección duradera es que transportar tráfico no basta. El operador aún debe ver, cambiar, reiniciar y explicar el servicio cuando un edificio crítico queda fuera.

Fuentes

  1. https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
  2. https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/
  3. https://baxtel.com/news/cloudflare-blames-flexential-dc-outage-for-its-service-disruption