La plupart des équipes SAP Operations savent très bien monitorer ce qui se passe à l’instant T. Elles configurent des alertes sur des seuils, réagissent aux incidents et ajustent les configurations en fonction des comportements observés. En revanche, il est beaucoup moins courant d’utiliser ces mêmes données de monitoring pour répondre à une autre question : de quoi aurons-nous besoin dans six mois, et quand faut-il commencer à agir pour l’obtenir ?
La planification de capacité consiste à anticiper les futurs besoins d’infrastructure à partir des tendances actuelles. C’est précisément ce que les données de monitoring permettent de faire, mais peu d’équipes le font de manière systématique. Sans cette planification, le scénario est souvent le même : une contrainte devient visible lorsqu’elle est déjà critique, et il faut alors la résoudre dans l’urgence alors que les délais d’achat ou de mise à disposition dépassent le temps restant.
La différence entre monitoring et planification de capacité
Le monitoring répond à la question : que se passe-t-il actuellement ? La planification de capacité répond à une autre question : quand les conditions actuelles vont-elles devenir une contrainte ? Les deux reposent sur les mêmes données, mais l’analyse n’est pas la même.
Un problème de performance concerne le présent : la mémoire HANA est utilisée à 89 % et nécessite une intervention immédiate. Un problème de capacité concerne l’avenir : l’utilisation de la mémoire HANA est passée de 62 % à 74 % en quatre mois et, à ce rythme, atteindra 86 % en mars. Le problème de performance est visible sans analyse de tendance. Le problème de capacité ne l’est que si quelqu’un suit son évolution dans le temps.
Cette distinction est importante, car les délais de réaction sont complètement différents. Un problème de performance peut parfois être résolu en quelques heures en ajustant une configuration, en redémarrant un service ou en réallouant des ressources. Un problème de capacité implique souvent un achat, le provisionnement d’une nouvelle infrastructure ou une modification contractuelle. Ces démarches prennent plusieurs semaines, voire plusieurs mois. Lorsque le problème de capacité commence à ressembler à un problème de performance, il est souvent déjà trop tard pour le résoudre dans le cadre du processus d’achat habituel.
Les métriques qui orientent les décisions de capacité
Mémoire HANA et puissance de calcul de la base de données
Le pic d’utilisation de la mémoire HANA, exprimé en pourcentage de la limite allouée, est le principal indicateur de capacité dans les environnements S/4HANA. La valeur pertinente n’est ni l’utilisation actuelle ni la moyenne quotidienne. C’est le pic observé pendant l’événement générant la charge la plus importante sur chaque période : la clôture mensuelle pour une analyse mensuelle, ou la clôture annuelle pour une analyse annuelle. C’est ce niveau de charge que l’infrastructure doit pouvoir absorber sans contrainte.
Collecter les pics d’utilisation de la mémoire sur six à douze mois permet de faire apparaître une tendance et de déterminer si le système consomme progressivement sa marge de capacité disponible. Une évolution de 65 % lors de la clôture de janvier à 73 % en juin, puis 80 % en octobre, est déjà très parlante. Il n’est pas nécessaire de disposer d’un modèle sophistiqué pour estimer quand le seuil de décision de 85 % sera atteint.
Le taux d’utilisation des threads CPU pendant les pics de traitement batch constitue un deuxième indicateur important. Si tous les threads d’exécution HANA disponibles sont saturés pendant le batch de clôture annuelle, le système ne dispose plus d’aucune marge pour absorber une charge analytique supplémentaire pendant cette même période. Cette saturation n’apparaît pas dans les moyennes quotidiennes. Elle n’est visible que lorsqu’on observe le pic d’utilisation pendant l’événement spécifique qui la provoque.
Capacité de stockage restante
La croissance du volume de données est l’une des métriques de capacité les plus prévisibles dans un environnement SAP, car elle dépend principalement du volume de transactions, qui évolue généralement de manière progressive et relativement régulière. Interrogez M_DISK_USAGE chaque semaine pendant douze semaines et relevez la taille du composant DATA. Divisez l’évolution observée sur cette période par le nombre de semaines pour obtenir un taux de croissance hebdomadaire. Il suffit ensuite de projeter ce taux pour estimer quand le stockage commencera à devenir une contrainte.
Le calcul est simple : soustrayez le volume de données actuel de la capacité de stockage disponible, puis divisez le résultat par le taux de croissance hebdomadaire. Vous obtenez ainsi le nombre de semaines avant épuisement de la capacité actuelle. Lorsque 80 % de cette marge temporelle est consommée, le processus d’extension devrait être lancé. Cette marge de 20 % permet d’absorber une éventuelle accélération de la croissance et les délais d’approvisionnement.
Le volume des logs fonctionne différemment. Il n’augmente pas directement avec le volume de données, mais avec le rythme des écritures transactionnelles et la fréquence des sauvegardes de logs. Une entreprise qui double son volume de transactions sans adapter la fréquence de sauvegarde des logs verra la pression sur le volume de logs augmenter plus vite que celle sur le volume de données. Il faut donc monitorer la fréquence des sauvegardes de logs parallèlement à l’utilisation de leur volume, et recalibrer les intervalles de sauvegarde lorsqu’une forte augmentation du volume transactionnel est constatée.
Marge de capacité des serveurs d’applications
L’utilisation des work processes de dialogue par instance, suivie au 95e percentile pendant les heures de pointe sur des fenêtres glissantes de 30 jours, permet de savoir si la couche des serveurs d’applications se rapproche de la saturation. Le 95e percentile est plus pertinent que la moyenne, car il reflète les conditions de charge élevées réellement ressenties par les utilisateurs, tout en évitant qu’un pic très ponctuel fausse l’analyse.
Une instance dont le 95e percentile est passé de 68 % à 78 % en six mois ne représente pas une urgence aujourd’hui. En revanche, c’est un sujet de capacité à intégrer au prochain cycle budgétaire. Une instance déjà à 85 % et dont la tendance continue d’augmenter dispose de beaucoup moins de marge et nécessite une discussion plus rapide.
La capacité des licences est une dimension non technique qui prend souvent les équipes de court. Le nombre de licences utilisateurs nommées ou d’accès simultanés est plafonné. À l’approche de cette limite, le provisioning de nouveaux utilisateurs ralentit ou devient impossible. Il est donc utile de comparer chaque mois le nombre d’utilisateurs couverts par les licences avec le nombre d’utilisateurs provisionnés. Dans les entreprises où les effectifs augmentent régulièrement, l’écart entre les deux se réduit à un rythme relativement prévisible.
Construire un modèle de croissance à partir des données de monitoring
La période de référence compte plus que le modèle
Une projection de croissance basée sur seulement 30 jours de données n’est pas fiable. Les 30 premiers jours suivant un go-live peuvent inclure des chargements initiaux qui gonflent artificiellement les taux de croissance. À l’inverse, une période de 30 jours en milieu d’exercice peut ne pas inclure la clôture mensuelle qui génère les pics de charge les plus importants. La projection sera alors incorrecte, et la décision prise à partir de cette projection le sera dans le même sens.
Une période de référence de six mois constitue le minimum pour construire un modèle de croissance fiable. Elle permet d’observer au moins deux cycles métier complets avec des périodes de charge comparables, de comparer plusieurs clôtures mensuelles et de disposer de suffisamment de points de données pour distinguer une tendance de croissance linéaire d’une variation saisonnière. Pour une planification de capacité liée à la clôture annuelle, une période de douze mois incluant la clôture de l’année précédente sera nettement plus fiable qu’une projection construite uniquement sur le trimestre précédent.
Le modèle lui-même n’a pas besoin d’être complexe. Une régression linéaire appliquée aux pics mensuels d’utilisation de la mémoire permet d’obtenir une pente correspondant au rythme mensuel de progression. En appliquant cette pente à la valeur actuelle et à la marge restante jusqu’au seuil de décision, on peut estimer le nombre de mois avant qu’une action soit nécessaire. Une fois les données de monitoring disponibles, ce calcul peut être réalisé très rapidement dans un simple tableur.
Saisonnalité et changements de palier
Les modèles de croissance basés sur une tendance linéaire sous-estimeront les besoins de fin d’année si la période de référence n’inclut pas des événements de forte charge comparables. Le pic de clôture mensuelle de juin n’est pas équivalent au pic de clôture annuelle de décembre. Une projection basée uniquement sur les données de juin à octobre passera complètement à côté du pic de décembre.
Pour corriger cela, il est possible de calculer un coefficient saisonnier à partir des données historiques. Quel était, les années précédentes, le rapport entre le pic d’utilisation de décembre et celui du mois d’octobre précédent ? Appliquez ce coefficient à l’utilisation projetée pour octobre afin d’estimer celle de décembre. Ce calcul ne sera jamais parfaitement précis, mais il sera nettement plus pertinent que de supposer que décembre ressemble à octobre.
Les changements de palier, comme le go-live d’une nouvelle business unit, l’activation d’une intégration majeure ou une augmentation à deux chiffres des effectifs sur un processus très utilisateur, génèrent une hausse brutale que les modèles linéaires ne peuvent pas anticiper. Le signal de monitoring associé à un tel changement est une accélération soudaine du taux de croissance sur une semaine précise. Dans ce cas, la projection doit être recalculée à partir du rythme observé après le changement, plutôt qu’à partir de la moyenne historique.
| Attention : les projections qui font la moyenne entre les taux de croissance avant et après un changement de palier sous-estiment les besoins futurs. Si le volume de données augmentait de 8 Go par mois pendant six mois, puis passe soudainement à 22 Go par mois après la mise en production d’une nouvelle intégration, une moyenne de 15 Go est incorrecte dans les deux sens : elle surestime la croissance historique et sous-estime la croissance future. Pour établir la nouvelle projection, segmentez la période de référence afin d’exclure les données antérieures au changement. |
|---|
Le délai est la vraie contrainte
Le délai nécessaire pour augmenter les capacités est la variable qui détermine à quel moment la discussion doit commencer. Il varie fortement selon le type d’infrastructure.
Pour du matériel on-premise, une extension de mémoire ou l’ajout de nouveaux nœuds de serveurs d’applications nécessite généralement huit à douze semaines entre le bon de commande et la capacité effectivement installée. Les délais sont similaires pour une extension de stockage. Ces estimations supposent que le processus d’achat se déroule sans retard. Les cycles de validation budgétaire peuvent facilement ajouter plusieurs semaines.
Dans les environnements hyperscaler et RISE with SAP, un changement de type d’instance nécessite une fenêtre de maintenance planifiée et un redémarrage. La modification technique elle-même peut parfois être réalisée en quelques jours après validation. Le délai vient surtout du processus d’approbation et de change management, plutôt que de la livraison du matériel. Deux à quatre semaines sont courantes lorsque le processus est simple. Les organisations disposant de cycles formels de change management peuvent toutefois avoir besoin de six à huit semaines entre la décision et la mise en œuvre.
Les délais d’achat de licences varient selon les accords avec les fournisseurs, mais il est rare d’obtenir de nouveaux volumes de licences en moins de trois semaines. Le processus peut être encore plus long lorsqu’un avenant contractuel est nécessaire. Dans le cadre d’un contrat d’entreprise, l’ajout de licences utilisateurs nommées peut également nécessiter une validation de la direction et une revue juridique.
Il faut donc raisonner à rebours. Si le seuil de décision pour la mémoire HANA est fixé à 85 % d’utilisation au pic et que l’achat de mémoire on-premise prend dix semaines, la discussion doit commencer lorsque la tendance indique que le système atteindra 85 % dans quatorze semaines. Pas dix. Les quatre semaines supplémentaires permettent de mener la discussion, préparer le business case, obtenir le budget et lancer le processus d’achat.
| En pratique : définissez le seuil de décision et le délai d’approvisionnement pour chaque dimension de capacité avant d’en avoir besoin. Lorsque la tendance détectée par le monitoring déclenche l’alerte, l’équipe doit savoir immédiatement quelle est l’étape suivante et qui doit la valider. Découvrir le processus d’achat en pleine crise de capacité peut ajouter plusieurs semaines alors que le calcul du délai supposait justement que ce temps était encore disponible. |
|---|
Traduire les tendances de monitoring en langage budgétaire
Les directions financières et IT ne prennent pas leurs décisions d’infrastructure à partir d’un pourcentage de mémoire HANA ou d’un taux d’utilisation des work processes de dialogue. Elles prennent des décisions en fonction du coût, du calendrier et des conséquences. Une analyse de capacité qui conduit réellement à une décision doit donc présenter trois éléments : la marge restante exprimée en mois, le coût de l’extension nécessaire et les conséquences opérationnelles si cette extension n’est pas réalisée à temps.
Pour chaque domaine de capacité susceptible d’atteindre une limite dans les douze prochains mois, produisez précisément ces trois informations. Mémoire HANA : sept mois de marge au rythme de croissance actuel, coût d’extension de X, conséquence en l’absence d’extension : risque d’arrêt d’urgence non planifié pendant la clôture financière de l’année suivante. Stockage : onze mois de capacité restante, coût d’extension de Y, conséquence : dépassement de la capacité de stockage disponible et nécessité de lancer un archivage d’urgence pendant une période où l’équipe est déjà mobilisée sur d’autres priorités. Ces informations permettent à un directeur IT de prendre une décision. Elles lui donnent également une échéance concrète.
Les données de monitoring fournissent les chiffres. Le processus de planification de capacité les transforme en informations suffisamment exploitables pour générer une ligne budgétaire et un bon de commande avant que la marge disponible ne soit épuisée.
Le monitoring sans planification de capacité est réactif par nature. Il déclenche une alerte lorsque les conditions sont déjà problématiques. La planification de capacité permet de rendre les données de monitoring réellement proactives : elle analyse les tendances afin d’identifier les décisions qui doivent être prises avant que l’évolution actuelle ne provoque le prochain incident.
L’infrastructure dont un environnement SAP aura besoin dans douze mois est déjà visible dans les données de monitoring d’aujourd’hui. La vraie question est de savoir si ce signal parvient suffisamment tôt aux personnes capables d’agir. Cela dépend directement de la façon dont l’organisation considère la planification de capacité : comme une activité opérationnelle régulière, ou comme une réponse d’urgence déclenchée par la métrique qu’elle était justement censée anticiper.
Redpeaks propose des vues d’analyse de tendances pour la mémoire HANA, le stockage, la puissance de calcul et les métriques liées aux work processes, avec des projections de capacité configurables basées sur des périodes de référence glissantes.
