4. Gestión de problemas (2015)

Resumen Español
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Ingeniería Informática - 3º curso
Asignatura Models de qualitat en la Gestió de les TIC
Año del apunte 2015
Páginas 6
Fecha de subida 03/04/2016
Descargas 19
Subido por

Vista previa del texto

Gestión de problemas 1. Visión general Sus principales funciones son:  Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.
 Determinar posibles soluciones a las mismas.
 Proponer las peticiones de cambio (RFC) necesarias para restablecer calidad del servicio.
 Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.
Puede ser: - Reactiva: analiza incidentes ocurridos para descubrir causa y dar solución Proactiva: monotoriza la calidad de la infraestructura TI y analiza su configuración para prevenir incidentes.
2. Introducción y objetivos La Gestión de Problemas deberá determinar las causas y soluciones de las incidencias recurrentes o que tienen un fuerte impacto sobre la infraestructura TI.
- Problema: causa subyacente de una serie de incidentes/incidente aislado, no identificada.
- Error conocido: cuando se determinan las causas de un problema pasa a ser error conocido.
Las principales funciones de la Gestión de Problemas son: - Identificar, registrar, clasificar los problemas y proponer sus soluciones.
Dar soporte a Gestión de Incidentes proporcionando información y soluciones temporales o parches.
Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI.
Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.
- Realizar informes que documenten orígenes/soluciones a un problema y sirvan de soporte a la estructura TI en su conjunto.
Analizar tendencias para prevenir incidentes potenciales.
Los principales beneficios son:     Aumento calidad general de los servicios TI.
Se minimiza el número de incidentes.
Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI ahorrando recursos e innecesarios escalados.
La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad, Disponibilidad y Niveles de Servicio.
Las principales dificultades son:  Establecer estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y resolver los problemas.
 Mantener actualizadas las BD asociadas requiere un compromiso por parte de todos los agentes implicados  Aumento de los costes por la contratación de personal especializado 3. Proceso Las principales actividades de la Gestión de Problemas son: - Control de Problemas: registra y clasifica los problemas para determinar sus causas.
Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas a la Gestión de Cambios. Efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.
Si la estructura de la organización lo permita, desarrolla Gestión Problemas Proactiva para detectar problemas antes de que se manifiesten (por deterioro, por ejemplo).
3.1 Control de problemas Control de problemas: su objetivo es conseguir que se conviertan en errores conocidas.
Se compone de tres fases: Identificación y riesgo: Identificar los problemas a través de diferentes fuentes de información: - BD de Incidentes: analizar su el incidente producido es aislado o su impacto en la estructura antes de elevarlo a categoría de problema.
Análisis de la infraestructura TI: analizar procesos y determinar los aspectos de los sistemas y estructura TI que hay que reforzar para evitar problemas.
Deterioro de los niveles de servicio.
El registro de problemas es similar al de los incidentes aunque el énfasis debe hacerse en la naturaleza y posible impacto del incidente. Debe incorporar información cómo: - Los CIs implicados.
Causas del problema y soluciones temporales Síntomas asociados.
Servicios involucrados.
Niveles de prioridad, urgencia e impacto.
Estado: activo, error conocido, cerrado.
Clasificación y Asignación de Recursos: Engloba cualquier tipo de característica (si es HW/SW, áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo).
La determinación de la prioridad del problema es básica. Se determina a partir de la urgencia (demora aceptable para la solución del problema) y su impacto (grado de deterioro de la calidad del servicio). La prioridad podrá variar a lo largo del curso del ciclo de vida. Cuando se ha determinado, se asignarán recursos necesarios para solucionarlo eficazmente.
Análisis y Diagnóstico: Error conocido: Los objetivos principales del proceso de análisis son determinar las causas del problema y proponer soluciones temporales para minimizar el impacto del problema.
El origen del problema no siempre será por un error de HW/SW ya que puede ser causado por una documentación incorrecta, falta coordinación entre varias áreas, errores de procedimiento, un bug conocido de una aplicación utilizada,.. Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.
3.2 Control de errores Identificación y Registro de errores: Cada error conocido debe llevar asociada una solución temporal para minimizar el impacto de los incidentes asociados.
Análisis y Solución: Se deben investigar diferentes soluciones para el error evaluando en cada momento: - El posible impacto de las mismas en la infraestructura TI.
Los costes asociados.
Sus consecuencias sobre los SLAs.
Si el impacto puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios, si no, antes hay que tener en cuenta varias consideraciones cómo si es conveniente demorar la solución, si la solución temporal aportada es suficiente para mantener unos niveles de calidad de servicios aceptable y si los beneficios justifican los costes asociados.
Toda la información del error y su solución deberán registrarse en BD asociadas. Y si se considera que el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos.
Revisión Post Implementación y Cierre: Se analiza el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR) antes de dar el problema por resuelto y cambiar su estado a “cerrado”. Si todo es lo deseado, se cierran los incidentes relacionados, se concluye el proceso y se emiten los informes correspondientes.
4. Control del Proceso En particular una buena gestión de problemas debe traducirse en una: - Disminución número de incidentes y su rápida resolución Mayor eficacia en la resolución de problemas.
Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información de vital importancia a otras áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:    Informes de Rendimiento de la Gestión de Problemas: detallando número de errores resueltos, eficacia de las soluciones propuestas e impacto en la Gestión de Incidentes.
Informes de Gestión Proactiva: detallando acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.
Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc.
Determinar quién son los responsables de cada proceso es básico para una eficaz Gestión de Problemas, aunque en el caso de pequeñas organizaciones no es recomendable para evitar costes asociados.
5. Caso Práctico El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio. La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido (usando modelo de Kepner y Tregoe): - Identificación del problema.
Clasificación del problema.
Establecimiento de las posibles causas.
Comprobación de la causa más probable.
Verificación de la causa verdadera.
Identificación: aplicación de pedidos online muestra errores en el registro de ciertos pedidos, sin que este error parezca tener correlación con otros componentes de hardware / software.
Clasificación: - Identificación: Problemas en el registro de pedidos.
Origen: Módulo de pedidos online.
Frecuencia: el problema no es recurrente, es la primera vez que se detecta.
Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio.
Posibles causas: Errores en la programación del lado cliente de la aplicación o en los módulos de registro del servidor web o en la configuración de la base de datos. Analistas deciden cuál es el más probable.
Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes se intenta reproducir el problema, se comprueba que el error sólo se reproduce con una determinada marca de helados y que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas.
Verificación: Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción. Se introducen las modificaciones necesarias en la programación y se comprueba el correcto registro del pedido.
El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores. Eleva una RFC con la solución propuesta y lleva a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.
...