Service Level Management: Informe oficial de

Mejores Prácticas

Contenido
Introducción
Descripción general de la administración de niveles de servicio
Factores de éxito crítico
Indicadores de rendimiento
Flujo del proceso de administración de nivel de servicio
Implementar la administración de nivel de servicio
Definición de los niveles de servicio de la red
Creando y mantener los SLA
Indicadores de rendimiento de la administración de nivel de servicio
Service Level Agreement o definición de nivel de servicio documentado
Métricas del Indicador de rendimiento
Revisión de la administración de nivel de servicio
Resumen de administración de nivel de servicio
Información Relacionada

Introducción
Este documento describe la administración de nivel de servicio y los acuerdos de nivel de servicio
(SLA) para las redes de alta disponibilidad. Incluye los factores de éxito importantes para que la
administración de nivel de servicio y los indicadores de rendimiento ayuden a evaluar el éxito. El
documento también provee detalles significativos de los SLA que siguen pautas de práctica
identificadas por el equipo de servicio de gran disponibilidad.

Descripción general de la administración de niveles de servicio

Las organizaciones de la red han cumplido históricamente los requisitos de la red de extensión
construyendo las infraestructuras de red sólidas y trabajando reactivo para manejar los problemas
del servicio individual. Cuando ocurra una interrupción, la organización construirá nuevos
procesos, capacidades de administración o infraestructura para evitar que una interrupción
particular vuelva a ocurrir. Sin embargo, debido a una tarifa más alta y a los requisitos de
disponibilidad en aumento del cambio, ahora necesitamos un modelo mejorado dinámico prevenir
el tiempo de inactividad imprevisto y reparar rápidamente la red. Mucho el proveedor de servicio y
las organizaciones corporativas han intentado definir mejor el nivel de servicio requerido para
alcanzar las metas comerciales.

Factores de éxito crítico

Los factores de éxito crítico para los SLA se utilizan para definir los elementos fundamentales
para con éxito construir los niveles de servicio obtenibles y para mantener los SLA. Para calificar
como un factor crítico del éxito, un proceso o un paso del proceso debe mejorar la calidad del
SLA y beneficiar la disponibilidad de la red en general. El factor crítico del éxito también debe ser
cuantificable para que la organización pueda determinar cuán exitoso ha sido con relación al
procedimiento definido.

Para obtener más información, consulte Implementación de la administración de nivel de servicio.

Indicadores de rendimiento

Los indicadores de rendimiento brindan el mecanismo por el cual una organización mide los
factores de éxito críticos. Usted revisa típicamente éstos en una base mensual para asegurarse
de que las definiciones de nivel de servicio o los SLA están trabajando bien. El grupo de
operaciones de red y los grupos de herramientas necesarias pueden realizar las siguientes
mediciones.

Note: Para las organizaciones sin los SLA, le recomendamos realizamos las definiciones de nivel
de servicio y los estudios del servicio-nivel además de las métricas.

Los indicadores de rendimiento comprenden:

●Definición de nivel de servicio documentada o SLA que incluye la Disponibilidad, el

funcionamiento, el tiempo de respuesta del servicio reactivo, los objetivos de la solución de
problemas, y el incremento de la gravedad de los problemas.
●Revisar reunión del servicio-nivel de la conexión de redes mensual para revisar la
conformidad del servicio-nivel y para implementar las mejoras.
●Las mediciones de indicador de rendimiento, incluyendo la Disponibilidad, funcionamiento,
tiempo de respuesta de servicio por la prioridad, miden el tiempo para resolver por la
prioridad, y otros parámetros de SLA mensurables.
Consulte Implementación de la administración de nivel de servicio, para obtener más información.

Flujo del proceso de administración de nivel de servicio

El flujo del proceso de alto nivel para la administración de nivel de servicio contiene dos grupos
principales:

1. Definición de los niveles de servicio de la red

2. Crear y mantener los SLA
Haga clic en los objetos en el diagrama siguiente para ver los detalles para ese paso.
Implementar la administración de nivel de servicio
Implementar la administración de nivel de servicio consiste en dieciséis pasos divididos en las dos
categorías principales siguientes:

● Definición de los niveles de servicio de la red

● Crear y mantener los SLA

Definición de los niveles de servicio de la red

Necesidad de los administradores de la red de definir las reglas principales por las cuales la red
es soportada, manejado, y medido. Los niveles de servicio representan metas para todo el
personal de la red y se pueden utilizar como métrica de la calidad de todo el servicio. También
puede usar las definiciones de nivel de servicio como una herramienta para presupuestar los
recursos de la red y como evidencia por si fueran necesarios más fondos QoS. También proveen
una forma de evaluar al proveedor y el rendimiento de la portadora.

Sin una medición y definición de nivel de servicio, la organización no tiene objetivos bien
definidos. La satisfacción del servicio debe regirse por los usuarios sin grandes diferencias entre
aplicaciones, operaciones servidor/cliente o soporte de red. El presupuesto puede ser más difícil
porque el resultado final no está claro a la organización, y finalmente, la organización de la red
tiende a ser más reactiva, no dinámica, en la mejora de la red y del modelo soporte.

Recomendamos los pasos siguientes para construir y soportar un modelo del servicio-nivel:
 1. Analice los objetivos y restricciones técnicas.
2. Determine el presupuesto de disponibilidad.
3. Cree los perfiles de aplicación que detallan las Características de la red de las aplicaciones
críticas.
4. Defina la Disponibilidad y los estándares de rendimiento y defina los términos comunes.
5. Cree una definición de nivel de servicio que incluya la Disponibilidad, el funcionamiento, el
tiempo de respuesta del servicio, los Tiempos promedio para resolver el problema, la
detección de falla, los umbrales de la actualización, y el trayecto de escalada.
6. Recoja la métrica y monitoree la definición de nivel de servicio.

Paso 1: Analice los objetivos y restricciones técnicas

La mejor forma de comenzar a analizar objetivos y restricciones técnicas es generar una tormenta
de ideas o investigar objetivos y requisitos técnicos. A veces ayuda invitar a otros técnicos IT para
que se sumen al debate ya que ellos tienen objetivos específicos relativos a sus servicios. Los
objetivos técnicos incluyen la Disponibilidad de los niveles, producción, jitter, retardo, tiempo de
respuesta, los requisitos de ampliación, las introducciones de la nueva función, las introducciones
de la nueva aplicación, Seguridad, manejabilidad, e incluso coste. La organización luego debe
investigar las limitaciones para alcanzar esos objetivos dados los recursos disponibles. Puede
crear una hoja de trabajo para cada objetivo con una explicación de las restricciones.
Inicialmente, puede parecer como si la mayor parte de las metas no sean realizables. Luego,
comience a priorizar los objetivos o a disminuir las expectativas que aún pueden cumplir con los
requisitos de la empresa.

Por ejemplo, usted puede ser que tenga una Disponibilidad llana del 99.999 por ciento, o 5
minutos del tiempo muerto por el año. Hay varias restricciones para alcanzar este objetivo, por
ejemplo, puntos individuales de errores en el hardware, Tiempo intermedio para reparar (MTTR)
hardware dañado en ubicaciones remotas, confiabilidad de la portadora, capacidades de
detección de fallas proactivas, velocidades de cambio altas y limitaciones de la capacidad de la
red actual. Como consecuencia, usted puede ajustar la meta a un nivel más realizable. El modelo
de disponibilidad de la sección siguiente puede ayudarle a establecer objetivos realistas.

También puede considerar proporcionar una mayor disponibilidad en ciertas áreas de la red que
poseen menos restricciones. Cuando la organización de la red publica estándares de servicio
para disponibilidad, los grupos de negocios dentro de la organización pueden hallar inaceptable
este nivel. Éste es, entonces, un punto natural para iniciar discusiones SLA o modelos de
financiación/presupuesto que puedan satisfacer los requisitos comerciales.

Haga lo necesario para identificar todas las restricciones o riesgos que conlleva la realización del
objetivo técnico. Dé prioridad a las restricciones en función del riesgo o impacto al objetivo
deseado. Esto ayuda a la organización para dar prioridad a las iniciativas de mejora de la red y
para determinar cómo el obstáculo puede ser dirigido fácilmente. Hay tres tipos de limitaciones:

● Tecnología de red, elasticidad, y configuración

● Prácticas del ciclo vital, incluyendo las hojas de operación (planning), el diseño, la
implementación, y la operación
● Carga de tráfico o conducta de la aplicación actual
La tecnología de red, la elasticidad, y las restricciones de configuración son cualesquiera
limitaciones o riesgo asociado a la tecnología actual, al hardware, a los links, al diseño, o a la
configuración. Las limitaciones de la tecnología abarcan cualquier restricción que pueda presentar
la tecnología en si misma. Por ejemplo, ninguna tecnología actual permite los tiempos de
convergencia sub-segundos en los entornos de Red redundante, que pueden ser críticos para las
conexiones de voz de mantenimiento a través de la red. Otro ejemplo puede ser la velocidad sin
procesar que los datos pueden atravesar en los links terrestres, que es aproximadamente 100
millas por milisegundo.

Las investigaciones del riesgo de la elasticidad del hardware de red deben concentrar en la
topología del hardware, la jerarquía, la modularidad, la Redundancia, y el MTBF a lo largo de las
trayectorias definidas en la red. Los apremios del link de red deben centrarse en los links de red y
la conectividad de la portadora para las organizaciones corporativas. Los apremios del link
pueden incluir la redundancia de link y la diversidad, las limitaciones de medios, atando con
alambre las infraestructuras, la Conectividad del local loop, y la conectividad de larga distancia.
Las limitaciones de diseño se relacionan con la comprobación o el diseño lógico de la red e
incluyen todo del espacio disponible para el equipo al scalability de la aplicación de Routing
Protocol. Todos los diseños del protocolo y de los media se deben considerar en relación con la
configuración, la Disponibilidad, el scalability, el funcionamiento, y la capacidad. Los apremios del
servicio de red tales como Protocolo de configuración dinámica de host (DHCP), Domain Name
System (DNS), Firewall, traductores de protocolos, y traductores de dirección de red deben
también ser considerados.

Las Prácticas del ciclo vital definen los procesos y la Administración de la red usada para
desplegar constantemente las soluciones, detectan y reparan los problemas, previenen la
capacidad o los problemas de rendimiento, y configuran la red para obtener consistencia y la
modularidad. Debe considerar esta área porque la falta de disponibilidad generalmente depende
de la experiencia y los procesos. El ciclo vital de la red refiere al ciclo de las hojas de operación
(planning), del diseño, de la implementación, y de las operaciones. Dentro de cada una de estas
áreas, usted debe entender la funcionalidad de la administración de red, tales como la
administración de rendimiento, la administración de configuración, el tratamiento de fallas y la
seguridad. Una evaluación del ciclo vital de la red es disponible desde servicios de (HAS) de los
servicios de gran disponibilidad de Cisco NSA que muestran las restricciones de la disponibilidad
de la red actual asociadas a las prácticas del ciclo vital de la red.

La carga de tráfico o las restricciones de aplicación actual refiere simplemente al impacto del
tráfico y de las aplicaciones actuales.

Desafortunadamente, muchas aplicaciones tienen restricciones significativas que requieren una

administración cuidadosa. El jitter, el retardo, la producción, y los requerimientos de ancho de
banda para las aplicaciones actuales tienen típicamente muchos apremios. La forma en que se ha
escrito la aplicación también puede causar restricciones. El perfil de aplicación le ayuda mejor a
entender estos problemas; la siguiente sección cubre esta característica. La Disponibilidad, el
tráfico, la capacidad, y el rendimiento general actuales de investigación también ayuda a los
administradores de la red a entender las expectativas y los riesgos actuales del servicio-nivel.
Esto se logra típicamente con un proceso llamado el establecimiento de líneas de base de red,
que ayuda a definir el rendimiento de la red, la Disponibilidad, o las medias de la capacidad por
un período del tiempo definido, normalmente cerca de un mes. Esta información se utiliza
normalmente para la planificación de capacidad y tender, pero se puede también utilizar para
entender los problemas del servicio-nivel.

La siguiente hoja de trabajo usa el ya mencionado método objetivo/limitación para el ejemplo del
objetivo de prevención de un ataque a la seguridad o un ataque de Negación de servicio (DoS).
Usted puede también utilizar esta hoja de trabajo para ayudar a determinar la cobertura del
servicio para los ataques a la seguridad de reducción al mínimo.

Riesgo o restricción Tipo de Imp

 acto
restricción pote
ncial
Las herramientas disponibles de la
Tecnología
detección DOS no pueden detectar Alto
/resistencia
todos los tipos de ataques DOS.
Prácticas
No tenga el personal y el proceso
del ciclo Alto
requeridos a reaccionar a las alertas.
vital
Prácticas
Las políticas de acceso de la red Med
del ciclo
actual no son en el lugar. io
vital
La conexión de Internet actual del
bajo-ancho de banda puede ser un Capacidad Med
factor si la congestión de ancho de de la red io
banda se utiliza para el ataque.
Actualmente la Configuración de
Tecnología Med
seguridad a ayudar a prevenir los
/resistencia io
ataques puede no ser completa.

