La disponibilidad —o availability en inglés— es un atributo de calidad de una arquitectura de software que define el grado en el cual un sistema, producto o componente está operativo y accesible cuando se requiere su uso1.
Es la probabilidad de que un sistema esté en funcionamiento en cualquier momento dado. Este atributo es relevante para sistemas, productos o componentes que deben estar continuamente disponibles, como servicios de emergencia, sistemas bancarios, plataformas de comercio electrónico, entre otros.
Bass y otros2 incluyen dentro del atributo de disponibilidad conceptos de prevención de fallos y recuperación de los fallos, que en ISO/IEC 250101 pueden estar también relacionados con los atributos de tolerancia a fallos y capacidad de recuperación respectivamente.
Algo similar sucede en el Azure Well-Architected Framework3 donde el pilar es fiabilidad que incluye resiliencia y recuperación que están también relacionados con los atributos de tolerancia a fallos y capacidad de recuperación respectivamente.
La disponibilidad se mide generalmente como una proporción del tiempo en que el sistema está operativo y accesible frente al tiempo total. Se expresa como un porcentaje y se calcula utilizando la siguiente fórmula:
Donde:
-
$\text{Tiempo de Operación}$ o uptime: es el tiempo durante el cual el sistema está funcionando correctamente. -
$\text{Tiempo Total}$ : es la suma del tiempo de operación y el tiempo de inactividad —o downtime—, que incluye tanto el tiempo planificado para mantenimiento como el tiempo no planificado debido a fallos o interrupciones.
Por ejemplo:
Si un sistema estuvo operativo durante 696 horas en un mes —que tiene 720 horas— y tuvo 24 horas de inactividad no planificada, la disponibilidad se calcularía de la siguiente manera:
La fórmula de disponibilidad también se puede expresar en términos de tiempo medio entre fallos —o MTBF por sus siglas en inglés, que significa mean time to failure— y tiempo medio de reparación —o MTTR por sus siglas en inglés, que significa mean time to repair—.
La disponibilidad se puede calcular utilizando MTBF y MTTR con la siguiente fórmula:
Donde:
-
$\text{MTTF}$ : es el tiempo promedio que transcurre entre fallos sucesivos de un sistema. Representa la fiabilidad del sistema. -
$\text{MTTR}$ : es el tiempo promedio que se tarda en reparar un fallo y restaurar el sistema a su funcionamiento normal. Representa la capacidad de recuperación del sistema.
Para entender cómo ambas fórmulas están relacionadas, considera lo siguiente:
-
Tiempo total de operación y reparación:
- El tiempo total de operación entre dos fallas es MTBF.
- El tiempo total para reparar y volver a la operación es MTTR.
-
Ciclo completo:
- Un ciclo completo incluye el tiempo de operación o MTBF y el tiempo de reparación o MTTR.
- Entonces, el tiempo total de un ciclo es
$\text{MTBF} + \text{MTTR}$ .
-
Proporción del tiempo de operación:
- La disponibilidad es la proporción del tiempo de operación en relación con el tiempo total.
- Por lo tanto, se calcula como la fracción del tiempo de operación sobre el tiempo total del ciclo.
Por ejemplo:
Supongamos que un sistema tiene un MTBF de 1000 horas y un MTTR de 10 horas:
Esto significa que la disponibilidad del sistema es aproximadamente 99.01%.
- MTBF: Un mayor MTBF indica que el sistema es más fiable y tiene menos fallas en un período de tiempo determinado, lo que aumenta la disponibilidad.
- MTTR: Un menor MTTR indica que el sistema se repara más rápidamente cuando ocurre una falla, lo que también aumenta la disponibilidad.
Las organizaciones a menudo establecen objetivos de disponibilidad específicos, conocidos como acuerdos de nivel de servicio o SLA por sus siglas en inglés —service level agreement-, que pueden ser del 99.9% —conocido como "tres nueves"—, 99.99% —"cuatro nueves"— o incluso más altos, dependiendo de la criticidad del sistema.
- 99.9% o tres nueves: Aproximadamente 8.76 horas de inactividad al año.
- 99.99% o cuatro nueves: Aproximadamente 52.56 minutos de inactividad al año.
- 99.999% o cinco nueves: Aproximadamente 5.26 minutos de inactividad al año.
La disponibilidad es un aspecto crucial de la arquitectura de un producto que requiere alta confiabilidad y accesibilidad constante.
Vean más detalles sobre estas tácticas para la disponibilidad aquí.
| Tácticas de disponibilidad | Detectar fallas | Monitoreo | |
| Ping/echo | |||
| Heartbeat | |||
| Timestamp | |||
| Monitoreo de condiciones | |||
| Chequeo de salud | |||
| Voto: replicación, redundancia funcional, redundancia analítica | |||
| Detección de excepciones | |||
| Auto-diagnóstico | |||
| Recuperarse de las fallas | Preparación y reparación | Repuesto redundante | |
| Rollback | |||
| Manejo de excepciones | |||
| Actualización de software | |||
| Re-intentos | |||
| Ignorar el comportamiento fallido | |||
| Degradación elegante | |||
| Re-configuración | |||
| Re-introducción | Sombra | ||
| Re-sincronización del estado | |||
| Escalamiento del reinicio | |||
| Reenvío sin pausa | |||
| Prevenir fallas | Remoción del servicio o rejuvenecimiento de software o reinicio terapéutico | ||
| Transacciones | |||
| Modelo predictivo | |||
| Prevención de excepciones | |||
| Aumentar el conjunto de competencia | |||
Vean Cloud design patterns that support reliability en Azure Well-Architected Framework.
Vean Tactics and Patterns for Software Robustness en Carnegie Mellon University, Software Engineering Institute's Insights Blog.
Footnotes
-
ISO/IEC 25010. (2011). ISO/IEC 25010:2011, Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. ↩ ↩2
-
Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in Practice, 4th edition. Addison-Wesley. ↩
-
Microsoft. (2023). Reliability design principles. Disponible aquí. ↩