Sistemas de Información en la

Tema Empresa

6 Practicas de Gestión de Servicio (III)

Prof. Mary Luz Mouronte López

Grado en Ingeniería Informática

Escuela Politécnica Superior
Índice

• Introducción
• Monitorización y gestión de eventos.
• Gestión de problemas.
• Gestión de versiones.
• Aspectos humanísticos.

2
Introducción
• Hay 17 prácticas de gestión
del servicio:
– Gestión de disponibilidad
– Análisis de negocio
– Gestión de capacidad y
rendimiento
– Control del cambio
– Gestión de incidencias
– Gestión de activos de TI
– Monitorización y gestión de
eventos
– Gestión de problemas
– Gestión de versiones
– Mesa de servicio
– Gestión del nivel de servicio
– Gestión de solicitudes de servicio
– Gestión de la configuración del
servicio
– Gestión de continuidad del
servicio
– Gestión del catálogo de servicios
– Diseño del servicio
– Validación y pruebas de servicio
3
Monitorización y Gestión de
Eventos

Grado en Ingeniería Informática

Escuela Politécnica Superior
Propósito
• Su propósito es observar sistemáticamente los servicios o
componentes de servicio, y registrar y reportar los cambios de
estado identificados como eventos.
• Gestiona los eventos a través de su ciclo de vida para prevenir,
minimizar, o eliminar su impacto negativo sobre el negocio.
• Esta práctica identifica y prioriza los eventos de infraestructura,
servicios, procesos comerciales así como de seguridad de la
información, y establece la respuesta adecuada a los mismos,
incluida la respuesta a condiciones que podrían conducir a fallos
potenciales o incidencias.

5
Definiciones
• Evento
– Un evento puede ser definido como cualquier cambio de estado
que tenga importancia para la gestión de un servicio TI o
elemento de configuración (CI) . Normalmente son notificaciones
creadas por un servicio de TI, CI o una herramienta de
monitorización.
• Alerta
– Advertencia de que se ha superado un umbral, de que algo ha
cambiado o de que hubo un fallo. A menudo las alertas se crean
y gestionan con herramientas de gestión de sistemas y son
administradas por el proceso de gestión de eventos

6
Definiciones (Cont.)
• Informativos Eventos que indican funcionamiento normal
– Se ha completado una carga de trabajo programada.
– Se ha entregado un email a su destinatario.
– Un usuario ha accedido a utilizar una aplicación
• Advertencia Eventos que significan una operación inusual, pero no
excepcional
– La utilización de memoria de un servidor llega al 5% de su nivel de
rendimiento más alto aceptable.
– El tiempo de realización de una transacción es un 10% superior a lo
normal
• Excepción - Eventos que significan una excepción respecto del
funcionamiento normal
– Un usuario intenta iniciar sesión en una aplicación con la contraseña
incorrecta
– Una situación inusual en un proceso de negocio, puede indicar
excepción y necesitar una mayor investigación

7
Objetivos
• Detectar cambios de estado que tengan significado para la gestión
de los CI y servicios de TI.
• Determinar la acción de control apropiada para el evento y
asegurar que son comunicados a las funciones apropiadas.
• Proporcionar disparadores, o puntos de entrada para la ejecución
de muchos de los procesos de operación del servicio y las
actividades de gestión de operaciones.
• Proporcionar medios para comparar el rendimiento operativo real a
los estándares y los SLA.
• Proporcionar una base para la garantía de servicio y presentación
de informes y la mejora del servicio.

8
Objetivos
• La parte de monitorización de la práctica pone foco en la
observación sistemática de los servicios y los CIs que apuntalan los
servicios para detectar condiciones de significancia potencial. La
monitorización debe ser ejecutada de manera automatizada, y
puede ser realizada activamente o pasivamente.
• La parte de gestión de eventos, pone foco en registrar y gestionar
esos cambios de estado monitorizados que son definidos por la
organización como un evento, determinando su significado e
identificando e iniciando la acción de control correcta para
gestionarlos. Frecuentemente, la acción de control correcta será
iniciar otra práctica, pero algunas veces no se tomará otra acción
que seguir monitorizando.

9
Objetivos
• No todos los eventos tienen la misma significancia o requieren la
misma respuesta.
• Los procesos y procedimientos precisos en la práctica de gestión de
eventos deben abordar las siguientes actividades clave, entre otras:
– Identificar que servicios, sistemas, CI u otros componentes de
servicio deberían ser monitorizados y establecer la estrategia de
monitorización.
– Implementar y mantener la monitorización, haciendo uso de
características de monitorización nativas de los elementos que
están siendo observados así como de herramientas de
monitorización diseñadas expresamente.

