Sei sulla pagina 1di 18
Para tener claro una perspectiva de disponibilidad y capacidad de recuperación de un sistema es

Para tener claro una perspectiva de disponibilidad y capacidad de recuperación de un sistema es necesario identificar ciertos criterio y/o factores que son:

- Calidad

- Disponibilidad (Aplicabilidad)

- Concerns (Preocupaciones)

- Actividades

- Tácticas arquitectónicas

- Problemas y trampas

(Aplicabilidad) - Concerns (Preocupaciones) - Actividades - Tácticas arquitectónicas - Problemas y trampas
(Aplicabilidad) - Concerns (Preocupaciones) - Actividades - Tácticas arquitectónicas - Problemas y trampas
(Aplicabilidad) - Concerns (Preocupaciones) - Actividades - Tácticas arquitectónicas - Problemas y trampas
(Aplicabilidad) - Concerns (Preocupaciones) - Actividades - Tácticas arquitectónicas - Problemas y trampas

CALIDAD DESEADA

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.

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 recuperación de errores.

 

- Tiempo de inactividad planificado

- Tiempo de inactividad no planificado

CONCERN

- Tiempo de reparación

- Recuperación de desastres

- Clases de servicio

 

- Identificar requisitos de disponibilidad.

- Identificar tiempos de disponibilidad del sistema.

ACTIVIDAD

- 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

TACTICA DE ARQUITECTURA

software.

- Seleccionar o crear software tolerante a fallos

- Diseñar para el fracaso

- Replicar componentes

- Identificar soluciones de Backup y recuperación a fallos.

 

- Punto único de fallo

- Desarrollo en cascada (Fracaso)

- Indisponibilidad en cuanto a arquitecturas

PROBLEMA Y TRAMPA

- No llevar normas o estándares internacionales en cuanto

disponibilidad

- Tecnologías incompatibles.

- No llevar normas o estándares internacionales en cuanto disponibilidad - Tecnologías incompatibles.
- No llevar normas o estándares internacionales en cuanto disponibilidad - Tecnologías incompatibles.
- No llevar normas o estándares internacionales en cuanto disponibilidad - Tecnologías incompatibles.
- No llevar normas o estándares internacionales en cuanto disponibilidad - Tecnologías incompatibles.
- No llevar normas o estándares internacionales en cuanto disponibilidad - Tecnologías incompatibles.
deseada se refiere a la La calidad calificación que los usuarios o clientes dan sobre

deseada se refiere

a

la

La calidad calificación

que

los

usuarios

o

clientes

dan

sobre

el

sistema(Software) en cuanto a sus

componentes,

y/o

operaciones.

funciones

En este ámbito lo que se quiere lograr es que el usuario este 100% satisfecho con el producto adquirido, claro que en la mayoría 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 satisfacción, según el tiempo, costo e interoperabilidad del

software hacia lo que se llegar a

lograr.

a una mejor satisfacción, según el tiempo, costo e interoperabilidad del software hacia lo que se
a una mejor satisfacción, según el tiempo, costo e interoperabilidad del software hacia lo que se
a una mejor satisfacción, según el tiempo, costo e interoperabilidad del software hacia lo que se
a una mejor satisfacción, según el tiempo, costo e interoperabilidad del software hacia lo que se
a una mejor satisfacción, según el tiempo, costo e interoperabilidad del software hacia lo que se
VISTAS CARACTERISTICAS Funcional La disponibilidad es una preocupación clave para los usuarios y arquitectos

VISTAS

CARACTERISTICAS

Funcional

La disponibilidad es una preocupación 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 operación cuando este no está en línea y/o cuando las redes de comunicaciones no están disponibles.

Información

Una consideración clave de la disponibilidad es el establecer sistemas de proceso de Backup y recuperación de información, sistemas basados también en llevar un respaldo de toda la información que se maneja, capaces de soportar y respaldar en un tiempo determinado o cuando se lo requiera el sistema frente a un fallo.

Concurrencia

Características tales como la replicación de hardware y fallos en el sistema implicando cambios para generar un mejor manejo del diseño de concurrencia.

 

El enfoque para lograr disponibilidad, puede imponerse, diseñando limitaciones sobre el modulo de software, por ejemplo:

Desarrollo

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.

Despliegue

Disponibilidad y capacidad de recuperación pueden tener un gran impacto en el entorno de despliegue. Los requisitos de disponibilidad pueden generar un entorno de producción es decir generar una alta o baja disponibilidad dependiendo del número de requisitos del despliegue.

