Principia #3: Disponibilidad (Availability)
Más allá del simple uptime
George Berkeley fue un matemático y filósofo del siglo XVIII, conocido por su teoría del idealismo. Según Berkeley, la existencia de un objeto depende de que sea percibido por una mente consciente. En otras palabras, “ser es ser percibido” (esse est percipi).
Si un árbol cae en un bosque y no hay nadie para escucharlo, ¿hace algún sonido?
Desde la perspectiva de Berkeley, el árbol no haría ningún sonido porque no hay una mente consciente que lo perciba. El sonido es una experiencia sensorial que requiere un oyente. Si no hay nadie para escuchar el árbol caer, entonces no hay experiencia auditiva y, por lo tanto, en términos de percepción, el sonido no existe.
Desde el punto de vista de la física, sin embargo, el árbol sí emitiría un sonido al caer, ya que produciría ondas sonoras.
Esta misma situación es la que me encuentro a menudo al tratar de definir, junto con colegas, qué es exactamente la disponibilidad. ¿Está disponible un servicio si nadie lo está usando?
La casuística es de lo más variopinta y las interpretaciones dependen en gran medida del contexto. Pero empecemos por una definición general. Según la RAE:
Disponibilidad: Cualidad o condición de disponible.
No nos ayuda mucho, así que afinemos un poco más el tiro.
En ingeniería de sistemas, la disponibilidad se refiere a la capacidad de un sistema o servicio para estar operativo y accesible cuando se requiere. Esto implica que el sistema debe estar funcionando correctamente y ser capaz de responder a las solicitudes de los usuarios en cualquier momento.
La disponibilidad se mide comúnmente como un porcentaje del tiempo total durante el cual un sistema está operativo. Por ejemplo, una disponibilidad del 99,9 % implica aproximadamente 8,76 horas de inactividad al año.
Pero ¿qué significa esto en la práctica?
Normalmente, estos porcentajes se establecen en los SLA (Service Level Agreements) entre proveedores y clientes, junto con penalizaciones por incumplimiento. El problema es que casi siempre se deja abierta la interpretación de qué significa exactamente que un sistema esté “operativo y accesible”.
En muchas empresas, la disponibilidad se mide simplemente como el tiempo que un servicio está en línea y responde a solicitudes básicas. El uptime suele calcularse mediante herramientas de monitorización que hacen pings periódicos al servicio. Si responde, se considera disponible.
Esto es engañoso.
Un servicio puede estar levantado y, aun así, no estar funcionando correctamente. Por ejemplo, un servicio web puede responder, pero si una API externa de la que depende está caída, el servicio no puede cumplir su función.
¿Está disponible en ese caso? Evidentemente no.
Aquí aparece el acoplamiento de disponibilidad: la disponibilidad de nuestro servicio nunca puede ser mayor que la de los servicios de los que depende. Si dependemos de una API externa con una disponibilidad del 99 %, ese será, como máximo, nuestro techo teórico.
De ahí la importancia de definir con claridad qué significa “disponible” en nuestros SLA.
Otra forma de medir la disponibilidad es mediante el número de peticiones exitosas frente al total de peticiones. Si un servicio recibe 1000 peticiones en un día y 990 son exitosas, la disponibilidad sería del 99 %.
Esta métrica refleja mucho mejor la experiencia real del usuario.
Pero también tiene sus trampas. No es lo mismo estar caído una hora en plena hora punta que una hora de madrugada. Si el tráfico es uniforme durante 24 h, esta métrica es bastante representativa. Si no, hay que interpretarla con cuidado.
Por último, podemos medir la disponibilidad a partir del tiempo medio entre fallos (MTBF) y del tiempo medio de reparación (MTTR). El MTBF mide cuánto tiempo funciona un sistema sin fallar; el MTTR, cuánto tarda en recuperarse cuando falla. Cuanto mayor sea el primero y menor el segundo, mayor será la disponibilidad.
De esto hablamos en el Principia #1: Fiabilidad (Reliability). Si un servicio tiene un MTBF de 1000 horas y un MTTR de 1 hora, su disponibilidad aproximada será del 99,9 %, calculada como:
Esta métrica es especialmente útil porque es menos sensible al “ruido”. Se declara un fallo cuando el sistema deja de funcionar, algo que podemos detectar directamente mediante alertas o indirectamente a través de quejas de usuarios. Una vez detectado el fallo, medimos cuánto tardamos en recuperarnos.
Si ocurre un fallo que no se detecta, no afecta a la métrica de disponibilidad, aunque sí puede afectar brevemente a la experiencia del usuario… que normalmente se encargará de avisarnos si el problema se alarga demasiado.
En resumen, la disponibilidad es una métrica imprescindible para evaluar tanto la fiabilidad como la experiencia de usuario de un sistema o servicio. Pero, como casi todo en ingeniería, su valor depende de cómo la definamos y de qué estemos midiendo realmente.
Porque, al final, igual que con el árbol de Berkeley: si el servicio deja de funcionar cuando nadie lo utiliza… ¿está realmente disponible?
¡Muchas gracias por leerme!