10
Objetivos
– Establecer y mantener umbrales y otros criterios para determinar que cambios
de estado serán tratados como eventos, y elegir criterios para definir cada tipo
de evento (informacional, aviso, excepción).
– Establecer y mantener políticas de como cada tipo de evento debe ser
manejado para asegurar la gestión apropiada.
– Implementar los procesos y automatizaciones requeridas para para poner en
operación los umbrales, criterios y políticas definidas.
• Esta práctica es altamente interactiva con otras prácticas que
participan en la cadena de valor de servicio.

11
Objetivos
• Aunque el trabajo de esta práctica, una vez puesta en operación,
está altamente automatizada, la intervención humana es todavía
requerida, y es de hecho esencial. Para la definición de estrategias
de monitorización y especificación de umbrales y criterios de
evaluación.
• Las organizaciones y las personas son también críticas para
suministrar una apropiada respuesta a los datos y eventos
monitorizados, en alineación con las prioridades y políticas de la
organización.
– Roles y responsabilidades deben ser claramente definidos, y cada persona
debe tener fácil, acceso puntual a la información necesaria para ejecutar su rol.

12
Objetivos
• La automatización es clave para la práctica de gestión de eventos y
monitorización.
• Algunos componentes de servicio vienen equipados con
capacidades de monitorización y reporte que pueden ser
configurados, para cumplir con las necesidades de la práctica, pero
a veces es necesario implementar y configurar herramientas de
monitorización a propósito.
• La monitorización puede ser activa o pasiva. En la monitorización
activa las herramientas hacen poll a los CI clave, buscando su
estado para generar alertas cuando se identifica una condición de
excepción. En la monitorización pasiva, el CI en si mismo genera las
alertas operacionales.

13
Objetivos

• Las herramientas automáticas deben ser también

utilizadas para la correlación de eventos.
• Hay un gran volumen de datos generados por esta
práctica, pero sin políticas claras y estrategias sobre
como limitar, filtrar y usar estos datos, esto no tendrá
valor.

14
Gestión de Eventos-Actividades Cadena Valor del Servicio

• Mejora: la práctica de monitorización y gestión de eventos es

esencial para la observación próxima del ambiente para evaluar y
proactivamente mejorar su salud y estabilidad.
• Compromiso: la gestión de monitorización y eventos puede ser la
fuente de compromiso interno para acciones.
• Diseño y transición: la monitorización de datos es información útil a
las decisiones de diseño. La monitorización constituye un
componente esencial de transición: suministra información sobre el
éxito de la transición en todos los entornos.
• Obtener/Construir: la monitorización y gestión de eventos soporta
los entornos de desarrollo, asegurando su transparencia y gestión.
• Entrega y soporte: guía como la organización gestiona el soporte
interno de eventos identificados, iniciando otras prácticas cuando
sean necesarias.

15
Gestión de Problemas

Grado en Ingeniería Informática

Escuela Politécnica Superior
Propósito
• Reducir la probabilidad e impacto de incidencias identificando las
causas reales y potenciales de incidencias, y gestionando
workarounds y errores conocidos.

17
Definiciones
• Problema: causa, o causa potencial, de una o más incidencias.
• Errores conocidos: problema que ha sido analizado pero no ha sido
resuelto.
• Workaround: solución que reduce o elimina el impacto de una incidencia o
problema para la cual una solución definitiva no está todavía disponible.
Algunos workaround reducen la probabilidad de incidencias,
• Gestión reactiva de problemas: se refiere a la solución de problemas como
respuesta a uno o mas incidencias
• Gestión proactiva de problemas: se refiere a identificar y solucionar
problemas y errores conocidos antes de que los incidencias relacionadas
con ellas puedan producirse
• Modelo de Problema: forma predefinida de tratar con problemas ya
conocidos
Los problemas son la causa de incidencias recurrentes pero, a veces se
toma la decisión de no aplicar la solución (por ejemplo, porque es muy
costosa) y de “convivir” con ellos, tratándolos a través de modelos
definidos.

18
Objetivos

• Minimizar el impacto adverso de incidencias y problemas

