M

at
er
Gestión de
ia
Disponibilidad y
l
Gestión de
riv

Capacidad
a
P
do

Unidad 2 : Diseño del Servicio

 M
AGENDA • BIENVENIDOS
• FUNDAMENTOS de Gestión de
• Gestión de Disponibilidad
• Gestión de Capacidad
at Servicios de TI (ITSM)
• Creando Clientes Felices
er • Procesos

ia • Portafolio de Servicios (Service

Portfolio)
l • Gestión de Relaciones de
Negocios
riv

• Paquete de Diseño del Servicio

(Design Package Service)
• Gestión de Catalogo de Servicios
a

(Management Catalog)
P
do

• Gestión de Niveles de Servicio

(Service Level Management)
Gestión de Disponibilidad
M
at
er• Una de las cosas que debemos tomar en cuenta es que es mucho
más barato y optimo pensar en la disponibilidad de un sistema o
ia
servicio en la etapa de diseño que descubirlo luego.
l
• Cuándo estamos diseñando, nuestro paquete de diseño, nuestro
servicio , ¿cuánto realmente de disónibilidad hay que introducir en el
riv

diseño?
• Por supuesto que la respuesta rápida sería todo lo que se pueda,
a

pero lo cierto es que pensar en técnicas de tolerancia a fallos para

P

servidores, aplicaciones y otros es CARO

do
Gestión de Disponibilidad
M
at
• Uno de los atajos o trucos a tomar, es identificar primero las
ernecesidades del Cliente, y que entre ambos estemos dispuesto a pagar
o invertir.
ia
• Uno de los objetivos es buscar esas necesidades del cliente y
desarrollar un plan de disónibilidad en base a esas necesidades
l
• Otro objetivo ; como parte del diseño es proveer guía y
riv

aseguramiento a todas las áreas de la empresa con respecto a la

disponibilidad y sus respectivos incidentes sí es que no lo consideramos.
• Por ejemplo: En el proceso de GRN (BRM) , sí descubirmos que nuestro
a
P

cliente no puede permitirse que su aplicación (el servicio) que le

do

estemos dando no debe estar abajo por más de 10 minutos; eso debe
estar considerado en el diseño del servicio respecto a la dispnibilidad.
Gestión de
M
Disponibilidad
at
• Sí hubiesen cambios igual en nuestro
er
servicio, modificaciones que surgen luego
de que están en producción. El proceso de
ia
gestión de disponibilidad también debe
sentarse a la mesa y velar que los
l
cambios o los nuevos servicios contengan
las metricas correctas de disponibilidad.
riv
a
P
do
 Uno de los conceptos respecto a las actividades de esto
M proceso de gestión de Disponibildiad son los tipos:

at
er
Gestión de
ia Tipo 1 – Proactivo – Antes de la puesta en marcha del servicio

Disponibilidad
l Planes de disponibilidad
DIseño y mejoras respecto
a la disponibilidad
riv
a
P

Tipo 2 – Reactivo – Despues de la ´puesta en marcha

do

Monitoreo Analisis Incidentes Problemas

 M
at
er
Gestión
ia
l
de Disponibilidad
riv
a
P
do
 • Lo bueno del resultado de Gestión de riesgos es
que tendras contramedidas.
M • Por ejemplo: Sale como resultado la
at implementación de firewalls para nuestros
serivdores y en la red o seguridad en la nube como
er
Gestión de
servicio contra amenazas potenciales.
• Otro elemento anterior era el "Testing" que
ia
Disponibilidad probablemente lo veamos más en la etapa de
l transición.
• Pero no me refiero aquí a solo Testing de las
riv

funcionalidades del servicio que estamos

ofreciendo
a

• Deberíamos probar sobre los mecanismos de

P
do

disponibilidad y reliabilidad
 M • Ahora en el lado Proactivo, vimos un elemento
at importante que es Monitoreo.
• Por ejemplo: sí ofrecemos Cloud Security como
er
Gestión de Proveedor de Servicios y tenemos 5 VM´s que
hacen ese trabajo , como también las aplicaciones
ia
Disponibilidad que dan el servicio, por ejemplo 5 Apps.
l • Tener en cuenta como esta ese diseño de
servidores y de las mismas aplicaciones
riv

considerando la tolerancia a fallos o Alta

Disponibilidad.
a
P
do
Gestión de Disponibilidad
M
at
• Otro termino es la fiabilidad
er
• Que tanto puede ofrecer desempeño sin que
se quiebre, lo mejor para descubrir esto es
MTBF y MTBSI
ia
• Para ITIL no es que te debes aprender de
memoria estas metricas, pero es importante
l
que sepas que hay metricas para medir esto
en los componentes.
riv

• MTBF: (o Mean Time Between Failures) es la medida de

fiabilidad que indica normalmente cuántas horas pasan
antes de que se pueda producir algún fallo en la
unidad. En un disco duro el MTBF suele rondar las
a

300.000 horas,
P

• Aspecto tambien como las 5 (9s),

do

• Veamos un ejemplo
M
at
er
ia Diseño:
l Gestión de
Capacidad
riv
a
P
do
 M
Diseño : Gestión de
Capacidad at
er
• Por ejemplo: digamos que somos un
cliente que consume algún servicio, puede
ia
ser ( servicio de virtual machines, o de
redes u otro) y en uno de esos momentos
l
empezamos a notar un BAJO
PERFORMANCE !!!
riv

• Empieza a hacerse lento y mas lento y

lento. Y es por que hay un factor critico que
el proveedor de servicios (osea nosotros)
a

fallo y no toma en cuenta … y eso es ??

P
do
 M • Y ojo, digamos que el servicio funciona (
disponibilidad concepto anterior) pero si no se hizo
at el proceso de Gestión de Capacidad el que sufre es
Performance !!
er
Gestión de • Saber hacer una buena gestión de capacidad,
ia por que en el fondo lo que queremos respecto a
Capacidad
l nuestros servicios y lo repito siempre es
SATISFACER LAS NECESIDADES DEL CLIENTE. (
SLA, BRM, SLR)
riv

• Vamos a ver los ingredientes de un buen proceso

de gestión de capacidad
a
P
do
 1. Plan de Gestión de Capacidad: y ese plan debe
contener detalles del servicio y uso del usuario
(Historico). Ademas un buen plan tiene predicciones
M 2.
sobre el servicio con el tiempo, diferentes escenarios.
Guiás: a todos los clientes o áreas internas sobre
at problemas de capacidad e incidentes en los
servicios
er
Gestión de 3. Monitoreo: monitorear los servicios para poder
ia cumplir con los SLA´s

Capacidad
l 4. Diagnostico: si hay incidentes o problemas de
capacidad , brindar un diagnostico de capacidad
sobre el servicio
riv

5. Impacto: relevar el impacto que tendría si hay

cambios en el servicio o performance.
a
P

6. La llave de todo esto es que debe ser considerado en

do

la etapa del diseño del servicio y no después por que

si seria un gran problema.
Gestión de Capacidad
M
at
Lo bueno de planear esto de forma correcta,
er
además de tunear las cosas es que preparas
un Bussinnes Case (Caso de Negocio) para
ia
poder defender ante el comité y justificar
costos para upgrades, updates de tus
l
sistemas.
riv
a
P
do