Cuatro niveles de tolerancia a fallos: en cuál estás y qué necesitas realmente

La tolerancia a fallos no es un estado de «tiene o no tiene». Es una escalera de cuatro niveles, y cada uno resuelve su propia tarea en su etapa de vida del producto.

Intentar saltarse un peldaño y construir un sistema complejo antes de tiempo es un clásico sobrediseño. Cuesta caro, ralentiza el desarrollo y crea una falsa sensación de seguridad: formalmente todo está replicado, pero en la práctica nadie entiende el sistema por completo.

El nivel lo determinan dos magnitudes, y ambas las fija el negocio, no el ingeniero:

• RTO — cuánto tiempo puede vivir el negocio sin el sistema funcionando.
• RPO — de qué periodo es aceptable perder datos.

Ley principal de la tolerancia a fallos

Los ingenieros quieren construir sistemas distribuidos porque es un reto interesante. El negocio funciona de otra manera.

El nivel de tolerancia a fallos lo dicta no la ambición del equipo, sino una desigualdad simple:

Costo de la solución por año < pérdida esperada por tiempo de inactividad por año

La parte derecha se calcula así: coste de una hora de inactividad × número esperado de horas de inactividad al año. Si una hora de inactividad de una tienda online cuesta 40 000 ₽, y la previsión realista es de ocho horas de inactividad al año, la pérdida esperada será de alrededor de 320 000 ₽. Pasar al cuarto nivel costará millones al año. La conclusión es obvia: no necesitas el cuarto nivel, necesitas honestamente llevar al segundo nivel descrito abajo — con copias de seguridad probadas y monitorización externa.

Si una hora de inactividad cuesta varios millones, el conmutado automático de la base de datos se amortiza en el primer incidente.

La respuesta casi siempre está un peldaño por debajo de lo que desea el equipo técnico, y un peldaño por encima de lo que está dispuesto a pagar el director financiero. La tarea del responsable es reconciliar estas dos posturas con cifras, no con convicciones.

Vamos a desglosar los cuatro niveles — desde un servidor hasta un sistema geográficamente distribuido. Para cada uno: qué medios son apropiados, qué errores son típicos y por qué señales se ve que es hora de subir al siguiente peldaño.

Nivel 1. MVP: «Que funcione al menos»

RTO: hasta un día · RPO: hasta un día · Presupuesto: mínimo

El producto acaba de nacer. La tarea principal es verificar la hipótesis y entender si el mercado lo necesita. Los usuarios normalmente no pagan o participan en pruebas beta.

Cómo está organizada la infraestructura

• Un servidor, normalmente una máquina virtual barata.
• En él está todo junto: frontend, backend, base de datos.
• Despliegue manual — con un script o el comando git pull.
• El conocimiento sobre la arquitectura del sistema existe solo en la cabeza de un desarrollador. No hay documentación, y ahora no hace falta: la prioridad es la velocidad para validar la hipótesis.

Riesgos principales

El error principal de este nivel es la ausencia de copias de seguridad. Hay que copiar no solo la base de datos, sino también el código y la configuración del servidor: sin ellos la recuperación se convierte en arqueología. Si el servidor desaparece —y esto ocurre con proveedores cloud— habrá que reconstruir el sistema desde cero, y los primeros usuarios no lo perdonarán.

El segundo error es más suave pero más frecuente: se hacen copias, pero se almacenan en el mismo servidor. Esa copia desaparece junto con el original.

Veredicto. Un servidor y copias configuradas en un almacenamiento externo es una solución económicamente justificada para un MVP. Nada más allá de esto es necesario en esta etapa.

Nivel 2. Fiabilidad básica: primeros clientes que pagan

RTO: horas · RPO: decenas de minutos · Presupuesto: moderado

El producto ha crecido: han aparecido usuarios que pagan y, con ellos, obligaciones. El negocio empieza a exigir garantías.

El paso a este nivel casi siempre viene acompañado del primer gran fallo. Escenario típico: la empresa lanza una primera campaña publicitaria a gran escala. Llega tráfico inusitado al único servidor, los archivos subidos por usuarios llenan el disco, la memoria se agota — y el sistema entra en fallo en cascada: primero la base de datos, luego el backend y el frontend. El desarrollador reinicia el servidor manualmente, los usuarios se van a la competencia y el inversor hace preguntas incómodas.

Cómo está organizada la infraestructura

