Guía de implementación › Ejemplos de casos prácticos › Ejemplos de modelado del contrato › Caso práctico 3: Tiempo de respuesta del sistema

Caso práctico 3: Tiempo de respuesta del sistema

El siguiente caso práctico ilustra las métricas de tiempo de respuesta. Los contratos se pueden modelar de varias maneras, cada una con sus propias ventajas.

El ejemplo siguiente examina los diversos métodos de modelado:

En base a la matriz superior, ¿cómo se calcula el nivel de servicio real?

En base a la definición de la categoría del dominio, parece que el nivel de servicio real se calcula como un valor máximo. Esto implica que, para todas las transacciones realizadas durante un mes, se captura la transacción con el valor máximo y este valor se compara con el destino.

Nota: El cálculo del nivel de servicio se basa en una agregación de datos sin procesar en un período de tiempo dado. Para cada período de tiempo, la métrica proporciona un solo resultado. El destino de una métrica no se compara con una sola transacción, sino que se compara con un resultado mensual que corresponde a la agregación periódica de todas las transacciones dentro de ese período. El gestor de contratos debe asegurarse de que este resultado refleja el contrato por un lado y la calidad del servicio por otro.

Tenga en cuenta que medir el tiempo de respuesta como valor máximo es una obligación muy estricta y muy difícil de lograr en la práctica. Medir un nivel máximo significa que una sola transacción de 751 ms entre un millón de transacciones llevadas a cabo durante el curso de un mes es suficiente como para generar una infracción del contrato. Todas las barras en los informes aparecerán por lo tanto en rojo y no reflejarán la calidad real del servicio que se ha proporcionado.

La ilustración siguiente muestra un informe típico en estas circunstancias.

Cualquier transacción que supere el destino se considerará una infracción del contrato, pero como base para entender que la calidad del servicio real proporcionada es muy pobre, ya que solamente refleja una sola transacción y no se sabe nada respecto al resto de las transacciones, como por ejemplo si era un único error o una tendencia. Si no era un incidente aislado, entonces ¿cuántos errores hubo? ¿o cuál es la tasa de transacciones erróneas con respecto al número total de transacciones realizadas durante el mes? Esos resultados pueden incluir varios meses y, por consiguiente, una infracción del contrato, ¿pero cuál es la tendencia? ¿Está mejorando o empeorando? Todas estas son preguntas que el gestor de nivel de servicio podría realizar, y el informe deberá ser capaz de proporcionar las respuestas.

Nota: Al definir la métrica y el esquema de cálculo asociado, es muy importante imaginar cómo aparecerán los resultados en un informe. Este informe debe proporcionar dos elementos cruciales:

• Si se ha producido una infracción del contrato.
• Debe proporcionar a los gestores suficiente transparencia en los datos y capacidad para investigar la causa raíz del error, así como debe darles las herramientas necesarias para entender completamente sus componentes de servicio.

Calcular el tiempo de respuesta medio da una idea mejor de la calidad de servicio mensual, al tiempo que puede reflejar esos meses con tiempos de respuesta extremos o fuera de contrato.

Mediante este método, el cálculo será el porcentaje de transacciones correctamente completadas bajo el umbral de 750 ms durante el período especificado según la fórmula:

((Número de transacciones bajo 750 ms.)/(Total de transacciones))*100

Expresar la garantía como una tasa de éxito proporciona la capacidad de conservar una garantía estricta (destino 100 %), mientras que también permite indicar el valor real que representa lo bueno o malo que fue el servicio.

Mediante este método, el destino no es ahora un límite superior de 750 ms, sino la tasa que debe mantenerse. En casos en los que la garantía deba ser estricta, el destino deberá ser 100 %, lo cual no deja lugar para siquiera un solo error. En este caso se ha introducido una variable adicional, el parámetro de métrica. Este parámetro se deberá implementar como un parámetro de métrica para permitir hacer modificaciones sencillas, si fuera necesario.

Un modelo alternativo a este método puede ser imponer un modelo de tipo escalación:

Las soluciones siguientes definen tres métricas en lugar de una sola métrica, como ocurría en las soluciones anteriores.

En caso de que sea necesario comunicar la obligación contractual, así como el número de transacciones que superen el umbral de 750 ms, es necesario definir una métrica adicional para contar el número de transacciones erróneas.

Nota: Cada métrica genera un solo resultado en un período de tiempo dado. Si se establece para calcular el porcentaje de transacciones, no puede proporcionar también el número de transacciones.

La única forma de producir informes adicionales desde una métrica es utilizar las salidas de la lógica de negocios. (Consulte Salidas: tablas de usuario para obtener más información acerca de los resultados de la lógica de negocios).