Paso 2: Determine el presupuesto de disponibilidad

Un presupuesto de disponibilidad es la disponibilidad teórica prevista de la red entre dos puntas

definidas. La información teórica precisa es útil en varias maneras:

● La organización puede utilizar esto como objetivo de disponibilidad interna y las desviaciones
pueden ser definidas y solucionadas rápidamente.
● Los planificadores de la red pueden utilizar la información al determinar la disponibilidad del
sistema para ayudar a garantizar que el diseño reunirá los requisitos del negocio.
Los factores que contribuyen a la indisponibilidad o período de interrupción incluyen la falla de
hardware, falla de software, poder y los Problemas de entorno, link o falla de portadora, diseño de
red, error humano, o falta de proceso. Deberá evaluar detenidamente cada uno de estos
parámetros al considerar el presupuesto de disponibilidad general para la red.

Si la organización mide actualmente la Disponibilidad, usted no puede necesitar un presupuesto

de disponibilidad. Use la medición de la disponibilidad como línea de base para estimar el nivel de
servicio actual usado para una definición del nivel del servicio. Sin embargo, usted puede estar
interesado en comparar los dos para entender la disponibilidad teórica potencial comparada al
resultado medido real.

La Disponibilidad es la probabilidad que un producto o un servicio actuará cuando está

necesitado. Consulte las siguientes definiciones:

1. Disponibilidad1 - (tiempo total de interrupción de la conexión) / (tiempo total de conexión en

servicio)1 - [Sigma(num connections affected in outage i X duration of outage i)] /(conns
numérico en el tiempo de operación del servicio X)
2. Falta de disponibilidad1 – Disponibilidad o tiempo de interrupción total de la conexión debido
a (falla de hardware, falla de software, problemas de entorno y de energía, falla de link o de
portadora, diseño de red, o error de usuario y falla de proceso).
3. Disponibilidad del hardwareLa primera área a investigar es error de hardware potencial y el
 efecto sobre la indisponibilidad. Para determinar esto, la organización debe comprender el
MTBF de todos los componentes de la red y el MTTR para los problemas de hardware de
todos los dispositivos en un trayecto entre dos puntos. Si la red es modular y jerárquica, la
disponibilidad de hardware será lo mismo entre casi cualquier dos puntas. La información
MTBF está disponible para todos los componentes de Cisco y está disponible a petición para
un administrador de cuenta local. El programa Cisco NSA HAS también utiliza una
herramienta para ayudar a determinar la disponibilidad de hardware en los trayectos de
redes, aún cuando existe redundancia de módulo, chasis y trayectos en el sistema. Un factor
importante de la confiabilidad del hardware es el MTTR. Las organizaciones deben evaluar
cómo pueden reparar rápidamente el hardware dañado. Si la organización no tiene ningún
plan escasamente y confía en un acuerdo estándar de Cisco SMARTnet™, después el
tiempo de reemplazo medio potencial es aproximadamente 24 horas. En un entorno LAN
típico con la redundancia del núcleo y ninguna Redundancia del acceso, la disponibilidad
aproximada es el 99.99 por ciento con un MTTR de cuatro horas.
4. Disponibilidad de softwareLa área de investigación siguiente es averiada fallas de software.
Para los propósitos de la medida, Cisco define las fallas de software como coldstarts del
dispositivo debido al error del software. Cisco ha hecho el progreso significativo hacia la
disponibilidad del software de comprensión; sin embargo, más nuevas versiones toman
tiempo para medir y se consideran menos disponible que el software General Deployment.
El software General Deployment, tal como versión de IOS 11.2(18), se ha medido en sobre
el 99.9999 por ciento de Disponibilidad. Esto se calcula en base al inicio sin presencia de red
vigente en los routers Cisco usando seis minutos como tiempo de reparación (tiempo para
que el router se recargue). Se supone que las organizaciones con diferentes versiones
tienen una menor disponibilidad debido a la complejidad añadida, la interoperatividad y el
aumento en los tiempos de resolución de problemas. Se espera que las organizaciones que
poseen las últimas versiones de software tengan una menor disponibilidad. La distribución
para la no disponibilidad también es bastante amplia, lo que implica que los clientes podrían
experimentar una significativa no disponibilidad o disponibilidad cercana a la versión de
despliegue general.
5. Ambiental y disponibilidad de alimentación eléctricaDebe también considerar problemas de
entorno y de energía en disponibilidad. Los Problemas de entorno se relacionan con la
ruptura de los sistemas de refrigeración necesarios para guardar el equipo en una
temperatura de funcionamiento especificada. Muchos dispositivos de Cisco apagarán
simplemente cuando están considerablemente fuera de especificación bastante que
arriesgando el daño a todo el hardware. Con el fin de un presupuesto de disponibilidad, el
poder será utilizado porque es la causa principal de la indisponibilidad en esta área.Aunque
los cortes del suministro de electricidad sean un aspecto importante de determinar la
disponibilidad de la red, esta discusión es limitada porque el análisis del poder teórico no
puede ser hecho exactamente. Lo que debe evaluar la organización para asegurar una
energía de calidad consistente para todos los dispositivos, es una medida aproximada de la
disponibilidad de energía para sus dispositivos de acuerdo a su experiencia en el área
geográfica, la cantidad de energía de respaldo disponible y los procesos
implementados.Para una evaluación conservadora, podemos decir que una organización
con los generadores de respaldo, los sistemas del (UPS) del uninterruptible-power-supply, y
los procesos de instrumentación del suministro de energía de calidad puede experimentar
seis 9s de la Disponibilidad, o el 99.9999 por ciento, mientras que las organizaciones sin
estos sistemas pueden experimentar la Disponibilidad en el 99.99 por ciento, o
aproximadamente 36 minutos del tiempo muerto anualmente. Por supuesto usted puede
 ajustar estos valores a valores más realistas basados en la opinión o los datos reales de la
organización.
6. Link o falla de portadoraEl link y las fallas de portadora son factores importantes referentes a
la Disponibilidad en los entornos WAN. Tenga presente que los entornos WAN son
simplemente otras redes que están conforme a los mismos temas de disponibilidad que la
red de la organización, incluyendo la falla de hardware, la falla de software, el error de
usuario, y el corte del suministro de electricidad.Muchas redes portadoras han realizado ya
un presupuesto de disponibilidad en sus sistemas, pero conseguir esta información puede
ser difícil. Tenga presente que los portadores también tienen con frecuencia Disponibilidad
de los niveles de la garantía que tienen poco o nada de base en un presupuesto de
disponibilidad real. Estos niveles de la garantía a veces simplemente están comercializando
y los métodos de venta usados para promover el portador. En algunos casos, estas redes
también publican las estadísticas disponibles que aparecen extremadamente buenas. Tenga
presente que estas estadísticas pueden aplicar solamente a las redes del núcleo totalmente
redundantes y no descomponen en factores en la indisponibilidad debido al acceso del local
loop, que es un contribuyente principal a la indisponibilidad en las redes WAN.Crear una
estimación de la Disponibilidad para los entornos WAN se debe basar en la información de
la portadora real y el nivel de Redundancia para la conectividad WAN. Si una organización
tiene las varias instalaciones de entrada al edificio, los proveedores redundantes del local
loop, el Acceso local del Synchronous Optical NETwork (SONET), y portadoras de larga
distancia redundantes con la diversidad geográfica, la disponibilidad de WAN será
aumentada considerablemente.El servicio telefónico es un presupuesto de disponibilidad
bastante preciso para conectividad de red no redundante en entornos WAN. La conectividad
de extremo a extremo para los teléfonos tiene una disponibilidad aproximada del
presupuesto del 99.94 por ciento usando una metodología del presupuesto de disponibilidad
similar a la que está descrita en esta sección. Esta metodología se ha utilizado con éxito en
entornos de datos con una leve variación únicamente y, en la actualidad, se utiliza como
objetivo en la especificación del cable de paquetes para redes de cable de proveedores de
servicio. Si aplicamos este valor totalmente a un sistema redundante, podemos asumir que
la disponibilidad de WAN estará cercana a 99.9999-percent disponible. Por supuesto muy
pocas organizaciones tienen los sistemas PÁLIDOS totalmente redundantes,
geográficamente dispersos debido al costo y la Disponibilidad, así que juicio apropiado del
uso con respecto a esta capacidad.Las fallas de link en un entorno LAN son menos
probables. Sin embargo, los planificadores pueden querer asumir un muy poco del tiempo de
inactividad debido a los conectores quebrados o flexibles. Para las redes LAN, un cálculo
conservador es la Disponibilidad aproximadamente 99.9999-percent, o cerca de 30
segundos por el año.
7. Diseño de redEl diseño de red es otro contribuyente principal a la Disponibilidad. los diseños
NON-scalable, los errores de diseño, y el tiempo de convergencia de red todo afectan
negativamente a la Disponibilidad.Note: Con el propósito de este documento, el diseño
NON-scalable o los errores de diseño se incluye en la sección siguiente.El diseño de red
entonces se limita a un valor mensurable basado en la falla de software y de hardware en la
red que causa el ruteo de tráfico. Habitualmente, este valor se denomina “tiempo de
traspaso del sistema” y es un factor de las capacidades de reparación propia del protocolo
dentro del sistema.Calcule la Disponibilidad por simplemente usando los mismos métodos
para cálculos del sistema. Sin embargo, esto es inválido a menos que el Switchover Time de
la red cumpla los requisitos de aplicación de red. Si el Switchover Time es aceptable, quítelo
del cálculo. Si el Switchover Time no es aceptable, después usted debe agregarlo a los
 cálculos. Un ejemplo pudo ser la voz sobre IP (VoIP) en un entorno donde está 30 segundos
el Switchover Time estimado o real. En este ejemplo, los usuarios colgarán simplemente
para arriba el teléfono e intentarán posiblemente otra vez. Seguramente, los usuarios
considerarán a este período de tiempo como de no disponibilidad, pero no se ha calculado
en el presupuesto de disponibilidad.Calcule la indisponibilidad debido al System Switchover
Time mirando la disponibilidad de software y de hardware teórica a lo largo de los trayectos
redundantes, porque el intercambio ocurrirá en esta área. Debe saber el número de
dispositivos que pueden fallar y causar el intercambio en el trayecto redundante, el MTFB de
esos dispositivos y el tiempo de intercambio. Un ejemplo simple sería un MTBF de 35,433
horas para cada uno de dos dispositivos idénticos redundantes y un Switchover Time de 30
segundos. Dividiendo 35,433 por 8766 (las horas por año hechas un promedio para incluir a
los años bisiestos), vemos que el dispositivo fallará una vez cada cuatro años. Si utilizamos
30 segundos como Switchover Time, podemos entonces asumir que cada dispositivo
experimentará, por término medio, 7.5 segundos por el año de indisponibilidad debido al
intercambio. Puesto que los usuarios pueden atravesar cualquier trayectoria, el resultado
entonces se dobla a 15 segundos por el año. Cuando esto se calcula en términos de
segundos por el año, el periodo de disponibilidad debido al intercambio se puede calcular
como Disponibilidad 99.99999785-percent en este sistema sencillo. Esto puede ser mayor
en otros entornos debido a la cantidad de dispositivos redundantes en la red en la cual hay
posibilidades de que ocurra una conmutación.
8. Error de usuario y procesoLas causas más importantes de no disponibilidad en empresas y
redes portadoras son los errores del usuario y los problemas de disponibilidad del proceso.
El aproximadamente 80 por ciento de indisponibilidad ocurre debido a los problemas tales
como detección de los errores, de los errores de cambio, y de los problemas de
rendimiento.Las organizaciones simplemente no querrán usar cuatro veces el resto de la no
disponibilidad teórica para determinar el presupuesto de disponibilidad, sin embargo, las
pruebas sugieren de manera concluyente que esto es lo que ocurre en muchos entornos. En
la siguiente sección se desarrolla este aspecto de no disponibilidad más
detenidamente.Puesto que usted no puede calcular teóricamente la cantidad de
indisponibilidad debido al error de usuario y al proceso, le recomendamos quitamos esto
quitado del presupuesto de disponibilidad y que las organizaciones se esfuerzan para la
perfección. La una advertencia es que las organizaciones necesitan entender el riesgo
actual a la Disponibilidad en sus propios procesos y niveles de experiencia. Una vez que
comprendan mejor estos riesgos e inhibidores, es posible que los planificadores de la red
deseen contabilizar alguna cantidad de no disponibilidad debido a estos inconvenientes. El
programa NSA HAS de Cisco investiga estos problemas y puede ayudar a las
organizaciones a entender una no disponibilidad potencial debido al proceso, a un error de
usuario o a problemas de conocimiento.
9. Determinar el presupuesto final de disponibilidadPuede determinar el presupuesto general
de disponibilidad al multiplicar la disponibilidad para cada una de las áreas definidas
anteriormente. Esto se hace típicamente en entornos homogéneos en los que la
conectividad es similar entre dos puntos, como por ejemplo un entorno LAN jerárquico
modular o un entorno WAN jerárquico estándar.En este ejemplo, el presupuesto de
disponibilidad se hace para un entorno de LAN modular jerárquico. El entorno utiliza los
generadores de respaldo y los sistemas UPS para todos los componentes de la red y
maneja correctamente el poder. La organización no utiliza VoIP y no desea incluir como
factor el tiempo de intercambio de software. Los cálculos son:La Disponibilidad del trayecto
del hardware entre el dos extremos señala el = 99.99 por ciento de DisponibilidadLa
 disponibilidad de software usando como referencia la confiabilidad del software GD =