de producción es decir generar una alta o baja disponibilidad dependiendo del número de requisitos del
de producción es decir generar una alta o baja disponibilidad dependiendo del número de requisitos del
de producción es decir generar una alta o baja disponibilidad dependiendo del número de requisitos del
de producción es decir generar una alta o baja disponibilidad dependiendo del número de requisitos del
La preocupación principal y/o fundamental dentro de este modelo es la disponibilidad del sistema (el

La preocupación principal y/o fundamental dentro de este modelo es la disponibilidad del sistema (el tiempo máximo o proporción 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 reparación -Recuperación del sistema (Por fallo)

planificado -Tiempo de inactividad no planificado -Tiempo de reparación -Recuperación del sistema (Por fallo)
planificado -Tiempo de inactividad no planificado -Tiempo de reparación -Recuperación del sistema (Por fallo)
planificado -Tiempo de inactividad no planificado -Tiempo de reparación -Recuperación del sistema (Por fallo)
planificado -Tiempo de inactividad no planificado -Tiempo de reparación -Recuperación del sistema (Por fallo)
planificado -Tiempo de inactividad no planificado -Tiempo de reparación -Recuperación del sistema (Por fallo)
Las clases de servicio dentro de un Concerns son indispensables ya que por ejemplo cuando

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 caída 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 fácil y probablemente mas barato ofrecer un servicio restringido solo durante tiempos muertos de operación, en lugar de ofrecer soluciones que ofrecen un servicio completo durante largos periodos.

tiempos muertos de operación, en lugar de ofrecer soluciones que ofrecen un servicio completo durante largos
tiempos muertos de operación, en lugar de ofrecer soluciones que ofrecen un servicio completo durante largos
tiempos muertos de operación, en lugar de ofrecer soluciones que ofrecen un servicio completo durante largos
tiempos muertos de operación, en lugar de ofrecer soluciones que ofrecen un servicio completo durante largos
tiempos muertos de operación, en lugar de ofrecer soluciones que ofrecen un servicio completo durante largos
En la practica, todos los sistemas informáticos requieren de inactividad ocasional, con el fin de:

En la practica, todos los sistemas informáticos requieren de inactividad ocasional, con el fin de:

-Instalar el sistema operativo

-Actualización de Software -Tareas externas fueras de línea

- Copias de seguridad

- Verificación 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 operación no esta en ejecución . Por lo general es posible realizar estimaciones precisas del tiempo o longitud de las tareas que se inactivan o no están disponibles durante dicha inactividad planificada.

del tiempo o longitud de las tareas que se inactivan o no están disponibles durante dicha
del tiempo o longitud de las tareas que se inactivan o no están disponibles durante dicha
del tiempo o longitud de las tareas que se inactivan o no están disponibles durante dicha
Este tiempo no planificado se debe cuando un recurso tanto de Hardware como de Software
Este tiempo no planificado se debe cuando un recurso tanto de Hardware como de Software

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

aplicación puede sufrir un error que sea muy difícil de recuperar.

La

mayoría

de

los

sistemas

son

vulnerables

a

la

inactividad

no

planificada.

de recuperar. La mayoría de los sistemas son vulnerables a la inactividad no planificada.
de recuperar. La mayoría de los sistemas son vulnerables a la inactividad no planificada.
de recuperar. La mayoría de los sistemas son vulnerables a la inactividad no planificada.
de recuperar. La mayoría de los sistemas son vulnerables a la inactividad no planificada.
El tiempo de reparación es dependiente del tipo de falla generado, ya que no todas

El tiempo de reparación es dependiente del tipo de falla generado, ya que no todas las fallas son iguales en cuanto la gravedad o daño que realiza en el componente de Software o Hardware, además es muy difícil cuantificar

dicho tiempo porque el fallo así lo caracteriza , además asegurar que el

problema no vuelva a suceder puede ser mucho mas complejo de predecir y de calcular.

caracteriza , además asegurar que el problema no vuelva a suceder puede ser mucho mas complejo
caracteriza , además asegurar que el problema no vuelva a suceder puede ser mucho mas complejo
caracteriza , además asegurar que el problema no vuelva a suceder puede ser mucho mas complejo
caracteriza , además asegurar que el problema no vuelva a suceder puede ser mucho mas complejo
caracteriza , además asegurar que el problema no vuelva a suceder puede ser mucho mas complejo
Si un sistema critico falla completamente o si el entorno operativo físico no esta disponible

Si un sistema critico falla completamente o si el

entorno operativo físico no esta disponible debido a una falla, el proceso de recuperación de dichos componentes implica restablecer todo el proceso y los subprocesos dependientes del mismo, la recuperación ante algún fallo puede implicar la recreación del entorno completo, incluido hardware, comunicación de red y la plataforma

algún fallo puede implicar la recreación del entorno completo, incluido hardware, comunicación de red y la
algún fallo puede implicar la recreación del entorno completo, incluido hardware, comunicación de red y la
algún fallo puede implicar la recreación del entorno completo, incluido hardware, comunicación de red y la
algún fallo puede implicar la recreación del entorno completo, incluido hardware, comunicación de red y la
algún fallo puede implicar la recreación del entorno completo, incluido hardware, comunicación de red y la
En esta etapa se debe analizar, entender y validar los requisitos que adquiere el sistema

En esta etapa se debe analizar, entender y validar los requisitos que adquiere el

sistema para el funcionamiento, además de esto es importante interactuar con los interesados en el software para que ellos mismos validen y corroboren que el los requisitos planteados se están 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

términos de servicio o grado de necesidad.

cada tipo de servicio identificado, definir la disponibilidad requerida en términos de servicio o grado de
cada tipo de servicio identificado, definir la disponibilidad requerida en términos de servicio o grado de
cada tipo de servicio identificado, definir la disponibilidad requerida en términos de servicio o grado de
cada tipo de servicio identificado, definir la disponibilidad requerida en términos de servicio o grado de
cada tipo de servicio identificado, definir la disponibilidad requerida en términos de servicio o grado de
Se refiere a realizar un calendario estimando tiempos, periodos o escalas para el servicio ofrecido

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 tácticas que me

permiten realizar de manera detallada esta lista como:

-Texto y tablas: Es la forma mas sencilla de representación donde se enumeran los servicios ofrecidos y se cita cuando los servicios son o no son necesarios dentro de algún 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 años. -Identificar las horas regulares cuando el servicio realmente no es necesario.

ser necesario en ciertas épocas del años. -Identificar las horas regulares cuando el servicio realmente no
ser necesario en ciertas épocas del años. -Identificar las horas regulares cuando el servicio realmente no
ser necesario en ciertas épocas del años. -Identificar las horas regulares cuando el servicio realmente no
ser necesario en ciertas épocas del años. -Identificar las horas regulares cuando el servicio realmente no
Para comprender la disponibilidad de un sistema es necesario realizar una estimación razonable y precisa

Para comprender la disponibilidad de un sistema es necesario realizar una estimación razonable y precisa en términos teóricos de que tanto debe estar

disponible el servicio o software, a esto se le denomina (Máximo teórico de

disponibilidad)

ACTIVIDADES:

-Crear un modelo de disponibilidad. -Establecer métricas de seguridad (Ej: 99.9%). -Tiempo de Inactividad del sistema (Ej: 5 horas al año).

MTBF = Tiempo transcurrido entre fallos inherentes de un sistema durante el funcionamiento. (Lapso de tiempo total / numero de fallos).

MTTR = Tiempo medio de reparación.

Disponibilidad del Hardware = ( MTBF/ (MTBF+MTTR))

tiempo total / numero de fallos). MTTR = Tiempo medio de reparación. Disponibilidad del Hardware =
tiempo total / numero de fallos). MTTR = Tiempo medio de reparación. Disponibilidad del Hardware =
tiempo total / numero de fallos). MTTR = Tiempo medio de reparación. Disponibilidad del Hardware =
tiempo total / numero de fallos). MTTR = Tiempo medio de reparación. Disponibilidad del Hardware =
Existen ciertas tácticas que deben ser tomadas en cuanta para mantener la disponibilidad en pie