sobre el negocio, los cuales son causados por errores
subyacentes a la infraestructura de TI, previniendo
proactivamente incidencias y problemas relacionados con
ellos.
• Identificar la causa raíz de las incidencias, documentar y
comunicar errores conocidos e iniciar acciones para mejorar o
corregir la situación.
• Prevenir los problemas e incidencias.
• Eliminar incidencias recurrentes.
• Minimizar el impacto de incidencias y problemas que no puedan
ser prevenidos.

19
Descripción
• Cualquier servicio tiene errores, defectos o vulnerabilidades.
Pueden incluir errores en cualquiera de las cuatro dimensiones de la
gestión del servicio.
• Muchos errores son identificados antes de que un servicio pase a
producción. Sin embargo, algunos permanecen sin identificar o sin
resolver, y pueden ser un riesgo para los vida del servicio.

20
Descripción (Cont.)
• Los problemas se relacionan con las incidencias, pero deben ser
distinguidos de ellos, pues son gestionados de un modo diferente.
– Los incidentes tienen un impacto sobre los usuarios o procesos
de negocio. y deben ser resuelto para que la actividad de
negocio normal pueda tener lugar.
– Los problemas son causa de incidencias. Requieren
investigación y análisis para identificar las causas, desarrollo de
workarounds, y recomendar soluciones a largo plazo. Esto
reduce el número e impacto de futuros incidentes.

21
Descripción (Cont.)

• La gestión de problemas, implica tres fases

distintas:
Identificación Control del Control de
1

3
de problema problema errores

22
Descripción (Cont.)
• La identificación de problemas identifica y registra los problemas:
– Ejecutar análisis de tendencias de los registros de incidencias.
– Detección de duplicados y asuntos recurrentes por usuarios,
service desk, y personal de soporte técnico.
– Durante la gestión de las incidencias mayores, identificar el
riesgo de que una incidencia pueda volver a ocurrir.
– Análisis de la información recibida de proveedores y socios,
– Analizar la información recibida de los desarrolladores de
software internos, equipos de pruebas y equipos de proyecto.
– Otras fuentes de información.

23
Descripción (Cont.)
• Las actividades de control de problemas incluye análisis de
problema, y documentar workarrounds y errores conocidos.
• Los problemas son priorizados para análisis basados en el riesgo
que pueden suponer, y son gestionados como riesgos basados en
su impacto potencial y probabilidad.
• No es esencial analizar cada problema, tiene más valor hacer
problemas significativos en el progreso de los problemas con
prioridad más alta que investigar cada problema menor del que la
organización es consciente.

24
Descripción (Cont.)
• Las incidencias típicamente tienen muchas causas
interrelacionadas, y las relaciones entre ellas pueden ser complejas.
La gestión de problemas debe considerar todas las causas
contribuidoras, incluyendo las causas que contribuyen a la dirección
e impacto de las incidencias, así como aquello que conduce a que
las incidencias sucedan.
• Los problemas deben analizarse desde la perspectiva de las cuatro
dimensiones de gestión de servicio.
• Cuando un problema no puede ser resuelto rápidamente, es útil
encontrar y documentar un workaround para futuras incidencias,
basads en el entendimiento del problema.

25
Descripción (Cont.)
• Los workaround son documentados en registro de problemas. Esto
puede ser realizado en cualquier fase, no es necesario esperar a
que el análisis sea completado. Si un workarond ha sido
documentado prontamente en el control de problema, entonces esto
debería ser revisado y mejorado después de que el análisis de
problemas haya sido completado.
• Un workaround de incidencias efectivo puede ser un modo de tratar
con algunos problemas cuando la solución del problema no es
viable o tiene un coste elevado.
• Cada workaround documentado debe incluir una definición clara de
los síntomas a los cuales aplica. En algunas casos, la aplicación de
workaround puede ser automatizado.

26
Descripción (Cont.)
• Para otros problemas, un modo de arreglar los errores debe ser
encontrado. Esto es una parte del control de errores.
• Las actividades de control de errores gestionan errores conocidos,
los cuales son problemas donde el análisis ha sido completado, esto
siempre significa que los componentes fallidos han sido
identificados.
• El control de errores también incluye la identificación de soluciones
permanentes potenciales las cuales pueden resultar en una
solicitud de cambio para implementación de la solución, pero solo si
esto puede ser justificado en términos de costes, riesgos, y
beneficios.

