Sie haben Systemzugriff. Vielleicht gibt es Dokumentation, vielleicht auch nicht. Der vorherige Basis Engineer ist entweder letzten Monat gegangen oder vor drei Jahren, und die vorhandene Dokumentation existiert entweder nicht oder beschreibt eine Landschaft, die sich deutlich von der heutigen Realität entfernt hat. Das Business weiß, dass das System läuft. Es weiß nicht, wie es läuft, und Sie wissen es ebenfalls noch nicht.
Das ist die typische Ausgangslage für alle, die eine bestehende SAP-Landschaft übernehmen. Dieser Artikel richtet sich genau an diese Situation: wie Sie sich schnell orientieren, was Sie prüfen sollten, bevor Sie etwas ändern, wie Sie ein SAP Monitoring aufbauen, das diese konkrete Umgebung abbildet statt nur ein generisches SAP Template zu verwenden, und welcher realistische Zeitrahmen nötig ist, um von „ich habe gerade Zugriff bekommen“ zu „ich verstehe wirklich, was hier passiert“ zu kommen.
Die Empfehlungen sind in der Reihenfolge aufgebaut, in der sie wichtig sind. Widerstehen Sie der Versuchung, direkt zur Monitoring-Konfiguration zu springen. Die Konfiguration ist erst dann sinnvoll, wenn Sie verstanden haben, was Sie überwachen.
Was Sie wirklich übernehmen, wenn Sie eine laufende SAP-Landschaft betreuen
Das Dokumentationsproblem
Jede SAP-Umgebung hat Dokumentation. Fast keine davon ist vollständig aktuell. Das Runbook zur Backup-Prozedur wurde geschrieben, als das System noch auf einem anderen Server lief. Das Schnittstelleninventar listet sechs Verbindungen zu einem externen ERP-System, das vor zwei Jahren außer Betrieb genommen wurde, verschweigt aber die vier Verbindungen zur Logistikplattform, die im letzten Jahr hinzugefügt wurden. Der Leitfaden zur Konfiguration der Monitoring-Schwellenwerte beschreibt Grenzwerte aus dem ursprünglichen Go-live, die während der ersten Stabilisierungsphase angepasst und nie aktualisiert wurden.
Das ist keine Nachlässigkeit. Es ist der normale Zustand eines Produktivsystems, das seit Jahren läuft und sich weiterentwickelt. Dokumentation wird während Projekten und während Incidents aktualisiert. Dazwischen verändert sich das System, die Dokumentation aber nicht.
Für das SAP Basis Onboarding bedeutet das: Sie können bestehender Dokumentation nicht als exaktem Bild des aktuellen Zustands vertrauen. Sie können sie als Ausgangspunkt für Ihre Untersuchung verwenden. Wenn die Dokumentation RFC-Verbindungen zu drei externen Systemen erwähnt, prüfen Sie, ob diese Verbindungen tatsächlich existieren und aktiv sind. Suchen Sie außerdem nach RFC-Verbindungen zu Systemen, die in der Dokumentation gar nicht genannt werden.
Warum die erste Aufgabe Discovery ist, nicht Konfiguration
Wenn man in eine neue SAP-Umgebung kommt, ist der erste Impuls oft, das Monitoring schnell zu konfigurieren, sichtbaren Fortschritt zu zeigen und vor dem ersten Incident zumindest etwas eingerichtet zu haben. Dieser Impuls ist verständlich, aber in den ersten Tagen sollte man ihm widerstehen.
Monitoring, das konfiguriert wird, bevor Sie die Umgebung verstehen, erzeugt Alerts, die Sie nicht interpretieren können. Um 03:00 Uhr wird ein Alarm ausgelöst, weil die Auslastung der Dialog Work Processes bei 87 % liegt. Ist das für dieses System während des nächtlichen Batch-Fensters normal? Ist es unnormal, passiert aber seit Monaten, ohne dass es jemand bemerkt hat? Ist es wirklich ein neues Verhalten, ausgelöst durch eine aktuelle Änderung? Ohne Baseline-Wissen über genau dieses System können Sie keine dieser Fragen beantworten. Sie haben einen Alert, aber keinen Kontext.
Die ersten zwei bis drei Tage, in denen Sie das System lesen statt es zu konfigurieren, schaffen den Kontext, der das spätere Monitoring aussagekräftig macht. Transaktionen werden nur lesend ausgeführt. Keine Änderungen. Nur Beobachtung.
Die ersten 48 Stunden: das System lesen, bevor Sie es anfassen
Transaktionen, die einen schnellen Gesundheitscheck liefern
Diese Transaktionen sollten Sie in den ersten Stunden nach Erhalt des Zugriffs durchgehen. Sie erfordern keine Konfiguration. Sie zeigen den aktuellen Systemzustand und die jüngere Historie des Systems.
ST22 ist der Short Dump Monitor. Öffnen Sie ihn und betrachten Sie die letzten sieben Tage in der Produktion. Ein gesundes Produktivsystem hat wenige oder gar keine Short Dumps pro Tag. Was Sie hier finden, zeigt sofort, ob wiederkehrende Programmfehler existieren, mit denen das vorherige Team zu tun hatte, und wie häufig sie auftreten. Achten Sie auf die Verteilung der Dump-Klassen: MEMORY_NO_MORE_PAGING deutet auf Speicherdruck hin, TIME_OUT auf Programme mit zu langer Laufzeit, DBIF_RSQL_INVALID_RSQL auf mögliche Dateninkonsistenzen. Jede Klasse verweist auf einen anderen Bereich des Systems.
SM13 ist der Update Monitor. Jede fehlgeschlagene Update-Anforderung steht für eine gespeicherte Transaktion, deren Datenbankschreibvorgang nicht abgeschlossen wurde. Wenn Einträge im Fehlerstatus vorhanden sind, klären Sie, ob sie aktiv bearbeitet werden oder ob sie sich unbemerkt angesammelt haben. Eine Liste mit 400 fehlgeschlagenen Update-Anforderungen in SM13, um die sich niemand gekümmert hat, ist ein Thema der Datenintegrität, kein gewöhnlicher operativer Punkt.
SM12 zeigt die Sperrtabelle. Prüfen Sie Einträge, die länger als einige Minuten gehalten werden. Lang gehaltene Sperren in einem produktiven OLTP-System deuten entweder auf einen Benutzer hin, der eine Transaktion gestartet und offen gelassen hat, oder auf einen Batch-Job, der Sperren über eine längere Verarbeitungssequenz hält. Keines von beiden verursacht zwangsläufig sofort einen Incident, aber beides schafft Risiko bei paralleler Last.
SM37 ist der Monitor für Hintergrundjobs. Betrachten Sie die Jobhistorie der letzten 48 Stunden in der Produktion, gefiltert nach den Status ABORTED und CANCELLED. Sie möchten verstehen, welche Jobs regelmäßig fehlschlagen und welche Fehler wirklich neu sind. Ein Job, der seit sechs Monaten jeden zweiten Tag fehlschlägt, ist ein bekannter Zustand. Ein Job, der gestern zum ersten Mal fehlgeschlagen ist, ist etwas anderes.
BD87 oder WE05 zeigt den IDoc-Status. Filtern Sie nach Fehlerstatus der letzten sieben Tage. Ein nennenswertes Volumen an Fehlern im Status 51, also Fehler bei der Buchung, weist entweder auf ein systematisches Datenqualitätsproblem in einer eingehenden Schnittstelle oder auf ein Konfigurationsproblem hin, das kontinuierlich Fehler erzeugt.
SM21 ist das Systemlog. Öffnen Sie es für die letzten 24 Stunden in der Produktion und suchen Sie nach Work Process Terminations, Memory Overflow Events und Roll File Events. Diese systemnahen Ereignisse liefern oft den fehlenden Kontext für Performance-Probleme, die Benutzer melden.
Verstehen, was in genau dieser Umgebung normal ist
Nach den Transaktionen für den Gesundheitscheck sollten Sie Zeit im Workload Monitor verbringen. In neueren Systemen ist dieser über /SDF/MON oder über die Performance-Übersicht zugänglich, in älteren Systemen über ST07 oder die Workload-Analyse. Betrachten Sie die Dialog Response Times der letzten zwei Wochen und versuchen Sie, das Muster zu erkennen: Wann liegt die Spitzenlast an, wann ist die Batch-Last besonders hoch, wann ist das System am ruhigsten?
Betrachten Sie außerdem den HANA Memory Trend in HANA Studio oder in dem Monitoring-Zugang, den Sie erhalten haben. Wie hoch ist die aktuelle Auslastung im Verhältnis zum Allocation Limit? Wie sieht der Trend aus? Ein System mit 70 % Auslastung, das monatlich um 2 % wächst, ist eine andere Situation als ein System, das seit zwei Jahren stabil bei 70 % liegt.
Das Ziel dieser Lesephase ist nicht, einen Bericht oder eine Risikobewertung zu erstellen. Es geht darum, ein Gefühl dafür zu entwickeln, wie dieses System normalerweise aussieht. Wenn später Monitoring-Daten eintreffen, können Sie erwartetes Verhalten von echten Anomalien unterscheiden. Diese Intuition lässt sich nicht aus einer früheren Rolle übertragen. Sie ist spezifisch für dieses System.
In der Praxis: Fragen Sie gezielt nach dem Monatsabschluss. Jede SAP-Umgebung hat ein Monatsabschlussmuster, das sich deutlich vom Tagesbetrieb unterscheidet: mehr Batch-Jobs, längere Laufzeiten, höhere HANA-Speicherauslastung, andere Schnittstellenvolumina. Wenn Ihr Onboarding Mitte des Monats stattfindet, enthält Ihre erste Baseline-Beobachtung dieses Monatsabschlussverhalten nicht. Stellen Sie sicher, dass Ihnen jemand erklärt, was zu erwarten ist, und planen Sie im ersten Monat Zeit ein, um den echten Monatsabschluss zu beobachten, statt ihn als Anomalie zu behandeln.
Einen Monitoring-Benutzer einrichten, ohne Berechtigungskontrollen zu schwächen
Welche Berechtigungen ein SAP Monitoring Benutzer wirklich braucht
Ein SAP Monitoring Benutzer benötigt Lesezugriff auf Systemansichten und Transaktionen, die Performance-Daten sammeln. Er benötigt keine Berechtigung, etwas zu ändern. Diese Unterscheidung ist wichtig, weil Berechtigungsprofile, die Änderungsrechte zusammen mit Leserechten vergeben, in regulierten Umgebungen Compliance-Probleme verursachen und die Monitoring-Verbindung zu einer Angriffsfläche machen, falls Zugangsdaten kompromittiert werden.
Die zentralen Berechtigungsobjekte für das Monitoring auf ABAP-Ebene sind S_RFC für RFC-Zugriff, da das Monitoring Tool per RFC verbindet, S_TCODE für den Zugriff auf relevante Transaktionen wie SM50, SM66, SM37, SM12, SM13, SM21, ST22 und weitere je nach Tool, sowie S_ADMI_FCD für Systemadministrationsfunktionen, die vom Monitoring genutzt werden. Für das Monitoring auf HANA-Ebene reicht für die meisten Metriksammlungen ein separater Datenbankbenutzer mit den Systemprivilegien MONITORING und CATALOG READ.
Die meisten Monitoring Tools stellen einen Leitfaden zur Einrichtung technischer Benutzer bereit, der die genauen Berechtigungsobjekte und Werte beschreibt. Nutzen Sie diesen Leitfaden, statt Berechtigungen manuell von Grund auf zu bauen. Wenn kein solcher Leitfaden existiert, fragen Sie den Anbieter vor dem Provisioning. Die Antwort „nehmen Sie einfach SAP_ALL für den Monitoring-Benutzer“ ist ein klares Warnsignal.
Die SAP_ALL Versuchung und warum sie Probleme schafft
Dem Monitoring-Benutzer SAP_ALL zu geben, ist während der Einrichtung der einfachste Weg. Keine Berechtigungsfehler beim Testen, keine Abstimmungen mit dem Security-Team über fehlende Objektwerte, keine Verzögerungen. Das Monitoring Tool verbindet sich, Daten fließen, die Einrichtung scheint abgeschlossen.
Die Probleme kommen später. In einer regulierten Umgebung fällt SAP_ALL auf einem Servicekonto bei Audits durch und muss unter Zeitdruck behoben werden. Wenn die Monitoring-Plattform jemals kompromittiert wird, geben die Zugangsdaten des Monitoring-Benutzers uneingeschränkten Systemzugriff. Wenn das Security-Team einen Berechtigungsreport ausführt und ein Servicekonto mit SAP_ALL findet, braucht es eine Erklärung, warum es so eingerichtet wurde. Diese Erklärung existiert meist in keinem Change Request.
Der richtige Ansatz braucht am Anfang mehr Zeit. Er erfordert, die minimal notwendigen Berechtigungen zu identifizieren, eine kundenspezifische Rolle zu erstellen, sie gegen die Verbindungsanforderungen des Monitoring Tools zu testen und sie dort anzupassen, wo das Tool Berechtigungsfehler meldet. In den meisten Monitoring Tools dauert dieser Prozess zwei bis drei Stunden. Das Ergebnis ist ein Berechtigungsprofil, das wartbar, auditierbar und ohne spätere Folgeprobleme ist.
Achtung: Berechtigungstests für einen Monitoring-Benutzer sollten zuerst in einem Entwicklungs- oder QA-System erfolgen, nicht in der Produktion. Eine fehlerhafte Berechtigungskonfiguration, die in der Produktion RFC-Berechtigungsfehler über die Monitoring-Verbindung erzeugt, verursacht Rauschen in SM21 und kann in Umgebungen mit aktivem SIEM Monitoring Sicherheitsalarme auslösen. Bringen Sie das Profil in Ordnung, bevor Sie die Produktion anbinden.
Die Monitoring-Plattform verbinden: was die initiale Einrichtung wirklich erfordert
RFC-Destination einrichten und prüfen, bevor Sie weitergehen
Die meisten SAP Monitoring Plattformen verbinden sich per RFC, entweder über eine RFC-Destination vom Typ 3, ABAP Connection, in SM59 auf dem überwachten System oder eingehend vom Monitoring Collector über eine RFC-fähige Funktionsbaustein-Schnittstelle. Das genaue Vorgehen unterscheidet sich je nach Plattform, aber die Prüfschritte bleiben gleich.
Nachdem die RFC-Destination erstellt oder die Monitoring-Verbindung konfiguriert wurde, prüfen Sie drei Dinge, bevor Sie die Einrichtung als abgeschlossen betrachten. Erstens: Führen Sie den Verbindungstest in SM59 aus und bestätigen Sie, dass er erfolgreich ist. Zweitens: Führen Sie den Berechtigungstest in SM59 aus und bestätigen Sie, dass der Monitoring-Benutzer Zugriff hat. Drittens, und das fehlt in vielen Setup-Guides: Prüfen Sie, ob Daten tatsächlich gesammelt werden, indem Sie das Dashboard der Monitoring-Plattform öffnen und bestätigen, dass Metriken angezeigt und im erwarteten Intervall aktualisiert werden. Ein erfolgreicher Verbindungstest und tatsächlich fließende Daten sind nicht dasselbe. Beide können unabhängig voneinander scheitern.
In HANA-Umgebungen ist die HANA Monitoring Verbindung getrennt von der ABAP-Verbindung und nutzt Zugangsdaten eines HANA-Datenbankbenutzers statt SAP-Benutzerzugangsdaten. Beide Verbindungen müssen unabhängig voneinander eingerichtet und geprüft werden. Eine Monitoring-Plattform, die für die ABAP-Verbindung grün anzeigt, sich aber nie erfolgreich mit HANA verbunden hat, überwacht in einer S/4HANA-Umgebung nicht die kritischste Performance-Schicht.
Der Unterschied zwischen verbunden und wirklich überwacht
Eine Monitoring-Plattform mit funktionierender Verbindung zum SAP-System ist nicht dasselbe wie eine Monitoring-Plattform mit sinnvoller Abdeckung. Die Verbindung ist die Voraussetzung. Ob das Monitoring nützlich ist, entscheidet die anschließende Konfiguration: welche Metriken gesammelt werden, in welcher Frequenz, mit welchen Alert-Schwellenwerten und an welche Personen die Alerts geroutet werden.
In der ersten Woche sollte die Monitoring-Plattform Daten sammeln, und Sie sollten diese Daten lesen, um zu verstehen, was sie über das System zeigen, das Sie gerade über die Gesundheitscheck-Transaktionen kennengelernt haben. Sie sollte noch nicht für Alerts konfiguriert werden, weil Ihnen die Baseline-Daten fehlen, um sinnvolle Schwellenwerte zu setzen. Alerts, die in der ersten Woche ohne Baseline konfiguriert werden, sind schwellenwertbasierte Vermutungen. Solche Vermutungen erzeugen entweder zu viele Alerts, sodass das Operations-Team sie ignoriert, oder zu wenige, sodass das Monitoring nichts erkennt.
Der Übergang von verbunden und sammelnd zu aktiv alarmierend erfolgt nach zwei bis vier Wochen Baseline-Daten. Diese Phase wird im Abschnitt zu Baselines beschrieben. Die Zwischenzeit ist keine verlorene Zeit. Sie ist die Phase, in der Sie lernen, wie das System unter normalen Bedingungen aussieht, damit abnormale Bedingungen sichtbar werden.
Die Dokumentation neu aufbauen, die Sie gebraucht hätten, aber nicht bekommen haben
Schnittstelleninventar aus dem System selbst ableiten
Wenn das Schnittstelleninventar nicht existiert oder veraltet ist, enthält das System selbst die verlässlichste Quelle. SM59 listet alle im System konfigurierten RFC-Destinationen. WE20 listet alle IDoc-Partnerprofile. BD54 zeigt die für ALE konfigurierten logischen Systeme. SMQ1 und SMQ2 zeigen aktive qRFC-Queues. Der ICM Monitor zeigt aktive HTTP-Verbindungen.
Ein Schnittstelleninventar aus diesen Transaktionsansichten aufzubauen dauert einige Stunden, liefert aber ein zuverlässigeres Bild als jede Dokumentation, die älter als sechs Monate ist: Es zeigt, welche Verbindungen tatsächlich existieren und welche aktuell aktiv sind. Eine RFC-Destination in SM59, die zuletzt vor drei Jahren verwendet wurde und beim Verbindungstest Fehler zeigt, ist ein Kandidat für Stilllegung. Eine RFC-Destination, die in keiner Dokumentation erwähnt wird, aber in den Statistiken hohe tägliche Nutzung zeigt, ist eine undokumentierte Abhängigkeit, die verstanden werden muss, bevor sie ausfällt.
Das Inventar muss am ersten Tag nicht vollständig sein. Priorisieren Sie Schnittstellen, die geschäftskritische Daten transportieren: Schnittstellen für Auftragsverarbeitung, Finanzbuchungen und Logistikausführung. Das sind die Verbindungen, deren Ausfall unmittelbare Auswirkungen auf das Business hat. Sie verdienen ein tiefes Verständnis statt nur eine beiläufige Dokumentation.
Jobplan-Dokumentation aus der SM37-Historie erstellen
SM37 mit einem Datumsbereich von 30 Tagen in der Produktion und ohne Filter auf Benutzer oder Jobname gibt Ihnen ein vollständiges Bild davon, was tatsächlich gelaufen ist. Exportieren Sie die Daten in eine Tabelle, wenn das Volumen groß ist. Gruppieren Sie nach Jobname. Erfassen Sie für jeden Job die durchschnittliche Laufzeit, die Erfolgsquote, die geplante Frequenz und das letzte Ausführungsdatum.
Diese Übung zeigt typischerweise drei Dinge, die in der Dokumentation nicht erwähnt wurden. Erstens Jobs, die in der Dokumentation stehen, aber seit Monaten nicht gelaufen sind, entweder weil sie außer Betrieb genommen wurden, ohne aus dem Schedule gelöscht zu werden, oder weil sie seit Langem fehlschlagen und niemand sich darum gekümmert hat. Zweitens Jobs, die regelmäßig laufen, aber nicht dokumentiert sind, weil sie irgendwann ad hoc erstellt und nie formal erfasst wurden. Drittens Jobs, deren Laufzeiten deutlich gestiegen sind, was sichtbar wird, wenn Sie den 30-Tage-Durchschnitt mit einer dokumentierten Baseline vergleichen.
Die Jobplan-Dokumentation, die Sie aus der SM37-Historie neu erstellen, wird zur operativen Baseline für das Job Monitoring: erwartetes Abschlussfenster, normaler Laufzeitbereich, Abhängigkeiten. Das ist Arbeit, die vor Ihrer Ankunft hätte erledigt sein sollen, aber nicht erledigt wurde.
Eskalationswege: herausfinden, wer wirklich angerufen wird
Die Eskalationsdokumentation listet wahrscheinlich Namen und Telefonnummern. Einige dieser Personen sind vielleicht noch im Unternehmen, andere nicht. Der tatsächliche Eskalationsweg, also wer angerufen wird, wenn das Produktivsystem an einem Sonntag um 02:00 Uhr ein Problem hat, ist institutionelles Wissen, das eher in den Köpfen von Menschen lebt als in Dokumenten.
Führen Sie in der ersten Woche direkte Gespräche mit mindestens drei Personen: dem IT-Manager, der für SAP verantwortlich ist, dem erfahrensten Business Process Owner, der das System täglich nutzt, und der Person, die vor Ihrer Ankunft nächtliche Incidents betreut hat. Fragen Sie jede dieser Personen, was passiert, wenn um 03:00 Uhr etwas schiefgeht. Die drei Antworten werden unterschiedlich sein und zusammen genauer als jedes Eskalationsdokument.
Das Ergebnis dieser Gespräche ist ein praktisches On-Call-Runbook: wer für welche Art von Incident kontaktiert wird, welche Reaktionszeit erwartet wird, welche Incidents bis zu den Geschäftszeiten warten können und welche nicht. Dieses Runbook schreiben und pflegen Sie. Es ist nicht das, was Sie erben.
Eine Baseline aufbauen, bevor Alerts konfiguriert werden
Warum Alerting am ersten Tag eher Rauschen als Signal erzeugt
Alert-Schwellenwerte, die ohne Baseline-Daten konfiguriert werden, basieren auf Intuition oder auf generischen SAP-Empfehlungen. Generische SAP-Empfehlungen sind Startpunkte für ein typisches System. Ihr System ist nicht typisch. Es hat ein spezifisches Workload-Profil, einen spezifischen Batch-Schedule, ein spezifisches Muster der HANA-Speichernutzung und bestimmte Schnittstellen mit eigenen Traffic-Volumina. Generische Schwellenwerte, die auf ein spezifisches System angewendet werden, lösen bei Bedingungen aus, die in dieser Umgebung völlig normal sind.
Ein Operations-Team, das zehn Alerts pro Tag für normale Bedingungen erhält, lernt sehr schnell, Alerts zu ignorieren. Alert Fatigue ist, sobald sie entstanden ist, schwer rückgängig zu machen. Ein Schwellenwert, der stummgeschaltet wird, weil er jeden Morgen während des Batch-Fensters auslöst, bleibt stumm, wenn er für ein echtes Problem auslösen würde. Mit keinen Alerts zu beginnen und sie aus Baseline-Daten aufzubauen, statt mit generischen Schwellenwerten zu starten und danach Rauschen zu reduzieren, ist der Ansatz, der eine verlässliche Monitoring-Konfiguration erzeugt.
Das zwei- bis vierwöchige Sammelfenster und was Sie damit machen
Zwei Wochen sind das Minimum für eine Baseline, wenn Sie ein System gerade übernommen haben. Vier Wochen sind besser, weil dann ein Monatsabschlusszyklus erfasst wird. Was Sie in dieser Zeit sammeln, ist die tatsächliche Verteilung der Werte für jede Metrik, auf die Sie später alerten wollen: nicht nur der Durchschnitt, sondern die gesamte Verteilung inklusive Spitzen.
Für die Auslastung der Dialog Work Processes sollten Sie den 95. Perzentilwert während der Geschäftszeiten kennen, den Spitzenwert während Batch-Fenstern und das typische nächtliche Minimum. Ein Alert-Schwellenwert, der beim 98. Perzentil der Baseline-Verteilung liegt, wird nur bei wirklich ungewöhnlichen Bedingungen auslösen. Ein Alert bei 80 % löst dagegen für die obersten 15 % normaler Beobachtungen aus.
Für die HANA-Speicherauslastung benötigen Sie dieselbe Verteilung plus den Monatsabschluss-Peak, falls Ihr Baseline-Fenster einen solchen enthält. Für jeden Hintergrundjob der Tier-1-Liste sollten Sie die Laufzeitverteilung an normalen Tagen und die Laufzeit beim Monatsabschluss kennen, um getrennte Laufzeitschwellenwerte definieren zu können.
Am Ende der Baseline-Phase haben Sie genügend Daten, um die erste Gruppe sinnvoller Alerts zu konfigurieren. Nicht alle Alerts für alle Metriken, sondern die wichtigsten: HANA-Speicher nähert sich dem Allocation Limit, Sättigung der Dialog Work Processes, kritische Batch-Jobs überschreiten ihr erwartetes Abschlussfenster, Wachstum des HANA Log Volumes und Fehler bei Update Tasks. Diese fünf Kategorien decken die meisten Produktionsvorfälle in einer typischen SAP-Umgebung ab. Alles Weitere kann schrittweise ergänzt werden.
Woche eins, Monat eins, Monat drei: was wann stehen sollte
Der folgende Zeitrahmen beschreibt einen realistischen Fortschritt für ein oder zwei Basis Engineers, die eine bestehende Landschaft übernehmen. Es ist kein Projektplan. Es ist ein Priorisierungsleitfaden.
Bis Ende der ersten Woche: Systemzugriff bestätigt, Gesundheitscheck-Transaktionen geprüft, kritische offene Themen identifiziert, insbesondere SM13, ST22 und SM37-Fehler, informeller Eskalationsweg aus Gesprächen dokumentiert, Monitoring-Plattform verbunden und im Read-only-Modus ohne Alerting Daten sammelnd.
Bis Ende des ersten Monats: Entwurf des Schnittstelleninventars aus SM59 und der Partnerprofilprüfung abgeschlossen, Jobplan-Dokumentation aus der SM37-Historie neu aufgebaut, Baseline-Daten für Kernmetriken gesammelt, erste Alerts nur für kritische Bedingungen konfiguriert, etwa HANA Log Volume, Update Task Fehler und kritische Jobfehler, Berechtigungsprofil des Monitoring-Benutzers geprüft und als minimal erforderlich bestätigt.
Bis Ende des dritten Monats: vollständige Alert-Konfiguration auf Basis der Baseline-Daten eingerichtet, Begründung der Schwellenwerte dokumentiert, Eskalations-Runbook geschrieben und getestet, Monatsabschlussverhalten beobachtet und in zeitabhängige Alert-Schwellenwerte übertragen, Monitoring-Handover-Dokumentation geschrieben, als würden Sie das System morgen an jemand anderen übergeben, weil das irgendwann passieren wird.
Das Monitoring-Handover-Dokument als Ergebnis des dritten Monats klingt vielleicht verfrüht. Ist es aber nicht. Es zwingt Sie, zu erklären, warum Schwellenwerte so gesetzt sind, welche Alerts zuverlässig sind, welche noch Feintuning brauchen und was der On-Call Engineer wissen muss, um auf jede Alert-Kategorie zu reagieren. Diese Klarheit unterscheidet Monitoring, das auch bei Teamwechseln funktioniert, von Monitoring, das beim nächsten Onboarding wieder komplett neu aufgebaut werden muss.
Das System, das Sie übernehmen, sagt Ihnen bereits, was es braucht
Jedes SAP-Produktivsystem, das länger als ein Jahr läuft, hat einen eigenen Charakter entwickelt: wiederkehrende Fehlermuster, spezifische Performance-Eigenschaften, die sein Normalverhalten definieren, und Integrationen, die mehr Aufmerksamkeit benötigen als andere. Dieser Charakter steht in keiner Dokumentation. Er steckt in SM21, in ST22, in der SM37-Historie, in den HANA Memory Trend Graphs und in der Abfolge der Ereignisse, auf die das vorherige Team reagiert hat.
Die Lesephase vor der Konfiguration ist keine Verzögerung beim Aufbau des Monitorings. Sie ist der Prozess, in dem Sie verstehen, was das System Ihnen bereits sagt, damit Ihre Monitoring-Konfiguration die wichtigen Signale verstärkt, statt Rauschen aus einem Template zu erzeugen, das für eine andere Umgebung entworfen wurde.
Day-one Monitoring bedeutet nicht, alles eingerichtet zu haben. Es bedeutet, die Dinge nicht zu übersehen, die zählen, während Sie alles andere lernen. Das heißt: Die Gesundheitscheck-Transaktionen sind geprüft, kritische offene Themen sind bekannt und die Monitoring-Plattform sammelt vor Ende der ersten Woche Daten. Alles danach ist Verfeinerung, und diese Verfeinerung basiert auf Beobachtung statt auf Annahmen.
Redpeaks verbindet sich über agentless RFC mit SAP-Systemen, ohne Transporte und ohne SAP-seitige Software. Die Baseline-Erfassung beginnt ab dem ersten Verbindungstag. Die Alert-Konfiguration kann schrittweise angewendet werden, während die Baseline-Daten reifen.
