Au moment de faire héberger son site web ou d’externaliser son système d’information, une étape capitale consiste à définir précisément ses attentes en termes de niveaux de services, ou SLA en bon franglais (Service Level Agreement).
L’exercice peut prêter à confusion, voici donc un guide des principales notions et des points de vigilance.
Nous allons nous concentrer sur les SLA les plus importants: PSG (Plage de Service Garanti), GTR (Garantie de Temps de Rétablissement), taux de disponibilité et RPO (Recovery Point Objective).
Cet article est un peu long mais le diable est dans les détails, et nous avons essayé de tout couvrir afin qu’après sa lecture vous soyez parfaitement à l’aise pour votre prochain appel d’offres.
La PSG ou Plage de Service Garanti
C’est le point de départ de toute définition des SLA. Sur quelle plage horaire avez vous besoin que le service soit garanti et disponible :
- Combien de jours par semaine: 5, 6 ou 7J/7 ?
- Sur quels horaires: des horaires de bureau standards 8h-18h, étendus 7h30-19h30, ou du 24h/24 ?
La plage de service garanti est la durée pendant laquelle le prestataire hébergeur vous garantit la disponibilité du service et sera engagé à le rétablir dans le délai maximum prévu pour la GTR, ou Garantie de Temps de Rétablissement, que nous verrons plus bas.
La question à se poser est celle de l’usage du service. Si votre application est utilisée par votre personnel, et potentiellement vos clients ou votre public, uniquement pendant les heures de bureau, une PSG 8h-18h peut très bien vous convenir.
Mais s’il s’agit d’un site internet consulté par le grand public, il devra être accessible 7j/7 et probablement sur des horaires beaucoup plus larges, comme 7h-24h, voire 24h/24.
En dehors de la PSG, en général le service n’est pas coupé, le prestataire le laisse fonctionner, mais il est libre d’utiliser cette période pour réaliser des opérations de maintenance, et il n’est pas tenu de rétablir immédiatement le service en cas d’incident.
La PSG permet de calculer une durée annuelle qui va nous servir pour calculer le taux de disponibilité. Par exemple :
- 8h-18h en 5j/7 = 10h/j x 5j x 52semaines (en faisant abstraction des jours fériés) = 2,600h/an
- 24h/24 en 7j/7 = 24h x 365j (en faisant abstraction des jours fériés) = 8,760h/an
La GTR ou Garantie de temps de rétablissement
La GTR est le délai maximum sur lequel s’engage le prestataire pendant la PSG pour rétablir le service à la suite d’un incident ou coupure de service. C’est bien une durée maximum, et le prestataire rétablira souvent le service dans un délai plus court, mais c’est celui sur lequel il s’engage contractuellement car il a mis en œuvre les moyens adéquats pour le respecter.
Avec une GTR de 4h, un incident intervenu à 10h30 un jeudi matin avec une PSG 8h-18h 5j/7 doit être corrigé avant 14h30.
Mais le même incident intervenu à 16h un jeudi devra contractuellement être corrigé pour le lendemain vendredi avant 10h car les 4h des GTR vont courir sur les 2h entre 16h et 18h, puis les 2h entre 8h et 10h le lendemain.
Le même incident, intervenu à 19h un vendredi, devra contractuellement être corrigé pour le lundi avant 12h car il s’est produit après la fin de la PSG. Hors PSG, les alertes de supervision ne remonteront pas, et le samedi et le dimanche n’étant pas inclus dans la PSG, le prestataire commencera à traiter l’incident le lundi matin à l’ouverture de la PSG.
A l’inverse, l’incident intervenu un vendredi à 16h avec une PSG 24/7 devra être résolu le vendredi à 20h.
On voit ainsi que le choix de la PSG et de la GTR doit être défini absolument de concert.
Dans le cas d’une application ou site web grand public, une PSG en horaires standards expose le site à rester indisponible tout le week-end. Il faut sérieusement se poser la question si c’est acceptable par exemple pour un site marchand, un site commercial d’une grande marque, ou le site d’une collectivité locale qui informe ses administrés.
La notion d’incident bloquant ou de coupure de service
La GTR ne s’applique que pour un incident bloquant, incident critique, ou encore coupure de service : indisponibilité totale de service ou dégradations très fortes, telles que le service est inutilisable (lenteurs très fortes, indisponibilité de fonctionnalités critiques…).
En revanche, un incident non-bloquant, une indisponibilité partielle, un dysfonctionnement d’une fonctionnalité secondaire, un ralentissement non problématique, peuvent faire l’objet d’une GTR plus longue.
Il faut aussi noter que l’incident peut ne pas être de la responsabilité du prestataire : si le peering internet est coupé entre deux fournisseurs d’accès internet, le prestataire ne pourra être tenu pour responsable du fait que les clients de tel opérateur ne peuvent accéder au site.
Le taux de disponibilité
Le taux de disponibilité , en général calculé annuellement (mais il peut aussi l’être sur une durée plus courte trimestrielle ou mensuelle), est le rapport entre le temps minimum pendant lequel le service est disponible et 100% de la PSG.
En fait, on calcule l’indisponibilité maximum autorisée, et on en déduit le taux de disponibilité par différence. A noter que cette indisponibilité annuelle doit être évaluée en ayant en tête la GTR, nous verrons pourquoi.
Premier exemple pour une PSG 8h-18h 5J/7 soit 2,600h/an avec une GTR de 4h :
- un taux de disponibilité de 99% nous donne 26h d’indisponibilité potentielle par an, soit environ 6,5 fois la GTR,
- un taux de 99,5% nous donne 13h d’indisponibilité potentielle par an, soit un peu plus de 3 fois la GTR,
- un taux de 99,7% nous donne un peu moins de 8h d’indisponibilité par an, soit environ 2 fois la GTR,
- un taux de 99,9% nous donne moins de 3h d’indisponibilité par an, ce qui est inférieur à la GTR et donc incohérent, l’un ou l’autre doivent être revus.
Deuxième exemple pour une PSG 24/7 soit 8760 h/an avec un GTR de 4h :
- un taux de disponibilité de 99% nous donne 87h d’indisponibilité potentielle par an, soit environ 20 fois la GTR,
- un taux de 99,5% nous donne 43h d’indisponibilité par an, soit environ 10 fois la GTR,
- un taux de 99,7% nous donne 26h d’indisponibilité par an, soit environ 6 fois la GTR,
- un taux de 99,9% nous donne 9h d’indisponibilité potentielle par an, soit un peu plus de 2 fois la GTR,
- un taux de 99,95% nous donne 4h20 d’indisponibilité potentielle par an, soit à peine plus d’une fois la GTR de 4h ou 2 fois une GTR ramenée à 2h.
On voit tout de suite que l’étendue de la PSG a un impact direct sur le taux de disponibilité. Avec la même infrastructure, le taux de disponibilité sera toujours inférieur avec une PSG moins étendue qu’en 24/7.
On voit aussi qu’un taux égal ou supérieur à 99,5% implique des mécanismes de haute disponibilité très performants, et exclut toute dépendance à l’égard d’une panne physique. Un hébergement à base de serveur physique sans redondance est à proscrire. Il faut s’orienter vers une solution de serveur virtuel en haute disponibilité, ou un cluster au minimum en actif/passif.
Une autre conséquence est que le taux de disponibilité doit respecter une certaine proportionnalité avec la GTR et le nombre maximum d’incidents que l’on pense pouvoir tolérer par an. On voit dans l’exemple du 24/7 qu’un taux de 99,95% n’est réaliste que si la GTR peut être réduite à 2h, ce qui implique que l’infrastructure le permette.
Le périmètre de service couvert par les SLA
Ce point est absolument capital et malheureusement le plus souvent mal compris. Bon nombre de prestataires entretiennent la confusion. Nous allons voir comment au travers d’un exemple.
Une collectivité locale ou une agence digitale vient de développer une nouvelle application internet d’information pour le grand public, et elle décide de la faire héberger. Cette application apporte des informations auquel le public va certainement accéder majoritairement sur son temps libre, en soirée ou le week-end. Il faut donc un service 24/7.
L’appel d’offres porte sur la fourniture d’une solution d’infrastructure en 24/7 avec une GTR de 2h maximum et un taux de disponibilité de 99,8%. La question est : sur quoi portent les SLA ? Schématiquement, on peut distinguer trois niveaux :
- La fourniture de l’infrastructure seule : serveurs, réseau, accès internet, stockage, sauvegarde…
- Le premier niveau + la fourniture de l’infrastructure avec l’OS, la configuration serveurs, et souvent l’administration des bases de données.
- Les deux premiers niveau + la disponibilité effective des applicatifs avec des procédures pour relancer ces derniers.
Bien entendu, l’infrastructure doit être opérationnelle en 24/7 mais si l’engagement ne porte que le 1er point, que va-t-il se passer lors d’un incident arrivé le vendredi soir du fait d’une attaque, d’un plantage système ou d’une surcharge applicative temporaire ? Le prestataire va superviser ses serveurs, vérifier que tout est OK, mais laissera le client se charger de relancer l’OS, son applicatif… et ceci peut prendre beaucoup de temps. A supposer que le client soit prévenu et organisé pour intervenir en 24/7, car dans ce cas, le prestataire ne fournira pas de supervision de l’applicatif.
Inversement, un prestataire qui garantit le niveau 3, supervisera la disponibilité l’application par un script, et se chargera de toutes les opérations pour le relancer, ou alertera le client et sa TMA en cas de problème purement applicatif.
Beaucoup de prestataires en mode IaaS ne fournissent que le serveur nu sans se charger de l’administration de l’OS et encore moins des moteurs applicatifs ou de la base de données. Souvent ces offres impliquent aussi que le client mette en place sa supervision pour être alerté des incidents. C’est envisageable, mais il faut alors s’organiser pour assurer la relance de tout ce qui tourne sur le serveur. Il faut donc lire le contrat en détail, vérifier les engagements de service et bien s’interroger sur son organisation et sa capacité d’action pour gérer les incidents en dehors des heures ouvrées.
La GTI ou Garantie de Temps d’Intervention (pour mémoire)
La GTI est le délai dans lequel le prestataire garantit qu’il prend en charge l’incident ou la demande. Disons le tout net, sans GTR, c’est un miroir aux alouettes, une promesse qui n’engage à rien. Elle permet essentiellement d’être informé que votre prestataire est au courant de l’incident et le prend en charge.
Il vaut mieux une GTI inexistante avec une GTR courte, qu’une GTI de 15mn sans engagement de rétablissement.
Le RPO ou Recovery Point Objective
Il n’y a pas de traduction directe du RPO : c’est en quelques sorte la durée de perte de données. Un incident se produit, on doit restaurer l’environnement, à quel dernier point de sauvegarde va-t-on remonter et quelle durée de transactions a t-on perdu ?
Vraies sauvegardes vs Snapshots
Ce point est essentiel et il implique que des sauvegardes soient faites régulièrement et contrôlées tant dans leur périmètre que leur régularité ou leur complétude. Il faut bien distinguer sauvegarde et snapshot. Un snapshot permet de revenir à un état antérieur d’un environnement en cas de mauvaise manipulation mais ce n’est pas une sauvegarde. Une sauvegarde est une image du serveur, des applications et/ou des données, réalisée à intervalle régulier, et stockée sur un espace de stockage distinct. En cas d’incident sur un serveur physique par perte du stockage, corruption, on peut remonter son serveur depuis une sauvegarde alors que les snapshots seront perdus.
En général, le RPO sera à J-1, avec une sauvegarde quotidienne la nuit. Cela peut être insuffisant sur un système qui traite un fort volume de transactions. On peut réduire ce délai :
- à une demi-journée, en réduisant l’intervalle des sauvegardes, en particulier des données,
- ou moins d’une demi-journée, en utilisant des mécanismes propres aux bases de données pour enregistrer les dernières transactions ou établir un cluster.
La plupart des offres à bas coût ne portent que sur le serveur, physique ou virtuel. Aucune sauvegarde n’est déployée en standard. Le client est responsable de mettre en place ses snapshots et potentiellement ses sauvegardes, à supposer qu’elles lui soient proposées et qu’elles soient bien stockées en dehors du serveur. Parfois, l’espace de sauvegarde est sur le même serveur. On perd le serveur, on perd les sauvegardes avec ! Le client doit aussi monitorer ses sauvegardes et tester la restauration.
A défaut, il peut se produire un incident matériel sur le serveur qui sera bien traité pas l’hébergeur dans la GTR, mais le client ne pourra pas remonter son applicatif parce que les données ou le système aura été écrasé et que les sauvegardes ne sont pas disponibles.
Avec un RPO à J-1, on aura peut être perdu une partie des transactions mais on pourra donc remonter son serveur avec l’applicatif dans l’objectif de GTR. Mais sans RPO et capacité à restaurer le serveur ou ses données, la GTR ne sera pas tenue.
Conclusion : cohérence et équilibre des SLA
On voit donc que tout se tient: PSG, GTR, taux de disponibilité et RPO doivent tous être précisés et cohérents entre eux.
Ensuite tout a un coût : plus les SLA seront élevés, plus la solution à mettre en oeuvre sera couteuse. L’inverse est vraie, une solution à bas coûts aura forcément une faille dans les SLA. C’est un peu comme exiger d’un vélo les performances d’une voiture.
Il faut donc viser des SLA équilibrés en fonction de ses objectifs, et surtout s’assurer de la cohérence des SLA entre eux et avec l’architecture proposée. Un hébergement avec un taux de disponibilité à plus de 99,5% sur un serveur physique avec seulement une GTI et pas d’engagement sur les sauvegardes pourra vous placer dans une situation intenable en cas d’incident.
Point capital trop souvent négligé, n’oubliez de préciser les services couverts par vos SLA : juste l’infrastructure et les serveurs, jusqu’à l’OS avec les bases de données et les middlewares, ou alors jusqu’à l’applicatif et le site web. C’est tout particulièrement important si votre applicatif, ou site web, doit être disponible en 24/7.
Enfin mieux vaut des SLA réalistes mais sécurisés, que des promesses mirobolantes mais irréalistes ou sérieusement biaisées qui s’avèreront intenables au moment critique.
Voilà vous savez tout, la suite vient avec la pratique. Vous pouvez aussi nous contacter pour du conseil sur le sujet.
