Disponibilidad y fiabilidad: nueves, MTBF, MTTR y tolerancia a fallos

Cuatro palabras que a menudo se confunden

Los usuarios perciben un sistema como algo que funciona o que no funciona. Los arquitectos necesitan palabras más precisas, porque cada palabra apunta a una respuesta de diseño distinta. La disponibilidad es la proporción del tiempo (o de las solicitudes) en la que el sistema está listo para prestar su servicio cuando se le pide. La fiabilidad es la probabilidad de que el sistema funcione correctamente, sin fallos, durante un periodo determinado y en unas condiciones determinadas. La tolerancia a fallos es la capacidad de seguir prestando el servicio aunque alguna parte haya fallado. La resiliencia es la capacidad más amplia de absorber una perturbación, mantener en marcha el servicio esencial (quizá degradado) y volver después a la normalidad.

ISO/IEC 25010:2023 sitúa la disponibilidad, la tolerancia a fallos y la recuperabilidad, junto con la ausencia de defectos (faultlessness, que sustituyó al término madurez de 2011), como subcaracterísticas de la fiabilidad. Bass, Clements y Kazman, en Software Architecture in Practice, tratan la disponibilidad como un atributo de calidad propio porque impulsa muchísimas decisiones arquitectónicas. Ninguna de las dos visiones es incorrecta; usa la que ayude a la conversación, pero deja claro a qué te refieres con cada palabra.

La diferencia entre disponibilidad y fiabilidad importa en la práctica. Imagina un servicio que se cae una vez por hora y se reinicia en un segundo. Su disponibilidad es 3599 / 3600 = 99.97%, lo que parece excelente. Su fiabilidad durante un trabajo por lotes de dos horas es mala: si los fallos llegan al azar a un ritmo de uno por hora, la probabilidad de funcionar dos horas sin ninguno es e^-2, alrededor del 13.5%. A un terminal de pago le importa la disponibilidad; a un cálculo científico de larga duración, a un robot quirúrgico o a un avión les importa la fiabilidad durante toda la misión.

Defecto, error y fallo

La comunidad de la confiabilidad (Avižienis, Laprie, Randell y Landwehr, 2004) separa tres ideas que el lenguaje cotidiano confunde. Un defecto es la causa: un bug, un disco averiado, una configuración errónea, un certificado caducado. Un defecto puede permanecer latente durante años. Cuando se activa, produce un error: una parte del estado interno del sistema que es incorrecta, como un registro dañado o un valor incorrecto en memoria. Si el error llega al límite del servicio, el resultado es un fallo: el servicio que se presta a los usuarios se desvía de lo que debería ser.

Bass, Clements y Kazman usan la misma idea de forma más sencilla: un fallo es una desviación de la especificación que los usuarios del sistema pueden observar, y la causa de un fallo es un defecto. Lo importante para los arquitectos es que cada eslabón de la cadena es un lugar donde intervenir. Puedes impedir que surjan defectos (revisión de código, retirar un componente del servicio antes de que se desgaste), detectar los errores antes de que se propaguen (validación, comprobaciones de estado) y contener o enmascarar los errores para que nunca se conviertan en fallos (redundancia, reintentos, transacciones).

Contar los nueves

Los objetivos de disponibilidad suelen escribirse como un porcentaje con un número de nueves: el 99.9% son tres nueves. Conviene convertir cada objetivo en tiempo de inactividad permitido, porque un porcentaje oculta el poco tiempo del que dispones realmente. El cálculo es sencillo: inactividad = (1 - disponibilidad) x periodo. Un año de 365 días tiene 525 600 minutos, así que el 99.9% permite 0.001 x 525 600 = 525.6 minutos, unas 8.76 horas. Para un mes de 30 días (43 200 minutos) permite 43.2 minutos.

