Vous avez accès au système. Vous avez peut-être de la documentation, ou peut-être pas. L’ancien ingénieur Basis est parti le mois dernier ou il y a trois ans, et ce qu’il a documenté n’existe peut-être pas, ou décrit un paysage qui a fortement dérivé par rapport à la réalité actuelle. Le métier sait que le système fonctionne. Il ne sait pas comment il fonctionne, et vous non plus, pas encore.
C’est le point de départ classique pour toute personne qui reprend un paysage SAP existant. Ce guide s’adresse précisément à cette situation : comment vous orienter rapidement, quoi regarder avant de toucher à quoi que ce soit, comment mettre en place un monitoring SAP qui reflète réellement cet environnement spécifique plutôt qu’un modèle SAP générique, et quel calendrier réaliste suivre pour passer de « je viens d’obtenir les accès » à « je comprends vraiment ce qui se passe ici ».
Les recommandations sont organisées dans l’ordre où elles comptent. Résistez à la tentation de passer directement à la configuration du monitoring. La configuration n’a de valeur qu’une fois que vous comprenez ce que vous surveillez.
Ce que vous héritez réellement lorsque vous reprenez un paysage SAP en production
Le problème de la documentation
Chaque environnement SAP possède de la documentation. Presque aucune n’est totalement à jour. Le runbook qui décrit la procédure de sauvegarde a été rédigé quand le système tournait encore sur un autre serveur. L’inventaire des interfaces liste six connexions vers un ERP externe qui a été décommissionné il y a deux ans, tout en oubliant les quatre connexions vers la plateforme logistique ajoutées l’année dernière. Le guide de configuration des seuils de monitoring décrit les seuils du go-live initial, qui ont été ajustés pendant la première phase de stabilisation sans jamais être mis à jour.
Ce n’est pas de la négligence. C’est l’état normal d’un système de production qui fonctionne et évolue depuis des années. La documentation est mise à jour pendant les projets et pendant les incidents. Entre ces événements, le système change, mais la documentation ne suit pas.
La conséquence pour l’onboarding SAP Basis est simple : vous ne pouvez pas faire confiance à la documentation existante comme représentation exacte de l’état actuel. Vous pouvez l’utiliser comme point de départ pour investiguer. Si la documentation indique qu’il existe des connexions RFC vers trois systèmes externes, vérifiez que ces connexions existent encore, qu’elles sont actives, et cherchez aussi les connexions RFC vers des systèmes qui ne sont mentionnés nulle part.
Pourquoi la première tâche est la découverte, pas la configuration
Lorsqu’on arrive dans un nouvel environnement SAP, le réflexe est de configurer le monitoring rapidement, de montrer une progression visible et d’avoir quelque chose en place avant le premier incident. Ce réflexe est compréhensible, mais il faut y résister pendant les premiers jours.
Un monitoring configuré avant de comprendre l’environnement génère des alertes que vous ne pouvez pas interpréter. Une alerte se déclenche à 03:00 indiquant que l’utilisation des work processes de dialogue atteint 87 %. Est-ce normal pour ce système pendant la fenêtre batch de nuit ? Est-ce anormal, mais déjà présent depuis des mois sans que personne ne l’ait remarqué ? Est-ce un comportement réellement nouveau causé par un changement récent ? Sans baseline propre à ce système, vous ne pouvez répondre à aucune de ces questions. Vous avez une alerte, mais aucun contexte.
Les deux ou trois premiers jours passés à lire le système plutôt qu’à le configurer créent le contexte qui rendra le monitoring utile ensuite. Les transactions doivent être exécutées en lecture seule. Pas de changements. Seulement de l’observation.
Les premières 48 heures : lire le système avant d’y toucher
Les transactions qui donnent une vue de santé immédiate
Voici les transactions à parcourir dans les premières heures après l’obtention des accès. Elles ne nécessitent aucune configuration. Elles montrent l’état de santé actuel et l’historique récent du système.
ST22 est le moniteur des short dumps. Ouvrez-le et consultez les sept derniers jours en production. Un système de production sain présente peu ou pas de short dumps par jour. Ce que vous trouvez ici vous indique immédiatement s’il existe des erreurs programme récurrentes que l’équipe précédente gérait, et à quelle fréquence. Faites attention à la répartition par classe de dump : MEMORY_NO_MORE_PAGING suggère une pression mémoire, TIME_OUT indique des programmes qui s’exécutent trop longtemps, DBIF_RSQL_INVALID_RSQL peut pointer vers des incohérences de données. Chaque classe oriente vers une zone différente du système.
SM13 est le moniteur des mises à jour. Toute demande de mise à jour en erreur représente une transaction sauvegardée dont l’écriture en base de données ne s’est pas terminée correctement. S’il existe des entrées en statut d’erreur, cherchez à savoir si elles sont suivies ou si elles s’accumulent silencieusement. Une liste de 400 demandes de mise à jour échouées dans SM13 que personne n’a traitées relève d’un sujet d’intégrité des données, pas d’un simple point opérationnel de routine.
SM12 affiche la table des verrous. Cherchez les entrées conservées depuis plus de quelques minutes. Des verrous maintenus longtemps dans un système OLTP de production indiquent soit un utilisateur qui a ouvert une transaction puis l’a laissée en suspens, soit un job batch qui conserve des verrous pendant une longue séquence de traitement. Aucun des deux cas ne provoque forcément un incident immédiat, mais les deux créent un risque sous charge concurrente.
SM37 est le moniteur des jobs d’arrière-plan. Consultez les 48 dernières heures d’historique des jobs en production, filtrées sur les statuts ABORTED et CANCELLED. L’objectif est de comprendre quels jobs échouent régulièrement et quelles erreurs sont réellement nouvelles. Un job qui échoue un jour sur deux depuis six mois est une condition connue. Un job qui a échoué pour la première fois hier correspond à une autre situation.
BD87 ou WE05 affiche les statuts IDoc. Filtrez les statuts d’erreur sur les sept derniers jours. Un volume important d’erreurs en statut 51, erreur de comptabilisation, indique soit un problème systématique de qualité de données dans une interface entrante, soit un problème de configuration qui produit des échecs en continu.
SM21 est le journal système. Ouvrez-le sur les dernières 24 heures en production et cherchez les arrêts de work processes, les événements de dépassement mémoire et les événements liés aux fichiers roll. Ces événements système sont souvent le contexte manquant derrière les problèmes de performance signalés par les utilisateurs.
Comprendre ce qui est normal dans cet environnement précis
Après les transactions de vue de santé, passez du temps dans le moniteur de charge. Dans les systèmes récents, il est accessible via /SDF/MON ou via la vue de performance. Dans les systèmes plus anciens, utilisez ST07 ou l’analyse de charge. Regardez les deux dernières semaines de temps de réponse dialogue et essayez d’identifier le rythme du système : quand la charge atteint son pic, quand les traitements batch sont les plus lourds, quand le système est le plus calme.
Consultez aussi la tendance mémoire HANA dans HANA Studio ou dans l’outil de monitoring auquel vous avez accès. Quelle est l’utilisation actuelle par rapport à la limite d’allocation ? À quoi ressemble la tendance ? Un système à 70 % d’utilisation avec une croissance de 2 % par mois est très différent d’un système stable à 70 % depuis deux ans.
Le but de cette phase de lecture n’est pas de produire un rapport ou une évaluation des risques. Le but est de développer une intuition sur le fonctionnement normal de ce système. Ainsi, lorsque vous commencerez à recevoir des données de monitoring, vous pourrez distinguer un comportement attendu d’une véritable anomalie. Cette intuition ne peut pas être transférée depuis un poste précédent. Elle est propre à ce système.
En pratique : posez explicitement des questions sur la clôture mensuelle. Chaque environnement SAP possède un schéma de traitement de fin de mois très différent des opérations quotidiennes : davantage de jobs batch, des temps d’exécution plus longs, une utilisation mémoire HANA plus élevée, des volumes d’interfaces différents. Si votre onboarding a lieu au milieu du mois, votre baseline d’observation n’inclut pas ce comportement de fin de mois. Assurez-vous que quelqu’un vous explique à quoi vous attendre, et prévoyez du temps pendant votre premier mois pour observer la vraie dynamique de clôture plutôt que de la traiter comme une anomalie.
Mettre en place un utilisateur de monitoring sans affaiblir les contrôles d’autorisation
Les autorisations dont un utilisateur de monitoring SAP a réellement besoin
Un utilisateur SAP dédié au monitoring a besoin d’un accès en lecture aux vues système et aux transactions qui collectent les données de performance. Il n’a pas besoin d’autorisation de modification. Cette distinction est importante, car les profils d’autorisation qui accordent des droits de modification en plus des droits de lecture créent des problèmes de conformité dans les environnements réglementés et transforment la connexion de monitoring en surface d’attaque si les identifiants sont compromis.
Les principaux objets d’autorisation pour le monitoring de la couche ABAP sont S_RFC pour l’accès RFC, car l’outil de monitoring se connecte via RFC, S_TCODE pour l’accès aux transactions pertinentes comme SM50, SM66, SM37, SM12, SM13, SM21, ST22 et d’autres selon l’outil, ainsi que S_ADMI_FCD pour les fonctions d’administration système utilisées par le monitoring. Pour le monitoring de la couche HANA, un utilisateur base de données séparé avec les privilèges système MONITORING et CATALOG READ suffit pour la plupart des besoins de collecte de métriques.
La plupart des outils de monitoring fournissent un guide de configuration de l’utilisateur technique qui précise les objets d’autorisation et les valeurs exactes nécessaires. Utilisez ce guide plutôt que de construire les autorisations manuellement à partir de zéro. S’il n’existe pas, demandez au fournisseur avant le provisionnement. La réponse « utilisez simplement SAP_ALL pour l’utilisateur de monitoring » doit immédiatement vous alerter.
La tentation SAP_ALL et les problèmes qu’elle crée
Attribuer SAP_ALL à l’utilisateur de monitoring est la solution la plus simple lors de la configuration. Pas d’erreurs d’autorisation pendant les tests, pas d’aller-retour avec l’équipe sécurité sur les valeurs d’objets manquantes, pas de délai. L’outil de monitoring se connecte, les données commencent à remonter, la configuration semble terminée.
Les problèmes apparaissent plus tard. Dans un environnement réglementé, SAP_ALL sur un compte de service échoue aux audits et impose une remédiation dans l’urgence. Si la plateforme de monitoring est compromise, les identifiants de l’utilisateur de monitoring donnent un accès illimité au système. Lorsque l’équipe sécurité exécute un rapport d’autorisations et trouve un compte de service avec SAP_ALL, il faut expliquer pourquoi il a été configuré ainsi, et aucune demande de changement ne fournit généralement une bonne réponse.
La bonne approche prend plus de temps au départ. Elle consiste à identifier les autorisations minimales nécessaires, créer un rôle personnalisé, le tester avec les exigences de connexion de l’outil de monitoring, puis l’ajuster là où l’outil signale des échecs d’autorisation. Dans la plupart des outils de monitoring, ce processus prend deux à trois heures. Le profil d’autorisation obtenu est maintenable, auditable et ne crée pas de problèmes en aval.
À surveiller : les tests d’autorisation pour un utilisateur de monitoring doivent d’abord être réalisés dans un système de développement ou de QA, pas en production. Une configuration incorrecte qui pousse la connexion de monitoring à générer des erreurs d’autorisation RFC en production crée du bruit dans SM21 et peut déclencher des alertes de sécurité dans les environnements avec supervision SIEM active. Stabilisez le profil avant de connecter la production.
Connecter votre plateforme de monitoring : ce que la configuration initiale exige vraiment
Configuration de la destination RFC et vérifications avant d’aller plus loin
La plupart des plateformes de monitoring SAP se connectent via RFC, en créant une destination RFC de type 3, connexion ABAP, dans SM59 sur le système monitoré, ou en se connectant depuis le collecteur de monitoring via une interface de modules fonction RFC. La procédure varie selon la plateforme, mais les vérifications restent les mêmes.
Après avoir créé la destination RFC ou configuré la connexion de monitoring, vérifiez trois éléments avant de considérer la configuration comme terminée. Premièrement, lancez le test de connexion dans SM59 et confirmez qu’il réussit. Deuxièmement, lancez le test d’autorisation dans SM59 et confirmez que l’utilisateur de monitoring dispose des accès nécessaires. Troisièmement, et c’est le point que beaucoup de guides oublient : vérifiez que les données sont réellement collectées en ouvrant le tableau de bord de la plateforme de monitoring et en confirmant que les métriques apparaissent et se mettent à jour à l’intervalle attendu. Un test de connexion réussi et des données qui circulent réellement ne sont pas la même chose. Les deux peuvent échouer indépendamment.
Dans les environnements HANA, la connexion de monitoring HANA est séparée de la connexion ABAP et utilise les identifiants de l’utilisateur base de données HANA plutôt que des identifiants utilisateur SAP. Les deux connexions doivent être configurées et vérifiées indépendamment. Une plateforme de monitoring qui affiche un statut vert pour la connexion ABAP mais qui ne s’est jamais connectée correctement à HANA ne surveille pas la couche de performance la plus critique dans un environnement S/4HANA.
La différence entre connecté et réellement monitoré
Une plateforme de monitoring avec une connexion fonctionnelle au système SAP n’est pas la même chose qu’une plateforme qui fournit une couverture utile. La connexion est un prérequis. Ce qui détermine l’utilité du monitoring, c’est la configuration qui suit : quelles métriques sont collectées, à quelle fréquence, avec quels seuils d’alerte, et vers quelles personnes les alertes sont routées.
Pendant la première semaine, la plateforme de monitoring doit collecter les données, et vous devez les lire pour comprendre ce qu’elles révèlent sur le système que vous venez d’explorer via les transactions de santé. Elle ne doit pas encore être configurée pour alerter, car vous n’avez pas encore les données de baseline nécessaires pour définir des seuils pertinents. Les alertes configurées dès la première semaine sans baseline sont des hypothèses basées sur des seuils, et ces hypothèses produisent soit trop d’alertes, ce qui pousse l’équipe opérations à les ignorer, soit trop peu, ce qui fait que le monitoring ne détecte rien.
La transition entre une plateforme connectée qui collecte et une plateforme qui alerte activement intervient après deux à quatre semaines de données de baseline, comme expliqué dans la section dédiée. Cette période intermédiaire n’est pas du temps perdu. C’est le moment où vous apprenez à quoi ressemble le système dans des conditions normales, afin que les conditions anormales deviennent visibles.
Reconstruire la documentation dont vous aviez besoin mais que vous n’avez pas reçue
Inventaire des interfaces à partir du système lui-même
Si l’inventaire des interfaces n’existe pas ou n’est pas à jour, le système contient lui-même la source de vérité. SM59 liste toutes les destinations RFC configurées dans le système. WE20 liste tous les profils partenaires IDoc. BD54 affiche les systèmes logiques configurés pour ALE. SMQ1 et SMQ2 montrent les files qRFC actives. Le moniteur ICM affiche les connexions HTTP actives.
Construire un inventaire des interfaces à partir de ces vues transactionnelles prend quelques heures, mais produit un résultat plus fiable que n’importe quelle documentation rédigée il y a plus de six mois : une image des connexions qui existent réellement et de celles qui sont actuellement actives. Une destination RFC dans SM59 dont la dernière utilisation remonte à trois ans et dont le test de connexion échoue est candidate au décommissionnement. Une destination RFC absente de toute documentation, mais avec un usage quotidien élevé dans les statistiques, est une dépendance non documentée qu’il faut comprendre avant qu’elle ne tombe en panne.
L’inventaire n’a pas besoin d’être exhaustif dès le premier jour. Priorisez les interfaces qui transportent des données critiques pour le métier : interfaces de traitement des commandes, interfaces de comptabilisation financière, connexions d’exécution logistique. Ce sont celles dont l’échec a un impact métier immédiat, et ce sont celles qu’il faut comprendre en profondeur plutôt que documenter rapidement.
Documentation du planning des jobs à partir de l’historique SM37
SM37 avec une plage de dates de 30 jours en production, sans filtre sur l’utilisateur ni sur le nom du job, donne une vision complète de ce qui a réellement tourné. Exportez ces données vers une feuille de calcul si le volume est important. Regroupez par nom de job. Pour chaque job, documentez le temps d’exécution moyen, le taux de succès, la fréquence planifiée et la dernière date d’exécution.
Cet exercice révèle généralement trois éléments que la documentation ne mentionnait pas. Premièrement, des jobs présents dans la documentation, mais qui n’ont pas tourné depuis des mois, soit parce qu’ils ont été décommissionnés sans être supprimés du planning, soit parce qu’ils échouent régulièrement sans que personne ne l’ait traité. Deuxièmement, des jobs qui tournent régulièrement, mais ne sont pas documentés, créés ponctuellement à un moment donné et jamais formalisés. Troisièmement, des jobs dont les temps d’exécution ont fortement augmenté, ce qui devient visible lorsque vous comparez la moyenne sur 30 jours à la baseline indiquée dans la documentation.
La documentation du planning des jobs que vous reconstruisez depuis l’historique SM37 devient la baseline opérationnelle du monitoring des jobs : fenêtre d’achèvement attendue, plage normale de durée d’exécution, dépendances. C’est un travail qui aurait dû être fait avant votre arrivée, mais qui ne l’a pas été.
Chemins d’escalade : savoir qui est réellement appelé
La documentation d’escalade liste probablement des noms et des numéros de téléphone. Certaines de ces personnes sont peut-être encore dans l’organisation. D’autres non. Le vrai chemin d’escalade, c’est-à-dire qui est appelé lorsque le système de production rencontre un problème à 02:00 un dimanche, est une connaissance institutionnelle qui existe dans la tête des personnes plus que dans les documents.
Pendant la première semaine, organisez une conversation directe avec au moins trois personnes : le responsable IT en charge de SAP, le responsable métier le plus senior qui utilise le système au quotidien, et la personne qui gérait les incidents de nuit avant votre arrivée. Demandez à chacun ce qui se passe lorsqu’un problème survient à 03:00. Les trois réponses seront différentes, et collectivement plus exactes que n’importe quel document d’escalade.
Le résultat de ces conversations est un runbook d’astreinte pratique : qui appeler selon le type d’incident, quel est le temps de réponse attendu, quels incidents peuvent attendre les heures ouvrées et lesquels ne le peuvent pas. C’est ce runbook que vous devez écrire et maintenir. Ce n’est pas celui que vous héritez.
Construire une baseline avant de configurer les alertes
Pourquoi les alertes dès le premier jour produisent du bruit plutôt que du signal
Les seuils d’alerte configurés sans données de baseline sont calibrés sur l’intuition ou sur les recommandations génériques SAP. Les recommandations génériques SAP sont des points de départ pour un système type. Votre système n’est pas un système type. Il possède un profil de charge spécifique, un planning batch spécifique, un modèle de consommation mémoire HANA spécifique et un ensemble d’interfaces avec des volumes de trafic propres. Des seuils génériques appliqués à un système spécifique déclencheront des alertes pour des conditions parfaitement normales dans cet environnement.
L’équipe opérations qui reçoit dix alertes par jour pour des situations normales apprend très vite à les ignorer. La fatigue liée aux alertes, une fois installée, est difficile à corriger. Le seuil désactivé parce qu’il se déclenche chaque matin pendant la fenêtre batch restera désactivé lorsqu’il se déclenchera pour un vrai problème. Commencer sans alertes, puis les construire à partir de données de baseline, plutôt que partir de seuils génériques et réduire ensuite le bruit, est l’approche qui produit une configuration de monitoring fiable.
La fenêtre de collecte de deux à quatre semaines et ce que vous en faites
Deux semaines représentent la période minimale de baseline pour un système que vous venez de reprendre. Quatre semaines, c’est mieux, car cela permet d’inclure un cycle de clôture mensuelle. Ce que vous collectez pendant cette période, c’est la distribution réelle des valeurs pour chaque métrique sur laquelle vous prévoyez d’alerter : pas seulement la moyenne, mais la distribution complète, y compris les pics.
Pour l’utilisation des work processes de dialogue, vous devez connaître la valeur au 95e percentile pendant les heures ouvrées, la valeur de pic pendant les fenêtres batch et le minimum typique pendant la nuit. Un seuil d’alerte placé au 98e percentile de la distribution de baseline se déclenchera uniquement pour des conditions réellement inhabituelles. Un seuil placé à 80 % se déclenchera pour les 15 % supérieurs des observations normales.
Pour l’utilisation mémoire HANA, il faut la même distribution, avec en plus le pic de clôture mensuelle si votre fenêtre de baseline l’inclut. Pour chaque job d’arrière-plan de la liste Tier 1, vous devez connaître la distribution des durées d’exécution les jours normaux et la durée lors de la clôture mensuelle, afin de définir des seuils de durée distincts.
À la fin de la période de baseline, vous disposez de suffisamment de données pour configurer un premier ensemble d’alertes pertinentes. Pas toutes les alertes pour toutes les métriques, mais les plus prioritaires : mémoire HANA approchant la limite d’allocation, saturation des work processes de dialogue, jobs batch critiques dépassant leur fenêtre d’achèvement attendue, croissance du volume des logs HANA et échecs des tâches de mise à jour. Ces cinq catégories couvrent la majorité des incidents de production dans un environnement SAP typique. Le reste peut être ajouté progressivement.
Semaine 1, mois 1, mois 3 : ce qu’il faut avoir en place
Le calendrier ci-dessous reflète une progression réaliste pour un ou deux ingénieurs Basis qui reprennent un paysage existant. Ce n’est pas un plan projet. C’est un guide de priorisation.
À la fin de la première semaine : accès système confirmés, transactions de vue de santé analysées, problèmes ouverts critiques identifiés, notamment SM13, ST22 et échecs SM37, chemin d’escalade informel documenté à partir des conversations, plateforme de monitoring connectée et collectant les données en lecture seule, sans alerting.
À la fin du premier mois : brouillon d’inventaire des interfaces terminé à partir de SM59 et de la revue des profils partenaires, documentation du planning des jobs reconstruite depuis l’historique SM37, données de baseline collectées pour les métriques clés, premier ensemble d’alertes configuré pour les conditions critiques uniquement, notamment volume des logs HANA, échecs des tâches de mise à jour et échecs de jobs critiques, profil d’autorisation de l’utilisateur de monitoring revu et confirmé comme minimal nécessaire.
À la fin du troisième mois : configuration complète des alertes en place sur la base des données de baseline, justification des seuils documentée, runbook d’escalade rédigé et testé, comportement de clôture mensuelle observé et intégré dans des seuils d’alerte sensibles au temps, documentation de handover du monitoring rédigée comme si vous deviez transmettre le système à quelqu’un d’autre, parce que cela finira par arriver.
Le livrable du troisième mois, la documentation de handover du monitoring, peut sembler prématuré. Il ne l’est pas. L’écrire vous oblige à expliquer pourquoi les seuils sont placés à ces niveaux, quelles alertes sont fiables, lesquelles doivent encore être ajustées, et ce que l’ingénieur d’astreinte doit savoir pour répondre à chaque catégorie d’alerte. Cette formulation fait la différence entre un monitoring qui continue à fonctionner lorsque l’équipe change et un monitoring qu’il faudra reconstruire à partir de zéro lors de la prochaine passation.
Le système que vous héritez vous dit déjà ce dont il a besoin
Chaque système SAP de production qui fonctionne depuis plus d’un an a développé une personnalité : des schémas d’échec récurrents, des caractéristiques de performance qui définissent son comportement normal, des intégrations qui demandent plus d’attention que les autres. Cette personnalité ne se trouve dans aucune documentation. Elle se trouve dans SM21, dans ST22, dans l’historique SM37, dans les graphiques de tendance mémoire HANA, dans la succession d’événements auxquels l’équipe précédente a répondu.
La phase de lecture avant la configuration n’est pas un retard dans la mise en place du monitoring. C’est le processus qui permet de comprendre ce que le système vous dit déjà, afin que votre configuration de monitoring amplifie les signaux importants au lieu de générer du bruit à partir d’un modèle conçu pour un autre environnement.
Le monitoring du premier jour ne consiste pas à tout avoir en place. Il consiste à ne pas manquer ce qui compte pendant que vous apprenez tout le reste. Cela signifie que les transactions de vue de santé sont revues, les problèmes ouverts critiques sont connus et la plateforme de monitoring collecte des données avant la fin de la première semaine. Tout ce qui vient ensuite relève de l’affinage, et cet affinage repose sur l’observation plutôt que sur l’hypothèse.
Redpeaks se connecte aux systèmes SAP via RFC sans agent, sans transports et sans logiciel côté SAP. La collecte de baseline commence dès le premier jour de connexion. La configuration des alertes peut être appliquée progressivement à mesure que les données de baseline mûrissent.
