Análisis post mortem de la interrupción del plano de control y los sistemas de analítica de Cloudflare
(blog.cloudflare.com)- A partir del 2 de noviembre de 2023 a las 11:43 UTC, el plano de control y los servicios de analítica de Cloudflare sufrieron una interrupción que afectó cambios en el dashboard/API y funciones de logs y analítica
- El punto de partida del incidente fue una falla eléctrica en PDX-04, en Oregon, operado por Flexential; en esa instalación estaban el clúster de analítica más grande y más de un tercio del equipo del clúster de alta disponibilidad
- La recuperación de la utility feed, los generadores, UPS y disyuntores se vio afectada en cadena, y las dependencias de Kafka y ClickHouse dedicadas a PDX-04 rompieron el diseño de alta disponibilidad
- El 2 de noviembre a las 13:40 UTC se decidió hacer failover al sitio europeo de recuperación ante desastres y, para las 17:57 UTC, la mayor parte del impacto para clientes había disminuido; sin embargo, el procesamiento de logs, algunas API bespoke, la configuración manual de Magic WAN y las cargas de Stream se vieron afectados por más tiempo
- Cloudflare impulsó bajo Code Orange requisitos de alta disponibilidad para productos GA, planes de recuperación ante desastres validados, chaos testing que incluya la eliminación completa de data centers centrales y un plan para evitar la pérdida de logs
Alcance de la interrupción e impacto para clientes
- A partir del 2 de noviembre de 2023 a las 11:43 UTC, se produjo una interrupción en el plano de control y los servicios de analítica de Cloudflare
- El plano de control se refiere a las interfaces orientadas a clientes, incluidos el sitio web y la API
- Los servicios de analítica incluyen logging y reportes de analítica
- El incidente completo se extendió desde el 2 de noviembre a las 11:44 UTC hasta el 4 de noviembre a las 04:25 UTC
- El 2 de noviembre a las 17:57 UTC, la mayor parte del plano de control se recuperó en la instalación de recuperación ante desastres
- Después de que la instalación de recuperación ante desastres quedó en línea, es posible que muchos clientes no hayan experimentado problemas en la mayoría de los productos
- Algunos servicios tardaron más en recuperarse, y los clientes que usaban esos servicios pudieron ver problemas hasta que se resolvieran por completo
- Los servicios de logs sin procesar no estuvieron disponibles para la mayoría de los clientes durante la mayor parte del incidente
- Los servicios de red y seguridad de Cloudflare funcionaron según lo esperado durante todo el incidente
- Hubo períodos en los que los clientes no pudieron modificar esos servicios
- El tráfico que pasaba por la red de Cloudflare no se vio afectado
Diseño original: alta disponibilidad basada en tres data centers en Oregon
- El plano de control y los sistemas de analítica de Cloudflare operan principalmente en servidores de tres data centers alrededor de Hillsboro, Oregon
- Los tres data centers son independientes entre sí, y cada uno cuenta con múltiples utility power feeds y múltiples conexiones de red redundantes e independientes
- Las instalaciones se eligieron para estar lo suficientemente separadas como para que fuera difícil que un desastre natural las afectara simultáneamente, pero lo bastante cerca para operar clústeres de datos redundantes active-active
- Las tres instalaciones sincronizan datos de forma continua
- Por diseño, aunque una instalación quedara offline, las restantes deberían poder seguir operando
- Este diseño de alta disponibilidad comenzó a implementarse hace cuatro años
- La mayoría de los sistemas centrales del plano de control se migraron a clústeres de alta disponibilidad
- Algunos servicios de productos nuevos aún no estaban incluidos en los clústeres de alta disponibilidad
- El sistema de logging no se incluyó deliberadamente en los clústeres de alta disponibilidad
- Los logs se trataron como un problema distribuido: se encolan en el edge de la red y luego se envían al core de Oregon o a instalaciones regionales de logging
- Si una instalación de logging queda offline, los logs de analítica esperan en el edge, y el retraso en la analítica se consideró aceptable
Inicio de la falla eléctrica en PDX-04
- La instalación más grande de las tres en Oregon es PDX-04, operada por Flexential
- Cloudflare aloja allí su clúster de analítica más grande
- Más de un tercio del equipo del clúster de alta disponibilidad también está en esa instalación
- También es la ubicación predeterminada para servicios que no han sido incorporados al clúster de alta disponibilidad
- Cloudflare es un cliente relativamente grande, que utiliza alrededor del 10% de la capacidad total de esta instalación
- El 2 de noviembre a las 08:50 UTC ocurrió un evento de mantenimiento no planificado en una de las feeds eléctricas independientes de Portland General Electric (PGE) que suministran energía a PDX-04
- Este evento interrumpió una de las feeds que entraban a PDX-04
- Flexential encendió generadores para complementar la feed interrumpida
- Flexential no informó a Cloudflare que había hecho failover a energía de generadores
- Las herramientas de observabilidad de Cloudflare no detectaron que la fuente de energía había cambiado
- Si hubiera habido aviso previo, Cloudflare habría monitoreado la instalación de cerca y podría haber movido a otro lugar los servicios del plano de control que dependían de esa instalación
- También fue inusual que Flexential operara simultáneamente la utility feed restante y los generadores
- Flexential opera 10 generadores, incluidos equipos redundantes, y puede cubrir la carga total de la instalación
- También habría sido posible operar la instalación solo con la utility feed restante
- Cloudflare no recibió una respuesta clara sobre por qué Flexential operó utility power y generator power al mismo tiempo
Causa no confirmada y detención de generadores
- La causa raíz de los eventos posteriores y algunas decisiones no fueron confirmadas con claridad por Flexential
- Una posibilidad que sigue abierta es que Flexential participara en el programa DSG de PGE
- DSG es un programa que permite a la empresa eléctrica local usar generadores de data centers para suministrar energía adicional a la red eléctrica
- A cambio, la empresa eléctrica apoya el mantenimiento de los generadores y el suministro de combustible
- Cloudflare no encontró registros de que Flexential hubiera informado sobre el programa DSG
- Tampoco recibió una respuesta sobre si DSG estaba activo en el momento del incidente
- Alrededor de las 11:40 UTC se produjo un ground fault en el transformador de PGE de PDX-04
- Cloudflare cree que este transformador probablemente era el equipo que reducía el voltaje de la segunda feed que entraba al data center, pero no pudo confirmarlo
- Tampoco se confirmó si este ground fault se originó en el mantenimiento no planificado de PGE que afectó a la primera feed
- Un ground fault en una línea de alta tensión de 12,470 V está diseñado para que el sistema eléctrico se corte rápidamente y evitar daños
- Esta protección también detuvo todos los generadores de PDX-04
- Como resultado, tanto la línea de utility como los 10 generadores quedaron offline
- PDX-04 contaba con bancos de baterías UPS que supuestamente podían sostener la instalación durante unos 10 minutos
- Ese tiempo está pensado para cubrir el intervalo entre una falla eléctrica y el reinicio automático de los generadores
- Según la observación de fallas en equipos de Cloudflare, las baterías comenzaron a fallar en 4 minutos
- Flexential tardó mucho más de 10 minutos en recuperar los generadores
Retraso en la recuperación eléctrica y primer aviso
- Aunque Cloudflare no recibió confirmación oficial, empleados de Flexential le comunicaron tres factores que dificultaron la recuperación de los generadores
- Debido a la forma en que el ground fault hizo trip en el circuito, era necesario acceder físicamente a los generadores para reiniciarlos manualmente
- El sistema de control de acceso de Flexential no tenía alimentación de respaldo por batería, por lo que estaba offline
- En el turno nocturno no había operadores ni especialistas eléctricos con experiencia; solo había personal de seguridad y un técnico sin acompañamiento con una semana de antigüedad
- Entre las 11:44 y las 12:01 UTC, las baterías UPS se descargaron mientras los generadores no se habían reiniciado por completo, y todos los clientes del data center perdieron energía
- Durante este proceso, Flexential no informó a Cloudflare sobre el problema en la instalación
- Cloudflare detectó por primera vez el problema del data center a las 11:44 UTC, cuando dos routers que conectaban la instalación con el exterior quedaron offline
- Al no poder acceder a los routers directamente ni mediante out-of-band management, contactó a Flexential y envió un equipo local a la instalación
- El primer mensaje de incidente que Flexential envió a Cloudflare fue a las 12:28 UTC
- El mensaje indicaba que el problema eléctrico de PDX-04 había comenzado alrededor de las 12:00 UTC, que ingenieros estaban trabajando en la recuperación y que enviarían actualizaciones cada 30 minutos
Problemas de dependencias revelados por el diseño de alta disponibilidad
- PDX-04 tenía un diseño con certificación Tier III previo a la construcción y se esperaba que ofreciera un SLA de alta disponibilidad, pero Cloudflare también planificó la posibilidad de que esta instalación quedara offline
- El impacto previsto era una interrupción de analítica, acumulación de logs en colas en el edge y retrasos, además de la suspensión temporal de servicios de baja prioridad no integrados al clúster de alta disponibilidad
- En términos generales, que los otros dos data centers asumieran el clúster de alta disponibilidad para mantener en línea los servicios centrales funcionó según lo planeado
- El problema fue que algunos servicios que debían estar en el clúster de alta disponibilidad dependían de servicios que solo se ejecutaban en PDX-04
- Kafka y ClickHouse, responsables del procesamiento de logs y analítica, solo se proporcionaban desde PDX-04
- Algunos servicios que se ejecutaban en el clúster de alta disponibilidad dependían de ellos
- Esta dependencia debió haber sido más laxa, debió haber fallado de forma más elegante y debió haberse detectado con antelación
- En las pruebas del clúster de alta disponibilidad, Cloudflare había dejado completamente offline a cada una de las otras dos instalaciones y a ambas a la vez
- También realizó pruebas dejando offline la parte de alta disponibilidad de PDX-04
- Sin embargo, no realizó una prueba que dejara completamente offline toda la instalación PDX-04
- Los criterios que exigían que los productos nuevos y sus bases de datos asociadas se integraran al clúster de alta disponibilidad también eran demasiado laxos
- Los equipos de producto tenían caminos distintos hacia la fase alpha
- Con el tiempo, el backend se migraba hacia las mejores prácticas, pero esto no se exigía formalmente antes de declarar GA
- Como resultado, la protección por redundancia funcionaba de manera inconsistente según el producto
Transición al sitio de recuperación ante desastres
- A las 12:48 UTC, Flexential reinició los generadores y la energía volvió a parte de la instalación
- La recuperación eléctrica de un data center normalmente se realiza de forma gradual, circuito por circuito
- Cuando llegó el momento de volver a encender los circuitos de Cloudflare, se determinó que los disyuntores estaban dañados
- No se sabe si esos disyuntores fallaron por el ground fault o por un surge, o si ya tenían problemas previos
- Flexential comenzó a reemplazar los disyuntores dañados
- Fallaron más disyuntores de los que había disponibles en la instalación, por lo que fue necesario conseguir disyuntores nuevos
- Como había más servicios offline de lo esperado y Flexential no podía dar un tiempo estimado de recuperación, Cloudflare decidió a las 13:40 UTC hacer failover al sitio de recuperación ante desastres en Europa
- Solo era necesario hacer failover de una pequeña proporción de todo el plano de control
- La mayoría de los servicios siguió ejecutándose en los sistemas de alta disponibilidad de los otros dos data centers core
- A las 13:43 UTC se inició el primer servicio en el sitio de recuperación ante desastres
- Este sitio está diseñado para proporcionar servicios centrales del plano de control durante un desastre
- No admite algunos servicios de procesamiento de logs
- Tras la puesta en marcha de los servicios, se produjo un problema de thundering herd por la acumulación de llamadas API que venían fallando
- Cloudflare aplicó rate limits para controlar el volumen de solicitudes
- Durante este período, los clientes de la mayoría de los productos pudieron ver errores intermitentes al realizar cambios mediante el dashboard o la API
- Para las 17:57 UTC, los servicios trasladados al sitio de recuperación ante desastres se estabilizaron y el impacto directo para la mayoría de los clientes disminuyó
- Algunos sistemas, como Magic WAN, aún requerían configuración manual
- Los servicios relacionados con el procesamiento de logs y algunas API bespoke no estuvieron disponibles hasta la recuperación de PDX-04
Recuperación demorada de algunos productos y reinicio de PDX-04
- Algunos productos no se ejecutaron correctamente en el sitio de recuperación ante desastres
- Principalmente eran productos nuevos cuyos procedimientos de recuperación ante desastres no se habían implementado ni probado por completo
- Esto incluyó el servicio Stream para cargas de nuevos videos y algunos otros servicios
- Los equipos de Cloudflare siguieron dos caminos en paralelo
- Volver a implementar esos servicios en el sitio de recuperación ante desastres
- Migrarlos al clúster de alta disponibilidad
- Flexential reemplazó los disyuntores dañados, restauró las dos utility feeds y confirmó energía estable a las 22:48 UTC
- Como el equipo había estado respondiendo a la emergencia durante todo el día, Cloudflare decidió que la mayoría del personal descansara y comenzara las tareas de regreso a PDX-04 a la mañana siguiente
- Esta decisión retrasó la recuperación total, pero buscaba reducir la posibilidad de cometer errores adicionales
- En la mañana del 3 de noviembre comenzó la recuperación de servicios en PDX-04
- Se arrancó físicamente el equipo de red
- Se encendieron miles de servidores y se restauraron servicios
- Como durante el incidente posiblemente hubo varios ciclos de energía, el estado de los servicios dentro del data center era desconocido
- El procedimiento seguro de recuperación era seguir un bootstrap completo de toda la instalación
- Los servidores de gestión de configuración se pusieron manualmente en línea, y reconstruirlos llevó 3 horas
- Luego, el resto de los servidores se reconstruyó mediante bootstrap
- La reconstrucción de cada servidor tomó entre 10 minutos y 2 horas
- Aunque se ejecutó en paralelo en múltiples servidores, algunas recuperaciones debieron hacerse en secuencia por dependencias entre servicios
- Todos los servicios quedaron completamente recuperados el 4 de noviembre de 2023 a las 04:25 UTC
- Para la mayoría de los clientes, se espera que no haya pérdida de datos en la mayor parte de la analítica del dashboard y la API, ya que los datos de analítica también se almacenaban en data centers core europeos
- Algunos datasets que no se replicaban en la UE quedaron con huecos persistentes
- Los clientes que usaban Logpush no tuvieron procesamiento de logs durante la mayor parte del incidente, y los logs no recibidos no se recuperarán
Code Orange y plan de mejoras
- Cloudflare tiene muchas preguntas que Flexential debe responder, pero concluyó que también debe anticipar la falla total de un data center
- De forma similar a Code Yellow y Code Red de Google, Cloudflare introdujo Code Orange, su propio proceso para concentrar recursos de ingeniería en resolver problemas durante incidentes graves o crisis
- Las funciones de ingeniería no esenciales se trasladaron a trabajos para garantizar la alta confiabilidad del plano de control
- Los cambios planificados son los siguientes
- Eliminar las dependencias de data centers core en la configuración del plano de control de todos los servicios y, cuando sea posible, migrar para que la red distribuida de Cloudflare se ejecute primero
- Garantizar que el plano de control que se ejecuta en la red siga funcionando aunque todos los data centers core estén offline
- Exigir que los productos y funciones GA que dependen de data centers core se apoyen en el clúster de alta disponibilidad, sin dependencias de software de una instalación específica
- Exigir que los productos y funciones GA cuenten con planes de recuperación ante desastres confiables y probados
- Probar el blast radius de fallas del sistema y minimizar la cantidad de servicios afectados por una falla
- Implementar chaos testing más estricto para todas las funciones de data center, incluida la eliminación completa de cada instalación core
- Auditar exhaustivamente todos los data centers core y establecer planes de reauditoría para garantizar el cumplimiento de estándares
- Preparar planes de recuperación ante desastres para logging y analítica, de modo que no se pierdan logs incluso ante fallas en cualquier instalación core
- Cloudflare resumió que, aunque contaba con los sistemas y procedimientos necesarios, le faltó el rigor para obligar a seguirlos y para probar dependencias desconocidas
1 comentarios
Opiniones de Hacker News
Fue una decisión extraña dedicar la mayor parte del texto a mencionar a un proveedor específico, atribuirle la responsabilidad y especular sobre la causa raíz.
También parece bastante inapropiado revelar que era un cliente grande dentro de la instalación e incluir en el análisis post mortem hasta diagramas eléctricos que el proveedor había marcado como confidenciales.
Entiendo explicar el detonante y el contexto del incidente, pero el foco del post mortem debería ser la falla de Cloudflare, no el proveedor.
Flexential también tendrá que hacer su propio post mortem, pero no hace falta que Cloudflare especule públicamente en su lugar.
También podría tener el objetivo de que Cloudflare dé una explicación de forma preventiva antes de que alguien más construya el relato.
En una situación con tres partes y varios sistemas conectados involucrados, es razonable que Cloudflare quiera saber hasta el final qué ocurrió para poder incorporar estos modos de falla compuestos en su diseño a futuro.
Personalmente, agradezco la información que compartió Cloudflare.
El 99% de la responsabilidad recae en Cloudflare, que no cumplió con su tarea principal.
Meterse tan a fondo con un tercero más bien muestra lo vergonzoso que fue esto para Cloudflare.
Parece que ni siquiera hicieron bien la inspección de los interruptores, y en una instalación relativamente nueva no lograron asegurar ni la mitad de las 10 horas necesarias para cargar las baterías de los generadores.
Durante este mantenimiento deberían haber pasado completamente a generadores, y es muy probable que no lo hayan hecho porque estaban ayudando a PGE.
Creo que el CEO de Cloudflare tiene razón. Uno paga por servicios de datacenter esperando redundancia total, y dicen que hay 18 MW en esta ubicación, pero por lo que se ve ni siquiera queda claro si solo hay 2 alimentaciones.
Si una alimentación cae, debería entrar una configuración 2N, y si hay generadores no debería haber problema.
Si es así, tiene sentido que incluya una descripción de los eventos iniciales identificados hasta ahora.
Parece bastante probable que venga un análisis posterior.
https://twitter.com/eastdakota/status/1720688383607861442?t=...
Por lo citado, la causa raíz de la interrupción fue la dependencia de un solo datacenter.
Dicen que la mayoría de los sistemas clave del plano de control ya se habían migrado a clústeres de alta disponibilidad, pero algunos productos nuevos todavía no; que algunos servicios que debían estar en el clúster de alta disponibilidad dependían de servicios que solo corrían en PDX-04; y que algunos productos no se levantaron correctamente en el sitio de recuperación ante desastres.
Para una empresa como Cloudflare, que sostiene una parte importante de Internet, es bastante vergonzoso.
Cloudflare dijo que, al permitir innovación rápida en varios equipos, los productos tomaron caminos distintos hasta el alfa inicial, y que con el tiempo los migraban a mejores prácticas, pero no lo exigían como requisito antes de la disponibilidad general.
Esto es un fracaso de gestión total. ¿No significa eso que vendieron a los clientes software que, según los estándares internos de Cloudflare, era de calidad alfa?
https://news.ycombinator.com/item?id=38113503
Parece faltarles autoconciencia.
Esto es de nivel amateur, y es especialmente grave que servicios nuevos se hayan lanzado sin alta disponibilidad.
Como alguien que se vio afectado un poco por esta interrupción, creo que este post mortem se queda corto.
El 75% trata sobre la falla eléctrica en PDX-04 y la responsabilidad de Flexential; por el texto, lo que ocurrió allí parece haber sido casi un desastre, así que lo entiendo.
Pero según el texto, para el 2 de noviembre UTC la energía ya estaba completamente restaurada, y aun así Cloudflare tardó unas 30 horas más en recuperarse por completo.
La recuperación duró más que la interrupción, pero el texto solo dice que demasiados servicios dependían entre sí. Me gustaría saber con más detalle por qué tomó tanto tiempo restaurar toda la operación.
¿No hubo lecciones aprendidas del propio proceso de recuperación? ¿O realmente todo ese tiempo se fue solo en resincronizar datos desde el edge hacia el “cerebro”?
Otra parte que falta es, en particular, la falta de comunicación con clientes enterprise. El soporte de Cloudflare estuvo prácticamente en silencio salvo por la página de estado y, aunque en la práctica no hubiera mucho que pudieran hacer, hacía falta al menos intentar comunicarse.
Más aún después de que en el post mortem culparan a Flexential por su falta de comunicación. Me gustan los productos de Cloudflare, pero creo que deberían sacar más conclusiones de este incidente.
Dicho eso, llamarlo post mortem queda un poco desajustado. Un post mortem completo debería tener el nivel de detalle mencionado arriba.
Si el logging se cae, ¿qué servicios fallan exactamente? ¿Se diseñó así sin querer? ¿Por qué nadie se dio cuenta?
Me parece bueno que el análisis post mortem de Cloudflare sea tan exhaustivo.
Una explicación honesta y transparente resulta refrescante frente a las estrategias de comunicación ambiguas de casi todas las demás empresas.
Nosotros también nos vimos afectados, pero textos como este hacen que, más bien, no quiera irme. Cualquiera puede cometer errores y tener un mal día; lo que marca la diferencia es cómo respondes después.
La falla eléctrica bastaba con un párrafo, y luego debería haber pasado al lado de Cloudflare. Las fallas de centros de datos pueden ocurrir.
La verdadera lección está en la respuesta de Cloudflare, que no consideró ni recuperó correctamente esa situación.
Dependemos mucho de CloudFlare Images, y en los últimos 30 días estuvo caído más de 67 horas.
Hubo 22 horas el 9 de octubre, 42 horas del 2 al 4 de noviembre y varias interrupciones de alrededor de 1 hora entre medio; la disponibilidad del último mes fue de 90.6%.
La transparencia es un gran diferenciador entre proveedores que compiten en el rango de 99.9% de disponibilidad, pero si apenas superas un solo nueve, ya no significa mucho.
No ayuda mucho a mejorar el comportamiento y puede empeorar los incentivos.
Valoro que vayan a corregir los errores de proceso aquí. Aun así, hay una tensión entre moverse rápido y hacer las cosas con certeza.
Por lo general, estas cosas se tratan como el clima: se manejan comprando un impermeable después de mojarse.
Me pregunto cómo hacer que la confiabilidad sea parte de la cultura sin que el desarrollo quede atado por el proceso.
También se podría modelar el sistema con software y validar ese modelo con análisis de tráfico. Si los experimentos virtuales pueden reducir el costo de los experimentos de confiabilidad, quizá se podrían detectar más problemas antes del lanzamiento.
Es raro que, después de leer este artículo, mi confianza en Cloudflare haya disminuido.
Atacan con fuerza a Flexential diciendo que actuó de forma poco profesional, y puede que haya sido así.
Pero el hecho de que todo el sistema del que dependen las personas se haya caído es una enorme falla de redundancia del lado de Cloudflare. Un centro de datos de este tipo debería poder desaparecer y el servicio debería seguir funcionando.
Me preocupa especialmente que el diseño previsto empiece con: “El plano de control y los sistemas de análisis de Cloudflare corren principalmente en servidores de 3 centros de datos cerca de Hillsboro, Oregon”.
Si es un plano de control usado por personas en todo el mundo, necesita una distribución geográfica mucho más amplia. Lo más sorprendente es que esto no sea una implementación defectuosa, sino parte del diseño previsto.
Si vas a lanzar nuevos productos para consumidores, ¿no debería el diseño con redundancia ser la prioridad principal? Me sorprende que haya sido algo opcional.
Yo también uso Cloudflare en algunos sistemas porque creía que, si ocurría algo así, habría una conmutación por error excelente. Ahora me hace replantearme si Cloudflare Workers está realmente a salvo de este tipo de decisiones de diseño.
Que al activar el sitio de recuperación ante desastres se acumularan llamadas a la API que fallaban y el servicio quedara abrumado también me parece, en última instancia, consecuencia de que el diseño central de Cloudflare no era lo bastante redundante.
Me decepcionó este texto que intenta pasarle la responsabilidad a Flexential. Como cliente, espero que Cloudflare lo maneje con elegancia incluso si Flexential desaparece mañana por un terremoto.
¿Es buena idea poner un clúster tan crítico completo en una zona conocida de riesgo sísmico y de tsunami?
Parece que la recuperación ante desastres en Europa tampoco funcionó correctamente.
“Nunca habíamos probado poner completamente offline toda la instalación PDX-04” es una lección dolorosa.
Pero si no cortas físicamente la energía del centro de datos, o al menos su red hacia el mundo exterior, no estás probando un desastre real.
Puedes culpar al operador de la instalación, pero al final debes poder recuperarte aunque un centro de datos quede completamente offline y nunca vuelva.
Un desastre natural podría borrar esa instalación de la faz de la Tierra.
Me gustó la parte que dice: “Como el equipo se movilizó por completo y estuvo todo el día respondiendo a la emergencia, decidimos que la mayoría descansara y empezar por la mañana el trabajo de volver a PDX-04. Esta decisión retrasó la recuperación completa, pero creemos que redujo la posibilidad de acumular errores adicionales”.
En informes como este, la fatiga humana suele subestimarse. Intentar reparar un incidente grande en un estado de agotamiento excesivo solo aumenta los errores evitables.
No sé cómo funcionaría en una organización del tamaño de Cloudflare, pero nosotros también tenemos un plan para que el personal trabaje y duerma por turnos cuando ocurre un incidente grande.
El problema es que necesitas una forma de transferir el estado actual del incidente al personal nuevo que se despierta o se conecta.
Como decía Mike Tyson, todos tienen un plan hasta que reciben un golpe en la cara.
La estructura del texto es bastante sorprendente. Dedica el 75% del blog a hablar de un tercero y luego trata los esfuerzos de recuperación de Cloudflare en muchos menos párrafos.
Es positivo que hayan presentado un camino a seguir, pero me pregunto por qué ahora solo reconocieron fallas y la situación, en vez de publicar después, cuando se asentara el polvo, un post mortem completo y sin especulaciones.
Los inversionistas pueden leer este texto o su resumen y pasarlo como un simple problema del proveedor, en lugar de verlo como un problema profundo que requiere meses de retrabajo y millones de dólares.
El documento es malo.
Tenían una configuración de alta disponibilidad con 3 centros de datos, y falló por completo.
¿Por qué llenar la primera parte del documento culpando al operador del centro de datos? La administración de las instalaciones del centro de datos está fuera del control de Cloudflare.
Cloudflare apostó a que no pasaría nada aunque no probara correctamente la configuración de alta disponibilidad que sí podía controlar.
Los problemas operativos del centro de datos deberían discutirse con el operador, pero eso es un asunto entre ambas partes, no algo que deba estar en este post mortem.
Enterraron lo más importante bien al fondo. Hay que hacer bastante scroll para llegar a esta frase:
“Algunos de los servicios que debían estar en un clúster de alta disponibilidad dependían de servicios que solo se ejecutaban en PDX-04”.
Justo eso es lo central.
Si vas a crear un sitio de “desastre”, de alguna forma tienes que encontrar cómo probarlo.
Dicen que, cuando el servicio volvió a encenderse, se produjo un problema de manada atronadora: se amontonaron llamadas a la API que venían fallando, y tuvieron que implementar rate limiting para controlar el volumen de solicitudes.
Pero parece que esto quedó fuera de los puntos al final del artículo.
Lo que ahora me da curiosidad es cómo se diseña un failover en frío cuando el sistema es lo bastante complejo como para provocar una falla metaestable[1] y no hay margen para probar con tráfico real.
Puedo imaginar las técnicas que se usarían en la implementación, pero el problema es el diseño y las pruebas para comprobar que esas técnicas funcionen en una situación real.
Otra parte que parece haber quedado totalmente fuera es que la interrupción empezó el 2 de noviembre a las 11:43 UTC, pero el momento en que decidieron cambiar al sitio europeo de recuperación ante desastres fue a las 13:40 UTC.
¿Por qué tardaron tanto en decidirlo? Entiendo que no es una decisión que pueda tomarse a la ligera, pero aunque durante la mayor parte del tiempo hubieran esperado que la energía se restableciera pronto, 2 horas parecen demasiada vacilación.
Tiene que haber un criterio previo a partir del cual se apriete el botón, sin importar qué compromisos existan. ¿De verdad ese umbral estaba fijado tan lejos?
[1] http://charap.co/metastable-failures-in-distributed-systems/
A menudo, lo que provoca la falla es el propio sistema redundante.