Para tener claro una perspectiva de disponibilidad y capacidad de recuperacin de un sistema es necesario identificar ciertos criterio y/o factores

que son: Calidad Disponibilidad (Aplicabilidad) Concerns (Preocupaciones) Actividades Tcticas arquitectnicas Problemas y trampas

CALIDAD DESEADA

DISPONIBILIDAD

Es la capacidad del sistema para que sea totalmente o en parte operativo cuando sea necesario / Buen manejo de fallos para que no se vea afectada la Disponibilidad. Se aplica para cualquier sistema que tenga los requisitos de disponibilidad muy altos, es decir procesos muy complejos en cuanto a tolerancia de fallos y recuperacin de errores. Tiempo de inactividad planificado Tiempo de inactividad no planificado Tiempo de reparacin Recuperacin de desastres Clases de servicio Identificar requisitos de disponibilidad. Identificar tiempos de disponibilidad del sistema. Evaluar en contra de los requisitos. Rehacer la arquitectura Seleccionar tolerancia a fallos en Hardware Usar clustering de alta disponibilidad y balanceo de carga Registrar transacciones Aplicar soluciones de disponibilidad por medio de software. Seleccionar o crear software tolerante a fallos Disear para el fracaso Replicar componentes Identificar soluciones de Backup y recuperacin a fallos. Punto nico de fallo Desarrollo en cascada (Fracaso) Indisponibilidad en cuanto a arquitecturas No llevar normas o estndares internacionales en cuanto disponibilidad Tecnologas incompatibles.

CONCERN

ACTIVIDAD

TACTICA DE ARQUITECTURA

PROBLEMA Y TRAMPA

La calidad deseada se refiere a la calificacin que los usuarios o clientes dan sobre el sistema(Software) en cuanto a sus componentes, funciones y/o operaciones. En este mbito lo que se quiere lograr es que el usuario este 100% satisfecho con el producto adquirido, claro que en la mayora de las veces no lo es as. Si se mantiene un alto grado de disponibilidad de el proceso a ofrecer o los procesos adquiridos este hace que se llegue a una mejor satisfaccin, segn el tiempo, costo e interoperabilidad del software hacia lo que se llegar a lograr.

VISTAS

Funcional

Informacin

Concurrencia

Desarrollo

Despliegue

CARACTERISTICAS La disponibilidad es una preocupacin clave para los usuarios y arquitectos interesados, ya que este puede soportar algunos requerimientos externos necesarios para el funcionamiento del sistema, tales como la capacidad de operacin cuando este no est en lnea y/o cuando las redes de comunicaciones no estn disponibles. Una consideracin clave de la disponibilidad es el establecer sistemas de proceso de Backup y recuperacin de informacin, sistemas basados tambin en llevar un respaldo de toda la informacin que se maneja, capaces de soportar y respaldar en un tiempo determinado o cuando se lo requiera el sistema frente a un fallo. Caractersticas tales como la replicacin de hardware y fallos en el sistema implicando cambios para generar un mejor manejo del diseo de concurrencia. El enfoque para lograr disponibilidad, puede imponerse, diseando limitaciones sobre el modulo de software, por ejemplo: Todos los sistemas y subsistemas deben soportar, inicios, paradas, pausas y restauraciones de comandos para alinear criterios con estrategias de soporte de manejo al sistema. Disponibilidad y capacidad de recuperacin pueden tener un gran impacto en el entorno de despliegue. Los requisitos de disponibilidad pueden generar un entorno de produccin es decir generar una alta o baja disponibilidad dependiendo del nmero de requisitos del despliegue.

La preocupacin principal y/o fundamental dentro de este modelo es la disponibilidad del sistema (el tiempo mximo o proporcin de tiempo en que el sistema debe estar en funcionamiento y disponible para proporcionar servicios al usuario), Sin embargo, existen ciertos criterios dentro de los Concerns que son : -Clases de Servicio -Tiempo de inactividad planificado -Tiempo de inactividad no planificado -Tiempo de reparacin -Recuperacin del sistema (Por fallo)

Las clases de servicio dentro de un Concerns son indispensables ya que por ejemplo cuando se piensa en el tiempo de inactividad del sistema, no es necesario restringirse en cuanto a disponibilidad o no disponibilidad que este me genera sobre modelo de servicio, sino es importante y conveniente considerar diferentes niveles de servicio que soporten la cada del servicio y que por medio de esto no se vea afectado ciertos componentes del sistema que hacen que su rendimiento y funcionalidad sea completo. Aunque la no disponibilidad del sistema es generalmente indeseable, puede ser mas fcil y probablemente mas barato ofrecer un servicio restringido solo durante tiempos muertos de operacin, en lugar de ofrecer soluciones que ofrecen un servicio completo durante largos periodos.

