ITIL

Gestión de Servicios Informáticos
75 46 - Administración
75.46
Ad i i t ió y Control
C t l de
d P
Proyectos
t II
Lic. Sergio G. Martínez
Retomando…
El concepto de servicio
Cliente
Lavadero
Transporte
Lavadero Industrial
P i por ell S
Precio
Servicio
i i
Mismo día：\500
\
Día Siguiente：\300
En 4 H ： \
\50
En 2 H ： \100
En 4 H ： \
\50
En 2 H ： \100
SLA
SLO
La Gestión del Servicio
El concepto de servicio
y
Los servicios son los medios para entregar valor a los
clientes, facilitando sus tareas para obtener resultados, sin
que los ellos deban asumir los costos específicos ni los riesgos
asociados.
y
Los proveedores de servicios asumen los riesgos y asignan
costos a cada cliente por los servicios que ellos proveen.
y
Los resultados se logran a través de la ejecución de tareas y
están limitados por la presencia de ciertas restricciones.
y
Los servicios facilitan la obtención de resultados por medio
del aumento del rendimiento de las tareas asociadas y la
reducción de los efectos de las restricciones.
y
El resultado es el incremento de la probabilidad de obtener
los resultados deseados.
Negocio
Servicio de IT
Servicio de IT
C
Cliente
e de IT
T
etc.
Routters
Aplicaciones
A
Servidorres
Basees de Daatos
Visión tradicional del Servicio Informáticos
Tendemos a organizarnos de esta forma…
Desarrollo de
Aplicaciones
Tecnología
Operaciones
Objetivos y
Prioridades
Objetivos y
Prioridades
Objetivos y
Prioridades
Pero los clientes nos ven así…
Pero los clientes nos ven así…
•
•
•
•
•
Disponibilidad
P f
Performance
Seguridad
Soporte
Etc.
Organización
Se
ervice Lev
vel
Managemen
nt
Problem
Managemen
nt
Incident
Managemen
nt
Co
onfiguratio
on
Managemen
nt
Change
Managemen
nt
Servicio de IT
Servicio de IT
Clientee de IT
C
T
etc.
Routters
Aplicaciones
A
Servidorres
Basees de Daatos
Nueva visión del Servicio Informáticos
Negocio
Tradicional
Gestión de Servicios Informáticos
y
Foco en Tecnología
y
Foco en el Negocio
y
Administrar Infraestructura
y
Proveer Servicios
y
Us ari s
Usuarios
y
Clientes
y
Modalidad “Bombero”
y
Prevención y Control
y
Reactivo
y
Proactivo
y
Islas
y
Integrado
y
Caos y arbitrariedad
y
Estabilidad y Confiabilidad
y
Decisiones ad-hoc y personales
y
Decisiones informadas y repetibles
y
Procesos informales
y
Estandarización y mejores
prácticas
Visiones de TI
Gestión de Servicios Informáticos
15%
Tecnología: Herramientas e
infraestructura
Procesos: Definición, diseño,
estándares, mejora continua.
85%
Gente: Roles y
responsabilidades,
administración desarrollo de
administración,
habilidades y disciplinas.
Cultura: Valores, normas tácitas,
experiencia.
ITIL
y
Information Technology Infrastructure Library
y
Biblioteca sobre:
◦ Provisión de Servicios basados en IT
◦ Gestión de la Infraestructura de IT
y
Generados por OGC, recolectando la experiencia de
l referentes
los
f
de
d mercado.
d
ITIL
y
Mejores Prácticas (no metodología)
y
Lineamientos (no recetas)
y
Debe ser adaptado a cada caso:
◦ ¿Qué procesos son críticos en mi caso?
◦ ¿Cómo implemento en concreto cada proceso? (procedimientos,
d fi i ió d
definición
de responsabilidades
bilid d y autoridades,
id d hherramientas)
i
)
¿Qué no es ITIL?
y
Una herramienta de Software.
y
La solución que un proveedor quiere imponer.
y
Un conjunto de procedimientos a cumplir/seguir.
y
El reemplazo de todo lo que ya hacemos bien.
y
El único componente requerido para brindar un
mejor servicio.
y
Independiente del comportamiento y cultura de la
organización.
organización
y
La solución a todos nuestros males (La bala de
plata).
El modelo ITIL
y
ITIL V3 está compuesto por las siguientes cinco
publicaciones:
bli i
1.
Service Strategy
2
2.
S i Design
Service
D i
3.
Service Transition
4
4.
Service Operation
5.
Continual Service Improvement
La Gestión del Servicio
El concepto de Gestión del Servicio
y
La Gestión del Servicio es un conjunto de
habilidades organizacionales especializadas para
proveer valor a los clientes en la forma de
servicios.
y
Las habilidades toman la forma de funciones y
procesos para gestionar los servicios a través de
un ciclo de vida, con especializaciones
p
en:
1. Estrategia
2. Diseño
3. Transición
4. Operación
5 Mejora
5.
M j
continua
ti
Procesos de:
• Transición
• Operación
Gestión de Servicios Informáticos
CENTRO DE SERVICIOS AL
USUARIO
Objetivo
y
Proveer un punto único de contacto (SPOC) para los
clientes
li
y
Centralizar la gestión de la resolución de incidentes
Alcance
y
Restablecer la operación del servicio lo más rápido posible.
y
Registrar todos los incidentes/solicitudes.
y
Proveer un primer nivel de soporte y diagnóstico.
y
Proveer un primer nivel de solución cuando fuese posible.
y
Mantener informados a los usuarios del progreso de sus
casos.
y
Llevar a cabo las encuestas de satisfacción de los usuarios.
y
Cerrar incidentes y solicitudes.
s licit des
y
Actualizar la CMS.
Actividades
y
Clasificar, asignar, realizar diagnóstico inicial, priorizar y
escalar
l a quien
i corresponda
d ell incidente
i id
y
Facilitar la rápida recuperación de los servicios
y
Ofrecer orientación a los usuarios
y
Promover el servicio mediante comunicaciones
y
Proveer información de gestión (tiempo resolución,
incidentes que resultaron ser RFC, cambios planificación
para el próximo período,
período etc
etc.))
Estructuras organizativas
y
Local
y
Centralizado
y
Virtual
y
Siguiendo al Sol
Local
Usuario Local
Usuario Local
Usuario Local
Usuario Local
Service Desk
Local
Gestión Técnica
Gestión de
Aplicaciones
p
Gestión de
Operaciones de TI
Soporte de
terceros
Gestión de
Requerimientos
q
Local
y
Diseñado para soportar las necesidades locales del
negocio.
i
y
El soporte se encuentra y brinda usualmente en la
misma localidad que está siendo soportada.
soportada
y
Es práctico para pequeñas organizaciones.
y
EEs iimpráctico
á ti para organizaciones
i i
dispersas
di
geográficamente.
Service Desk centralizado
Sede Cliente 1
Sede Cliente 2
Sede Cliente 3
Service Desk
Segunda línea
Gestión Técnica
Gestión de
Aplicaciones
Gestión de
Operaciones de TI
Soporte de
terceros
Gestión de
Requerimientos
Service Desk centralizado
y
Se centraliza la atención de varios centros geográficos
di i
distintos
en un Service
S i Desk
D k central.l
y
Puede requerirse soporte en forma presencial, pero
esto debe ser manejado y administrado desde el Service
Desk.
y
Ventajas para las grandes organizaciones:
◦ Reduce los costos operacionales.
◦ Una vista ggerencial central consolidada.
◦ Mejora el uso de los recursos.
Service Desk virtual
San Francisco
Service Desk
Rio de Janeiro
Service Desk
Paris
Service Desk
Virtual
Service Desk
Sydney
Service Desk
Beijing
Service Desk
Sistema de Gestión
de los Servicios de
Conocimiento
London
Service Desk
Service Desk virtual
y
La ubicación de los analistas del SD es transparente al
usuario.
i
y
Puede incluir elementos de tele-trabajo.
y
Deben existir procesos y procedimientos comunes – un
solo registro de incidentes.
y
L
Lenguaje
j común
ú acordado
d d para la
l entrada
t d de
d datos.
d t
y
Punto único de contacto con el cliente.
y
Puede seguir requiriéndose presencia on-site para
algunos puntos.
Siguiendo al Sol
y
Permite brindar una cobertura de servicio total,
b á d
basándose
en los
l husos
h
horarios
h
i de
d las
l distintas
di i
regiones geográficas desde donde se da servicio.
y
Se debe considerar en este caso
caso, especial atención
sobre las herramientas, procesos e idioma a utilizar por
las distintas regiones.
Grupos de Service Desk especializados
y
En algunos casos es recomendable crear grupos de
especialistas
i li
dentro
d
de
d lla ffunción
ió de
d Service
S i Desk.
D k
y
Esto permitirá derivar los incidentes según el tipo de
especialista que pueda resolverlos.
resolverlos
Recomendaciones
y
Recomendaciones de ambientación:
◦ Luz natural y suficiente espacio físico.
◦ Control acústico del ambiente.
◦ Área de esparcimiento o break.
y
Recomendaciones para facilitar el contacto único:
◦ Hacer público el número telefónico del Service Desk.
◦ Adhesivos informando el número en los teléfonos.
◦ U
Utilización
l
ó de
d salvapantallas
l
ll con datos
d
de
d contacto del
d l Service
S
Desk.
◦ Incorporar
p
merchandisingg con el número de contacto.
Gestión de Servicios Informáticos
GESTIÓN DE INCIDENTES
Objetivos
y
Restaurar la operación normal del servicio afectado lo
más
á rápido
á id posible,
ibl minimizando
i i i d ell impacto
i
en ell
negocio y asegurando que se mantengan los niveles
acordados de calidad y disponibilidad.
p
y
Se entiende por operación normal del servicio a lo que
se haya definido dentro de los límites del SLA.
Alcance
y
Abarca cualquier evento que impacte, o pueda impactar,
a un servicio.
i i
y
Existen eventos de tipo informativo, para lo cual existe
un tratamiento especial en el proceso de Gestión de
Eventos.
y
Las Peticiones de Servicio (Service Request) serán
derivados al proceso específico correspondiente.
Incidente
y
Se refiere tanto a la interrupción no planificada de un
servicio
i i de
d TI como a la
l reducción
d ió en la
l calidad
lid d de
d éste.
é
y
También se consideran incidentes a aquellas fallas de
elementos de configuración que no hayan impactado
(todavía) a un servicio (Ej. la falla de un disco físico
correspondiente a un conjunto de discos espejados).
Modelos de incidentes
y
Son aquellos incidentes que pueden considerarse
repetitivos
ii
y para los
l cuales
l se crea un modelo
d l
predefinido de incidente. Se debe tener en cuenta:
◦ Los pasos a seguir en el incidente.
incidente
◦ El orden de estos pasos.
◦ Responsabilidades.
p
◦ Procedimientos de escalamiento.
◦ Líneas de tiempo.
Incidentes graves
y
Debe existir un proceso que se encargue del manejo de
i id
incidentes
graves.
y
La definición de qué es un Incidentes graves debe ser
realizada a nivel corporativo,
corporativo teniendo en cuenta los
criterios de priorización e impacto al negocio.
y
Un Incidente grave no es un problema.
y
Puede requerirse la utilización de un equipo de
investigación dedicado.
Actividades
y
Identificación
y
Registro
y
Categorización y priorización
y
Diagnóstico Inicial
y
Escalamiento
y
Investigación y diagnóstico
y
Resolución
eso uc ó y recuperación
ecupe ac ó
y
Cierre
Identificación
y
Puede ingresar en forma proactiva (monitoreo) o
reactiva
i (avisos
( i
d
dell usuario).
i )
Registro
y
Todos los incidentes deben ser registrados.
y
En caso de detectar un Incidente al resolver otro, se
debe abrir un nuevo registro.
y
Datos básicos a incluir en un registro de incidente:
◦ Número único de referencia
◦ Prioridad
◦ Fecha y hora de registro
◦ CI relacionado
◦ Categoría de cierre
◦ Método de call-back
◦ Estado
E d del
d l incidente
d
Categorización
y
Se debe definir correctamente la granularidad del árbol
d categorización.
de
i ió
y
Pasos para lograr el diseño de las categorías:
◦ Sesión de brainstorming entre los involucrados.
◦ Definición del nivel inicial.
◦ U
Utilización
ili ió d
de llas categorías
í iniciales
i i i l por un período
í d corto de
d
tiempo.
◦ Realizar un análisis de lo registrado.
◦ Implementar las revisiones.
◦ Repetir el punto 4.
Priorización
y
Normalmente la prioridad de un incidente se define en función de:
◦ La urgencia: Cuán rápido el negocio necesita una solución.
◦ El impacto: Generalmente medido con la cantidad de usuarios afectados por el
incidente.
y
Otros factores determinantes del nivel de impacto son:
◦ Riesgo de vida.
◦ Número de servicios afectados.
afectados
◦ Nivel de pérdidas financieras.
◦ Efectos en la imagen (reputación) del negocio.
◦ Violación de marcos legales o regulatorios.
y
Algunas organizaciones necesitarán definir una prioridad especial para
usuarios VIP (Gerentes,
(Gerentes Ejecutivos,
Ejecutivos Directores).
Directores)
Priorización
U
Urgencia
Código d
Códi
de
prioridad
1
2
3
4
5
Alto
Alta 1
M di 2
Media
Baja 3
Descripción
Críitica
Alta
Media
Baja
Planificada
Imapcto
p
Medio
Bajo
2
3
3
4
4
5
Tiempo d
Ti
de resolución
l ió
promedio
1 hora
8 horas
24 horas
48 horas
Planificada
Diagnóstico inicial
y
Se utiliza para esto los scripts de diagnóstico y la base de
datos de errores conocidos.
conocidos
y
En esta actividad se intentará resolver el incidente en un
primer nivel de atención.
y
Escalamiento:
◦ Funcional
◦ Jerárquico
J á
y
Investigación y diagnóstico:
◦ Entender el orden cronológico de eventos que causaron el
incidente.
◦ Búsquedas a la KEDB.
◦ Confirmar
C f
ell impacto del
d l incidente.
d
Resolución y recuperación
y
Involucra la resolución del incidente para lo cual se
pueden
d usar los
l siguientes
i i
métodos:
é d
◦ Realizarlo conjuntamente con el usuario.
◦ Resolverlo
R l l remotamente.
◦ Utilizando un grupo de soporte presencial.
◦ Contactando un proveedor externo.
externo
Cierre
y
Esta actividad será realizada siempre por el Service
D k
Desk.
y
El Service Desk deberá validar junto con el usuario el
cierre del incidente.
incidente También deberá verificar lo
siguiente:
◦ Categorización
g
de cierre.
◦ Encuesta de satisfacción.
◦ Documentación del incidente.
◦ Cierre formal.
Roles y responsabilidades
y
Administrador de Incidentes
◦ Promover la eficiencia y eficacia del proceso.
◦ Producir información de gestión.
◦ Administrar los recursos humanos.
◦ Monitoreo de la efectividad del proceso y recomendaciones de
mejora.
◦ Desarrollo y mantenimiento de los sistemas de la Gestión de
Incidentes.
◦ Administración de Incidentes Mayores.
◦ Desarrollo y mantenimiento del proceso de la Gestión de
Incidentes y sus procedimientos.
procedimientos
Roles y responsabilidades
y
Primera línea
◦ Atención inicial de incidentes
◦ Escalamiento
y
Segunda línea
◦ Grupo de soporte (puede ser soporte de campo).
◦ Mayor conocimiento técnico.
y
Tercera línea
◦ Incluye a los grupos de especialistas (Servers, bases de datos,
redes).
Gestión de Servicios Informáticos
GESTIÓN DE PROBLEMAS
Objetivos
y
Prevenir la ocurrencia de problemas e incidentes
asociados.
i d
y
Eliminar incidentes recurrentes.
y
Minimizar el impacto de incidentes que no pudieron ser
prevenidos.
Problema
y
Causa desconocida de uno o más Incidentes.
Impacto, urgencia y prioridad
y
Los problemas deben priorizarse utilizando los mismos
criterios
i i utilizados
ili d para llos IIncidentes
id
((matriz
i d
de
prioridades).
y
Se debe tener en cuenta lo siguiente:
◦ Frecuencia e impacto de incidentes relacionados.
◦ Definición sobre qué constituye un problema.
problema
◦ Incorporar el concepto de severidad del problema (costo,
tiempo de resolución, recursos).
Solución alternativa
y
En algunos casos puede ser encontrada una solución
alternativa
l
i a llos iincidentes
id
causados
d por ell problema.
bl
y
Es importante que aún así, se continúe con la
investigación de la causa raíz del problema.
problema
y
Siempre debe registrarse en la herramienta de gestión
el detalle de la solución alternativa encontrada.
Error conocido
y
Una vez que se complete el diagnóstico del problema y que
se haya encontrado una solución alternativa, se deberá
registrar en la KEDB el error conocido.
y
De esta manera, si surgen nuevos incidentes o problemas
relacionados,, éstos ppueden ser resueltos rápidamente.
p
y
También puede detectarse la necesidad de registrar un error
conocido en una fase previa al diagnóstico, a modo
informativo.
y
Identificación de errores conocidos
◦ La identificación y registro del error conocido debe llevarse a cabo
aún si todavía no se ha encontrado la solución definitiva del error,
proporcionando información de su existencia y/o posibles registros
de soluciones temporales de prueba.
◦ Para evitar la duplicación de registros, se recomienda centralizar la
administración
d i i t ió d
de la
l KEDB en un único
ú i responsable.
bl
Base de datos de errores conocidos
y
Permite el almacenamiento del conocimiento obtenido a
t é de
través
d la
l resolución
l ió de
d incidentes
i id t y problemas,
bl
para
permitir un rápido diagnóstico y solución en caso que
ocurran.
y
El registro de error conocido debe contener detalles exactos
de la falla y sus síntomas, además de datos precisos para la
solución (alternativa o definitiva) del problema.
y
Pueden existir casos donde se decida convivir con un
problema en la infraestructura de TI, cuando el caso de
negocio no justifique
f
la
l resolución.
l ó
y
Los datos incluidos en la KEDB debe ser fácilmente
accesibles.
accesibles
Roles y responsabilidades
y
Gestor de Problemas
y
Grupos de Resolución de Problemas
Gestión de Servicios Informáticos
GESTIÓN DE CAMBIOS
Gestión de Cambios
y
Objetivo:
◦ Mantener la Infraestructura bajo control
◦ Asegurar la aplicación de procedimientos estándares para la
atención de los cambios,
cambios de manera de minimizar el impacto en
los servicios.
Gestión de Cambios
y
Actividades:
◦ Aceptación (recepción y filtro inicial)
◦ Clasificación (menor, significativo, mayor, urgente)
◦ Aprobación y Planificación
◦ Seguimiento de la ejecución
◦ IInformación
f
ó de
d G
Gestión
ó ((cantidad
d d de
d Cambios
C b que no se
aceptaron, cambios OK, etc.)
Actividades
Crear RFC
Propuesta de
Cambios
(opcional)
Registrar el RFC
Solicitado
Revisar el RFC
G ió d
Gestión
dell Cambio
C bi
Listo para evaluación
Evaluar el cambio
Listo para decisión
Ordenes de Trabajo
Autorizar el
cambio
Autorizar la propuesta de
cambio
Change authority
Autorizado
Plan actualizado
Gestión del Cambio
Ordenes de Trabajo
Planificado
Coordinar la implementación
de Cambio*
Gestión del Cambio
Implementado
Reporte de evaluación
Revisar y cerrar el registro
de cambio
Cerrado
*Incluye construcción y prueba del cambio
Actualizar el caambio y la información de la congigguración en el CM
MS
Iniciador
Crear el RFC
y
El cambio es originado por pedido de un iniciador.
y
Para cambios mayores con implicaciones
organizacionales y/o financieras significativas, puede ser
requerida una propuesta de cambio (Change Proposal).
Proposal)
y
La propuesta de cambio contendrá una descripción
completa del cambio junto con una justificación
financiera y de negocio.
y
Los procedimientos para registrar y documentar los
cambios deben estar previamente definidos.
Crear el RFC
RFC
Número RFC
Iniciación
Motivo del Cambio
Descripción del Cambio
CI (atributos)
Análisis de Riesgo
e Impacto / Recursos
P i id d y Urgencia
Prioridad
U
i
Fecha y Hora de
Implementación
Recomendación del CAB
Implementación
Programada
I l
Implementador
t d d
dell
Cambio
Resultados del Cambio
Resutado de las Pruebas
Autorizado por
Fecha y Hora de
Aprobación
Revisión
Post-Implementación
Revisar el RFC
y
La Gestión de Cambios debe revisar cada uno de los
requerimientos
i i
y fil
filtrar llos que considera
id
que son:
◦ Imprácticos.
◦ R
Repetidos
id en otros RFC recientes
i
que fueron
f
aprobados,
b d
rechazados o continúan en revisión.
◦ Incompletos.
Evaluar el RFC
y
Debe evaluarse la implementación de cada cambio. Se
propone seguir
i ell método
é d d
de llas siete
i ‘R’ d
de lla G
Gestión
ió
del Cambio
◦ ¿Quién REQUIERE el cambio?
◦ ¿Cuál es la RAZÓN del cambio?
◦ ¿¿Cuál es el RETORNO esperado
p
del cambio?
◦ ¿Cuáles son los RIESGOS implicados en el cambio?
◦ ¿Cuáles son los RECURSOS necesarios para realizar el cambio?
◦ ¿Quién es RESPONSABLE de la construcción, prueba e
implementación del cambio?
◦ ¿Cuál
C ál es la
l RELACIÓN entre éste
é y otros cambios?
bi ?
Gestión del Cambio
Evaluar el RFC
y
Categorización de riesgos.
y
Evaluación de cambios.
y
Asignación de prioridad.
y
Planificación de cambios.
Coordinar la Implementación
y
Los especialistas técnicos deben construir el cambio.
y
Change Management tiene la responsabilidad de
asegurar que los cambios sean implementados tal como
fueron planificados.
planificados
y
Verificar los procedimientos de vuelta atrás
(Remediation Plan)
y
Change Management tiene un rol de control para
asegurar que todos los cambios hayan sido testeados.
Gestión del Cambio
Revisar y Cerrar el RFC
y
Es necesario realizar una revisión post-implementación
para confirmar
fi
◦ Que el cambio cumplió con sus objetivos.
◦ Q
Que ell iiniciador
i i d y los
l demás
d á iinteresados
d están
á conformes
f
con ell
resultado.
◦ Que no se han producido efectos colaterales.
Gestión del Cambio
Roles y responsabilidades
y
Administrador de Cambios
◦ Asigna prioridades a los RFC junto con el iniciador.
◦ Rechaza los RFC que son impracticables.
◦ Lista todos los RFC para ser revisados en las reuniones del
CAB.
◦ Elabora la agenda de la reunión y la envía con anticipación a
todos los miembros del CAB.
◦ Decide quiénes deben asistir a las reuniones, dependiendo de la
naturaleza del RFC,
RFC qué es lo que será modificado y qué áreas
de conocimiento técnico son necesarias.
Gestión del Cambio
Roles y responsabilidades
y
Administrador de Cambios
◦ Convoca las reuniones del Comité de Cambios / Comité de
Emergencia (CAB/EC : Change Advisory Board / Emergency
Committee) para los cambios urgentes.
◦ Preside todas las reuniones del CAB y del CAB/EC.
◦ Actualiza el registro del cambio.
◦ Revisa todos los cambios implementados.
◦ Cierra los RFC.
◦ Realiza reportes regulares de la gestión.
Gestión del Cambio
Roles y responsabilidades
y
Comité de Administración de Cambios
◦ El CAB es un cuerpo que existe para dar soporte en la
autorización de los cambios y en asistir en la evaluación y
priorización de los mismos.
◦ Reglamento del CAB
x Deben distribuirse los RFC con antelación a la reunión.
x Responder y realizar el análisis de los RFC (mandatorio).
x Concurrir a la reunión del CAB (opcional).
x Aprobar o rechazar los RFC.
x Analizar cambios aplicados sin una referencia al CAB
x Revisión del proceso de cambios
x Resultados del negocio que salen del proceso de cambio
Gestión del Cambio
Roles y responsabilidades
y
Comité de Emergencias
◦ Es un grupo pequeño de personas que se reúnen o contactan
para la evaluar y autorizar los cambios de emergencia.
◦ La selección de los miembros puede depender de la naturaleza
del cambio. Los miembros deben tener conocer y entender
tanto las perspectiva del negocio como los temas técnicos, para
poder tomar las decisiones apropiadas.
◦ El contacto vía teléfono o email puede ser el único medio
factible de reunión.
Gestión de Servicios Informáticos
GESTIÓN DE ACTIVOS DE
SERVICIO Y CONFIGURACIÓN
Gestión de la Configuración
y
Objetivo:
◦ Identificar, registrar y ofrecer información de todos los
componentes de IT que están bajo el control de Gestión de la
Configuración
Gestión de la Configuración
y
Los CI (configuration items) se registran en una CMDB
( fi
(configuration
i management database)
d b )
y
Los CI tienen:
◦ Alcance (qué aplicativos, sectores, etc interesan?)
◦ Nivel (registro “1 PC” o registro “1 mouse” + 1 teclado”, etc)
◦ Atributos
A ib
◦ Relaciones
y
DSL (Definitive Software Library)
Gestión de la Configuración
SLA
Personas
Ubicaciones
Información
Capacidad
Activos
Información
Disponibilidad
Releases
CMDB
Licencias
Documentación
Información
Financiera
Cambios
Incidentes
Gestión de la Configuración
y
Actividades:
◦ Planificar
◦ Identificar
◦ Controlar
◦ Información de gestión (info de capacidad y crecimiento,
clasificación de los CI
CI’s,
s, cambios que tuvo cada CI, datos
incorrectos en la CMDB, etc )
Configuration Management System
y
Para administrar configuraciones grandes y complejas, la
gestión
ió requiere
i
ell uso d
de algún
l ú sistema
i
d
de soporte, all
que normalmente se conoce como Configuration
Management
g
System.
y
y
El CMS mantiene en la CMDB toda la información de
los CI bajo control de configuración según está definida
en el alcance.
Definitive Media Library
y
La Definitive Media Library es una biblioteca segura en la
cual las versiones definitivas de todos los CI son almacenadas
y protegidas.
y
En la DML se almacenan todas las copias maestras que han
pasado por
p
p los controles de calidad.
y
La DML debe incluir copias definitivas de software comprado
(junto con licencias e información) y de software
desarrollado internamente.
y
Las copias maestras de la documentación de un sistema
también deben ser almacenada de forma electrónica en la
DML.
y
La DML incluirá un lugar físico para guardar copias.
y
Sólo lo que ha sido debidamente autorizado podrá aceptarse
en la DML.
DML
Relación entre la DML y la CMDB
DML and CMDB
DML
Cis Físicos
Información sobre CIs
CMDB
Cis
Electrónicos
Registro de
versión
Construcción de
una nueva
versión
Implementación de
una nueva versión
Prueba de una
nueva versión
Distribución de una
nueva versión en
producción
Configuration Baseline
y
Es la configuración de un servicio producto o
i f
infraestructura
que ha
h sido
id formalmente
f
l
revisada,
i d
acordada
y
Servirá de base para futuras actividades y puede ser
modificada sólo a través de procedimientos formales de
cambio.
y
Contiene la estructura, los contenidos y los detalles de
una configuración, y representa un conjunto de CI y sus
relaciones.
relaciones
Configuration Snapshot
y
Es el estado actual de un CI o de un entorno, por
ejemplo
j
l obtenido
b id a través
é d
de una herramienta
h
i
de
d
descubrimiento.
y
Esta foto es guardada en el CMS y queda como un
registro de estado histórico.
Roles del Proceso
y
Administrador de Activos de Servicio
y
Administrador de Configuraciones
y
Analista de Configuraciones
y
Administrador de la Librería de Medios
y
Administrador de Herramientas / CSM
y
Comité de Control de Configuración
Gestión de Servicios Informáticos
GESTIÓN DE LIBERACIONES
Y DESPLIEGUE
Gestión de Liberaciones
y
Objetivo:
◦ Asegurar que todos los aspectos de la liberación de un cambio
(técnicos y no técnicos) sean tenidos en cuenta.
◦ Facilitar la introducción del software y hardware en un ambiente
de IT controlado
Alcance
y
Asegurar planes de despliegue e implementación claros
y comprensibles.
comprensibles
y
Definir paquetes de versiones que puedan ser
construidos, instalados, testeados y desarrollados
eficientemente, para que sea posible una
implementación exitosa.
y
Permitir introducir servicios nuevos o modificados,
modificados
junto con los sistemas, tecnología y organización que lo
soporten, que sean capaces de cumplir con los SLA.
y
Lograr clientes, usuarios y personal de sistemas
conformes con las prácticas y los entregables del
p
proceso.
Unidad de implementación
y
Describe la porción de un servicio o de la
i f
infraestructura
d
de TI que normalmente
l
es lanzada
l
d en
forma conjunta, de acuerdo con la política de versiones
de la organización.
g
y
Puede variar dependiendo del tipo de elemento o
componente de servicio, sea éste HW o SW.
y
Las versiones deben ser identificados de forma única de
acuerdo con el esquema definido en la política de
release La identificación del release debe incluir una
release.
referencia a los CI que representa.
Servicio A de TI
A1
A3
A2
A2.1
A2.1.1
A2.2
A3.1
Paquete de implementación
y
Un paquete puede ser una única versión o un conjunto
estructurado
d de
d unidades
id d de
d implementación
i l
ió .
Formas de implementación
y
Big Bang vs. Por fases
◦ Big Bang: El servicio nuevo o modificado es implementado conjuntamente a
todos los usuarios.
◦ Por fases: El servicio es implementado inicialmente a una parte de los
usuarios, y luego se repite la misma operación al resto de usuarios siguiendo
un plan.
y
Push vs. pull
◦ Push: El componente del servicio es distribuido desde una posición central
a las estaciones de trabajo de los usuarios.
◦ Pull: El componente
p
del servicio es colocado en una pposición central y los
usuarios lo bajan cuando disponen de tiempo a sus estaciones de trabajo.
y
Automatizado vs. manual
◦ Es
E ell mecanismo de
d implementación
l
ó de
d las
l versiones.
Actividades
y
Planificación (políticas, recursos)
y
Preparación y automatización de la instalación
y
Aceptación (de usuarios y demás áreas afectadas)
y
Planificación del despliegue
y
Comunicación
y
Capacitación
y
Distribución
st buc ó e instalación
sta ac ó (despliegue)
( esp egue)
y
Información de Gestión (cantidad de despliegues,
cantidad de CI’s impactados en cada despliegue, etc.)
Actividades
Roles de Administración de Cambios
Órdenes de Trabajo para
Cambio Menor
Órdenes de Trabajo
para Cambio
Signif icativ o o May or
8.3
Preparar Liberación
Sistema de
Monitoreo
disponible
8.4
Realizar Pre-Producción y
Validación
FIN
Roles de Administración de
Incidentes y Requerimientos de
Servicio
"Plan de Corrección Mayor"
Notif icación sobre
serv icio prov isto
8.5
Activar Liberación
"Liberación f allida y
Corrección no autorizada"
Órdenes de Trabajo para Cam
mbio Significativo o Mayor com
mpletadas
"Cambio Significativo o Mayo
or revertido"
"Plan de Corrección Menor"
"Prueba de
Aceptación
exitosa"
Órdenes de Trabajo para Cam
mbio Menor completadas
Administrador de Liberación
Notas de Liberación
(posibles errores
conocidos)
"Cambio Menor revert ido"
3
Administración de Problemas
Órdenes de Trabajo para Cam
mbio Estándar completadas
P líti
Políticas
y
Plan de
Liberación
Anual
"Cambio Estándar revertido"
Plan de Rev ersión de
Liberación
"Tiempo insuficiente para Libe
eración"
Roles de Administración de
Problemas
Políticas y Plan de Liberación
Anual actualizados
"Planeación de Corrección Significativa o Mayyor autorizada"
Sistema de Administración de
Servicios
82
8.2
Planear Liberación
"Planeación de Corrección Significativa o Mayyor no autorizada"
y Plan de Liberación Anual
Orden de Trabajo para
Cambio Estándar
"Planeación de Corrección Menor autorizada"
"Ciclo de
Políticas de
8.1
Planeación de
Liberación
Liberaciones" Revisar y Actualizar Políticas
"Planeación de Corrección Menor no autorizada"
Administrador de Liberación
Empresarial
5
Administración de Cambios
"Liberación implementada"
FIN
2
Administración de
Incidentes y
Requerimientos de Servicio
Roles
y
Gestor de Implentación y Versión (Release and
D l
Deployment
M
Manager))
y
Gestor del Paquete de Implementación (Release
Packaging and Build Manager)
y
Personal del Despliegue (Deployment staff)
Interacción entre los principales
procesos de
d Transición
T
ó y Operación
O
ó
Incidente
escalado
CLIENTES
Marketing
Ventas
Finanzas
Clientes externos
Etc.
Incidente /
Requerimiento
De Servicio
Incidente
resuelto
Service
Desk
Gestión de Incidentes
Incidente /
Requerimiento
De servicio
resuelto
Cis Gestión de l C fi
la Configu‐
ración
Problema
Gestión de Problemas
RFC
Base de conocimiento
SLA
RFC
Catálogo de Servicios
Gestión de Release
Gestión de Cambios
Escenario Genérico
Cliente
Escenario
Genérico
¿Qué hacer?
Incidente 1
Restauración de servicio (1), SL Gold, Tiempo: 15m.
¿Tiene
SLA?
Incident
Manager
Incidente 2
Restauración de servicio (2), SL
Se evitan futuros
incidentes
relacionados
l i d con
la Causa Raíz
Identifica
Id
ifi lla
Causa Raíz
“Silver”, Tiempo: 1hr.
¿Tiene
SLA?
¿Cuál es el mejor
Release/Operations momento? Change
Manager
Manager
Service
Order
Incidentes
Registrados
Problem
Manager
Request for
Change
Cliente
Escenario Genérico
Incidente 1
Restauración de servicio (1), SL Gold, Tiempo: 15m.
Incident
Manager
Incidente 2
Restauración de servicio (2), SL
Se evitan futuros
incidentes
relacionados
l i d con
la Causa Raíz
“Silver”, Tiempo: 1hr.
CMDB
Configuration Mgmt. DB
Release/Operations
Manager
Service
Order
Change
Manager
Incidentes
Registrados
Problem
Manager
Request for
Change
Gestión de Servicios Informáticos
GESTIÓN DE NIVELES DE
SERVICIO
Gestión de Niveles de Servicio
y
Objetivo:
◦ Mantener y optimizar la calidad de los servicios de IT, a través de
ciclos constantes de acuerdo y monitoreo para alcanzar los
objetivos de negocios del cliente
Gestión de Niveles de Servicio
y
SLA:
◦ Service level agreement es un acuerdo escrito entre el
proveedor de servicios de IT y sus clientes donde se definen
puntos claves de servicios y responsabilidades de ambas partes.
Gestión de Niveles de Servicio
y
Actividades:
◦ Planificar: Establecer el proceso (mediciones actuales, iniciar
acuerdos internos y con proveedores)
◦ Implementar SLA (definir catálogo de servicios,
servicios acordar SLAs,
SLAs
definir frecuencia de revisiones y mediciones)
◦ Administrar el proceso (realizar y evaluar mediciones, revalidar
con ell cliente,
l
actualizar
l
SLA
SLAs))
Gestión de Niveles de Servicio
SLRs
OLAs
Áreas
Internas
UCs
Áreas
Externas
Catálogo
de
S i i
Servicios
de TI
Cliente
SLAs
Gestión de Servicios Informáticos
GESTIÓN DE CAPACIDAD
Gestión de la Capacidad
y
Objetivo:
◦ Asegurar que todos los aspectos de performance (actuales y
futuros) de los requerimientos de negocio sean provistos de
manera efectiva en costos
◦ Balancear capacidad con demanda
Gestión de la Capacidad
y
Actividades:
◦ Business Capacity Management:
x Asegura que se tengan en cuenta los requerimientos futuros del
negocio para los servicios de IT, planificándolos e implementándolos
en los tiempos requeridos
◦ Service Capacity Management:
x Identifica e interpreta la performance actual de los servicios de IT
(donde están los picos? Se cumple con los SLAs?)
◦ Resource Capacity Management:
x Identifica e interpreta la capacidad y utilización de cada elemento de
la infraestructura. Está al tanto de nuevas tecnologías. Asegura el uso
óptimo de los recursos.
Gestión de Servicios Informáticos
GESTIÓN DE
DISPONIBILIDAD
Gestión de la Disponibilidad
y
Objetivo:
◦ Optimizar la capacidad de la infraestructura de IT, los Servicios y
la Organización de soporte para proveer un nivel de
disponibilidad efectivo en costos y que facilite al negocio
alcanzar sus objetivos
◦ Minimizar interrupciones en los servicios
Gestión de la Disponibilidad
y
Actividades:
◦ Determinar requerimientos (OLO)
◦ Planificar
◦ Monitorear
◦ Información de Gestión
Gestión de Servicios Informáticos
GESTIÓN DE LA
CONTINUIDAD DEL
SERVICIO
Gestión de Continuidad del
Servicio
y
Objetivo:
◦ Asegurar que los servicios de IT puedan ser recuperados dentro
de los plazos acordados
Gestión de Continuidad del Servicio
y
Actividades:
◦ Inicio (definición y organización del proyecto, identificación de
políticas, recursos requeridos, etc.)
◦ Requerimientos y estrategia (definición de procesos de negocio
críticos, pérdida potencial, plazos; se trata de una evaluación de
riesgos)
◦ IImplementación
l
ó (d
(definición
f
ó de
d procedimientos,
d
contratos con
proveedores, instalaciones, capacitación, pruebas)
◦ Administración (p
(pruebas pperiódicas))
Gestión de Servicios Informáticos
GESTIÓN FINANCIERA
Gestión Financiera
y
Objetivo:
◦ Costear y distribuir los servicios de IT
Gestión Financiera
y
Actividades:
◦ Presupuestación
◦ Contabilidad
◦ Distribución
◦ Información de Gestión
Gestión Financiera
Hardware
Servicios Externos
Software
Transferencias
Oficinas
Gente
Gestión de Servicios Informáticos
FIN