Un SPOF (Single Point of Failure) es un componente cuya falla individual detiene un sistema completo. En un data center, basta un SPOF mal identificado para que un proveedor firme un SLA de 99.9 % y termine entregando 95 %.
Encontrarlos antes de que fallen es una de las tareas más baratas y más rentables del facility management. Esta guía explica qué son, dónde se esconden y cómo auditarlos.
Qué es un SPOF, en concreto
Es cualquier elemento que, al fallar, interrumpe el servicio sin que haya un respaldo automático que tome el relevo. La falla puede ser eléctrica, mecánica, lógica o humana.
Eléctrica: un solo UPS alimentando un rack crítico sin bypass.
Mecánica: una sola bomba de agua helada en el circuito de enfriamiento.
Red: un solo switch ToR (Top of Rack) sin enlace uplink redundante.
Humana: el único técnico que sabe cómo reiniciar el Storage Area Network después de un apagón.
De proceso: una sola ruta de cambio de configuración sin peer review.
Dónde se esconden los SPOF en un data center
Los SPOF obvios (un solo UPS, un solo chiller) son visibles en cualquier diagrama unifilar. Los peligrosos están en capas intermedias, donde el diagrama miente o simplifica demasiado.
El tablero de distribución general: si alimenta toda la sala desde una sola acometida, ese tablero es SPOF aunque los UPS estén redundantes.
La transferencia automática: el ATS (Automatic Transfer Switch) que commuta entre CFE y generador. Si falla, ambas fuentes quedan desconectadas.
El backbone de fibra: un solo ODF (Optical Distribution Frame) sin ruta alternativa al Site Entry Room.
El concentrador de Management: un solo switch de gestión fuera de banda (OOB) sin peer.
La consola KVM o el ILO/OOB: un solo dispositivo por donde se accede a todos los servidores.
La licencia: un software con license server central que, si cae, deja inoperante toda la plataforma.
La persona: el único DBA o sysadmin con conocimiento tribal del entorno.
Cómo auditar SPOF en 7 pasos
La auditoría de SPOF no requiere comprar equipo. Requiere tiempo, papel y una reunión con el equipo de operaciones. La secuencia es esta.
Listar cada componente que sostiene la operación: energía, enfriamiento, red, cómputo, almacenamiento, gestión, personas.
Para cada componente, preguntar: si este elemento falla a las 3 AM del domingo, ¿qué pasa?
Si la respuesta es «se cae el servicio», es un SPOF.
Si la respuesta es «el respaldo toma el relevo automáticamente», verificar que el respaldo existe, está probado y no comparte modo de falla con el principal.
Clasificar cada SPOF por severidad: ¿cuánto cuesta cada hora de indisponibilidad en este sistema?
Asignar acción: eliminar el SPOF, agregar redundancia, documentar procedimiento manual de respaldo, o aceptar el riesgo formalmente.
Repetir la auditoría cada 6 meses o cada vez que hay un cambio mayor en el DC.
Errores comunes al evaluar redundancia
«Tenemos dos UPS, así que no tenemos SPOF» es la frase más cara del facility management. La redundancia sin validación de modo de falla común no es redundancia.
Dos UPS alimentados por el mismo tablero eléctrico: comparten modo de falla, no son 2N.
Dos enlaces de fibra por la misma canaleta: un solo incendio o una sola intervención los tumbará juntos.
Dos switches de red con la misma configuración: un error de configuración se replica automáticamente en ambos.
Un sistema de respaldo documentado pero nunca probado: el primer fallo real es el primer día que opera, no es redundante, es decorativo.
Plantilla mínima de registro de SPOF
Para cada SPOF identificado, conviene registrar al menos cinco campos. Esta plantilla funciona para cualquier DC mediano y se mantiene en una hoja de cálculo o en el módulo de gestión de riesgos del DCIM.
ID: identificador único (ej. SPOF-EN-001 para energía, SPOF-RED-002 para red).
Descripción: qué componente es y por qué es SPOF.
Impacto: a qué sistemas afecta su falla.
Acción: eliminarlo, redundarlo, documentar respaldo manual, o aceptar el riesgo.
Estado: abierto, en proceso, cerrado, aceptado.
Un DC mediano serio mantiene entre 10 y 30 SPOF abiertos en un momento dado. Si la auditoría regresa cero SPOF, probablemente la auditoría fue superficial.
La tarea del facility manager no es eliminar todos los SPOF — eso es imposible en cualquier sistema real — sino tenerlos identificados, priorizados por impacto y con plan de mitigación. La indisponibilidad del domingo a las 3 AM se evita el martes a las 10 AM en la mesa de diseño.
Fuentes
[1] Microsoft Azure — Well-Architected Framework: Reliability (identificación de SPOF en arquitecturas cloud y on-prem) — https://learn.microsoft.com/en-us/azure/well-architected/reliability/
[2] NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations (catálogo de controles de disponibilidad) — https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home