1. Balanceador de tráfico separado. Nginx o su análogo se sitúa frente a la aplicación. Esto permite controlar el tráfico: si el backend cae, el usuario verá una página de mantenimiento clara en lugar de un error 500.
2. Externalización de la estática. Imágenes y archivos de usuario se trasladan a un almacenamiento de objetos (S3 y compatibles). El disco del servidor deja de llenarse.
3. Separación de capas. El backend se reparte en dos-tres servidores, la base de datos vive por separado. Las sesiones de usuario se sacan a un cache común (Redis), para que cualquier petición pueda ser atendida por cualquier servidor.
4. Replicación de la base de datos. Se configura un esquema «primary — replica»: la réplica repite continuamente los cambios del primario. Las copias de seguridad se toman desde la réplica y se almacenan en otra ubicación.
5. Monitorización básica. Se vigila el llenado de discos, el uso de memoria y —con comprobaciones externas separadas— la disponibilidad de páginas y escenarios clave: realizar un pedido, inicio de sesión, pago. Aparecen los primeros procedimientos escritos de recuperación.

Riesgos principales

Normalmente en esta etapa contratan al primer ingeniero de sistemas, y éste tiene la tentación natural de introducir tecnologías por la tecnología. Trampas típicas:

• Fragmentación prematura del sistema. Dividir el monolito en cuarenta servicios cuando hay tres desarrolladores será contraproducente: la cohesión aumentará y la comprensión del sistema disminuirá.
• Automatizar lo equivocado. El ingeniero invierte semanas en complejos escenarios de autorecuperación para una operación que se realiza manualmente una vez al año.
• La aplicación no está preparada para la redundancia. No se reconecta a Redis reiniciado, guarda archivos subidos en disco local o se rompe si varias instancias procesan peticiones a la vez. La infraestructura está replicada, pero el código sigue pensado para un solo servidor.

Cabe recordar por separado: al sacar las sesiones a Redis, se crea un nuevo punto único de fallo. En este nivel es un compromiso aceptable, pero hay que conocerlo.

Qué sigue siendo manual

El conmutado a la réplica. La replicación funciona sola, pero la decisión «el servidor primario murió, promovemos la réplica» la toma y ejecuta una persona. Por eso el RTO se mide en horas —en ellas entra el tiempo hasta que el ingeniero se despierte, entienda la situación y haga el cambio.

Veredicto. Los puntos únicos de fallo a nivel de hardware están eliminados, pero la recuperación sigue dependiendo del ingeniero de guardia.

Nivel 3. Producción madura: automatización

RTO: minutos · RPO: segundos · Presupuesto: medio

El proyecto genera ingresos y la caída se convierte directamente en pérdida de dinero. Aparecen compromisos formales de disponibilidad con los clientes. El número de servicios crece hasta decenas, la gestión manual deja de ser viable y un nuevo ingeniero tarda semanas en incorporarse porque las interdependencias no están documentadas en ningún sitio.

Cómo está organizada la infraestructura

• Orquestación. Se introduce Kubernetes o un análogo: distribuye la carga entre servidores, reinicia servicios caídos sin intervención humana y los escala según la carga.
• Red de entrega de contenido (CDN). La estática se sirve desde nodos cercanos al usuario.
• Conmutado automático de la base de datos. La gestión de la replicación se delega a un sistema especializado —por ejemplo, Patroni para PostgreSQL: detecta la caída del primario y promueve la réplica. Las conexiones pasan por un pool (PgBouncer), de lo contrario durante el conmutado la aplicación chocará con el límite de conexiones.
• Transmisión fiable de mensajes. Las tareas asíncronas van a un broker (Kafka, RabbitMQ). Aquí lo importante no es la mera instalación, sino la configuración: factor de replicación mayor que uno y requerimiento de confirmación por múltiples réplicas —de lo contrario la caída de un nodo destruirá mensajes no entregados.
• Observabilidad. La monitorización deja de ser un conjunto de gráficos de hardware: se añaden métricas de negocio (pedidos por minuto, porcentaje de pagos exitosos), tendencias históricas y comprobaciones externas. El monitoring se supervisa a sí mismo —de lo contrario el sistema de alertas morirá silenciosamente primero, y llegará una calma engañosa.
• Preparación organizacional. Aparece un plan escrito de recuperación ante desastres y el equipo practica periódicamente. Los postmortems se hacen sin búsqueda de culpables: el ingeniero que teme reportar un error lo hará tarde.

Riesgos principales

