Errores de memoria rompieron el conmutador central de Salesforce y su conmutación por error: 900.000 suscriptores quedaron bloqueados

El 6 de enero de 2009, salesforce.com quedó fuera de servicio. A partir de las 20:39 UTC (alrededor del mediodía en el Pacífico), los clientes no podían iniciar sesión ni acceder a sus datos de CRM; The Register informó que más de 900.000 suscriptores quedaron bloqueados fuera de las aplicaciones con las que gestionan sus negocios. Business Insider cifró la caída total en 30 a 40 minutos. Para una empresa cuyo argumento era que los negocios podían confiar sus datos más importantes a su nube, la mayor parte de una hora de fallo total cayó en plena jornada laboral.

La explicación de la propia Salesforce, publicada después: «un dispositivo central de red falló debido a errores de asignación de memoria. El fallo hizo que dejara de transmitir datos, pero no activó correctamente una conmutación por error ordenada al sistema redundante, ya que los errores de asignación de memoria también estaban presentes en el sistema de conmutación por error». En otras palabras, el dispositivo redundante falló de la misma manera que el primario, y la plataforma tuvo que recuperarse con pasos manuales.

El incidente también dejó al descubierto un fallo de segundo orden. El panel público de estado de «confianza» de Salesforce —la página que promocionaba su fiabilidad— estaba caído junto con el producto, de modo que los clientes no podían saber si eran los únicos afectados. Cientos recurrieron a Twitter para confirmar la caída, una temprana demostración de que, cuando una plataforma SaaS falla, su capa de comunicación falla con ella a menos que se mantenga deliberadamente fuera del radio de impacto.

Aproximadamente 40 minutos de fallo total del servicio para más de 900.000 suscriptores, en plena jornada laboral y sin una conmutación por error funcional.

El dispositivo de conmutación por error tenía el mismo defecto de asignación de memoria que el primario que falló, por lo que la ruta «redundante» nunca recibió el tráfico.

La conmutación por error no se activó de forma ordenada; restaurar el servicio completo requirió pasos de recuperación manuales por parte del equipo de operaciones.

El panel público de confianza estaba dentro del mismo dominio de fallo, lo que dejó a los clientes a ciegas y los empujó a diagnosticar la caída por sí mismos en Twitter.

La redundancia construida con piezas idénticas hereda defectos idénticos. Si la unidad de reserva tiene el mismo defecto que la primaria, es un espejo, no un margen: diversifica la ruta de conmutación por error.

Salesforce publicó su explicación en el sitio de confianza, afirmó que la causa raíz había sido «abordada mediante la solución provisional» y dijo que su equipo seguiría trabajando con los proveedores de hardware para detallar la causa raíz e identificar más parches. The Register y la prensa económica enmarcaron la caída como el «lado oscuro» de la computación en la nube para una empresa que vendía la disponibilidad como su ventaja central frente al software de CRM instalado. Los observadores de la fiabilidad extrajeron una lección distinta: todo falla, y lo que distingue a los operadores es si los clientes pueden averiguar qué está pasando; la comunicación, no el tiempo de actividad, fue el fallo.