En la practica, todos los sistemas informticos requieren de inactividad ocasional, con el fin de:

-Instalar el sistema operativo -Actualizacin de Software -Tareas externas fueras de lnea - Copias de seguridad - Verificacin de datos - Entre otros.
El tiempo muerto de indisponibilidad se planifica de tal manera que se realiza un acuerdo con un programa predeterminado que se aliena a los requisitos del negocio. El tiempo de inactividad planificado por lo general ocurre durante la noche o fines de semana donde la operacin no esta en ejecucin . Por lo general es posible realizar estimaciones precisas del tiempo o longitud de las tareas que se inactivan o no estn disponibles durante dicha inactividad planificada.

Este tiempo no planificado se debe cuando un recurso tanto de Hardware como de Software falla en un tiempo determinado, esto hace que el sistema se caiga y/o sea inutilizable. Lo mas frecuente para generar una inactividad del sistema es : -La CPU o el Disco Duro puede fallar. -La conectividad de red puede perderse. -El sistema operativo se bloquea o la aplicacin puede sufrir un error que sea muy difcil de recuperar. La mayora de los sistemas son vulnerables a la inactividad no planificada.

El tiempo de reparacin es dependiente del tipo de falla generado, ya que no todas las fallas son iguales en cuanto la gravedad o dao que realiza en el componente de Software o Hardware, adems es muy difcil cuantificar dicho tiempo porque el fallo as lo caracteriza , adems asegurar que el problema no vuelva a suceder puede ser mucho mas complejo de predecir y de calcular.

Si un sistema critico falla completamente o si el entorno operativo fsico no esta disponible debido a una falla, el proceso de recuperacin de dichos componentes implica restablecer todo el proceso y los subprocesos dependientes del mismo, la recuperacin ante algn fallo puede implicar la recreacin del entorno completo, incluido hardware, comunicacin de red y la plataforma

En esta etapa se debe analizar, entender y validar los requisitos que adquiere el sistema para el funcionamiento, adems de esto es importante interactuar con los interesados en el software para que ellos mismos validen y corroboren que el los requisitos planteados se estn cumpliendo. Los pasos mas comunes para identificar los requisitos son.
-Considerar cada uno de los servicios ofrecidos. -Clasificar los servicios en grupos por actividades comunes o por productividad. -Establecer niveles de servicio. -Para cada tipo de servicio identificado, definir la disponibilidad requerida en trminos de servicio o grado de necesidad.

Se refiere a realizar un calendario estimando tiempos, periodos o escalas para el servicio ofrecido por el Software ya que al ser validado por los interesados (Stakeholders) este se puede programar; existen ciertas tcticas que me permiten realizar de manera detallada esta lista como: -Texto y tablas: Es la forma mas sencilla de representacin donde se enumeran los servicios ofrecidos y se cita cuando los servicios son o no son necesarios dentro de algn proceso. -Notaciones graficas: Se pueden realizar por medio de Diagramas de Gantt. ACTIVIDADES: -Identificar la disponibilidad en funcionamiento normales, para cada uno de los servicios del sistema. -Cuando incluya la disponibilidad estacional Cuando el sistema o servicio puede ser necesario en ciertas pocas del aos. -Identificar las horas regulares cuando el servicio realmente no es necesario.

Para comprender la disponibilidad de un sistema es necesario realizar una estimacin razonable y precisa en trminos tericos de que tanto debe estar disponible el servicio o software, a esto se le denomina (Mximo terico de disponibilidad) ACTIVIDADES: -Crear un modelo de disponibilidad. -Establecer mtricas de seguridad (Ej: 99.9%). -Tiempo de Inactividad del sistema (Ej: 5 horas al ao). MTBF = Tiempo transcurrido entre fallos inherentes de un sistema durante el funcionamiento. (Lapso de tiempo total / numero de fallos). MTTR = Tiempo medio de reparacin. Disponibilidad del Hardware = ( MTBF/ (MTBF+MTTR))

Existen ciertas tcticas que deben ser tomadas en cuanta para mantener la disponibilidad en pie en un sistema tanto de software como de hardware: -Seleccionar hardware tolerante a errores o fallos, en el cual el fallo no afecte componentes internos o externos a el. - Utilizar hardware redundante o duplicado. - Usar clustering o balanceo de cargas. -Registrar transacciones (Copias de seguridad).

Un sistema es tan solo componente menos fiable.

fiable

como

su

-REDUCCIN DEL RIESGO Identificar modelos arquitectnicos que permitan generar punto de vista en lo funcional del sistema, para detectar la presencia de cualquier punto nico de fallo. -Identificar Beneficio Costo ya que muchas veces el modelo que se implementa es muy costoso y hace que para una empresa no sea rentable.