• El código no está listo para la orquestación. Los servicios se reinician en bucle por fugas de memoria, la aplicación no sabe trabajar con múltiples instancias o falla en migraciones de base incompatibles con la versión anterior. Kubernetes no resuelve esos problemas —solo los hace más visibles.
• Retrasar la transición. Intentar permanecer en gestión manual cuando el proyecto ya la supera conduce al aumento de costes operativos y al burnout de los de guardia.

Veredicto. La rutina la asume la automatización. La pérdida de un servidor, de la base de datos o de una zona de disponibilidad se gestiona sin intervención humana —no hace falta despertar al ingeniero a las tres de la madrugada.

Nivel 4. Distribución geográfica

RTO: minutos incluso ante la caída de una región completa · RPO: cercano a cero · Presupuesto: alto

Aquí lo que cambia no es la velocidad de recuperación, sino la escala del fallo que el sistema soporta. El tercer nivel protege contra la pérdida de un servidor o un sitio dentro de una región. El cuarto protege contra la pérdida de una región entera: incendio en un data center, rotura de fibra troncal durante obras, desconexión del proveedor por decisión del regulador. En este nivel se trata ya no de infraestructura, sino de continuidad del negocio.

Cómo está organizada la infraestructura

• Varios regiones. La infraestructura se reparte entre ubicaciones geográficamente independientes con alimentación, enlaces y jurisdicción separados.
• Gestión del tráfico a nivel de red. Anuncios BGP desde un sistema autónomo propio o balanceo global permiten desviar tráfico fuera de una región fallida sin esperar a la actualización de DNS por los operadores.
• Gestión de múltiples clústeres. Despliegue unificado y configuraciones coordinadas en todos los sitios. Hay que tener en cuenta que la federación oficial de clústeres Kubernetes no se desarrolló plenamente —en la práctica la tarea se resuelve con herramientas de entrega de configuraciones y balanceo externo.
• Bases de datos distribuidas. Transición de RDBMS clásicas a sistemas diseñados para trabajar en múltiples regiones simultáneamente (CockroachDB, YugabyteDB, Spanner).
• Fallos gestionados. La resiliencia se verifica con experimentos regulares en producción —desde apagar máquinas individuales hasta simular cortes de red entre regiones. Solo se considera probado un escenario que se haya ejecutado en la práctica.
• Procedimiento de emergencia de un solo paso. Aislar una región fallida se hace con un solo comando, no con una secuencia de cuarenta pasos que nadie recuerda bajo estrés.

Riesgos principales

• No se puede eludir la física. Entre regiones la latencia es de decenas de milisegundos, y eso no se puede eliminar. La replicación síncrona añade ese tiempo a cada operación de escritura —la aplicación se vuelve perceptiblemente más lenta. La asíncrona mantiene la velocidad, pero en un conmutado de emergencia se pierden los datos que no llegaron. Elegir entre «más lento» y «con pérdidas» es una decisión arquitectónica, no un ajuste.
• Divergencia de datos. Si se rompe la conexión entre regiones, cada una puede decidir que es la sobreviviente y continuar aceptando escrituras. El resultado: dos conjuntos de datos contradictorios que habrá que reconciliar manualmente.
• Complejidad no lineal. El coste de soporte crece más rápido que la fiabilidad. Se necesitan especialistas escasos y caros, y cualquier cambio se despliega en todas las ubicaciones de forma coordinada.

Veredicto. Caro, complejo y requiere un equipo dedicado de soporte —pero el negocio sobrevive a la pérdida de un centro de datos completo.

Por dónde empezar

1. Determine el coste de una hora de inactividad. Sin esta cifra cualquier conversación sobre tolerancia a fallos es una discusión de gustos.
2. Dibuje un mapa de dependencias. Qué depende de qué: dominio, DNS, correo, pasarela de pago, base de datos, servicios externos. Marque qué fallos detienen las ventas.
3. Compruebe la recuperación. No «si se hacen copias», sino «cuándo fue la última vez que nos restauramos desde una copia y cuánto tardó». Una copia desde la que nadie se ha restaurado no es una copia de seguridad, es una suposición.
4. Compare el nivel con la realidad. Si descubre herramientas de tercer nivel para tareas de primer nivel —está pagando por fiabilidad que no usa.

Si no está seguro de en qué nivel se encuentra, empiece por una comprobación externa: el servicio revisará DNS, correo, certificado TLS y la velocidad del sitio y mostrará los puntos débiles en lenguaje sencillo.

Si necesita un análisis más profundo —determinaremos su nivel, calcularemos el coste del tiempo de inactividad y elaboraremos un plan de transición sin gastos innecesarios.