99.9999 % de disponibilidadAmbiental y disponibilidad de alimentación eléctrica con los
sistemas de reserva el = 99.999 por ciento de DisponibilidadFalla de link en el entorno LAN
el = 99.9999 por ciento de DisponibilidadSystem Switchover Time no descompuesto en
factores el = 100 por ciento de DisponibilidadError de usuario y disponibilidad de proceso
perfectos = disponibilidad del 100 por cientoEl presupuesto final de disponibilidad que deben
buscar las organizaciones equivale a 0.9999 X 0.999999 X 0.999999 X 0.999999 =
0.999896, o una disponibilidad del 99.9896 por ciento. Si descomponemos en factores en la
posible falta de disponibilidad debido al usuario o al error del proceso y asumimos que la
indisponibilidad es 4X disponibilidad debido debido a los factores técnicos, podríamos
asumir que el presupuesto de disponibilidad es el 99.95 por ciento.Este ejemplo de análisis
indica, entonces, que la disponibilidad de LAN caería, en promedio, entre un 99.95 y 99.989
por ciento. Estos números se pueden usar ahora como un objetivo de nivel de servicio para
la organización de la red. Puede obtener un valor adicional al medir la disponibilidad en el
sistema y determinar el porcentaje de no disponibilidad debido a cada una de las anteriores
seis áreas. Esto le permite a la organización evaluar de manera apropiada a los
proveedores, empresas de comunicaciones, procesos y al personal. El número también se
puede usar para establecer las expectativas dentro del negocio. Si el número es inaceptable,
después los recursos adicionales del presupuesto para ganar los niveles deseados.Puede
ser útil que los administradores de la red entiendan la cantidad de tiempo de inactividad en
cualquier Disponibilidad determinada del nivel. La cantidad de tiempo de inactividad en
minutos durante un periodo de un año, en cualquier nivel de disponibilidad, es:Minutos del
tiempo muerto en un año = 525600 - (Disponibilidad del nivel X 5256)Si usted utiliza la
Disponibilidad llana del 99.95 por ciento, esto se resuelve para ser igual a 525600 - (99.95 x
5256), o 262.8 minutos del tiempo muerto. Para la definición de disponibilidad antedicha,
esto es igual a la cantidad promedio de tiempo muerto para todas las conexiones en el
servicio dentro de la red.

Paso 3: Cree los perfiles de aplicación

Ayuda de los perfiles de aplicación que la organización de interconexión de redes entiende y que
define los requisitos del nivel de servicio de la red para las aplicaciones individuales. Esto lo
ayuda a asegurarse de que la red soporte requisitos de aplicación individuales y servicios de red
generales. Los perfiles de aplicación pueden también servir como línea de fondo documentada
para el soporte de servicio de red cuando punta de la aplicación o de los grupos de servidores a
la red como el problema. En última instancia, los perfiles de aplicación ayudan a alinear los
objetivos del servicio de red con los requerimientos de aplicación o de negocios mediante la
comparación de los requisitos de aplicación, como el rendimiento y la disponibilidad, con los
objetivos realistas de servicio de red o las limitaciones actuales. Es importante no sólo para la
administración de nivel de servicio, sino también para el diseño general descendente de la red.

Cree los perfiles de aplicación cualquier momento usted introduce las nuevas aplicaciones a la
red. Es posible que sea necesario establecer un acuerdo entre el grupo de aplicación de IT, los
grupos de administración de servidores y la conexión en red para ayudar a imponer la creación de
perfiles de aplicación para los servicios nuevos y los que ya existen. Perfiles de aplicación
completos para las aplicaciones comerciales y las aplicaciones del sistema. Las aplicaciones
comerciales pueden incluir el email, transferencia de archivos, exploración de la Web, diagnóstico
por imágenes, o fabricación. Las aplicaciones del sistema pueden incluir la distribución del
software, la autenticación del usuario, el respaldo de la red y la administración de la red.
Un analista de red y una aplicación o la aplicación de soporte de servidor deben crear el perfil de
aplicación. Las nuevas aplicaciones pueden requerir el uso de un analizador de protocolo y de un
emulador WAN con la emulación del retardo de caracterizar correctamente los requerimientos de
la aplicación. Esto ayuda a identificar el ancho de banda necesario, el retraso máximo para la
utilidad de la aplicación y los requerimientos de fluctuación. Esto puede realizarse en un entorno
de laboratorio siempre que tenga los servidores requeridos. En otros casos, por ejemplo con el
VoIP, los requisitos de la red incluyendo el jitter, el retardo, y el ancho de banda se publican bien
y la prueba de laboratorio no será necesaria. Un perfil de aplicación debe incluir los elementos
siguientes:

● Nombre de la aplicación
● Tipo de aplicación
● ¿Nueva aplicación?
● Importancia comercial
● Requerimientos de disponibilidad
● Protocolos y puertos usados
● Ancho de banda de usuario estimado (kbps)
● Número y ubicación de los usuarios
● Requisitos de la transferencia de archivos (tiempo incluyendo, volumen, y puntos finales)
● Impacto de la interrupción de la red
● Retardo, jitter, y requerimientos de disponibilidad
El objetivo del perfil de aplicación es comprender los requisitos comerciales para la aplicación, el
carácter crítico del negocio y los requisitos de la red como el ancho de banda, el retardo y la
fluctuación. Además, la organización de interconexión de redes debe entender el impacto del
tiempo de inactividad de la red. En algunos casos, usted necesitará los recomienzos de la
aplicación o del servidor que agregan perceptiblemente al tiempo de inactividad de la aplicación
total. Cuando completa el perfil de la aplicación, puede comparar las capacidades generales de la
red y contribuir a alinear los niveles de servicio de la red con los requisitos comerciales y de la
aplicación.

Paso 4: Defina la Disponibilidad y los estándares de rendimiento

La Disponibilidad y los estándares de rendimiento fijaron las expectativas del servicio para la
organización. Éstos pueden ser definidos para distintas áreas de la red o para aplicaciones
específicas. El funcionamiento se puede también definir en términos de retardo de ida y vuelta,
jitter, rendimiento máximo, compromisos de ancho de banda, y escalabilidad general. Además de
fijar las expectativas del servicio, la organización debe también tomar el cuidado para definir cada
uno de los estándares del servicio de modo que el usuario y los grupos TIC que trabajan con el
establecimiento de una red entiendan completamente el servicio estándar y cómo se relaciona
con sus requisitos de la aplicación o de la administración de servidores. Los grupos de usuarios y
de IT también deben comprender cómo se debe medir el estándar de servicio.

Los resultados de los pasos de definición de nivel del servicio previo ayudarán a crear el
estándar. En este momento, la organización de interconexión de redes debe tener un
conocimiento de los riesgos y de los apremios actuales en la red, una comprensión de la
conducta de la aplicación, y una disponibilidad teórica del análisis o línea de base de
disponibilidad.

1. Defina el geográfico o las áreas de aplicación donde estarán aplicados los estándares del
servicio.Podría incluir áreas como la LAN de oficinas centrales, la WAN local, extranet o la
conectividad asociada. En algunos casos, la organización puede tener diversos objetivos de
 nivel de servicio dentro de una área. Este no es común para las empresas o las
organizaciones proveedoras de servicios. En estos casos, no sería infrecuente crear
diversos estándares del nivel de servicio basados en los requisitos del servicio individual. Se
pueden clasificar como estándares de servicio de oro, plata y bronce dentro de un área
geográfica o de servicio.
2. Defina los parámetros estándars del servicio.La Disponibilidad y el retardo de ida y vuelta
son la mayoría de los estándares del servicio de red común. El rendimiento máximo, el
compromiso de ancho de banda mínimo, el jitter, los índices de errores aceptables, y las
capacidades de escalabilidad se pueden también incluir según las necesidades. Tenga
cuidado al revisar el parámetro de servicio para los métodos de medición. Si el parámetro
avanza hacia la SLA o no, la organización debe pensar en cómo se debería medir o justificar
el parámetro de servicio cuando ocurren problemas o desacuerdos de servicio.
Después de que usted defina las áreas de servicio y los parámetros de servicio, utilice la
información de los pasos anteriores para construir la matriz de estándares de servicios. La
organización también necesitará definir las áreas que pueden ser confusas a los usuarios y a los
grupos TIC. Por ejemplo, el tiempo de respuesta máximo será muy diferente para un ping de ida y
vuelta que para golpear tecla Enter (Intro) en un lugar remoto para una aplicación específica. La
tabla siguiente muestra los objetivos de rendimiento dentro de los Estados Unidos.

Blanco
media
Tiempo Método de
Dispon Método del
Área de la medición
ibilidad de tiempo
de respuesta de tiempo
de la medici de
red máximo de
blanco ón respues
validado respuesta
ta de la
red
Minuto
s de Respuesta
99.99 Menos
LAN usuario 10 ms de ping de
% de 5 ms
impact ida y vuelta
ado
Menos
Minuto
de 100
s de Respuesta
99.99 ms
WAN usuario 150 ms de ping de
% (ping de
impact ida y vuelta
ida y
ado
vuelta)
Menos
WAN Minuto
de 100
crític s de Respuesta
99.99 ms
oy usuario 150 ms de ping de
% (ping de
extra impact ida y vuelta
ida y
net ado
vuelta)

Paso 5: Defina el servicio de red

Éste es el paso más reciente hacia la Administración del nivel del servicio básico; define el
reactivo y los procesos proactivos y las capacidades de administración de red que usted
implementa para alcanzar los objetivos de nivel de servicio. El documento final típicamente se
llama un plan de soporte de las operaciones. La mayoría de los planes del soporte de
aplicaciones incluyen solamente los requisitos de soporte reactivo. En los entornos de gran
disponibilidad, la organización debe también considerar los procesos de la administración
proactiva que serán utilizados para aislar y los problemas de red de la resolución antes de que se
inicien las llamadas de servicio de usuario. En general, el documento final debe:

● Describa el reactivo y el proceso proactivo usados para alcanzar el objetivo de nivel de

servicio
● Cómo el proceso del servicio será manejado
● Cómo el proceso del objetivo del servicio y del servicio será medido.
Esta sección contiene los ejemplos para que las definiciones y las definiciones de servicio
proactivo del servicio reactivo consideren para muchos el proveedor de servicio y a las
organizaciones corporativas. El objetivo de elaborar las definiciones del nivel de servicio es
ofrecer un servicio que cumpla con los objetivos de rendimiento y disponibilidad. Para lograrlo, la
organización debe desarrollar el servicio con las restricciones técnicas actuales, el presupuesto
de disponibilidad y los perfiles de aplicación en mente. Específicamente, la organización debe
definir y construir un servicio que identifique y resuelva constantemente y rápidamente los
problemas dentro de las épocas afectadas un aparato por el modelo de disponibilidad. La
organización también debe definir un servicio que pueda identificar y solucionar con rapidez los
problemas de servicio potenciales que afectarán la disponibilidad y el rendimiento si se los ignora.

Usted no alcanzará el nivel del servicio deseado durante la noche. Los defectos tales como baja
experiencia, limitaciones del proceso actual o niveles de personal inadecuados pueden evitar que
la organización alcance los estándares u objetivos deseados, aun luego de los pasos previos del
análisis del servicio. No existe un método preciso para coincidir exactamente el nivel de servicio
requerido con los objetivos deseados. Para acomodar para esto, la organización debe medir los
estándares del servicio y medir los parámetros de servicio usados para soportar los estándares
del servicio. Cuando la organización no está resolviendo los objetivos del servicio, debe entonces
mirar para mantener la métrica para ayudar a entender el problema. En muchos casos, los
aumentos de presupuesto se pueden hacer para mejorar los servicios del soporte y para llevar a
cabo mejoras necesarias alcanzar las metas del servicio deseado. Con el transcurso del tiempo la
organización puede realizar varios ajustes, tanto a los objetivos de los servicios como a la
definición de los servicios, a fin de alinear los servicios de red y los requisitos comerciales.

Por ejemplo, una organización pudo alcanzar el 99 por ciento de Disponibilidad cuando la meta
era mucho más alta en el 99.9 por ciento de Disponibilidad. Al observar el servicio y las
mediciones de soporte, los representantes de la organización encontraron que el reemplazo de
hardware llevó aproximadamente 24 horas, mucho más que el tiempo estimado originalmente ya
que la organización había presupuestado únicamente cuatro. Además, la organización encontró
que las capacidades de administración proactiva eran ignoradas y abajo los dispositivos de la Red
redundante no eran reparados. También encontraron que no tenían los personales para llevar a
cabo mejoras. Como consecuencia, después de considerar que bajaba los objetivos del servicio
actuales, la organización presupuestada para los recursos adicionales necesitó alcanzar el nivel
del servicio deseado.

