Disponibilidad : Alta disponibilidad

Service Level Management: Informe oficial de Mejores Prácticas

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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 resuelto históricamente los requisitos de la red de extensión por las infraestructuras de red sólidas constructivas y el trabajo reactivo de 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íticos

Los factores de éxito críticos 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 las bases mensuales 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.

Nota: 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.

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/15117-highlevel.gif

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

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, el Tiempo 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 a dar prioridad a las iniciativas de mejora de la red y a 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 el tiempo de convergencia sub-segundo 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 restricción Impacto potencial
Las herramientas disponibles de la detección DOS no pueden detectar todos los tipos de ataques DOS. Tecnología/resistencia Alto
No tenga el personal y el proceso requeridos a reaccionar a las alertas. Prácticas del ciclo vital Alto
Las políticas de acceso de la red actual no son en el lugar. Prácticas del ciclo vital Medio
La conexión de Internet actual del bajo-ancho de banda puede ser un factor si la congestión de ancho de banda se utiliza para el ataque. Capacidad de la red Medio
Actualmente la Configuración de seguridad a ayudar a prevenir los ataques puede no ser completa. Tecnología/resistencia Medio

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. Disponibilidad

    • 1 - (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 disponibilidad

    1 – 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 hardware

    La 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 software

    La á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éctrica

    Debe 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 las 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 portadora

    El 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 la 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 tienen también 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 los muy poco de 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 red

    El 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.

    Nota: 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 proceso

    Las 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 disponibilidad

    Puede 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 Disponibilidad

    • La disponibilidad de software usando como referencia la confiabilidad del software GD = 99.9999 % de disponibilidad

    • Ambiental y disponibilidad de alimentación eléctrica con los sistemas de reserva el = 99.999 por ciento de Disponibilidad

    • Falla de link en el entorno LAN el = 99.9999 por ciento de Disponibilidad

    • System Switchover Time no descompuesto en factores el = 100 por ciento de Disponibilidad

    • Error de usuario y disponibilidad de proceso perfectos = disponibilidad del 100 por ciento

    El 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 la disponibilidad debido 4X 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 los conocimientos 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.

Área de red Disponibilidad de la blanco Método de medición Blanco media del tiempo de respuesta de la red Tiempo de respuesta máximo validado Método de la medición de tiempo de respuesta
LAN 99.99% Minutos de usuario impactados Menos de 5 ms 10 ms Respuesta de ping de ida y vuelta
WAN 99.99% Minutos de usuario impactados Menos de 100 ms (ping de ida y vuelta) 150 ms Respuesta de ping de ida y vuelta
WAN crítico y extranet 99.99% Minutos de usuario impactados Menos de 100 ms (ping de ida y vuelta) 150 ms Respuesta de ping de ida y 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 proactivas 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.

Gravedad 1 Gravedad 2 Gravedad 3 Gravedad 4
Sitio WAN crítico severo del usuario de LAN o del segmento del servidor del impacto comercial abajo abajo Alto impacto comercial con la pérdida o la degradación, LAN de oficina central en el lugar de la solución alternativa posible abajo; 5-99 usuarios afectaron al impacto PÁLIDO internacional del rendimiento crítico del sitio del sitio del WAN local abajo abajo Una cierta funcionalidad de la red específica se pierde o se degrada, por ejemplo la redundancia LAN afectada funcionamiento del LAN de oficina central de la pérdida de redundancia perdida Una interrogación o un incidente funcional que no tienen ningún impacto comercial para la organizació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.

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

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:

Gravedad del problema Respuesta del escritorio de ayuda Respuesta de Nivel 2 Nivel 2 en el sitio Reemplazo de hardware Solución del problema
1 Escalación inmediata a la grada 2, administrador de las operaciones de la red 5 minutos 2 horas 2 horas 4 horas
2 Escalación inmediata a la grada 2, administrador de las operaciones de la red 5 minutos 4 horas 4 horas 8 horas
3 15 minutos 2 horas 12 horas 24 horas 36 horas
4 15 minutos 4 horas 3 días 3 días 6 días

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 los conocimientos del problema en Administración y pueden ayudar generalmente a llevar a dinámico futuro o a las medidas preventivas. Vea la tabla siguiente:

Tiempo transcurrido Gravedad 1 Gravedad 2 Gravedad 3 Gravedad 4
5 minutos Administrador de las operaciones de la red, soporte de la grada 3, director de interconexiones de red      
1 hora Actualizar al administrador de operaciones de red, soporte de nivel 3, director de interconexiones de red Actualizar al administrador de operaciones de red, soporte de nivel 3, director de interconexiones de red    
2 horas Extiéndase al VP, actualización al director, administrador de operaciones      
4 horas El análisis de la causa raíz no resuelto que se efectuó a VP, director, administrador de operaciones y soporte de nivel 3 requiere notificación de CEO Extiéndase al VP, actualización al director, administrador de operaciones    
24 horas     Administrador de las operaciones de la red  
5 días       Administrador de las operaciones 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.

Área de red Relación de identificación del problema proactivo Relación de transformación reactiva de la Identificación del problema
LAN el 80% 20%
WAN el 80% 20%

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.

Dispositivo de red o link abajo Método de detección notificación 5 x 8 7 x 24 notificación resolución 5 x 8 Resolución 7 x 24
LAN del núcleo Dispositivo SNMP y consulta de links, trampas El NOC crea el ticket de problemas, localizador de tareas de LAN de la página El localizador de tareas de LAN de las Páginas automáticas, persona de tareas de LAN crea el ticket de problemas para la cola del LAN del núcleo Analista LAN asignado en el plazo de 15 minutos por el NOC, reparación según la definición de respuesta del servicio Prioridades 3 y de las prioridades 1 y 2 resolución e investigación inmediata cola 4 para la resolución posterior
WAN local Dispositivo SNMP y consulta de links, trampas El NOC crea el ticket de problemas, llamar al radiolocalizador de WAN en servicio El localizador de tareas de WAN de las Páginas automáticas, persona de tareas de WAN crea el ticket de problemas para la cola PÁLIDA Analista de WAN asignado en 15 minutos por NOC, reparación como definición de respuesta por servicio. Prioridades 3 y de las prioridades 1 y 2 resolución e investigación inmediata cola 4 para la resolución posterior
Extranet Dispositivo SNMP y consulta de links, trampas El NOC crea el ticket de problemas, localizador de tareas del partner de página El localizador de tareas del partner de las Páginas automáticas, persona del deber del partner crea el ticket de problemas para la cola del partner Analista asociado asignado dentro de los 15 minutos por NOC, reparación según definición de repuesta del servicio Prioridades 1 y 2 resolución e investigación inmediata; Las prioridades 3 y 4 quedan pendientes para resolverse luego

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 proactivos 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 los conocimientos generales 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ía de error Método de detección Umbral Acción realizada
Errores de software (caídas forzadas por el software) Estudio diario de los mensajes de Syslog usando el visor de Syslog hecho por el soporte de la grada 2 Cualquier ocurrencia para prioridad 0, 1, y 2 sobre 100 acontecimientos del nivel 3 o arriba Revise el problema, cree un ticket con el inconveniente y envíelo si vuelve a ocurrir o si el problema requiere atención
Errores de hardware (caídas forzadas por el hardware) Estudio diario de los mensajes de Syslog usando el visor de Syslog hecho por el soporte de la grada 2 Cualquier ocurrencia para prioridad 0, 1, y 2 sobre 100 acontecimientos del nivel 3 o arriba Revise el problema, cree un ticket con el inconveniente y envíelo si vuelve a ocurrir o si el problema requiere atención
Errores del protocolo (IP Routing Protocol solamente) Estudio diario de los mensajes de Syslog usando el visor de Syslog hecho por el soporte de la grada 2 Diez mensajes por el día de las prioridades 0, 1, y 2 sobre 100 acontecimientos del nivel 3 o arriba Revise el problema, cree un ticket con el inconveniente y envíelo si vuelve a ocurrir o si el problema requiere atención
Errores de control de medios (FDDI, POS, y fast ethernet solamente) Estudio diario de los mensajes de Syslog usando el visor de Syslog hecho por el soporte de la grada 2 Diez mensajes por el día de las prioridades 0, 1, y 2 sobre 100 acontecimientos del nivel 3 o arriba Revise el problema, cree un ticket con el inconveniente y envíelo si vuelve a ocurrir o si el problema requiere atención
Mensajes del entorno (poder y temporeros) Estudio diario de los mensajes de Syslog usando el visor de Syslog hecho por el soporte de la grada 2 Cualquier mensaje Cree el ticket de problemas y el envío para los nuevos problemas
Errores de precisión (errores de entrada del link) Consulta SNMP en cinco minutos los eventos de umbral de los intervalos recibidos por el NOC Errores de entrada o salida un error en cinco minutos el intervalo en cualquier link Cree el ticket de problemas para los nuevos problemas y envío al soporte de la grada 2

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 los conocimientos técnicos profundizados 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 los conocimientos generales 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:

  • Conocimientos 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 para 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 los conocimientos 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 red/media Método de detección Umbral Acción realizada
Estructura básica y links de distribución del LAN de oficina central Consulta SNMP en cinco minutos los desvíos de la excepción de los intervalos RMON en la base y los links de distribución utilización del 50% en cinco minutos la utilización de los intervalos el 90% vía el desvío de la excepción Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del requisito de QoS o del plan por problemas recurrentes
Links del WAN local Consultas SNMP en intervalos de 5 minutos 75 % de utilización en intervalos de 5 minutos Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del requisito de QoS o del plan por problemas recurrentes
Links de WAN del extranet Consultas SNMP en intervalos de 5 minutos utilización del 60% en cinco minutos los intervalos Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del requisito de QoS o 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.

         
Cisco 7500 CPU, memoria, buffers Consulta SNMP en la notificación de RMON de los intervalos -5-minute para el CPU CPU en el 75% durante cinco minutos los intervalos, el 99% vía la memoria de la notificación de RMON en el 50% durante cinco minutos los buffers de los intervalos en la utilización del 99% La notificación por correo electrónico al grupo del email del funcionamiento y de la capacidad alias para resolver los problemas o la actualización RMON CPU del plan en el 99%, el ticket de problemas y la grada 2 del lugar de la página soporta el paginador
Cisco 2600 CPU, memoria Consultas SNMP en intervalos de 5 minutos CPU en el 75% durante cinco minutos la memoria de los intervalos en el 50% durante cinco minutos los intervalos Notificación por correo electrónico al grupo del email del funcionamiento y de la capacidad alias para resolver los problemas o la actualización del plan
Catalyst 5000 Utilización de backplane, memoria Consultas SNMP en intervalos de 5 minutos Backplane en la memoria de la utilización del 50% en la utilización del 75% Notificación por correo electrónico al grupo del email del funcionamiento y de la capacidad alias para resolver los problemas o la actualización del plan
Switch ATM de LightStream� 1010 CPU, memoria Consultas SNMP en intervalos de 5 minutos CPU en la memoria de la utilización del 65% en la utilización del 50% Notificación por correo electrónico al grupo del email del funcionamiento y de la capacidad alias para resolver los 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 el 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 red/media Método de medición Umbral Acción realizada
LAN de oficina central Ningunos ningún problema contaban con difícil medir la infraestructura LAN entera tiempo de respuesta de viaje de ida y vuelta de 10 milisegundos o menos en todo momento Notificación por correo electrónico al grupo del email del funcionamiento y de la capacidad alias para resolver la actualización del problema o del plan
Links del WAN local Medición actual del SF al NY y del SF a Chicago solamente usando el eco ICMP del Internet Performance Monitor (IPM) tiempo de respuesta de ida y vuelta 75-millisecond hecho un promedio durante cinco minutos el período Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del requisito de QoS o del plan por problemas recurrentes
de San Francisco a Tokyo Medición actual de San Francisco a Bruselas usando el IPM y el eco ICMP tiempo de respuesta de ida y vuelta 250-millisecond hecho un promedio durante cinco minutos el período Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del requisito de QoS o del plan por problemas recurrentes
San Francisco a Bruselas Medición actual de San Francisco a Bruselas usando el IPM y el eco ICMP tiempo de respuesta de ida y vuelta 175-millisecond hecho un promedio durante cinco minutos el período Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del requisito de QoS o del plan por problemas 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ón Método de medición Umbral Acción realizada
Puerto TCP 1529 Bruselas de la aplicacion de planificación de recursos para empresas (ERP) al SF Bruselas a San Francisco usando el gateway de Bruselas de medición del rendimiento de ida y vuelta del puerto 1529 IPM al gateway SFO 2 tiempo de respuesta de ida y vuelta 175-millisecond hecho un promedio durante cinco minutos el período Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del problema o del plan por problemas recurrentes
Puerto TCP 1529 Tokio de la aplicación ERP al SF Bruselas a San Francisco usando el gateway de Bruselas de medición del rendimiento de ida y vuelta del puerto 1529 IPM al gateway SFO 2 tiempo de respuesta de ida y vuelta 200-millisecond hecho un promedio durante cinco minutos el período Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del problema o del plan por problemas recurrentes
Puerto TCP 1702 Sydney de la aplicación de soporte de cliente al SF Sydney a San Francisco usando el gateway Sydney de medición del rendimiento de ida y vuelta del puerto 1702 IPM al gateway SFO 1 tiempo de respuesta de ida y vuelta 250-millisecond hecho un promedio durante cinco minutos el período Notificación por correo electrónico al grupo del email del funcionamiento alias para evaluar la actualización del problema o del plan por problemas 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. Midiendo el 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 directamente para mantener 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 proactivas. 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 de 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.

Nota: 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 para 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ón Platino Oro Plata
Dispositivos Routers redundantes para conectividad WAN Router redundante para realizar copias de seguridad en el sitio central Ninguna redundancia del dispositivo
WAN Conectividad redundante T1, portadoras múltiples Conectividad T1 con el backup de Frame Relay Ninguna redundancia de WAN
Requerimientos de ancho de banda y explosión T1 redundante con distribución de carga para ráfaga. NON-carga que comparte, backup de Frame Relay para las aplicaciones críticas solamente; Frame Relay 64K CIR solamente Hasta T1
Rendimiento Tiempo de respuesta de ida y vuelta constante 100-ms o menos Tiempo de respuesta 100 ms o un 99.9% menos esperado. Ms del tiempo de respuesta 100 o el 99% menos previsto
Requerimiento de disponibilidad 99.99% 99.95% 99.9%
Prioridad del escritorio de ayuda cuando abajo Prioridad 1: el servicio de importancia comercial no funciona Prioridad 2: el servicio de impacto comercial está fuera de servicio Prioridad 3: conectividad comercial abajo

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.

Unidad comercial Aplicaciones Costo de tiempo de inactividad Prioridad de problemas cuando desciende Requisito de Servidor/Red
Fabricación ERP Alto 1 Redundancia más alta
Soporte de cliente Atención al cliente Alto 1 Redundancia más alta
El dirigir Servidor de archivos, diseño de ASIC Medio 2 Redundancia del núcleo LAN
Comercialización Servidor de archivos Medio 2 Redundancia del 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 acuerdo

    • Partes involucradas en el acuerdo

    • Objetivos y objetivos para el acuerdo

  2. Servicios brindados y productos admitidos

    • Servicio y Seguimiento de llamada del servicio de ayuda

    • Definiciones de la gravedad de los problemas basadas en el impacto comercial para las definiciones MTTR

    • Prioridades del servicio técnico comercial crítico para las definiciones de QoS

    • Categorías de solución definidas basadas en la Disponibilidad y los requisitos de rendimiento

    • Requisitos de entrenamiento

    • Requisitos de la planificación de capacidad

    • Requisitos de escalación

    • Informes

    • Soluciones de red proporcionadas

    • Nuevas peticiones de la solución

    • Productos incompatibles o aplicaciones

  3. Políticas de negocios

    • Soporte durante las horas hábiles

    • definiciones del soporte de la Después-hora

    • Cobertura durante un feriado

    • Números de teléfono de contacto

    • Pronóstico de carga de trabajo

    • Resolución conciliatoria

    • Criterios de asignación de servicios.

    • Responsabilidades de seguridad del usuario y el grupo

  4. Procedimientos para la administración de problemas

    • Iniciación de llamada (usuario y automatizado)

    • Relación de transformación de primer nivel de la reparación de la respuesta y de la llamada

    • Seguimiento de llamada y registro

    • Responsabilidades del llamador

    • Diagnósticos de problemas y requerimientos del cierre de llamada

    • Detección del problema de administración de red y respuesta del servicio

    • Definiciones o categorías de resolución de problemas

    • Dirección de problema crónica

    • Manejo de llamadas del problema crítico/de la excepción

  5. Objetivos de calidad del servicio

    • Definiciones de la calidad

    • Definiciones de medición

    • Metas de calidad

    • Tiempo intermedio de iniciar la solución de problemas por la prioridad de problemas

    • Tiempo promedio para resolver el problema por la prioridad de problemas

    • Tiempo intermedio de substituir el hardware por la prioridad de problemas

    • Disponibilidad de la red y funcionamiento

    • Manejo de la capacidad

    • Manejo del crecimiento

    • Generación de informes de calidad

  6. Personal y presupuestos

    • Modelos de incorporación de personal

    • presupuesto de operaciones

  7. Mantenimiento de acuerdo

    • Horario del estudio de la conformidad

    • Información y estudio del funcionamiento

    • Reconciliación de las mediciones de informe

    • Actualizaciones periódicas de SLA

  8. Aprobaciones

  9. Conexiones y objetos expuestos

    • Diagramas de flujo de llamadas

    • Matriz de escalada

    • Matriz de la solución de red

    • Ejemplos 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 encargados 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 el 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 los recursos generales 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.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 15117