lunes, 6 de marzo de 2017

Software Architecture in Practice: Parte 2-2: Disponibilidad (Availability)

Esta entrada nace como un aproximación a la asignatura de Arquitectura de Software de la Especialización en Procesos de Software que estoy cursando en la Universidad San Buenaventura en Santiago de Cali, Colombia.

El objetivo de esta entrada dar a conocer apartes, síntesis y opiniones acerca del libro Software Architecture in Practice.


Parte 2-2: Disponibilidad (Availability)

Definición.
La disponibilidad de un sistema de información se puede definir como la propiedad que exhibe un sistema para estar siempre listo para desempeñar sus funcionalidades, en el momento que se le necesite. Especialmente, después que se hayan manifestado fallos.

Este atributo de calidad esta fuertemente relacionado con la Confiabilidad (Reliability) y con la Recuperabilidad (Recoverabilityde un sistema.

De hecho, la disponibilidad se puede definir como:


Disponibilidad = Confiabilidad + Recuperabilidad

En esencia, la disponibilidad de un sistema consiste en la implementación de mecanismos que permitan minimizar el tiempo fuera de servicio de un sistema, mediante la mitigación de fallos.

El objetivo es lograr tiempos de disponibilidad similares a los mostrados en la siguiente tabla:



Estos fallos pueden ser prevenidos, tolerados, eliminados, etc. Estos fallos deben ser identificados por el sistema con el fin de que este pueda reaccionar de alguna manera. La reacción deseada dependerá de la criticidad del sistema.


Escenarios de Calidad.
Los escenarios de calidad para la Disponibilidad se definen así:
  • Fuente del Estimulo: Pueden ser interno o externos.
  • Estimulo: Es un fallo de alguna de estas categorías:
    • Omisión: Un componente no responde a una entrada.
    • CrashUn componente sufre repetidas veces fallos de omisión.
    • Sincronización: Un componente responde a una entrada correctamente, pero lo hace en un tiempo muy temprano o muy tarde.
    • Respuesta: Un componente responde a una entrada de forma errónea.
  • Ambiente: El estado del sistema cuando el fallo ocurre, condiciona la respuesta esperada del escenario. No es lo mismo reaccionar cuando sucede el primer fallo, que cuando el sistema ya esta operando en modo degradado.
  • Artefacto: Especifica el recurso o componente del cual se requiere la disponibilidad. 
  • Respuesta: Reacciones al fallo en el sistema:
    • El fallo debe ser identificado y correlacionado.
    • El sistema debe poder recuperarse del fallo.
      • Registrar el fallo
      • Notificaciones a usuarios especiales
      • Limitar el uso de funciones o capacidad
  • Medida de la Respuesta: Las medidas disponibles son:
    • Porcentaje de Disponibilidad
    • Tiempo para detectar la falla
    • Tiempo para reparar la falla
    • etc

Ejemplo de un escenario de calidad:



Tácticas para la Disponibilidad.
Las tácticas para la Disponibilidad se categorizan en:
  • Detección de Fallos: Estas tácticas, básicamente buscan detectar señales de vida de los diferentes componentes críticos del sistema. Aquellos componentes cuyo mal funcionamiento implica directamente el mal funcionamiento del sistema, son los objetivos de estas tácticas.
  • Recuperación de Fallos: Estas tácticas combinan los mecanismos para reintentar la operación y/o el mantener lógica y datos redundantes.
  • Prevención de Fallos: Estas tácticas dependen de mecanismos para remover los elementos con fallo de servicio o de mecanismos para limitar el alcance de los fallos.

El listado de tácticas de cada una de estas categorías, se pueden ver en el siguiente árbol:


Todas estas tácticas de Disponibilidad son Tácticas de Coordinación de Elementos. Esto implica que la forma en la cual el sistema de información es construido (implantado y/o desarrollado) facilitara o no la implementan de estas tácticas.










    No hay comentarios:

    Publicar un comentario