Las definiciones de servicio deben incluir las definiciones y las definiciones proactivas del soporte
reactivo. Las definiciones reactivas definen cómo la organización reaccionará a los problemas
después de que se hayan identificado de la queja del usuario o de las capacidades de
administración de red. Las definiciones proactivas describen cómo la organización identificará y
resolverá los problemas de la red potencial, incluyendo la reparación de los componentes de la
red “espera” quebrados, detección de error, y los umbrales de capacidad y las actualizaciones.
Las siguientes secciones proporcionan información sobre las definiciones de nivel de servicio
reactivo y proactivo.

Definiciones de nivel de servicio reactivo

Las siguientes áreas de nivel de servicio se miden generalmente utilizando estadísticas de una
base datos del mostrador de informaciones y de auditorías periódicas. Esta tabla muestra un
ejemplo de gravedad de problema para una organización. Note que la carta no incluye cómo
manejar los pedidos el nuevo servicio, que se puede manejar por SLA o un perfil de aplicación y
un análisis adicionales del qué si del funcionamiento. Típicamente, la gravedad 5 podría ser una
solicitud de un nuevo servicio en caso de darle tratamiento por medio del mismo proceso de
soporte.

Graved Graved
Gravedad 2 Gravedad 3
ad 1 ad 4
Una
Sitio
Alto impacto Una cierta interrog
WAN
comercial con la funcionalidad ación o
crítico
pérdida o la de la red un
severo
degradación, LAN de específica se incident
del
oficina central en el pierde o se e
usuario
lugar de la solución degrada, por funcion
de LAN
alternativa posible ejemplo la al que
o del
abajo; 5-99 usuarios redundancia no
segmen
afectaron al impacto LAN afectada tienen
to del
PÁLIDO funcionamiento ningún
servidor
internacional del del LAN de impacto
del
rendimiento crítico oficina central comerci
impacto
del sitio del sitio del de la pérdida al para
comerci
WAN local abajo de redundancia la
al abajo
abajo perdida organiz
abajo
ación

Cuando se ha definido la gravedad del problema, defina o investigue el proceso de apoyo para
crear definiciones de respuesta del servicio. Las definiciones de respuesta del servicio requieren
generalmente una estructura del soporte por niveles juntada con un sistema de soporte del
software del escritorio de ayuda para seguir los problemas vía los ticketes de problemas. La
métrica debe también estar disponible en el tiempo de respuesta y el tiempo de resolución para
cada prioridad, el número de llamadas por la prioridad, y la respuesta/la calidad de resolución.
Para definir el proceso de soporte, es útil definir los objetivos de cada nivel de soporte en la
organización y sus roles y responsabilidades. Esto ayuda a los requerimientos de recursos de
comprensión de la organización y a los niveles de conocimiento para cada nivel de soporte. La
siguiente tabla brinda un ejemplo de una organización de soporte por niveles con pautas para la
solución de problemas.

Niv
el
de
Responsabilidad Metas
sop
ort
e
So Las llamadas al servicio técnico a tiempo Resoluc
por ión del
completo de la respuesta del soporte del
te 40% de
escritorio de ayuda, los ticketes de
de las
problemas del lugar, trabajo sobre el
la llamada
problema hasta 15 minutos, boleto del
gra s
documento y se extienden para apropiarse
da entrante
del soporte de la grada 2
1 s
Resoluc
So Haga cola la supervisión, Administración
ión del
por de redes, los ticketes de problemas del
100%
te lugar de la supervisión de la estación por
de las
de problemas identificados del software
llamada
la implementan las llamadas de la toma de la
s en el
gra grada 1, vendedor, y la escalada de la
nivel de
da grada 3 asume la propiedad de la llamada
la grada
2 hasta la resolución
2
Ninguna
So
Debe proporcionar el soporte inmediato a propied
por
la grada 2 para todos los problemas de la ad
te
prioridad 1 acuerdan ayudar con todos los directa
del
problemas sin resolver por la grada 2 del
niv
dentro del periodo de resolución SLA problem
el 3
a

El siguiente paso es crear la matriz para la definición de servicio de la resolución de la respuesta

del servicio y del servicio. Esto establece metas para la rapidez con que los problemas se
resuelven, inclusive el reemplazo del hardware. Es importante fijar las metas en esta área porque
el tiempo de respuesta y el tiempo de recuperación del servicio afectan directamente la
disponibilidad de la red. Los tiempos de resolución de problemas también deben adaptarse al
presupuesto de disponibilidad. Si un gran número de problemas de la suma gravedad no se
explican en el presupuesto de disponibilidad, la organización puede entonces trabajar para
entender la fuente de estos problemas y de un remedio potencial. Vea la tabla siguiente:

Grave Resp Niv Reem Soluc

dad uesta el 2 plazo ión
Respuesta del
del de en de del
escritorio de ayuda
probl Nivel el hardw probl
ema 2 sitio are ema
Escalación inmediata
5 2
a la grada 2, 2 4
1 minut hor
administrador de las horas horas
os as
operaciones de la red
Escalación inmediata
5 4
a la grada 2, 4 8
2 minut hor
administrador de las horas horas
os as
operaciones de la red
2 12
24 36
3 15 minutos hora hor
horas horas
s as
4 3 6
4 15 minutos hora 3 días
días días
 s

Además de la resolución de la respuesta del servicio y del servicio, construya una matriz para
escalada. Las ayudas de la Matriz de escalada se aseguran de que los recursos disponibles estén
centrados en los problemas que afectan seriamente al servicio. Generalmente cuando los
analistas se centran en los problemas de la fijación, se centran raramente en traer a los recursos
adicionales adentro en el problema. Definición cuando los recursos adicionales deben ser ayudas
notificadas para promover el conocimiento del problema en Administración y pueden ayudar
generalmente a llevar a dinámico futuro o a las medidas preventivas. Vea la tabla siguiente:

Tiemp
o Graveda Graved Graved
Gravedad 2
transc d 1 ad 3 ad 4
urrido
Administr
ador de
las
operacio
nes de la
red,
5
soporte
minuto      
de la
s
grada 3,
director
de
intercone
xiones de
red
Actualiza
r al
administr
ador de
operacio Actualizar al
nes de administrador de
red, operaciones de
1 hora soporte red, soporte de    
de nivel nivel 3, director de
3, interconexiones
director de red
de
intercone
xiones de
red
Extiénda
se al VP,
actualiza
ción al
2
director,      
horas
administr
ador de
operacio
nes
 El
análisis
de la
causa
raíz no
resuelto
que se
efectuó a
Extiéndase al VP,
VP,
actualización al
4 director,
director,    
horas administr
administrador de
ador de
operaciones
operacio
nes y
soporte
de nivel 3
requiere
notificaci
ón de
CEO
Adminis
trador
24 de las
     
horas operaci
ones de
la red
Adminis
trador
de las
5 días      
operaci
ones de
la red

Hasta ahora, las definiciones de nivel de servicio se centraron en cómo la organización de soporte
de las operaciones reacciona ante los problemas una vez que se identifican. Durante años, las
organizaciones de operaciones han creado planes de soporte operacional con información similar
a la mencionada anteriormente. Sin embargo, cuál falta en estos casos es cómo la organización
identificará los problemas y qué problemas identificarán. Organizaciones de la red más
sofisticadas han intentado resolver este problema simplemente creando las metas para el
porcentaje de problemas que dinámico se identifican, en comparación con problemas
reactivamente identificado por el informe de problema o la denuncia del usuario.

La siguiente tabla muestra cómo una organización puede desear evaluar las capacidades de
soporte proactivo y el soporte proactivo en general.

Áre Relación de Relación de transformación

a de identificación del reactiva de la Identificación
red problema proactivo del problema
LAN el 80% 20%
WA
el 80% 20%
N
Esto es un buen comienzo en la definición de más definiciones del soporte proactivo porque es
simple y bastante fácil medir, especialmente si las herramientas proactivas generan
automáticamente los ticketes de problemas. Esto también ayuda a las herramientas de
administración de red/información del foco sobre los problemas de resolución dinámico bastante
que ayudando con la causa raíz. Sin embargo, la cuestión principal con este método es que no
define los requisitos de soporte proactivo. Por lo general, esto crea brechas en las capacidades
de administración de soporte proactivo y tiene como resultado riesgos de disponibilidad
adicionales.

Definiciones de nivel de servicio proactivas

Una más amplia metodología para crear las definiciones de nivel de servicio incluye más detalle
en cómo se monitorea la red y cómo la organización de operaciones reacciona a los umbrales de
la estación de administración de la red definida (NMS) sobre las 7 x 24 bases. Esto puede parecer
una tarea imposible debido al elevado número de variables de Base de información para
administración (MIB) y la cantidad de información de administración de la red disponible
pertinente para la integridad de la misma. Podía también ser extremadamente costoso y uso
intensivo de recurso. Desafortunadamente, estas objeciones evitan, en muchos casos, que se
implemente una definición de servicio proactivo que, por naturaleza, debe ser simple, bastante
fácil de seguir y aplicable sólo a los mayores riesgos de disponibilidad o rendimiento de la red. Si
una organización entonces considera el valor en las definiciones de servicio proactivo básicas,
más variables se pueden agregar en un cierto plazo sin el impacto significativo, mientras usted
implemente un acercamiento organizado.

Incluya la primera área de las definiciones de servicio proactivo en todos los planes de soporte de
las operaciones. De la definición de servicio los estados simplemente cómo el grupo de
operaciones dinámico identificará y responderá a la red o conectará abajo de las condiciones en
diversas áreas de la red. Sin esta definición (o soporte de administración), la organización puede
esperar soporte variable, expectativas de usuarios irreales y, en última instancia, una
disponibilidad de red menor.

La siguiente tabla muestra cómo una organización puede crear una definición de servicio para
condiciones de link/dispositivo fuera de funcionamiento. El ejemplo muestra una organización
empresarial que quizás tenga diferentes requerimientos de notificaciones y de respuestas según
el momento del día y el área de la red.

Dispos
Métod
itivo 7 x 24 resolu
o de notificació Resolución
de red notifica ción 5
detecc n 5 x 8 7 x 24
o link ción x8
ión
abajo
El Analist Prioridades
El NOC localiz a LAN
Dispos 3 y de las
crea el ador asigna
itivo prioridades
ticket de de do en
SNMP 1y2
problema tareas el
LAN y resolución e
s, de plazo
del consul investigació
localizado LAN de 15
núcleo ta de n inmediata
r de de la minuto
links, cola 4 para
tareas de Página s por
tramp la
LAN de la autom el
as resolución
página ática, NOC, posterior
 person
a de
tareas
repara
de
ción
LAN
según
crea el
la
ticket
definic
de
ión de
proble
respu
mas
esta
para la
del
cola
servici
del
o
LAN
del
núcleo
El
localiz
ador
de Analist
tareas a de
de WAN
WAN asigna
de la do en Prioridades
El NOC
Dispos Página 15 3 y de las
crea el
itivo autom minuto prioridades
ticket de
SNMP ática, s por 1y2
problema
y person NOC, resolución e
WAN s, llamar
consul a de repara investigació
local al
ta de tareas ción n inmediata
radiolocali
links, de como cola 4 para
zador de
tramp WAN definic la
WAN en
as crea el ión de resolución
servicio
ticket respu posterior
de esta
proble por
mas servici
para la o.
cola
PÁLID
A
El Analist Prioridades
El NOC localiz a 1y2
Dispos
crea el ador asocia resolución e
itivo
ticket de de do investigació
SNMP
problema tareas asigna n inmediata;
y
Extran s, del do Las
consul
et localizado partner dentro prioridades
ta de
r de de la de los 3y4
links,
tareas del Página 15 quedan
tramp
partner de autom minuto pendientes
as
página ática, s por para
 person
a del
deber NOC,
del repara
partner ción
crea el según
ticket definic resolverse
de ión de luego
proble repue
mas sta del
para la servici
cola o
del
partner

Las definiciones de nivel de servicio proactivo restantes se pueden dividir en dos categorías:
Errores de red y capacidad/problemas de rendimiento. Sólo un pequeño porcentaje de las
organizaciones de red poseen definiciones de nivel de servicio en éstas áreas. Como
consecuencia, estos problemas se ignoran o se manejan esporádico. Esto puede ser adecuado
para algunos entornos de red, pero los entornos con alta disponibilidad necesitan generalmente
una administración de servicio uniforme y proactiva.

Las organizaciones de interconexión de redes tienden a luchar con las definiciones de servicio
proactivo por varias razones. Esto se debe principalmente a que no realizaron un análisis de
requisitos con respecto a definiciones de servicio proactivo en base a riesgos de disponibilidad,
presupuesto de disponibilidad y problemas de aplicación. Esto lleva a los requisitos no
entendibles para las definiciones de servicio proactivo y a las ventajas no entendibles,
especialmente porque los recursos adicionales pueden ser necesarios.

El segundo motivo implica el equilibrio de la cantidad de administración preactiva que puede