Cada nueve adicional divide el margen entre diez, mientras que el costo de ingeniería suele crecer mucho más deprisa. Con el 99.99% tienes unos 4.3 minutos al mes: menos de lo que tarda una persona en recibir el aviso, despertarse, iniciar sesión y entender qué falla. Por eso, por encima de tres o cuatro nueves, la recuperación debe ser automática; las personas son demasiado lentas para formar parte del proceso.

MTBF, MTTF y MTTR

Tres promedios relacionan los fallos y las reparaciones. El tiempo medio hasta el fallo (MTTF) es el tiempo medio que funciona un componente antes de fallar. El tiempo medio de reparación (MTTR) es el tiempo medio desde el fallo hasta que se restablece el servicio (algunas organizaciones leen la R como recover o restore, es decir, recuperar o restablecer; la idea es la misma, pero di qué reloj usas: desde el fallo, desde la detección o desde la primera alerta). El tiempo medio entre fallos (MTBF) es el tiempo medio desde un fallo hasta el siguiente.

La fórmula clásica de estado estacionario es A = MTBF / (MTBF + MTTR). En rigor, para un sistema reparable MTBF = MTTF + MTTR, y la expresión exacta es MTTF / (MTTF + MTTR): el tiempo de actividad dividido entre el tiempo de actividad más el de inactividad. Los libros de texto escriben a menudo MTBF cuando se refieren al tiempo medio de actividad; cuando las reparaciones son breves en comparación con el tiempo entre fallos, como suele ocurrir, la diferencia es despreciable. La fórmula supone un promedio a largo plazo y no dice nada sobre cómo se distribuyen las caídas, por lo que combina bien con una medida de fiabilidad y con percentiles del tiempo de reparación.

Componentes en serie y en paralelo

Los sistemas reales son cadenas de piezas. Si una solicitud necesita la capa web, el servidor de aplicaciones y la base de datos, los tres deben funcionar: los componentes están en serie, y sus disponibilidades se multiplican. Como cada factor es menor que uno, el producto siempre es inferior al del eslabón más débil. Diez componentes al 99.9% cada uno dan 0.999¹⁰ = 0.990, solo un 99.0%.

Si, en cambio, basta con una cualquiera de varias copias idénticas, las copias están en paralelo (redundancia). El conjunto solo falla cuando fallan todas las copias a la vez, así que se multiplican las indisponibilidades: A_paralelo = 1 - (1 - A)ⁿ para n copias idénticas. Dos servidores al 99% cada uno dan 1 - 0.01 x 0.01 = 99.99%.

Tácticas de disponibilidad: detectar, recuperar, prevenir

Bass, Clements y Kazman agrupan las tácticas de disponibilidad en tres familias. Son opciones de diseño, no una lista de comprobación que haya que aplicar entera; cada una tiene un costo.

Elegir entre activo-pasivo y activo-activo

Activo-pasivo es más fácil de razonar, sobre todo para componentes con estado, como una base de datos relacional con un único primario en el que se puede escribir. Sus costos son la reserva ociosa, un intervalo de failover (detección más promoción, a menudo decenas de segundos) y el riesgo de que la reserva se haya desincronizado sin que nadie lo note. Una trampa clásica es el split brain (cerebro dividido): la red entre los dos se rompe, cada uno cree que el otro ha muerto y ambos aceptan escrituras. Protegerse contra ello requiere un quórum o un árbitro externo.

Activo-activo usa toda la capacidad y no tiene paso de promoción, pero cada nodo debe dimensionarse para soportar toda la carga si su pareja falla. Dos nodos que funcionan cada uno al 70% de utilización recibirán una demanda del 140% cuando uno muera, y el superviviente se hunde: un diseño redundante que falla de todos modos. Activo-activo también te obliga a resolver la consistencia de los datos entre las copias, que es un gran tema en sí mismo (consulta consistencia, CAP y PACELC).

Recuperación ante desastres: RTO y RPO

