Souvent, lors de présentations que je donne, j’aborde la notion de performance de la plateforme SharePoint en termes de SLA (Service Level Agreement ou accord de niveau de service).
Cette notion n’est pas nouvelle mais, transposée aux systèmes informatiques, elle ouvre de nouveaux horizons.
Quel est l’objectif du SLA, pour un IT, au sein de l’organisation qui l’emploie ?
Il s’agit de garantir la disponibilité du système informatique et remédier aux périodes d’indisponibilité en fonction de l’investissement que l’organisation est prête à faire en matière de hardware et de personne.
Ainsi, on parlera de SLA à 90 %, 99 % jusqu’à, ce qui est considéré comme ce qu’il se fait de mieux, 99.99999 %
Néanmoins, et surtout pour des raisons financières, garantir un SLA de 99.999 % est déjà une obligation fort contraignante, comme nous allons le voir.
Plantons tout d’abord le décor, en précisant quels sont les termes utilisés, outre SLA en matière de disponibilité de système informatique :
· Temps de réponse (response time)
· La robustesse (robustness)
· La capacité à monter en charge (scalability)
· Disponibilité (availability)
On parle d’architecture à haute disponibilité à partir d’un SLA de 99.99%
Pour chiffrer cette disponibilité, il est nécessaire de déterminer les bons paramètres :
· L’uptime : c’est la période de temps ou le système fonctionne correctement, depuis son démarrage ou son redémarrage
· Le MTBF (mean time between failures) : c’est le temps moyen entre deux interruptions de service. Ce MTBF ne prend pas en compte les pannes récurrentes dues, par exemple, aux défauts de fabrication du hardware ou à son usure.
· L’AFR (annualized Failure Rate) qui représente le nombre de composants à changer chaque année
· Le dowtime qui représente la période de temps ou le service n’est pas assuré
· Le MTTR (mean time to repair) représente le temps moyen nécessaire à la réparation et à la restauration du service
· L’AST (agreed service time) qui est, en fait, l’accord que vous avez avec l’organisation au sujet des exigences de continuité de service.
Il existe plusieurs méthodes pour calculer le temps de disponibilité (D), celle que j’utilise est celle-ci
D = 
L’organisation calculera plutôt de cette façon :
D = 
Une troisième façon de calculer sera
D = 
Comment améliorer notre SLA ?
En améliorant le MTBF par exemple. Ceci peut être fait en assurant la redondance du hardware (router, firewall, carte réseau…), la redondance du l’infrastructure logicielle (Network Load Balancing, SQL clustering…)
Il est possible de réduire le MTTR en assurant la formation des équipes chargées de la maintenance, tant logicielle que hardware, en définissant des procédures claires et détaillées et en utilisant des procédures de monitoring (ce point particulier fera l’objet d’un article détaillé dans le futur proche)
A titre d’exemple, vous trouverez dans le tableau ci-dessus les temps d’indisponibilité réels en fonction du pourcentage de SLA
| Downtime |
| Disponibilité | En sec. Par an | En min par an | En heures par an | En jours par an |
| 90 % | 3 155 760 | 52 596 | 877 | 37 |
| 98 % | 631 152 | 10 519 | 175 | 7 |
| 99 % | 315 576 | 5 260 | 88 | 4 |
| 99.8 % | 63 115 | 1 052 | 18 | |
| 99.9 % | 30 558 | 526 | 9 | |
| 99.99 % | 3 156 | 53 | | |
| 99.999% | 316 | 5 | | |
| 99.9999 % | 32 | | | |
| 99.99999 % | 3 | | | |
Ainsi donc, pour répondre à un SLA de 99.999 %, cela veut dire que votre système ne pourra pas être indisponible pendant plus de 5 minutes par an. Ce SLA est plus communément utiliser et porte le nom de « Règle de 5 neufs ».
Plus le pourcentage de SLA sera haut, plus l’effort en termes humains et de matériel sera élevé.
A vos calculatrices…