realizarse con los recursos existentes o los recientemente definidos. Sólo genere aquellas alertas
que tienen un potencial impacto severo en la disponibilidad o en el rendimiento. Usted debe
también considerar la Administración o los procesos de la correlación de eventos para asegurarse
de que los ticketes de problema proactivo múltiples no están generados para el mismo problema.
La última razón por la cual las organizaciones pueden ofrecer resistencia es que la creación de un
nuevo conjunto de alertas proactivas puede, con cierta frecuencia, llegar a generar una
inundación inicial de mensajes que pasaron previamente desapercibidos. El grupo de operaciones
debe ser preparado para esta inundación inicial de los problemas y de los recursos a corto plazo
adicionales para reparar o para resolver estas condiciones previamente desapercibidas.

La primera categoría de definiciones de nivel de servicio proactivo es errores de red. Los Errores
de red se pueden subdividir más a fondo en los errores del sistema que incluyen los errores del
software o los Errores de hardware, los errores del protocolo, los errores de control de medios, los
errores de precisión, y las advertencias ambientales. Desarrollar una definición de nivel de
servicio comienza con un conocimiento general de cómo estos problemas serán detectados, de
los cuales los mirarán, y qué sucederán cuando ocurren. Agregue los mensajes o los problemas
específicos a la definición de nivel de servicio si se presenta la necesidad. Es posible que también
sea necesario trabajar en las siguientes áreas para garantizar el éxito:

● Responsabilidades de soporte de nivel 1, nivel 2 y nivel 3

● Equilibrando la prioridad de la información de administración de red con la cantidad de trabajo
proactivo que el grupo de operaciones puede manejar eficazmente
 Requisitos de capacitación para asegurar que el equipo de soporte pueda encargarse de
●

forma efectiva de las alertas definidas.

Metodologías de correlación de eventos para asegurarse de que los varios tickets de
●

problemas no estén generados por el mismo problema de causa raíz

La documentación en los mensajes o las alertas específicos esos ayuda con la identificación
●

de evento en el Nivel de soporte de la grada 1

La tabla siguiente muestra un ejemplo de una definición de nivel de servicio para errores de red
que sirve para comprender claramente quién es responsable de las alertas de error de la red
proactiva, cómo se identificará el problema y qué sucederá cuando aparezca el problema. La
organización puede todavía necesitar esfuerzos adicionales según lo definido arriba para
asegurar el éxito

s.

Categorí
Método de Acción
a de Umbral
detección realizada
error
Estudio diario Cualquier Revise el
Errores de los ocurrencia problema, cree
de mensajes de para un ticket con el
software Syslog prioridad 0, inconveniente y
(caídas usando el 1, y 2 sobre envíelo si
forzadas visor de 100 vuelve a ocurrir
por el Syslog hecho acontecimien o si el problema
software) por el soporte tos del nivel requiere
de la grada 2 3 o arriba atención
Errores Estudio diario Cualquier Revise el
de de los ocurrencia problema, cree
hardwar mensajes de para un ticket con el
e Syslog prioridad 0, inconveniente y
(caídas usando el 1, y 2 sobre envíelo si
forzadas visor de 100 vuelve a ocurrir
por el Syslog hecho acontecimien o si el problema
hardwar por el soporte tos del nivel requiere
e) de la grada 2 3 o arriba atención
Estudio diario Diez Revise el
Errores
de los mensajes por problema, cree
del
mensajes de el día de las un ticket con el
protocol
Syslog prioridades 0, inconveniente y
o (IP
usando el 1, y 2 sobre envíelo si
Routing
visor de 100 vuelve a ocurrir
Protocol
Syslog hecho acontecimien o si el problema
solament
por el soporte tos del nivel requiere
e)
de la grada 2 3 o arriba atención
Errores Estudio diario Diez Revise el
de de los mensajes por problema, cree
control mensajes de el día de las un ticket con el
de Syslog prioridades 0, inconveniente y
medios usando el 1, y 2 sobre envíelo si
(FDDI, visor de 100 vuelve a ocurrir
POS, y Syslog hecho acontecimien o si el problema
fast
ethernet por el soporte tos del nivel requiere
solament de la grada 2 3 o arriba atención
e)
Estudio diario
de los
Mensaje
mensajes de Cree el ticket de
s del
Syslog problemas y el
entorno Cualquier
usando el envío para los
(poder y mensaje
visor de nuevos
temporer
Syslog hecho problemas
os)
por el soporte
de la grada 2
Consulta Errores de
Errores
SNMP en entrada o Cree el ticket de
de
cinco minutos salida un problemas para
precisión
los eventos error en los nuevos
(errores
de umbral de cinco problemas y
de
los intervalos minutos el envío al soporte
entrada
recibidos por intervalo en de la grada 2
del link)
el NOC cualquier link

Las otras definiciones de nivel de la categoría del servicio proactivo se aplican al funcionamiento y
a la capacidad. La verdadera administración de capacidad y rendimiento incluye la administración
de excepciones, el establecimiento de líneas de base y tendencia y el análisis de ¿qué pasa si…?
La definición de nivel de servicio define simplemente los umbrales del funcionamiento y del
umbral de excepción de capacidad y medios que iniciarán la investigación o la actualización.
Estos umbrales pueden utilizarse con los tres procesos de gestión de rendimiento y capacidad de
alguna manera.

Las definiciones de nivel de la capacidad y del servicio de rendimiento se pueden analizar en

varias categorías: links de red, dispositivos de red, rendimiento de extremo a extremo, y
rendimiento de la aplicación. Desarrollar las definiciones de nivel de servicio en estas áreas
requiere el conocimiento técnico profundizado con respecto a los aspectos específicos de la
capacidad del dispositivo, de la capacidad de medios, de las características QoS, y de los
requerimientos de la aplicación. Por esta razón, recomendamos que los arquitectos de la red
desarrollan el funcionamiento y las definiciones de nivel de servicio capacidad-relacionadas con la
entrada de información del vendedor.

Como los Errores de red, desarrollar una definición de nivel de servicio para la capacidad y el
funcionamiento comienza con un conocimiento general de cómo estos problemas serán
detectados, de los cuales los mirarán, y qué sucederán cuando ocurren. Puede agregar
definiciones de eventos específicas a la definición del nivel de servicio en caso de necesitarlo. Es
posible que también sea necesario trabajar en las siguientes áreas para garantizar el éxito:

● Un conocimiento de los requisitos de rendimiento de la aplicación

● La investigación técnica profundizada en los valores de umbral que tienen sentido para la
organización basó en los requisitos comerciales y los costos totales
● Requisitos para la actualización presupuestarios del ciclo y del out-of-cycle
● Responsabilidades de soporte de nivel 1, nivel 2 y nivel 3
● La prioridad y criticidad de la información de administración de la red equilibrada con la
 cantidad de trabajo proactivo que el grupo de operaciones puede manejar de manera efectiva
● Requisitos de entrenamiento de asegurarse de que el equipo de soporte técnico entienda los
mensajes o las alertas y pueda ocuparse eficazmente de la condición definida
● Metodologías de correlación de eventos o procesos para asegurarse de que los varios tickets
de problemas no estén generados por el mismo problema de causa raíz
● La documentación en los mensajes o las alertas específicos esos ayuda con la identificación
de evento en el Nivel de soporte de la grada 1
La tabla siguiente muestra una definición de nivel del servicio de ejemplo para la utilización del
vínculo que proporciona un conocimiento de quién es responsable de las alertas de error de red
proactivo, de cómo el problema serán identificados, y qué sucederá cuando ocurre el problema.
La organización puede necesitar todavía esfuerzos adicionales para asegurar el éxito, como se
definió antes.

Área
de Método de
Umbral Acción realizada
red/me detección
dia
Estruct
Consulta utilización
ura Notificación por
SNMP en del 50% en
básica correo electrónico
cinco minutos cinco
y links al grupo del email
los desvíos de minutos la
de del funcionamiento
la excepción utilización
distribu alias para evaluar
de los de los
ción la actualización del
intervalos intervalos el
del requisito de QoS o
RMON en la 90% vía el
LAN del plan por
base y los desvío de
de problemas
links de la
oficina recurrentes
distribución excepción
central
Notificación por
correo electrónico
75 % de al grupo del email
Links Consultas utilización del funcionamiento
del SNMP en en alias para evaluar
WAN intervalos de intervalos la actualización del
local 5 minutos de 5 requisito de QoS o
minutos del plan por
problemas
recurrentes
Notificación por
correo electrónico
Links al grupo del email
utilización
de Consultas del funcionamiento
del 60% en
WAN SNMP en alias para evaluar
cinco
del intervalos de la actualización del
minutos los
extran 5 minutos requisito de QoS o
intervalos
et del plan por
problemas
recurrentes

La tabla siguiente define las definiciones de nivel de servicio para la capacidad del dispositivo y
los umbrales de rendimiento. Asegúrese que usted cree los umbrales que son significativos y
útiles en la prevención de los problemas de red o de los temas de disponibilidad. Esta es un área
muy importante porque los problemas de recursos de plano de control de dispositivos no
verificados pueden tener un grave impacto en la red.

         
La
notificación
por correo
electrónico
al grupo del
email del
Consult funcionamie
CPU en el 75%
a nto y de la
durante cinco
SNMP capacidad
minutos los
en la alias para
intervalos, el 99%
CPU, notifica resolver los
vía la memoria de
mem ción de problemas o
Cisco la notificación de
oria, RMON la
7500 RMON en el 50%
buffe de los actualizació
durante cinco
rs interval n RMON
minutos los
os -5- CPU del
buffers de los
minute plan en el
intervalos en la
para el 99%, el
utilización del 99%
CPU ticket de
problemas y
la grada 2
del lugar de
la página
soporta el
paginador
Notificación
por correo
electrónico
Consult CPU en el 75% al grupo del
as durante cinco email del
SNMP minutos la funcionamie
CPU,
Cisco en memoria de los nto y de la
mem
2600 interval intervalos en el capacidad
oria
os de 5 50% durante cinco alias para
minuto minutos los resolver los
s intervalos problemas o
la
actualizació
n del plan
Utiliz Consult Notificación
ación as Backplane en la por correo
Cataly de SNMP memoria de la electrónico
st back en utilización del 50% al grupo del
5000 plane interval en la utilización email del
, os de 5 del 75% funcionamie
mem minuto nto y de la
 capacidad
alias para
resolver los
oria s problemas o
la
actualizació
n del plan
Notificación
por correo
electrónico
Consult al grupo del
Switch as email del
CPU en la
ATM SNMP funcionamie
CPU, memoria de la
de en nto y de la
mem utilización del 65%
LightSt interval capacidad
oria en la utilización
ream® os de 5 alias para
del 50%
1010 minuto resolver los
s problemas o
la
actualizació
n del plan

La tabla siguiente especifica definiciones de nivel de servicio para la capacidad y el rendimiento

de extremo a extremo. Estos umbrales generalmente se basan en los requisitos de aplicación,
pero también pueden utilizarse para indicar algún tipo de problema de rendimiento o capacidad de
red. La mayoría de las organizaciones con las definiciones de nivel de servicio para el
funcionamiento crean solamente a un conjunto de definiciones de rendimiento porque el
funcionamiento de medición de cada punta en la red a cada otra punta requiere a los recursos
significativos y crea una gran cantidad de tara de red. Estos problemas de rendimiento de
extremo a extremo también se pueden atrapar en umbrales de capacidad del dispositivo o link.
Nosotros recomendamos definiciones generales por área geográfica. Algunos sitios o links
críticos se pueden agregar en caso necesario.

Área
de
Método de
red/ Umbral Acción realizada
medición
medi
a
Notificación por
correo electrónico
tiempo de
Ningunos al grupo del email
LAN respuesta de
ningún del
de viaje de ida y
problema funcionamiento y
ofici vuelta de 10
contaban con de la capacidad
na milisegundos
difícil medir la alias para
cent o menos en
infraestructura resolver la
ral todo
LAN entera actualización del
momento
problema o del
plan
Link Medición actual tiempo de Notificación por
s del del SF al NY y respuesta de correo electrónico
WA del SF a ida y vuelta al grupo del email
 del
Chicago 75-
funcionamiento
solamente millisecond
alias para evaluar
usando el eco hecho un
N la actualización
ICMP del promedio
local del requisito de
Internet durante cinco
QoS o del plan
Performance minutos el
por problemas
Monitor (IPM) período
recurrentes
Notificación por
tiempo de
correo electrónico
respuesta de
de al grupo del email
Medición actual ida y vuelta
San del
de San 250-
Fran funcionamiento
Francisco a millisecond
cisc alias para evaluar
Bruselas hecho un
oa la actualización
usando el IPM y promedio
Toky del requisito de
el eco ICMP durante cinco
o QoS o del plan
minutos el
por problemas
período
recurrentes
Notificación por
tiempo de
correo electrónico
respuesta de
al grupo del email
San Medición actual ida y vuelta
del
Fran de San 175-
funcionamiento
cisc Francisco a millisecond
alias para evaluar
o a Bruselas hecho un
la actualización
Brus usando el IPM y promedio
del requisito de
elas el eco ICMP durante cinco
QoS o del plan
minutos el
por problemas
período
recurrentes

El área final para las definiciones de nivel de servicio es para el rendimiento de las aplicaciones.
Las definiciones de nivel de servicio del rendimiento de la aplicación son creadas normalmente
por la aplicación o el grupo de administración de servidores porque el funcionamiento y la
capacidad de los servidores ellos mismos es probablemente el factor más grande del rendimiento
de la aplicación. Las organizaciones de interconexión de redes pueden realizar la enorme ventaja
creando las definiciones de nivel de servicio para el funcionamiento de la aplicación de red
porque:

