ITIL-es » utilidades http://itil-es.es ITIL a la Española, tecnología, servicios IT, seguridad, y cualquier cosa que me llame la atención Wed, 28 Apr 2010 15:15:43 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 CFIA o de cómo meter el pie en Gestión del a Disponibilidad y la Continuidad sin despeinarse http://itil-es.es/2010/01/20/cfia-o-de-como-meter-el-pie-en-gestion-del-a-disponibilidad-y-la-continuidad-sin-despeinarse/ http://itil-es.es/2010/01/20/cfia-o-de-como-meter-el-pie-en-gestion-del-a-disponibilidad-y-la-continuidad-sin-despeinarse/#comments Wed, 20 Jan 2010 08:41:52 +0000 jbanez http://metodico.wordpress.com/?p=77 A primera vista, es fácil ver que el Análisis de Impacto de Fallo de Componente (sus siglas en inglés son CFIA: Component Failure Impact Analysis) está relacionada de algún modo con los procesos de Gestión de Problemas y de Disponibilidad, pero sigue siendo un concepto algo difuso para la mayoría. Aunque CFIA suena guay y suena grande, es simplemente una forma de evaluar (y predecir) el impacto de fallos y caídas, y tambien ayuda a la localización de puntos únicos de fallo. Y todo lo que hace falta para hacer ese análisis es una hoja de Excel (o algo aún mejor…). Nada de sumar al pack de herramientas de gestión otra aplicación carísima.

El CFIA permite:

  • Identificar items de configuración (CI) que pueden provocar un corte de servicio
  • Localizar CIs que no están redundados o que por lo menos no tienen un backup
  • Evaluar el riesgo de fallo de cada CI
  • Justificar la demanda de inversiones
  • Colabora en la creación y mantenimiento de la CMDB.

Los 3 pasos clave para realizar el CFIA con éxito serían:

1. Seleccionar un servicio TI, obtener la lista de CIs que lo conforman; si tenemos la suerte de tener Gestión de la Configuración, lo obtendremos de ahí, si no… toca recopilar la documentación que tenga el departamento de sistemas y sonsacarle lo que podamos a los administradores: tirar de inventarios, de documentos, de manuales de explotación y de lo que se tenga a mano. O sea, lo de siempre.
2. En una hoja de Excel (o en un folio, o en cualquier papel), listar en la primera fila los servicios que estemos considerando y en una columna los CI que los componen; después, para cada CI bajo cada servicio:
  • Marca una “X” si un fallo del CI provoca una parada de servicio
  • Marca una “A” si el CI tiene backup inmediato (el backup entra en acción inmediatamente tras un fallo del CI)
  • Marca una “B” si el CI tiene backup intermedio (requiere una intervención para activar el backup y supone un corte en el servicio, aunque sea breve).

    Con esto, se consigue una matriz básica de CFIA. Cada “X” y cada “B” representa una vulnerabilidad potencial, y el último paso, será generar una petición de cambio (RfC) para erradicarlas:

3. Evaluamos las “X” y las “B” de la matriz; las podemos analizar con preguntas del tipo
  • Es este CI un punto único de fallo?
  • Qué impacto tiene para el cliente/para el negocio el fallo de este CI? A cuántos usuarios afectará? Cuál será el coste para el negocio?
  • Cuál es la probabilidad de fallo? Qué puede cambiarse para evitar ese impacto?
  • Podría prevenirse ese impacto realizando algún cambio de diseño? Sería conveniente dotar ese CI de redundancia o hacerlo más robusto? Y en tal caso, cuánto costaría?

Realmente, es un método sencillo y muy resultón para empujar al departamento de TI a meter el pie en Gestión de la Disponibilidad, que no es uno de los procesos más populares ahora mismo; de paso, lo que me pregunto es si podría expandirse la matriz para incluir los procedimientos o instrucciones de trabajo de recuperación de fallo de esos CI, quizás añadiendolo como una fila en la parte inferior de la matriz CFIA, aunque esto requiere primero que el departamento de TI sea lo suficientemente maduro como para tener todo eso por escrito (voy a dar por hecho que sí; en caso contrario, no tiene ningún sentido plantearse ni CFIA ni disponibilidades sin tener lo más básico listo: algo de documentación).

Añadir la documentación a la matriz CFIA podría usarse para evaluar tanto la organización como la infrastructura, analizandolo con preguntas tipo:

  • Cómo se responde cuando ese CI falla?
  • Qué procedimientos se siguen? ¿Están documentados esos procedimientos?
  • ¿Se pueden mejorar esos procedimientos? ¿Se pueden automatizar?
  • ¿Se podrían mejorar los procedimientos formando al personal o usando nuevas técnicas o herramientas?
  • ¿Se podría haber evitado el problema efectuando mantenimientos preventivos?

Si se logara la ejecución metódica y exhaustiva de análisis de impacto de fallo de componentes a todos los niveles (a nivel de infrastructura y de la organización), se generarán RfCs que aporten mejoras reales al negocio pero sin requerir un elevado nivel de madurez en los procesos ni derrochar en software de soporte. Tambien aporta beneficios al departamento TI, porque además de poner un primer pie en Gestión de la Disponibilidad tambien significa meter la cabeza en Gestión de la Continuidad; los datos obtenidos en la preparación de la matriz CFIA sirve como input para Gestión de la Configuración, sobretodo si se añade la documentación de recuperación, que puede aprovechar ese conocimiento para la CMDB. Y por supuesto, Gestión de Incidencias, que usará esos procedimientos de recuperación, y Gestión de Problemas, que recibirá como input el resultado de los análisis efectuados.

]]> http://itil-es.es/2010/01/20/cfia-o-de-como-meter-el-pie-en-gestion-del-a-disponibilidad-y-la-continuidad-sin-despeinarse/feed/ 4