27
Descripción (Cont.)
• El control de errores reevalúa el estado de errores conocidos que
no han sido resueltos, incluyendo el impacto completo sobre los
clientes , disponibilidad y costes de las soluciones permanentes y
efectividad de workarounds.
• La efectividad de workarounds debe ser evaluada cada vez que un
workaround es utilizado, y como un workaround puede ser mejorado
cada vez que es utilizado.
• La gestión de problemas son muy próximas a la de gestión de
incidencias. Las prácticas necesitan ser diseñadas para trabajar
juntas dentro de la cadena valor.

28
Descripción (Cont.)
• Muchas actividades de gestión de problemas dependen del
conocimiento y experiencia del personal, además de procedimientos
detallados de seguimiento.
• Las personas responsables del diagnóstico de problemas a menudo
necesitan habilidad para entender complejos sistemas, y pensar
sobre como los diferentes fallos podrían ocurrir. Desarrollar esta
habilidad creativa y analítica a menudo requiere mentorización y
tiempo, así como un adecuado entrenamiento.

29
Gestión de Problemas-Actividades Cadena Valor

• Mejora: es el principal foco para la gestión de problemas. La gestión

efectiva de problemas suministra el entendimiento necesario para reducir el
número de incidencias y el impacto de aquellas incidencias que no puedan
ser prevenidas.
• Compromiso: los problemas que tienen un impacto significativo sobre el
servicio serán visibles a los clientes y usuarios. En algunos casos, los
clientes pueden desear estar implicados en la priorización de problemas.
Los estados y planes para gestionar los problemas deberán ser
comunicados. Los workaround son a menudo presentados a los usuarios a
través del portal de servicio.
• Diseño y Transición: la gestión de problemas solicita información que ayuda
a mejorar las pruebas y la transferencia del conocimiento.
• Obtener/Construir: los defectos de un producto pueden ser identificados a
través de la gestión de problemas, estos son, después gestionados como
parte de esta actividad de la cadena valor.

30
Gestión de Problemas-Actividades Cadena Valor
(Cont.)
• Entrega y Soporte: la gestión de problemas hace una contribución
significativa para prevenir la repetición de incidencias y soportar a
tiempo su resolución.

31
Gestión de Versiones

Grado en Ingeniería Informática

Escuela Politécnica Superior
Propósito
• Su propósito es hacer servicios nuevos o cambiar los existentes y
las características que estén disponibles para utilizar.

(DION Training, s.f. p. 41)

DION Training (s.f.) ITIL® 4 Foundation Study Guide. Recuperado el 15 de julio de 2020 de:
https://itil.diontraining.com/

33
Definiciones
• Versión: Una versión de un servicio u otro elemento de configuración , o un
conjunto de elementos de configuración, que está disponible para usar.
• Unidad de Entrega
– Parte de un servicio o infraestructura de TI que normalmente es liberado
de forma conjunta y de acuerdo a la política de versiones de la
organización
– El objetivo es decidir el contenido de la unidad de entrega más
apropiado para cada servicio en función de los recursos, riesgos,
complejidad, tiempo necesario para la implementación, etc.
– Ejemplos de unidades de entrega
1. PC de Sobremesa, incluyendo hardware, software, licencias,
documentación, etc.
2. Aplicación de Nóminas, incluyendo los procedimientos de
operaciones de TI y la formación del usuario.

34
Definiciones (Cont.)
• Paquete de Entregas
– Es una sola unidad de entrega o una colección estructurada de
unidades de entrega.
• Opciones comunes para el despliegue
– La opción seleccionada tendrá un impacto significativo en el
despliegue e implementación, así como los resultados de
negocio.
– Es importante comprender los patrones de actividad del negocio
y los perfiles de usuario en la planificación y diseño de la
entrega.
1. ‘Big bang’ vs fases
2. Push vs pull
3. Automatizado vs manual

35
Objetivos
• Definir y acordar planes de versiones y despliegues con clientes e
interesados.
• Crear y probar los paquetes de las versiones.
• Asegurar la integridad de los paquetes de las versión y sus componentes, y
que todos estos paquetes sean almacenados en la Definitive Media Library
(DML) y registrados correctamente en la Configuration Management
System (CMS).
• Desplegar los paquetes de las versiones desde la DML al entorno real.
• Asegurar que todos los paquetes de las versiones se puedan probar,
instalar, rastrear, verificados y si fuera necesario desinstalar o retirados.

