Le SLA garantit une disponibilité de 99,9 %. Le mois dernier, le système était disponible pendant 99,92 % du temps mesuré, dépassant donc techniquement l’engagement. Pourtant, pendant les 0,08 % restants, le batch de clôture financière n’a pas terminé son exécution dans le délai convenu. Le dashboard SLA était au vert. Le directeur financier a reçu son rapport avec deux heures de retard et n’a pas pu respecter l’échéance prévue pour la réunion du conseil d’administration. Le SLA était respecté. L’engagement, lui, ne l’était pas.
Ce décalage entre ce que le monitoring mesure et ce que le métier s’attend réellement à recevoir est précisément le problème que l’observabilité des SLA cherche à résoudre. Pour y parvenir, il faut mesurer le service au niveau où l’engagement a été pris, et non simplement au niveau où les données sont les plus faciles à collecter.
Pourquoi les métriques d’uptime surestiment systématiquement le respect des SLA
La disponibilité exprimée en pourcentage est un bon point de départ, mais elle ne suffit pas pour mesurer un SLA. Elle masque deux éléments essentiels : le moment où l’indisponibilité s’est produite et ce qu’elle a empêché de fonctionner.
Un système indisponible pendant 43 minutes réparties sur plusieurs fenêtres de maintenance nocturnes, en semaine à 2 h du matin, n’a pas le même impact métier qu’une indisponibilité de 43 minutes à 7 h 30 le premier jour ouvré après la fin du mois, lorsque les utilisateurs consultent les rapports de clôture et que les derniers batchs doivent terminer leur exécution. Dans les deux cas, le pourcentage de disponibilité est identique. Les conséquences métier ne le sont pas.
Une disponibilité pondérée selon le calendrier, qui attribue davantage de poids aux interruptions survenant pendant les périodes critiques, reflète mieux la réalité des environnements SAP où le coût d’une indisponibilité varie fortement selon l’heure ou la période du mois. Une panne de 15 minutes pendant une clôture annuelle peut avoir un impact opérationnel supérieur à quatre heures d’indisponibilité un dimanche matin.
Les SLA qui ne prennent pas en compte cette asymétrie produisent des indicateurs satisfaisants sur le papier, tout en échouant à protéger les processus métier qu’ils sont censés garantir.
Les trois niveaux auxquels les SLA SAP existent réellement
Disponibilité de l’infrastructure : le minimum, pas l’objectif final
La disponibilité de l’infrastructure, autrement dit la possibilité d’accéder au système SAP, constitue la condition minimale pour respecter un SLA. Un système inaccessible échoue nécessairement à tout engagement qui suppose qu’il puisse être utilisé. Mais l’inverse n’est pas vrai : ce n’est pas parce qu’un système est accessible qu’il respecte tous ses engagements.
La disponibilité de l’infrastructure est donc une base indispensable, mais pas une vision complète du service.
Pour la mesurer correctement, il faut commencer par définir ce que signifie exactement « disponible » dans le contrat. Selon une première définition, un système qui répond à un ping réseau est disponible. Selon une définition plus exigeante, le système doit accepter des connexions de dialogue et retourner les résultats des transactions dans un temps de réponse défini.
Une grande partie des désaccords autour des SLA de disponibilité vient simplement du fait que les deux parties utilisent des définitions différentes du même terme.
Performance applicative : le niveau intermédiaire que les SLA définissent souvent mal
Le temps de réponse des transactions de dialogue est la métrique applicative qui reflète le plus directement l’expérience utilisateur. Un système SAP dont l’infrastructure est disponible mais qui affiche des temps de réponse moyens de huit secondes ne respecte aucun engagement de performance raisonnable, même si son indicateur d’uptime ne montre aucune dégradation.
La difficulté vient du fait que le temps de réponse varie selon la transaction, l’heure de la journée, la charge simultanée et les volumes de données traités.
Un SLA qui indique simplement « temps de réponse moyen inférieur à 2 secondes » reste ambigu. Moyenne sur quelles transactions ? Pendant quelles plages horaires ? Avec combien d’utilisateurs simultanés ? Tant que ces paramètres ne sont pas définis, le SLA peut être interprété de différentes manières, notamment en choisissant la méthode de calcul produisant le résultat le plus favorable.
Le SLO, ou Service Level Objective, qui accompagne un SLA de temps de réponse devrait donc définir précisément son périmètre de mesure. Par exemple : le 95e percentile du temps de réponse des transactions standard pendant les heures ouvrées, mesuré toutes les cinq minutes, doit rester inférieur à deux secondes.
Cette définition ne laisse place qu’à une seule interprétation et peut être mesurée de manière cohérente à partir des données de monitoring.
Exécution des processus métier : le niveau que presque aucun SLA ne mesure aujourd’hui
Les engagements dont le métier dépend réellement concernent les processus, pas l’infrastructure.
Le batch de clôture financière doit être terminé avant 6 h le deuxième jour ouvré suivant la fin du mois. Les commandes clients reçues avant 16 h doivent apparaître dans le système de gestion d’entrepôt dans les 30 minutes. Le traitement nocturne des IDocs doit atteindre un taux de réussite supérieur à 99,5 % avant 7 h.
Ce sont des engagements mesurables.
Mais pour les suivre, il faut monitorer l’achèvement des jobs batch, les taux de succès des interfaces et la création des documents métier, et non simplement la disponibilité des serveurs.
Très peu de SLA proposés par les MSP, et très peu d’accords de service internes aux équipes IT, intègrent aujourd’hui ce type de métrique. La raison est simple : les mesurer nécessite de comprendre suffisamment les processus métier pour définir précisément leurs critères de réussite, puis d’instrumenter le monitoring afin de vérifier si ces critères sont respectés.
Les organisations qui définissent et mesurent des SLO au niveau des processus sont celles où la relation entre les équipes IT et les métiers repose sur des données partagées concernant les résultats, plutôt que sur des dashboards d’infrastructure que personne ne comprend complètement.
Mettre en place cette couche de mesure demande davantage de travail que de suivre un pourcentage d’uptime. Mais elle permet aussi de mesurer beaucoup plus honnêtement si le service attendu est réellement fourni.
Le problème du MTTR : mesurer à partir de l’impact, pas de la détection
Le Mean Time to Recover, ou MTTR, est une métrique classique des SLA de gestion des incidents. Il mesure le temps écoulé entre la détection d’un problème et sa résolution. En théorie, un MTTR plus faible signifie que les incidents sont résolus plus rapidement. En pratique, il mesure souvent le mauvais intervalle.
Imaginons qu’un système de production commence à se dégrader à 2 h 15 mais que personne ne détecte le problème avant 4 h 30. Si l’incident est résolu à 5 h, le MTTR mesuré est de 30 minutes.
L’impact réel sur le service a pourtant duré 2 heures et 45 minutes.
Le MTTR de 30 minutes est techniquement correct, mais opérationnellement trompeur.
L’observabilité des SLA appliquée à la gestion des incidents nécessite donc deux mesures distinctes : le temps de détection, entre le début de l’impact et sa première détection, puis le temps de résolution, entre la détection et le rétablissement du service.
Ces deux métriques sont pertinentes. Le MTTR seul sous-estime systématiquement l’impact réel du service lorsqu’il existe un retard de détection, ce qui est le cas dans la majorité des environnements.
Un MSP qui communique un MTTR moyen de 22 minutes sans préciser que le délai moyen de détection est de 90 minutes présente des données exactes, mais dans un cadre qui masque une partie importante de la réalité.
Le temps de détection est également la métrique qui reflète le plus directement la qualité du monitoring. Réduire le délai de détection de 90 minutes à 5 minutes aura généralement beaucoup plus d’impact métier que de réduire le délai de résolution de 30 à 15 minutes.
Mais le temps de détection ne devient une métrique pilotée que lorsqu’il est effectivement mesuré.
| Attention : les SLA qui définissent uniquement un délai de résolution peuvent involontairement encourager à retarder la déclaration officielle d’un incident. Si le chronomètre démarre au moment où le ticket est créé plutôt qu’au début de l’impact, le MTTR mesuré dépend de la rapidité avec laquelle l’équipe ouvre un ticket et non de la durée réelle de dégradation du service. Ce n’est pas nécessairement intentionnel, mais cette méthode favorise systématiquement le prestataire lors d’une revue de SLA. Définissez le début de l’impact dans le SLA, et non l’heure de création du ticket. |
|---|
Ce que les MSP doivent mesurer différemment
Un MSP qui gère les systèmes SAP de plusieurs clients produit ses propres données de monitoring et calcule le respect de ses SLA à partir de cette infrastructure. Le client, lui, dispose de sa propre perception de la qualité du service reçu. Lorsque ces deux perspectives produisent des résultats différents, le désaccord concerne autant la méthodologie de mesure que la qualité réelle du service.
La question de la source de référence est donc importante : en cas de désaccord sur un SLA, quelles données de monitoring font foi ?
Le contrat devrait le préciser. Dans la grande majorité des cas, ce n’est pas le cas.
En l’absence de définition contractuelle, chaque partie présente ses propres chiffres et la résolution du désaccord devient lente et conflictuelle.
Un MSP qui choisit de mesurer les SLA du point de vue du client, c’est-à-dire à partir de données reflétant ce que le client vit réellement plutôt que simplement ce que l’infrastructure indique, supprime une grande partie de ce problème.
Cela signifie mesurer les délais d’exécution depuis la couche des processus métier du client et non uniquement la disponibilité des systèmes. Cela signifie calculer le temps de détection à partir du début de l’impact métier et non au moment où l’alerte du MSP se déclenche. Cela signifie également inclure les taux de succès des IDocs et les fenêtres d’exécution des jobs batch aux côtés de l’uptime des serveurs.
Cette approche nécessite un monitoring plus profond et un investissement plus important pour comprendre suffisamment les processus métier du client et définir les bons SLO.
Mais elle produit également des rapports SLA réellement utiles plutôt que construits uniquement pour démontrer le respect contractuel. Dans un marché où les clients sont de plus en plus sceptiques face aux taux de disponibilité qui n’expliquent pas pourquoi leurs processus ont malgré tout échoué, cette transparence peut devenir un véritable différenciateur commercial.
Les error budgets comme outil concret de gestion des SLA
Un error budget représente la quantité de non-conformité autorisée par un SLA sur une période donnée. Si le SLA de disponibilité mensuelle est de 99,9 %, l’error budget représente environ 43 minutes par mois. Ce budget est consommé chaque fois que le système est indisponible.
Suivre la consommation de cet error budget en temps réel change complètement la dynamique opérationnelle.
Si le monitoring indique que 35 des 43 minutes disponibles pour le mois ont déjà été consommées le mercredi de la troisième semaine, l’équipe dispose d’une information concrète pour prendre une décision : la maintenance planifiée pour le week-end devrait peut-être être reportée ou déplacée vers une période disposant d’un nouveau budget, car son exécution immédiate pourrait consommer la tolérance restante et provoquer une violation du SLA.
Les error budgets permettent également de rendre beaucoup plus concrète la discussion sur la dette technique et les investissements en fiabilité.
Un système qui consomme régulièrement 80 % de son error budget mensuel à cause d’incidents non planifiés a un problème de fiabilité mesurable. Un système qui utilise son error budget principalement pour des maintenances planifiées démontre au contraire une meilleure stabilité.
Cette différence apparaît clairement dans l’évolution des error budgets au fil du temps, bien davantage que dans un simple nombre d’incidents.
Pour les MSP, les error budgets créent également un référentiel commun avec les clients. Les deux parties savent combien de tolérance a déjà été consommée pendant le mois, combien il en reste et si les changements planifiés peuvent être réalisés sans risquer une violation du SLA.
Cette visibilité partagée remplace la mauvaise surprise de la revue SLA de fin de mois par une discussion continue basée sur des données concrètes.
L’infrastructure de monitoring nécessaire à l’observabilité des SLA n’est pas fondamentalement différente de celle utilisée pour le monitoring opérationnel. Elle collecte les mêmes données.
Ce qui change, c’est la manière de les interpréter.
Au lieu de demander si le système est actuellement en bonne santé, l’observabilité des SLA cherche à déterminer si les engagements pris pour le mois sont toujours respectés, si la marge de tolérance est presque épuisée et si les résultats métier dont l’entreprise dépend sont réellement délivrés dans les délais convenus.
Pour y parvenir, il faut définir les SLO avec suffisamment de précision pour qu’ils soient mesurables, instrumenter le monitoring afin de collecter les bonnes métriques au bon niveau et produire des rapports qui montrent le respect des engagements plutôt qu’un simple état de santé de l’infrastructure.
La plupart des déploiements de monitoring savent déjà faire le troisième point.
Les deux premiers sont ceux qui permettent réellement de construire l’observabilité des SLA.
Redpeaks propose des dashboards SLA pour les environnements de services managés SAP, couvrant les fenêtres de disponibilité, les SLO d’exécution des batchs, les taux de succès des interfaces et les temps de détection des incidents, dans un format accessible aussi bien aux équipes opérationnelles qu’aux parties prenantes métier.