La redundancia dentro de un centro de datos no te protege de perder todo el centro de datos, una región, una cuenta en la nube o tus datos por un ransomware. La planificación de la recuperación ante desastres usa dos números que deberían venir del negocio, no de los ingenieros. El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable para restaurar el servicio después de un desastre. El objetivo de punto de recuperación (RPO) es la mayor pérdida de datos aceptable, medida en tiempo: un RPO de 15 minutos significa que puedes perder como máximo los cambios de los últimos 15 minutos.

Los dos números llevan a diseños y costos muy distintos. Las copias de seguridad nocturnas copiadas a otra región dan un RPO de hasta 24 horas y un RTO de muchas horas (restaurar terabytes lleva tiempo). La replicación asíncrona continua a un warm standby (espera semiactiva) en otra región podría dar un RPO de segundos y un RTO de minutos, quizá con el doble de costo de infraestructura. La replicación síncrona puede acercar el RPO a cero, pero añade a cada escritura el tiempo de ida y vuelta entre sedes. Los proveedores de nube describen una escalera de estrategias: copia de seguridad y restauración, pilot light (piloto encendido), warm standby y activo-activo multisitio, cada una más rápida y más cara que la anterior. Los detalles corresponden a multirregión y recuperación ante desastres.

Sea cual sea la estrategia, una copia de seguridad que nunca has restaurado no es una copia de seguridad. Prueba las restauraciones de forma programada y mide cuánto tardan; el tiempo de restauración medido es tu RTO real.

De los objetivos a los SLI, SLO y SLA

La práctica moderna de operaciones expresa la disponibilidad con tres términos relacionados, que se tratan a fondo en SLI, SLO y presupuestos de errores. Un indicador de nivel de servicio (SLI) es la medición, por ejemplo la proporción de solicitudes de pago que tienen éxito en menos de 800 ms. Un objetivo de nivel de servicio (SLO) es el objetivo interno para esa medición en una ventana de tiempo, por ejemplo el 99.9% en 30 días. Un acuerdo de nivel de servicio (SLA) es un contrato con los clientes que establece consecuencias, como créditos de servicio, si no se alcanza un nivel; normalmente se fija más laxo que el SLO para que el equipo reciba un aviso antes de que se incumpla el contrato.

El SLO convierte la disponibilidad en un presupuesto. Un SLO mensual del 99.9% permite que falle el 0.1% de las solicitudes; con 2 millones de solicitudes al mes, son 2000 solicitudes fallidas, o unos 43 minutos de caída total. Los equipos gastan este presupuesto de errores en riesgo: lanzamientos, experimentos, migraciones. Cuando se agota, frenan e invierten en fiabilidad. Esto conecta los nueves abstractos de esta sección con las decisiones del día a día.

Errores comunes

Prometer nueves sin contar las dependencias: un servicio del 99.99% construido sobre una única base de datos del 99.9% no puede cumplir su objetivo. Añadir redundancia sin eliminar las causas compartidas (la misma versión, el mismo cambio de configuración, el mismo certificado que caduca en todos los nodos a medianoche). Medir la disponibilidad desde dentro del sistema, donde todo se ve en verde, mientras los usuarios no pueden acceder por culpa del DNS o de una red de distribución de contenidos. Planificar el failover pero no ensayarlo nunca; la ingeniería del caos existe precisamente para ejercitar estos caminos de forma deliberada (ingeniería del caos). Por último, perseguir un número por sí mismo: un sistema de turnos de personal que se usa en horario de oficina no necesita cinco nueves, y el dinero se gasta mejor en otra cosa.

Para que la disponibilidad se pueda probar, escríbela como un escenario (Sección 2.3): Cuando el servidor primario de la base de datos falla en las horas de máxima demanda, el sistema lo detecta en menos de 10 segundos y vuelve a aceptar pedidos en menos de 60 segundos, sin perder ningún pedido confirmado. Cada parte de esa frase se convierte en una decisión de diseño y en una prueba.