36
Objetivos (Cont.)
• Asegurar que los cambios o nuevos servicios y sus
correspondientes sistemas, tecnología y organización, sean
capaces de desplegar la utilidad y garantía acordadas.
• Registrar y gestionar desviaciones, riesgos, y problemas
relacionados con los servicios nuevos o modificados y tomar las
medidas correctivas necesarias.
• Asegurar que hay transferencia de conocimiento que permita a
clientes y usuarios optimizar el uso del servicio y apoyar sus
actividades de negocio.

37
Descripción
• Una versión puede comprender muchos componentes de infraestructura y
aplicaciones que trabajan juntas para producir nuevas versiones o cambios
de funcionalidad. Puede también incluir documentación, entrenamiento
(para los usuarios o para el personal TI), adaptar procesos y herramientas,
y cualquier otro componente que sea requerido.
• El tamaño de las versiones es variable.
• Un plan de versiones especificará la combinación exacta de componentes
nuevos y cambiados para que estén disponibles, y la fecha prevista para
sus versiones.
• Un calendario de versiones se utiliza para documentar los tiempos de
versiones. Este calendario deber ser negociado y acordado con clientes y
otros interesados. Una revisión de la versión tras la implantación posibilita
aprender y mejorar, y ayuda a asegurar la satisfacción de los clientes.

38
Descripción (Cont.)
• En entornos DevOps/Agile puede existir una significativa actividad
de gestión de versiones tras el despliegue. En estos casos, el
software y la infraestructura son típicamente desplegados en
muchos pequeños incrementos, y la actividad de gestión de
versiones posibilita la nueva funcionalidad en un punto posterior.
Esto puede ser hecho en cada pequeño cambio.

39
Descripción (Cont.)
• La gestión de versiones es a menudo faseada, con versiones piloto,
estando disponibles para un pequeño número de usuarios para
asegurar que todas las cosas están trabajando correctamente antes
que la versión sea proporcionada a grupos adicionales. Este
enfoque faseado puede trabajar con ambas de las dos secuencias
mostradas en las figuras. Algunas veces una versión debe estar
disponible para todos los usuarios al mismo tiempo, cuando una
mayor reestructuración de los datos compartidos sea requerida.

40
Gestión de Versiones – Cadena Valor
• Planificar: políticas, guía, y cronograma para versiones son dirigidas por lla
estrategia organizacional y el portfolio de servicio. El tamaño, alcance y
contenido de cada versión debe ser planificada y gestionada.
• Mejorar: versiones nuevas o cambiadas pueden ser requeridas para entregar
mejoras , y éstas deben ser planificadas y gestionada del mismo modo que
cualquier otra versión.
• Compromiso: el contenido y cadencia de versiones debe ser diseñado para
unir las necesidades y expectativas de clientes y usuarios.
• Diseño y Transición: la gestión de versiones asegura que los servicios
nuevos o cambiados están disponibles para los usuarios de un modo
controlado.
• Obtener/Construir: los cambios a los componentes son normalmente
incluidos en una versión, entregado de un modo controlado.
• Entrega y soporte: las versiones pueden impactar sobre la liberación y
soporte. Formación, documentación, notas de versión, errores conocidos,
guías
(De de usuario,
Pablos, 2012,scripts de soporte, etc. Son suministrados por esta práctica
p. 143-145)
para facilitar la restauración del servicio.

41
Aspectos humanísticos
• Tomar conciencia de que, al realizar la gestión de un servicio según
estas prácticas ITIL se ponen en práctica capacidades que engloban
todas las dimensiones de la persona.
• Comprender el para qué de estas prácticas, cuál es el fin último que
busca y el bien que provee a la sociedad.
• En la ejecución de estas prácticas, debe atenderse, además y en
todo momento, a la vocación de servicio a los otros y al sentido de
su contribución al bien común

42
Aspectos humanísticos (Cont.)
• La ejecución de estas prácticas debe plasmarse de una manera
justa y eficaz, impulsando relaciones correctas con los equipos y las
personas que participan en ellas.
• En cuanto a las cuestiones éticas, en la ejecución de estas
prácticas, son relevantes los asuntos referentes al acceso y a la
distribución de la información.
• En la ejecución de esta prácticas están implicadas un gran número
de personas, es necesario buscar el modo de concienciar a todos
los participantes de las responsabilidades que poseen.

43
Bibliografía
• AXELOS (2019). ITIL Foundation. ITIL 4 Edition. London, United
Kingdom: TSO (The Stationery Office).
• DION Training (s.f.) ITIL® 4 Foundation Study Guide. Recuperado
el 15 de julio de 2020 de: https://itil.diontraining.com/

44