Paramétrer les niveaux de service

Evaluation du SLA

Pour remédier aux défaillances de l’architecture technique et garantir la disponibilité du système d’information (de 90% à 99,99999 %) le SLA dépendra d’un investissement financier adapté, tant en matériel qu’en compétences techniques, proportionnel au niveau de disponibilté souhaité.
Certains critères pour évaluer le SLA :

  • Période de fonctionnement correct depuis le dernier démarrage du système
  • Exigence de continuité de service.
  • Temps moyen entre deux interruptions de service.
  • Nombre de composants à maintenir chaque année
  • Temps moyen de réparation ou restauration du service

Plus le pourcentage de SLA est élevé, plus l’investissement humain et matériel sera conséquent.
La disponibilité d’une application est ce qui généralement fait l’objet d’un SLA. D’autres éléments de performances, comme les temps de réponse de certaines transactions métiers participent d’accords de niveaux de service. La disponibilité se mesure principalement sur les plages d’ouvertures concertées de l’application en rapport aux périodes où le service n’est pas assuré. En fait pour maintenir une architecture technique il faut bien prévoir contractuellement des périodes d’arrêts qui permettent les interventions nécessaires aux évolutions.  Ces périodes ne seront donc pas comptabilisées comme périodes de service non assuré.

Un calcul d’évaluation de la disponibilité pour exemple

(TEMPS d’ouverture concerté) – (TEMPS de service non assuré)
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
(TEMPS d’ouverture concerté)

Par cet exemple, pour une plage d’ouverture de 4h00 à 23h59 ce qui équivaut à 20 * 60 = 1200 min
on détermine lorsqu’un un incident provoque une coupure franche de 30 min, que le taux de disponibilité sera de 97,5 %. Pour la même plage d’ouverture une indisponibilité de 5 min amène à un taux de 99,58 %.  On évalue rapidement par cette illustration que pour obtenir des taux supérieurs à 99 % le temps de résolution d’un incident doit être très réactif !

C’est donc en améliorant la redondance des équipements techniques et logiciels par du clustering et du load balancing que l’on peut se prémunir des défaillances. Toutefois il faut assurer un bon niveau de formation des équipes chargées de l’intégration, de la maintenance et de l’exploitation, puis un transfert de compétences entre tous ces collaborateurs (documents validées et explicites). Pour mener les investigations et réagir de façon réactive il faut disposer d’outils de monitoring et d’un plan de surveillance adaptée à la complexité d’un architecture multi-tiers. C’est à partir de cet investissement que la fiabilité des interventions sur incident sera assurée et performante.

En conséquence plus le pourcentage souhaité est élevé plus l’investissement humain et matériel devra être conséquent !  Il y a un donc un piège à surévaluer l’importance de la disponibilité de son application, sans tenir compte de ce que cela implique pour maintenir en haute disponibilité une application.

Pour évaluer la qualité de service d’une application, les mesures de performances de certaines transactions métiers de référence peuvent compléter la disponibilité, par une vision de la satisfaction des utilisateurs en concurrences lors de certaines plages horaires (de pics de charge).

On peut très bien bâtir plusieurs SLA pour une même application, transactions métiers de référence, accès aux clusters de serveurs, quantité de la bande passante utilisée, temps moyen d’exécution des batchs, ou durée maximale de certains traitement hors TP, nombre de services transactionnels sollicitant la BD, etc…