● la medición y las definiciones del nivel de servicio pueden ayudar a eliminar conflictos entre
grupos.
● las definiciones de los niveles de servicio para las aplicaciones individuales son importantes
si la calidad de servicio (QoS) está configurada para las aplicaciones principales y el resto del
tráfico se considera opcional.
Si usted elige crear y rendimiento de la aplicación de la medida, es probablemente el mejor si
usted no mide el funcionamiento al servidor sí mismo. Esto, entonces, nos ayuda a distinguir entre
problemas de red y aplicaciones y problemas de servidores. Use sondas o el software agente de
disponibilidad del sistema que se ejecuta en los routers de Cisco y el IPM de Cisco que controla el
tipo de paquete y la frecuencia de medición.

La tabla siguiente muestra una definición de nivel de servicios simple para el rendimiento de la
aplicación.
Aplicació Método de
Umbral Acción realizada
n medición
Puerto tiempo de Notificación por
Bruselas a San
TCP 1529 respuesta correo
Francisco
Bruselas de ida y electrónico al
usando el
del vuelta grupo del email
gateway de
aplicacion 175- del
Bruselas de
de millisecon funcionamiento
medición del
planificaci d hecho alias para
rendimiento de
ón de un evaluar la
ida y vuelta del
recursos promedio actualización del
puerto 1529
para durante problema o del
IPM al
empresas cinco plan por
gateway SFO
(ERP) al minutos el problemas
2
SF período recurrentes
tiempo de Notificación por
Bruselas a San
respuesta correo
Francisco
de ida y electrónico al
usando el
Puerto vuelta grupo del email
gateway de
TCP 1529 200- del
Bruselas de
Tokio de millisecon funcionamiento
medición del
la d hecho alias para
rendimiento de
aplicación un evaluar la
ida y vuelta del
ERP al promedio actualización del
puerto 1529
SF durante problema o del
IPM al
cinco plan por
gateway SFO
minutos el problemas
2
período recurrentes
tiempo de Notificación por
Sydney a San
respuesta correo
Francisco
Puerto de ida y electrónico al
usando el
TCP 1702 vuelta grupo del email
gateway
Sydney 250- del
Sydney de
de la millisecon funcionamiento
medición del
aplicación d hecho alias para
rendimiento de
de un evaluar la
ida y vuelta del
soporte promedio actualización del
puerto 1702
de cliente durante problema o del
IPM al
al SF cinco plan por
gateway SFO
minutos el problemas
1
período recurrentes

Paso 6: Recoja la métrica y monitoree

por sí solas, las definiciones de nivel de servicio no son útiles a menos que la organización
recopile las medidas y monitoree el éxito. En crear una definición de nivel de servicio crítica,
defina cómo el nivel de servicio será medido y señalado. La medición del nivel de servicio
determina si la organización está logrando los objetivos y también identifica la causa raíz de la
Disponibilidad o de los problemas de rendimiento. También considere la meta al elegir un método
para medir la definición de nivel de servicio. Vea creando y mantener los SLA para más
información.
Los niveles del servicio de supervisión exigen el conducir de una reunión de la revisión periódica,
normalmente cada mes, para discutir el servicio periódico. Discuta toda la métrica y si ella se
ajusta a los objetivos. Si no conforman, determine la causa raíz del problema y implemente las
mejoras. Debería también cubrir el progreso y las iniciativas actuales para mejorar situaciones
individuales.

Creando y mantener los SLA

Las definiciones de nivel de servicio son un excelente componente esencial ya que ayudan a
crear una calidad de servicio uniforme en toda la organización y facilitan la optimización de la
disponibilidad. El siguiente paso es los SLA, que son una mejora porque alinean los objetivos
comerciales y los requisitos de costo de mantener directamente la calidad. SLA bien-construido
entonces sirve como modelo para la eficacia, calidad, y sinergia entre la comunidad del usuario y
el grupo de soporte manteniendo los procesos claros y los procedimientos para los problemas de
red o los problemas.

Los SLA proporcionan varias ventajas:

● Los SLA establecen responsabilidad de dos partes para los servicios, lo que significa que los
usuarios y los grupos de aplicación también son contables para el servicio de la red. Si no
ayudan a crear SLA para un servicio específico y a comunicar el impacto comercial con el
grupo de red, después pueden realmente ser responsables del problema.
● Los SLA determinan las herramientas estándar y los recursos necesarios para satisfacer los
requisitos comerciales. Decidiendo a cuánta gente y qué herramientas utilizar sin los SLA es
a menudo una conjetura presupuestaria. El servicio puede estar sobrediseñado, lo cual deriva
en gastos excesivos; o bien, subdiseñado que resulta en objetivos comerciales no
alcanzados. El ajuste de los SLA ayuda a alcanzar el nivel óptimo equilibrado.
● El SLA documentado crea un método más claro para configurar las expectativas del nivel de
servicio.
Recomendamos los siguientes pasos para formar SLA una vez que se han creado definiciones de
nivel de servicio: Recomendamos los siguientes pasos para formar SLA una vez que se han
creado definiciones de nivel de servicio:

7. Resuelva los requisitos previos para los SLA.

8. Determine los partidos implicados en el SLA.

9. Determine los elementos de servicio.

10. Entienda los Objetivos y necesidades comerciales del cliente

11. Defina SLA requerido para cada grupo.

12. Elija el formato de SLA

13. Desarrolle a los grupos de trabajo SLA

14. Celebre a las reuniones de grupo de trabajo y elabore SLA.

15. Negocie SLA.

16. Mida y monitoree la conformidad de SLA.

Paso 7: Requisitos previos de la reunión para los SLA

Los expertos en el desarrollo del SLA TIC identificaron tres requisitos previos a SLA acertado.
Desafortunadamente, las organizaciones que no alcanzan estos objetivos pueden esperar
problemas con el proceso SLA y deberán considerar los problemas potenciales involucrados en el
proceso SLA. El no poder implementar los SLA no es perjudicial si la organización de
interconexión de redes puede construir las definiciones de nivel de servicio que cumplen los
requisitos comerciales generales. Los siguientes son requisitos previos para el proceso de SLA:

● Su negocio debe contar con una cultura orientada al servicio.La organización debe poner las
necesidades de los clientes en primer lugar. Necesita un compromiso de prioridad verticalista
con el servicio, con lo que se obtiene una comprensión completa de las necesidades y
percepciones del cliente. Encuestas de satisfacción del cliente de la conducta e iniciativas
adaptadas a las necesidades del clien del servicio.Otro indicador del servicio puede ser que
la satisfacción del servicio o del soporte de estados de la organización como objetivo
corporativo. Esto no es poco común debido a que ahora, las organizaciones de IT están
críticamente relacionadas al éxito general de las organizaciones.La cultura de servicio es
importante porque el proceso SLA se trata principalmente de realizar mejoras según las
necesidades y los requerimientos del negocio del cliente. Si organizaciones no han están
hechos esto en el pasado, encontrarán el proceso de SLA difícil.
● El cliente/las iniciativas de negocios debe conducir todas las actividades TIC.La visión de la
compañía o los enunciados de la misión deben estar alineados con las iniciativas del cliente y
del negocio que luego conducen a todas las actividad de IT, incluyendo los SLA. Con mucha
frecuencia, una red es colocada en un lugar para alcanzar un objetivo en particular aunque el
grupo de conexión en red pierde de vista ese objetivo y los posteriores requisitos
comerciales. En estos casos, un presupuesto del conjunto se afecta un aparato a la red, que
puede reaccionar exageradamente a las necesidades actuales o subestima grueso el
requisito, dando por resultado el error.Cuando las iniciativas comerciales/de clientes se
alinean con las actividades de informática, la organización de la red puede estar en sintonía
con los desarrollos, nuevos servicios y otros requerimientos comerciales más fácilmente. La
relación y las metas comunes generales de cumplir con los objetivos corporativos están
presentes y todos los grupos funcionan como un equipo.
● Usted debe confiar al proceso de SLA y al contrato.El primer allí debe ser consolidación para
aprender el proceso de SLA para desarrollar los acuerdos efectivos. En segundo lugar, debe
cumplir con los requisitos de servicio del contrato. No espere crear los SLA potentes sin la
entrada y la consolidación significativas de todos los individuos implicados. Esta
consolidación debe también venir de la Administración y de todos los individuos asociados al
proceso de SLA.

Paso 8: Determine los partidos implicados en el SLA

Los SLA de redes del nivel empresarial dependen pesadamente de los elementos de redes, los
elementos de la administración de servidores, soporte del servicio de ayuda, los elementos de la
aplicación, y negocio o los requisitos del usuario. La Administración de la cada área estará
implicada normalmente en el proceso de SLA. Este escenario funciona bien cuando la
organización construye SLA de soporte reactivos básicos. Las organizaciones corporativas con
los requisitos de mayor disponibilidad pueden necesitar la asistencia técnica durante el proceso
de SLA de ayudar con los problemas tales como el presupuesto de disponibilidad, las limitaciones
de rendimiento, el perfil de aplicación, o las capacidades de administración proactiva. Para más
aspectos SLA de la administración proactiva, recomendamos a un equipo técnico de arquitectos
de la red y de arquitectos de aplicación. La asistencia técnica puede ofrecer información mucho
más aproximada sobre la disponibilidad y las capacidades de rendimiento de la red y lo que se
necesitaría para lograr objetivos específicos.

El proveedor de servicio SLA no incluye normalmente la entrada de usuario porque se crean con
el único propósito de ganar una ventaja competitiva en otros proveedores de servicio. En algunos
casos, la administración superior creará estos SLA en los niveles muy de gran disponibilidad o de
alto rendimiento para promover su servicio y para proporcionar las metas internas para los
empleados internos. Los proveedores de servicios se concentrarán en los aspectos técnicos de
disponibilidad de mejoras mediante la creación de definiciones de niveles de servicios fuertes que
son medidos y administrados internamente. En otros casos, ambos esfuerzos ocurren
simultáneamente pero no no necesariamente juntos o con las mismas metas.

Elegir los partidos implicados en SLA se debe entonces basar en las metas de SLA. Algunos
objetivos posibles son:

● Lograr los objetivos comerciales del soporte reactivo

● Proporcionando al del más alto nivel de la Disponibilidad definiendo los SLA dinámicos
● Promoción o venta de un servicio

Paso 9: Determine los elementos de servicio

Comúnmente, el servicio primario/soporte de los SLA tendrá muchos componentes, los cuales
incluyen el nivel de soporte, la forma en la que será medido, el trayecto de escalación para la
reconciliación de SLA y las preocupaciones relacionadas con el presupuesto general. Los
elementos de servicio para entornos de alta disponibilidad deben incluir definiciones de servicios
proactivos, así como objetivos reactivos. Los detalles adicionales incluyen el siguiente:

● Horas hábiles de soporte en el sitio y los procedimientos de soporte fuera de horario.

● Definiciones de las prioridades, incluyendo el tipo de problema, el tiempo máximo de
comenzar el trabajo sobre el problema, tiempo máximo para resolver el problema, y los
Procedimientos de escalada
● Productos y servicios con soporte, categorizados por orden de criticidad comercial.
● Soporte para expectativas de destreza, expectativas de nivel de rendimiento, generación de
informes de estado y responsabilidades del usuario en la solución de problemas
● Problemas y requisitos geográficos o de la unidad comercial del Nivel de soporte
● Metodología y procedimientos de administración de problemas (sistema de seguimiento de
llamadas)
● Metas del escritorio de ayuda
● Respuesta de la Detección de errores en la red y del servicio
● Disponibilidad de la red de la medida e información
● Capacidad de la red y medición de rendimiento e información
● Procedimientos de la resolución de conflicto
● Financiamiento del SLA implementado
La aplicación conectada en red o el servicio SLA puede tener necesidades adicionales basadas
en los requisitos y el carácter crítico del negocio del grupo de usuarios. La organización de la red
debe escuchar de cerca a estos requisitos comerciales y desarrollar las soluciones especializadas
que caben en la estructura de soporte total. El caber en la cultura total del soporte es crítico
porque es importante no crear un servicio preferencial previsto solamente para algunos individuos
o grupos. En muchos casos, estos requisitos adicionales se pueden poner en las categorías de la
“solución”. Un ejemplo pudo ser un platino, un oro, y una mejor solución basada en la necesidad
comercial. Consulte los siguientes ejemplos de requisitos SLA para cubrir necesidades
comerciales específicas.

Note: La estructura de soporte, el trayecto de escalada, los procedimientos del servicio de ayuda,
la medida, y las definiciones de las prioridades deben seguir siendo en gran parte lo mismo para
mantener y para mejorar una cultura del servicio coherente.

● Requerimientos de ancho de banda y capacidades para la explosión