Existen ciertas tácticas 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).

hardware redundante o duplicado. - Usar clustering o balanceo de cargas. -Registrar transacciones (Copias de seguridad).
hardware redundante o duplicado. - Usar clustering o balanceo de cargas. -Registrar transacciones (Copias de seguridad).
hardware redundante o duplicado. - Usar clustering o balanceo de cargas. -Registrar transacciones (Copias de seguridad).
hardware redundante o duplicado. - Usar clustering o balanceo de cargas. -Registrar transacciones (Copias de seguridad).
hardware redundante o duplicado. - Usar clustering o balanceo de cargas. -Registrar transacciones (Copias de seguridad).
“Un sistema es tan solo fiable como su componente menos fiable” . -REDUCCIÓN DEL RIESGO

“Un sistema es tan solo fiable como su componente menos fiable”.

-REDUCCIÓN DEL RIESGO Identificar modelos arquitectónicos 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.

– Costo ya que muchas veces el modelo que se implementa es muy costoso y hace
– Costo ya que muchas veces el modelo que se implementa es muy costoso y hace
– Costo ya que muchas veces el modelo que se implementa es muy costoso y hace
– Costo ya que muchas veces el modelo que se implementa es muy costoso y hace
– Costo ya que muchas veces el modelo que se implementa es muy costoso y hace