Gestión de la Disponibilidad

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Gestión de la Disponibilidad por Mind Map: Gestión de la Disponibilidad

1. SFA: Service Failure Analysis

1.1. Se utiliza para identificar las causas de la interrupción del servicio al usuario de una manera estructurada. El SFA se ejecuta como una tarea o proyecto, y puede utilizar otros métodos y técnicas de gestión de la disponibilidad para formular las recomendaciones para la mejora.

1.1.1. A grandes rasgos, su estructura debe contener: Seleccionar la oportunidad Alcance Planeación Construcción de las Hipótesis Análisis de los Datos Entrevistas con el personal clave Hallazgos y conclusiones Recomendaciones Reporte Final Validación

1.2. Al realizar un análisis detallado de las interrupciones del servicio e incluir las personas clave se puede identificar oportunidades de mejora que aumenten los niveles de disponibilidad.

1.3. Las actividades del SFA están alineadas con la gestión de problemas, y en muchas organizaciones estas actividades se realizan conjuntas.

2. FTA: Fault Tree Analysis

2.1. Es una técnica que se puede utilizar para determinar una cadena de eventos que ha causado un incidente o puede provocar un incidente en el futuro.

2.1.1. FTA utiliza una representación de una cadena de eventos a través de la notación Booleana. En la cual se distinguen los siguientes eventos:

2.1.1.1. Eventos Básicos

2.1.1.1.1. Los eventos se combinan utilizando los siguientes operadores lógicos: AND-gate OR_gate Exclusive OR-gate Inhibit gate

2.1.1.2. Eventos Resultantes

2.1.1.3. Eventos Condicionales

2.1.1.4. Eventos Disparadores (Trigger Events)

3. SPoF: Single Point of Failure

3.1. Un punto de fallo es cualquier item de configuración que puede causar un incidente cuando falla, y para el cual no se ha aplicado una contramedida.

3.1.1. Las contramedidas para el SPoF deben ser justificables en costo, y el impacto y la interrupción del servicio deben ser menores al costo de implementación de la medida.

3.1.2. El CFIA se puede utilizar para identificar el impacto potencial al negocio, al cliente o usuario y ayudar a determinar qué alternativas pueden o deben ser consideradas para atender esta debilidad en el diseño.

4. CFIA: Component Failure Impact Analysis

4.1. Se utiliza para predecir y evaluar el impacto en los servicios de TI derivado de los fallos de componentes de infraestructura. Los resultados del CFIA pueden ser utilizados para identificar el eslabón más débil (component failure) y considerar medidas correctivas.

4.1.1. Es una técnica desarrollada en 1970 basada en el diseño de hardware y su configuración, no obstante puede ser utilizada en un contexto más amplio.

4.1.1.1. Para realizar un CFIA se necesita: Crear una matriz con la infraestructura de TI necesaria, en las filas se colocan los items de configuración y en cada columna los servicios respectivos de TI. El siguiente paso es realizar la CFIA y rellenar la matriz de la siguiente manera: - Deje un espacio en blanco cuando un fallo del CI no afecta el servicio de ninguna manera - Introducir una "X" cuando el fallo del IC hace que el servicio de TI sea inoperante - Introducir una "A" cuando hay una alternativa a la prestación del servicio. - Introducir una "M" cuando hay una alternativa, pero se requiere intervención manual para recuperar

4.1.2. Algunos puntos importantes que toca: SPOF's que pueden impactar la disponibilidad El impacto del fallo de los componentes para el negocio Dependencias de los componentes Tiempo de Recuperación

5. VBF: Vital Business Function

5.1. Refleja la parte de un proceso de negocio que es fundamental para el éxito de la organización. Utiliza los siguientes conceptos para disponibilidad

5.1.1. Continuous Availability

5.1.1.1. Es un enfoque que pretende lograr el 100% de disponibilidad.

5.1.2. Fault Tolerance

5.1.2.1. Se refiere a la habilidad del servicio para continuar operando correctamente después de una falla.

5.1.3. High Availability

5.1.3.1. Es una característica del servicio que busca minimizar los efectos de una falla de los componentes ante los usuarios.

5.1.4. Continuous Operation

5.1.4.1. Busca eliminar o disminuir el downtime planeado de un servicio.