● Requisitos de rendimiento
● Requisitos y definiciones de QoS
● Requerimientos de disponibilidad y Redundancia de construir la matriz de soluciones
● Supervisión y requerimientos de notificación, metodología, y procedimientos
● Criterios de la actualización para los elementos de la aplicación/de servicio
● Requisitos de financiamiento del out-of-budget o metodología de cruz-carga
Por ejemplo, usted puede crear las categorías de solución para la conectividad de sitios WAN. La
solución platino se proporcionaría con servicios twin T1 para el sitio. Un diverso portador
proporcionaría cada línea T1. El sitio tendrá dos routers configurados para que, en caso de que
algún T1 o router falle, el sitio no sufra interrupción. El servicio del oro tendría dos Routers, pero
el Frame Relay de backup sería utilizado. Esta solución podría tener un ancho de banda limitado
durante la interrupción. La mejor solución tendría un solo router y un servicio de portadora.
Ninguno de estos soluciones serían consideradas para diversos niveles de prioridad para los
boletos del problema. Algunas organizaciones pueden necesitar una solución de platino o de oro
si se requiere un ticket de prioridad 1 ó 2 para una interrupción. Las organizaciones del cliente
pueden entonces financiar el nivel de servicio que requieren. La siguiente tabla muestra un
ejemplo de una organización que ofrece tres niveles de servicio, según la necesidad que presente
la empresa de una conectividad de red externa.

Solució
Platino Oro Plata
n
Routers Ninguna
Router redundante
redundante redundan
Disposit para realizar copias de
s para cia del
ivos seguridad en el sitio
conectivida dispositiv
central
d WAN o
Conectivid
ad Ninguna
Conectividad T1 con el
redundante redundan
WAN backup de Frame
T1, cia de
Relay
portadoras WAN
múltiples
Requeri T1 NON-carga que
mientos redundante comparte, backup de
de con Frame Relay para las
ancho distribución aplicaciones críticas Hasta T1
de de carga solamente; Frame
banda y para Relay 64K CIR
explosió ráfaga. solamente
n
Tiempo de Ms del
respuesta tiempo de
de ida y Tiempo de respuesta respuesta
Rendimi
vuelta 100 ms o un 99.9% 100 o el
ento
constante menos esperado. 99%
100-ms o menos
menos previsto
Requeri
miento
de 99.99% 99.95% 99.9%
disponi
bilidad
Priorida Prioridad 1:
Prioridad
d del el servicio
3:
escritori de Prioridad 2: el servicio
conectivid
o de importanci de impacto comercial
ad
ayuda a comercial está fuera de servicio
comercial
cuando no
abajo
abajo funciona

Paso 10: Información sobre las Necesidades y los Objetivos Corporativos del Cliente

Este paso le otorga al desarrollador de SLA gran credibilidad. Entendiendo las necesidades de los
diversos grupos empresariales, el documento inicial de SLA será mucho más cercano al requisito
comercial y al resultado deseado. Intente entender el costo de tiempo de inactividad para el
servicio de cliente. Estimación en términos de productividad perdida, ingresos, y fondo de
comercio del cliente. Tenga presente que incluso las conexiones simples con algunas personas
pueden afectar seriamente los ingresos. En este caso, esté seguro de ayudar al cliente a
entender la Disponibilidad y los riesgos de rendimiento que pueden ocurrir de modo que la
organización entienda mejor el nivel de servicio que necesita. Si usted falta este paso, usted
puede conseguir a muchos clientes que exigen simplemente la Disponibilidad 100-percent.

El desarrollador SLA también debería entender los objetivos del negocio y el crecimiento de la
organización para alojar actualizaciones de red, la carga de trabajo y el presupuesto. Es también
útil entender las aplicaciones que serán utilizadas. Esperanzadamente la organización tiene
perfiles de aplicación en cada aplicación, pero si no, considere hacer una evaluación técnica de la
aplicación para determinar los problemas relacionados con la red.

Paso 11: Defina SLA requerido para cada grupo

El soporte primario de SLA debe incluir unidades comerciales cruciales y representación de

grupos funcionales, como operaciones de red, operaciones de servidor y grupos de soporte de
aplicaciones. Estos grupos deben reconocerse de acuerdo con las necesidades comerciales y rol
que tienen en el proceso complementario. Teniendo representación de muchas ayudas de los
grupos también cree una solución de soporte del equitativo y general sin la preferencia o la
prioridad del grupo individual. Esto puede llevar a una organización de soporte a ofrecer un
servicio de primera a grupos individuales, un escenario que puede obstaculizar la cultura de
servicio en general de la organización. Por ejemplo, un cliente pudo insistir que su aplicación sea
la más crítica dentro de la sociedad cuando en la realidad el costo de tiempo de inactividad para
esa aplicación es perceptiblemente menos que otros en términos de ingresos perdidos,
productividad perdida, y fondo de comercio del cliente perdido.

Diversas unidades comerciales dentro de la organización tendrán diversos requisitos. Un objetivo

de SLA de red debe ser acordar un formato integral que se ajuste a los distintos niveles de
servicio. Estos requisitos son generalmente Disponibilidad, QoS, funcionamiento, y MTTR. En el
SLA de red, estas variables son manejadas dando prioridad a las aplicaciones comerciales para
QoS potencial que ajusta, definiendo las prioridades del servicio de ayuda para el MTTR de
diversos problemas de red-afectación, y desarrollando una matriz de soluciones que ayude a
manejar la diversos Disponibilidad y requisitos de rendimiento. Un ejemplo de una matriz de la
solución simple para una compañía fabricante de la empresa puede parecer algo la tabla
siguiente. Puede agregar información sobre la disponibilidad, Calidad de servicio (QoS) y
rendimiento.

Prioridad
Costo de de Requisito
Unidad tiempo de problema de
Aplicaciones
comercial inactivida s cuando Servidor/
d desciend Red
e
Redunda
Fabricaci
ERP Alto 1 ncia más
ón
alta
Redunda
Soporte Atención al
Alto 1 ncia más
de cliente cliente
alta
Servidor de Redunda
archivos, ncia del
El dirigir Medio 2
diseño de núcleo
ASIC LAN
Redunda
Comercia Servidor de ncia del
Medio 2
lización archivos núcleo
LAN

Paso 12: Elija el formato de SLA

El formato del SLA puede variar según los deseos del grupo o los requisitos de la organización.
Lo que sigue es un ejemplo recomendado delinea para el SLA de red:

1. Objetivo del acuerdoPartes involucradas en el acuerdoObjetivos y objetivos para el acuerdo

2. Servicios brindados y productos admitidosServicio y Seguimiento de llamada del servicio de
ayudaDefiniciones de la gravedad de los problemas basadas en el impacto comercial para
las definiciones MTTRPrioridades del servicio técnico comercial crítico para las definiciones
de QoSCategorías de solución definidas basadas en la Disponibilidad y los requisitos de
rendimientoRequisitos de entrenamientoRequisitos de la planificación de
capacidadRequisitos de escalaciónInformesSoluciones de red proporcionadasNuevas
peticiones de la soluciónProductos incompatibles o aplicaciones
3. Políticas de negociosSoporte durante las horas hábilesdefiniciones del soporte de la
Después-horaCobertura durante un feriadoNúmeros de teléfono de contactoPronóstico de
carga de trabajoResolución conciliatoriaCriterios de asignación de
 servicios.Responsabilidades de seguridad del usuario y el grupo
4. Procedimientos para la administración de problemasIniciación de llamada (usuario y
automatizado)Relación de transformación de primer nivel de la reparación de la respuesta y
de la llamadaSeguimiento de llamada y registroResponsabilidades del llamadorDiagnósticos
de problemas y requerimientos del cierre de llamadaDetección del problema de
administración de red y respuesta del servicioDefiniciones o categorías de resolución de
problemasDirección de problema crónicaManejo de llamadas del problema crítico/de la
excepción
5. Objetivos de calidad del servicioDefiniciones de la calidadDefiniciones de mediciónMetas de
calidadTiempo intermedio para iniciar la solución de problemas por la prioridad de
problemasTiempo promedio para resolver el problema por la prioridad de problemasTiempo
intermedio para substituir el hardware por la prioridad de problemasDisponibilidad de la red y
funcionamientoManejo de la capacidadManejo del crecimientoGeneración de informes de
calidad
6. Personal y presupuestosModelos de incorporación de personalpresupuesto de operaciones
7. Mantenimiento de acuerdoHorario del estudio de la conformidadInformación y estudio del
funcionamientoReconciliación de las mediciones de informeActualizaciones periódicas de
SLA
8. Aprobaciones
9. Conexiones y objetos expuestosDiagramas de flujo de llamadasMatriz de escaladaMatriz de
la solución de redEjemplos de informe

Paso 13: Desarrolle a los grupos de trabajo SLA

El siguiente paso es identificar a los participantes en el grupo de trabajo SLA, incluido el líder del
grupo. El grupo de trabajo puede incluir a usuarios y administradores de unidades comerciales,
grupos funcionales o representantes de una base geográfica. Estos individuos comunican los
problemas de SLA a sus respectivos grupos de trabajo. Los administradores y los responsables
que pueden estar de acuerdo con los elementos dominantes de SLA deben participar. Estos
individuos puede incluir individuos administradores así como técnicos que pueden ayudar a definir
problemas técnicos relacionados con SLA y tomar decisiones a nivel de IT (es decir,
administrador del escritorio de ayuda, administrador de operaciones del servidor, administradores
de aplicaciones y administrador de operaciones de la red).

El grupo de trabajo SLA de la red debería también consistir en aplicaciones amplias y

representaciones comerciales con el propósito de obtener un acuerdo sobre una red SLA que
incluya muchas aplicaciones y servicios. El grupo de trabajo debe tener la autoridad para alinear
los procesos y los servicios del negocio crítico para la red, así como Disponibilidad y los requisitos
de rendimiento para los servicios individuales. Se utilizará esta información para crear prioridades
para diferentes tipos de problemas que impacten a la empresa, para priorizar el tráfico comercial
crítico en la red y para crear soluciones futuras de redes estándar basadas en los requerimientos
de la empresa.

Paso 14: Celebre a las reuniones de grupo de trabajo y elabore SLA

El grupo de trabajo debería crear un estatuto de grupo de trabajo al comienzo. El informe debe
mostrar los objetivos, las iniciativas y las tramas de tiempo para SLA. El grupo debe desarrollar
los planes específicos de la tarea y determinar después los programas y los calendarios para
desarrollar y implementar el SLA. El grupo debe también desarrollar el proceso de la información
para medir el Nivel de soporte contra los criterios del soporte. El último paso está creando el
acuerdo de SLA del proyecto.

El grupo de trabajo en red SLA debería reunirse una vez por semana para desarrollar el SLA.
Después de que se haya creado y se haya aprobado SLA, el grupo puede resolver la publicación
mensual o aún trimestralmente para las actualizaciones de SLA.

Paso 15: Negocie SLA

El último paso para crear el SLA es la negociación final y la firma. Este paso incluye:

● Repaso del proyecto

● Negociación del contenido
● Editando y revisando el documento
● Obtención de la aprobación final
Este ciclo de revisión del borrador, negociación de contenidos y edición puede requerir varios
ciclos antes de que la versión final se envíe a la administración para su aprobación.

De la perspectiva del administrador de la red, es importante negociar los resultados realizables

que pueden ser medidos. Intente respaldar los acuerdos de rendimiento y disponibilidad con
aquellos de otras organizaciones relacionadas. Esto puede incluir las definiciones de la calidad,
las Definiciones de medición, y los objetivos de calidad. Recuerde que el servicio agregado es
equivalente a un costo extra. Aseegurese que los grupos de usuarios entienden que los niveles
adicionales de servicio costarán más y los dejan tomar la decisión si es un requisito comercial
crítico. Puede realizar fácilmente un análisis de los costos en varios aspectos del SLA, tales como
el tiempo de reemplazo del hardware.

Paso 16: Conformidad de SLA de la medida y del monitor

La conformidad de SLA y los resultados de medición el señalar son los aspectos importantes del
proceso de SLA que ayudan a asegurar la coherencia a largo plazo y los resultados.
Recomendamos generalmente que cualquier componente importante de SLA sea mensurable y
que una metodología de medición esté establecida antes de la implementación del SLA. Después
celebre a las reuniones mensuales entre el usuario y los grupos de soporte para revisar las
medidas, identifique las causas raíz del problema, y proponga las soluciones para cumplir o para
exceder el requisito de nivel de servicio. Esto ayuda a hacer el proceso de SLA similar a cualquier
programa de mejora de la calidad moderno.

La sección siguiente proporciona al detalle adicional en cómo la Administración dentro de una

organización puede evaluar sus SLA y su Service Level Management total.

Indicadores de rendimiento de la administración de nivel de

servicio
Los indicadores de rendimiento de la administración del nivel de servicio brindan un mecanismo
para monitorear y mejorar los niveles de servicio como medida del éxito. Esto permite que la
organización reaccione más veloz a los problemas de servicio y comprenda más fácilmente los
problemas que impactan al servicio o el costo de tiempo caído en su entorno. La medición de las
definiciones de nivel de servicio también niega cualquier trabajo proactivo positivo hecho porque
la organización es forzada en una posición reactiva. Nadie llamará decir el servicio es trabajo
grande, pero muchos usuarios llamarán decir el servicio en no cumplir sus requisitos.

