Manuel d'implémentation › Exemples d'étude de cas › Exemples de modélisation de contrat › Etude de cas 3 : Temps de réponse du système

Etude de cas 3 : Temps de réponse du système

L'étude de cas suivante illustre des métriques de temps de réponse. Un contrat peut être modelé de plusieurs façons, chacune ayant ses avantages.

L'exemple suivant examine diverses méthodes de modélisation :

D'après la matrice susmentionnée, comment le niveau de service réel est-il calculé ?

D'après la définition de la catégorie de domaine, il semble que le niveau de service réel soit calculé comme valeur maximale. Cela implique que, parmi toutes les transactions accomplies pendant un mois, la transaction ayant la valeur maximale est capturée et cette valeur est comparée à la cible.

Remarque : Le calcul du niveau de service se fonde sur une agrégation de données brutes pendant une période donnée. Pendant chaque période, la métrique fournit un résultat unique. La cible d'une métrique n'est pas comparée à une transaction unique, mais à un résultat mensuel qui est une agrégation périodique de toutes les transactions durant cette période. Le gestionnaire de contrats doit veiller à ce que ce résultat reflète, d'une part, le contrat, et, d'autre part, la qualité du service.

Notez que la mesure du temps de réponse comme valeur maximale est une obligation très stricte et très difficile à accomplir en pratique. Mesurer un niveau maximal signifie qu'une transaction unique de 751 ms sur un million de transactions réalisées au cours d'un mois suffit pour causer une infraction du contrat. Toutes les barres dans les rapports seront par conséquent rouges et ne refléteront pas la qualité réelle du service qui a été fourni.

L'illustration suivante décrit un rapport typique dans ces circonstances.

Une transaction qui dépasse la cible sera considérée comme violation du contrat. C'est une très mauvaise base pour estimer la qualité réelle du service fourni, car elle reflète uniquement une transaction unique et rien n'apparaît quant au reste des transactions. Par exemple, s'agit-il d'une défaillance unique ou d'une tendance ? S'il ne s'agit pas d'un incident isolé, combien de défaillances ont-elles été constatées ou quelle est la proportion de transactions échouées par rapport au nombre total de transactions accomplies au cours du mois ? Il peut y avoir un certains nombre de mois présentant de telles occurrences, qui constituent ainsi une violation du contrat, mais quelle est la tendance ? S'améliore-t-elle ou s'aggrave-t-elle ? Voilà autant de questions que le gestionnaire de niveau de service peut poser et le rapport doit pouvoir lui fournir des réponses.

Remarque : En définissant la métrique et le descriptif de calcul s'y rapportant, il est très important d'envisager comment les résultats s'afficheront dans un rapport. Ce rapport doit fournir deux éléments cruciaux :

• Y-a-t-il eu infraction au contrat ?
• Le rapport doit offrir aux gestionnaires suffisamment de transparence au niveau des données et de capacité pour examiner la cause première de la défaillance et leur apporter les outils nécessaires pour comprendre pleinement leurs composants de service.

Le calcul du temps de réponse moyen donne une meilleure idée de la qualité mensuelle de service et peut à la fois encore refléter ces mois avec des temps de réponse extrêmes ou hors-contrat.

Dans le cadre de cette méthode, le calcul détermine le pourcentage de transactions qui ont été correctement accomplies sous le seuil des 750 ms pendant la période spécifiée, donnée par la formule :

((Nombre de transactions en dessous de 750 ms.)/Nombre total de transactions))*100

L'expression de la garantie en taux de réussite fournit la capacité de conserver une garantie stricte (cible 100 %), tout en tenant également compte de la valeur réelle représentant la qualité du service.

Avec cette méthode, la cible n'est désormais plus une limite supérieure de 750 ms, mais la proportion à maintenir. Dans les cas où la garantie doit être stricte, la cible doit être de 100 %, ce qui ne laisse aucune place à la défaillance. Remarquez que, dans ce cas, une variable supplémentaire est introduite, à savoir le paramètre de la métrique. Ce paramètre doit être mis en oeuvre comme paramètre de métrique pour activer des modifications simples, le cas échéant.

L'imposition d'un modèle de type progressif peut présenter un modèle de type escalade :

Les solutions suivantes définissent trois métriques au lieu d'une métrique unique, comme dans les solutions précédentes.

S'il est nécessaire de signaler l'obligation contractuelle, ainsi que le nombre de transactions dépassant le seuil des 750 ms, vous devez définir une métrique supplémentaire pour calculer le nombre de transactions qui ont échoué.

Remarque : Chaque métrique génère un résultat unique pendant une période donnée. Si elle est définie pour calculer le pourcentage de transactions, elle ne peut pas également fournir le nombre de transactions.

La seule façon de produire des rapports supplémentaires à partir d'une métrique est d'utiliser les sorties de la logique applicative. (Consultez la section Sorties - Tables utilisateur qui traite de la sortie des résultats de la logique applicative).