Los indicadores de rendimiento de la administración de niveles de servicio son, por lo tanto, el

requisito principal para la administración de niveles de servicio, dado que proporcionan los medios
para comprender cabalmente los niveles de servicio existentes y para realizar ajustes en función
de los problemas actuales. Esta es la base para brindar soporte proactivo y hacer mejoras en la
calidad. Cuando la organización realiza un análisis sobre el origen de los problemas y optimiza la
calidad, ésta puede ser la mejor metodología a fin de mejorar la disponibilidad, el rendimiento y la
calidad de servicio disponibles.

Por ejemplo, considere el escenario real siguiente. La compañía X conseguía las denuncias de
los numerosos usuarios que la red fuera con frecuencia abajo por los períodos ampliados.
Midiendo la Disponibilidad, la compañía encontró el problema principal para ser algunos sitios
PÁLIDOS. La investigación más detallada de esas vistas reveló que la mayor parte de los
problemas estaban en algunos sitios PÁLIDOS. La causa raíz fue encontrada y la organización
resolvió el problema. Luego, la organización estableció objetivos de nivel de servicio para la
disponibilidad y celebró acuerdos con grupos de usuarios. Problemas identificados de las
mediciones futuras rápidamente debido a la inconformidad a SLA. Entonces vieron al grupo de
interconexión de redes como teniendo el mayor profesionalismo, la experiencia, y un recurso
general a la organización. El grupo se movió efectivamente de reactivo a proactivo en naturaleza
y la línea inferior de la compañía colaboró en esto.

Desafortunadamente, la mayoría de las organizaciones de redes cuentan con definiciones

limitadas de niveles de servicio y no poseen indicadores de rendimiento. Como consecuencia,
pasan la mayor parte de su tiempo que reacciona a las quejas del usuario o a los problemas en
vez dinámico de identificar la causa raíz y de construir un servicio de red que cumpla los
requisitos comerciales.

Utilice los siguientes indicadores de rendimiento de SLA para determinar el éxito del proceso de
administración de niveles de servicio:

● Definición de nivel de servicio documentada o SLA que incluye la Disponibilidad, el

funcionamiento, el tiempo de respuesta del servicio reactivo, los objetivos de la solución de
problemas, y el incremento de la gravedad de los problemas
● Las mediciones de indicador de rendimiento, incluyen disponibilidad, rendimiento, tiempo de
respuesta del servicio por medio de prioridad, tiempo para resolver por prioridad y otros
parámetros de SLA que se pueden medir.
● Reuniones del Service Level Management de la conexión de redes mensual para revisar la
conformidad del nivel de servicio y para implementar las mejoras

Service Level Agreement o definición de nivel de servicio documentado

El primer indicador de rendimiento es simplemente un documento que detalla el SLA o la

definición del nivel de servicio. Los objetivos primordiales de la definición de nivel de servicio
deben ser la disponibilidad y el rendimiento dado que son los requisitos principales de los
usuarios.

Los objetivos secundarios son importantes porque ayudan a definir cómo se alcanzarán los
niveles de disponibilidad o rendimiento. Por ejemplo, si la organización tiene la disponibilidad
agresiva y objetivos de rendimiento, será importante evitar que los problemas ocurran y reparar
los problemas rápidamente cuando ocurren. Los objetivos secundarios ayudan a definir los
procesos necesarios para alcanzar la Disponibilidad y los niveles de rendimiento deseados.
Los objetivos secundarios reactivos incluyen:

● Tiempo de respuesta de servicio reactivo por prioridad de llamada

● Objetivos de la solución de problemas o MTTR
● Procedimiento para el incremento de la gravedad de los problemas.
Los objetivos secundarios proactivos incluyen:

● Detección del dispositivo-abajo o de la conexión abajo

● Detección de errores en la red
● Detección de la capacidad o del problema de rendimiento.
La definición del nivel de servicio para metas primarias, disponibilidad y rendimiento debe incluir:

El objetivo

● Cómo la meta será medida

● Partidos responsables de medir la Disponibilidad y el funcionamiento
● Partes responsables de los objetivos de disponibilidad y rendimiento
● Procesos de no conformidad
Si es posible, recomendamos que los partidos responsables de la medida y los partidos
responsables de los resultados sean diferentes prevenir un conflicto de intereses. De vez en
cuando, él que usted puede también necesitar para ajustar los números de disponibilidad debido
a agrega/los errores del movimiento/del cambio, errores no detectados, o problemas de la
medición de disponibilidad. La definición del nivel de servicio también puede incluir un proceso
para la modificación de resultados que ayude a mejorar la exactitud y prevenir ajustes
inapropiados. Consulte la siguiente sección sobre las metodologías para medir disponibilidad y
rendimiento.

La definición de nivel de servicio para objetivos secundarios reactivos especifica cómo

responderá la organización a problemas de IT o la red, una vez que se hayan identificado, que
incluyen:

● Definiciones de la prioridad de problemas

● Tiempo de respuesta de servicio reactivo por prioridad de llamada
● Objetivos de la solución de problemas o MTTR
● Procedimientos para el incremento de la gravedad de los problemas
Estas metas definen generalmente quién serán responsable de los problemas cualquier cualquier
momento y en qué medida esos responsables debe caer sus tareas actuales de trabajar en los
problemas definidos. Como las definiciones de nivel del otro servicio, el documento del nivel de
servicio debe detallar cómo las metas serán medidas, los partidos responsables de la medida, y
los procesos de no conformidad.

La definición del servicio para objetivos secundarios proactivos, define cómo la organización
proporciona soporte proactivo, incluyendo las condiciones de identificación de caída de la red, del
link o de los dispositivos, las condiciones de error de la red y los umbrales de capacidad de la red.
Fije las metas que promueven la administración proactiva porque las ayudas de la administración
proactiva de la calidad eliminan los problemas y las ayudas reparan los problemas más
rápidamente. Generalmente se logra esto fijando un objetivo de la cantidad de casos proactivos
creados y resueltos sin notificación del usuario. Muchas organizaciones configuran un indicador
en el software del escritorio de ayuda para identificar los casos proactivos contra el para este
propósito de los casos reactivos. El documento de nivel del servicio debería contener también
información sobre la forma en que se medirá el objetivo, las partes responsables de la medición y
los procesos de no conformidad.

Métricas del Indicador de rendimiento

Siempre recomendamos que toda meta definida de nivel de servicio sea cuantificable, de manera
tal que la organización pueda medir los niveles de servicio, identificar los problemas de causas
raíz del servicio que dificultan la meta principal de disponibilidad y desempeño y efectuar mejoras
dirigidas a objetivos específicos. A nivel general, las mediciones son sólo una herramienta que
permite a los administradores de la red gestionar la coherencia en el nivel de los servicios y hacer
mejoras de acuerdo a los requerimientos comerciales.

Desafortunadamente, muchas organizaciones no recolectan información sobre la disponibilidad,

el rendimiento y otras mediciones. Las organizaciones atribuyen esto a la incapacidad para
proporcionar la exactitud, el coste, la tara de red, y a los recursos disponibles completos. Estos
factores pueden impactar en la capacidad de medición de los niveles de servicio, pero la
organización debe concentrarse en los objetivos generales de administración y mejora de esos
niveles. Muchas organizaciones han podido crear barato, la métrica de los bajo-gastos indirectos
que no puede proporcionar la exactitud completa, pero satisfacen estos objetivos principales.

La Disponibilidad y el funcionamiento de medición es una área descuidada a menudo en la

métrica del nivel de servicio. Las organizaciones que implementan exitosamente estas métricas
usan dos métodos bastante simples. Un método consiste en enviar paquetes de ping de Protocolo
de control de mensajes de Internet (ICMP) desde una ubicación central en la red hacia los bordes.
También puede obtener rendimiento a través de este método. Las organizaciones que son
exitosas con este método también agrupan dispositivos parecidos en "grupos de disponibilidad",
como dispositivos LAN u oficinas de campo domésticas. Esto es también atractivo porque las
organizaciones tienen generalmente diversos objetivos de nivel de servicio para diversas áreas
geográficas o de negocio crítico de la red. Esto permite que las métricas promedien todos los
dispositivos con el grupo de disponibilidad para obtener un resultado razonable.

El otro método exitoso para calcular la disponibilidad es utilizar tickets de problema y una
medición denominada minutos de usuarios impactados (IUM). Este método tabula la cantidad de
usuarios que han sido afectados por una interrupción y lo multiplica por la cantidad de minutos de
la interrupción. Cuando se expresa como un porcentaje de minutos totales en el periodo, se
puede convertir fácilmente a disponibilidad. En ambos casos, puede también ser útil identificar y
medir la causa raíz del tiempo muerto para poder apuntar más fácilmente la mejora. Las
categorías de causas de los problemas incluyen problemas de hardware, software, link o
portadora, potencia o entorno, fallas de cambios y errores de los usuarios.

Los objetivos de soporte reactivo mensurables incluyen:

● Tiempo de respuesta de servicio reactivo por prioridad de llamada

● Objetivos de la solución de problemas o MTTR
● Tiempo del problema de escalación
Objetivos de soporte reactivo de la medida generando los informes de las bases de datos del
escritorio de ayuda, incluyendo los campos siguientes:

● La hora en que se informó una llamada inicialmente (o se ingresó a la base de datos).

● La hora en que la persona que estaba trabajando en el problema aceptó la llamada
● El tiempo que el problema fue extendido
● El tiempo el problema era cerrado
Estas métricas pueden requerir la influencia de la administración para ingresar regularmente
problemas en la base de datos y actualizarlos en tiempo real. En algunos casos, las
organizaciones pueden generar automáticamente los ticketes de problemas para los eventos de
red o las peticiones del email. Esto ayuda a proporcionar la exactitud para identificar la hora de
inicio de un problema. Normalmente, los informes generados desde este tipo de métrica clasifican
los problemas por prioridad, grupo de trabajo y personas para ayudar a determinar los problemas
potenciales.

Que mide el soporte proactivo los procesos es más difícil porque le requiere monitorear el trabajo
proactivo y calcular una cierta medida de su eficacia. Poco trabajo se ha hecho en esta área. Está
claro, sin embargo, que solamente un pequeño porcentaje de la gente señalará realmente los
problemas de red a un escritorio de ayuda, y cuando señalan el problema, tomará tiempo
claramente para explicar el problema o para aislar el problema como siendo relacionado a la red.
No todos los casos proactivos tendrán un efecto inmediato sobre la Disponibilidad y el
funcionamiento debido al error de dispositivos redundantes o de links tendrá poco impacto en los
usuarios finales.

Las organizaciones que implementan las definiciones o acuerdos de nivel de servicio proactivos
hacen eso a causa de los requisitos comerciales y el riesgo potencial de disponibilidad. La medida
entonces se hace en términos de cantidad o porcentaje de los casos proactivos, en comparación
con los casos reactivos que son generados por los usuarios. Es una buena idea medir la cantidad
de casos proactivos en la cada área también. Estas categorías incluirían dispositivos inactivos,
links inactivos, errores de red y violaciones de capacidad. También se puede realizar un trabajo
con el modelado de la disponibilidad y los casos proactivos para determinar el efecto en la
disponibilidad logrado al implementar las definiciones de servicio proactivo.

Revisión de la administración de nivel de servicio

Otra medida de éxito del Service Level Management es el estudio del Service Level Management.
Esto debe hacerse ya sea que existan o no SLA (contratos de nivel de servicio). Ejecute la
revisión de la administración de nivel de servicio en una reunión mensual con individuos
responsables de medir y proveer niveles de servicios definidos. Los grupos de usuarios pueden
también estar presentes en que los SLA están implicados. El objetivo de la reunión es evaluar el
rendimiento de las definiciones del nivel de servicio medido y realizar mejoras.

Cada reunión debe tener un orden del día definido que incluya:

● Revisión de los niveles de servicio para el período determinado.

● Revise las iniciativas de mejora definidas para las áreas individuales.
● Métrica actual del nivel de servicio
● Una discusión de qué mejoras son necesarias sobre la base del conjunto de métricas
actuales.
En un cierto plazo, la organización puede también tender la conformidad del nivel de servicio para
determinar la eficacia del grupo. Este proceso no es distinto a un círculo de calidad o proceso de
mejoramiento de calidad. La reunión ayuda a identificar problemas individuales y a determinar
soluciones basadas en la causa raíz.

Resumen de administración de nivel de servicio

En resumen, el Service Level Management permite que una organización se mueva desde un
modelo de soporte reactivo a un modelo de soporte proactivo donde la disponibilidad de la red y
los niveles de rendimiento son determinados por los requisitos comerciales, no por el último
conjunto de los problemas. El proceso ayuda a crear un entorno de mejoras continuas en el nivel
del servicio continua y aumenta la competitividad comercial. El Service Level Management es
también el componente de administración más importante para la Administración de la red
proactiva. Por este motivo, el Service Level Management se recomienda altamente en cualquier
fase del planeamiento de red y de diseño y debe comenzar con nuevamente la arquitectura de
red definida. Este permite que la organización implemente soluciones de forma correcta desde la
primera vez, con la menor cantidad de tiempo de inactividad o de corrección.

Información Relacionada
● Soporte Técnico - Cisco Systems