Bei der Einführung von RISE with SAP fällt meist der Satz: „SAP verwaltet die Infrastruktur.“ Das ist richtig, führt aber häufig zur Annahme, damit sei auch das Monitoring der darauf laufenden Anwendungen abgedeckt. Die Grenze zwischen SAP-Verantwortung und Kundenaufgaben ist schärfer und für Kunden weniger umfassend, als dieser Satz nahelegt.
Dieser Leitfaden beschreibt diese Grenze, ihre operative Bedeutung und eine Monitoring-Anbindung, die die Lücken des gemeinsamen Verantwortungsmodells schließt.
Was SAP in RISE verwaltet und was das für Monitoring bedeutet
RISE bündelt S/4HANA Cloud Private Edition, BTP und verwaltete Infrastruktur. SAP und der Hyperscaler betreuen Compute, Storage, Netzwerk, Betriebssystempatches, HANA-Hochverfügbarkeit, Datenbankadministration und Plattform-Incidents bei Infrastrukturfehlern.
Operative Sicht auf die Anwendung gehört nicht zu diesem Infrastrukturumfang. SAP überwacht Plattformverfügbarkeit und laufenden HANA-Service, nicht die rechtzeitige Job-Fertigstellung, IDoc-Fehler, Dialogantwortzeiten im fachlichen SLA oder stille Verbuchungsfehler. Diese Zustände liegen beim Kunden.
RISE reduziert daher nicht den Bedarf an Anwendungsmonitoring. Es übernimmt das zuvor kundenseitige Infrastrukturmonitoring, den kleineren Teil des SAP-Monitorings. Die Anwendungsschicht, in der die meisten Incidents entstehen, bleibt vollständig Kundenaufgabe.
Die gemeinsame Verantwortung im Überblick
Die folgende Zuordnung trennt Plattformverfügbarkeit und Anwendungsgesundheit. SAPs Verpflichtung betrifft die Plattform, der Kunde besitzt die Anwendungsebene.
| SAP verwaltet in RISE | Beim Kunden verbleibt |
|---|---|
| Hyperscaler-Infrastruktur: Compute, Storage, Netzwerk | Hintergrundjob-Planung und Ergebnisüberwachung |
| HANA-Cluster-HA und Failover | HANA-Anwendungsperformance und M_*-Sichten |
| OS-Patches und Kernel-Updates | IDoc-, RFC- und API-Schnittstellengesundheit |
| SAP-Plattformverfügbarkeits-SLA | ABAP-Short-Dumps und Verbuchungsfehler |
| Netzwerkanbindung an die Hyperscaler-Region | BTP-Erweiterungen und Integration-Suite-Flows |
| Reaktion auf Plattform-Incidents | Geschäftsprozess-Abschluss-SLOs |
| Datenbankadministration und HANA-Plattformdienste | Qualität eigener ABAP-Programme und Berechtigungsdesign |
Achtung: Das RISE-SLA deckt Infrastruktur- und Plattformverfügbarkeit ab, nicht Anwendungsantwortzeiten, Job-Erfolgsquoten, Schnittstellenlaufzeiten oder Prozessfenster. Wer das verwechselt, entdeckt die Lücke im Incident, wenn SAP eine gesunde Plattform und ein Anwendungsproblem bestätigt.
Der Monitoring-Umfang, der nicht übertragen wird
Anwendungsmetriken
Alle früher relevanten Anwendungsmetriken bleiben relevant: Dialogzeiten nach Transaktionscode, WP-Auslastung je Instanz, Verbuchungsqueues, Job-Erfolg und Dump-Häufigkeit. SM50, SM66, SM37, SM13 und ST22 bleiben verfügbar. Workprozess- und Hintergrundjob-Monitoring werden unverändert benötigt.
Auch HANA-Anwendungsmetriken bleiben beim Kunden. SYS-Sichten wie M_MEMORY_OVERVIEW, M_DISK_USAGE, M_BACKUP_CATALOG, M_DELTA_MERGE_STATISTICS und M_EXPENSIVE_STATEMENTS sind für einen entsprechend eingerichteten Monitoring-Datenbankbenutzer zugänglich. SAP überwacht HANA als Dienst, der Kunde als Datenbank seiner Anwendung. Verschiedene Ziele erfordern verschiedene Metriken. Das HANA-Monitoring erläutert den vollständigen Anwendungsumfang.
Geschäftsergebnisse
SAP weiß nicht, ob ein bestimmter Job bis 06:00 Uhr fertig sein sollte oder fachlich korrekte Ergebnisse liefert. Diese Anforderungen und die SLOs darüber, was wann geliefert wird, liegen außerhalb des RISE-Plattformumfangs.
So wird der Unterschied zwischen 99,9 % Plattformverfügbarkeit und echter Kontinuität sichtbar: Die Plattform kann zu 100 % verfügbar sein, während ein Job ausfällt, eine Schnittstelle stoppt und der Monatsabschluss seine Frist verfehlt. SAPs SLA ist erfüllt, das Geschäftsziel nicht. Nur der Kunde kann diese Ebene überwachen und reagieren.
BTP-Erweiterungen und Integration
BTP kann zum Paket gehören, doch Erweiterungen sind Kundencode auf SAP-Infrastruktur. SAP betreibt die Plattform; der Kunde überwacht Performance, Fehler und Verfügbarkeit seiner Integration-Suite-Flows, Anwendungen und S/4HANA-Erweiterungs-APIs. Die Hinweise zum SAP-Integration-Hub-Monitoring gelten auch hier.
Wie Monitoring mit RISE verbunden wird
RFC zur ABAP-Anwendungsschicht
Die Anbindung ähnelt jedem SAP-System: dedizierten technischen Benutzer im Produktivmandanten anlegen, lesende Monitoring-Rechte zuweisen und die entsprechende RFC-Destination in SM59 konfigurieren. Infrastrukturzugriff und Installation von SAP-seitiger Software sind nicht erforderlich.
Das ist der agentenlose Ansatz. RFC-Erfassung benötigt geeignete Berechtigungen, ohne besondere RISE-spezifische Einschränkung auf dieser Ebene. Die agentenlose Architektur beschreibt die Einrichtung. Dasselbe Verfahren wie lokal gilt für RISE Private Edition.
HANA-SQL-Zugriff in RISE
Ein Monitoring-Datenbankbenutzer benötigt insbesondere MONITORING und CATALOG READ. Die Einrichtung folgt SAPs Verfahren für Kundendatenbankbenutzer statt umfassendem DBA-Zugriff. Das Tool verbindet sich per JDBC und liest Systemviews für die kundenseitigen Anwendungsmetriken.
Anwendungsdatenerfassung ist von Infrastrukturzugriff zu unterscheiden. SAP begrenzt direkten SSH-Zugang, weitergehende HANA-Administration und Änderungen verwalteter Konfiguration. Diese Einschränkungen betreffen nicht dieselbe Ebene wie lesendes Anwendungsmonitoring.
Hinweis: Public Edition ist stärker eingeschränkt als Private Edition. Standardisierte Konfiguration reduziert Änderungen an Parametern und individuelle Monitoring-Konfigurationen. Prüfen Sie mit SAP die verfügbaren Zugriffe und Anbindungen, bevor Sie Private-Edition-Fähigkeiten voraussetzen.
Monitoring-Lücken nach dem Go-live
Das Muster ist wiederkehrend: Früher selbstverständlich vorhandene Fähigkeiten benötigen explizite Einrichtung, weil „SAP übernimmt Monitoring“ zu weit ausgelegt wurde.
Am häufigsten fehlen Hintergrundjobs. SAP warnt bei Infrastrukturereignissen, nicht automatisch bei Kundenbatchjobs. Ein um 04:00 Uhr scheiternder Tier-1-Job erzeugt ohne entsprechend konfiguriertes Kundenmonitoring keinen Alert. SAP bestätigt eine gesunde Plattform; der Fehler gehört zur Anwendung.
Zweitens fehlen Schnittstellen: fehlerhafte IDocs in BD87, qRFC-Rückstände in SMQ1, nicht mehr erreichbare RFC-Destinationen und ablaufende Zertifikate von Integration-Suite-Connectors sind Anwendungsereignisse ohne automatische RISE-Warnung. Der SAP-Schnittstellenleitfaden gilt direkt, denn RFC erreicht dieselbe Anwendungsschicht unabhängig vom Hardwarestandort.
Drittens fehlt HANA-Anwendungsperformance. SAP überwacht Plattformstabilität; Speicher nahe dem Allokationslimit muss der Kunde verfolgen, bevor daraus ein Plattformereignis wird. Ohne Monitoring ist das erste Zeichen wie lokal möglicherweise ein ungeplanter Datenbankstopp. Der S/4HANA-Go-live-Leitfaden beschreibt die Instrumentierung vor der ersten Produktivlast bei Migration und Neueinführung.
RISE ändert die Infrastrukturverantwortung, nicht die nötigen Anwendungsmetriken oder deren Eigentümer. Vorbereitete Kunden lesen das Modell vor dem Go-live, verbinden Monitoring frühzeitig und unterscheiden Infrastrukturverwaltung von Anwendungsüberwachung.
Unvorbereitete Kunden entdecken die Lücke beim ersten Incident: SAP meldet eine gesunde Plattform und die eigentliche Untersuchung beginnt ohne vorhandene Anwendungsdaten bei null.
Redpeaks verbindet RISE über Standard-RFC und HANA SQL ohne Infrastrukturzugriff. Die bekannte On-Premises-Abdeckung steht damit auch in RISE zur Verfügung. Entdecken Sie das RISE-with-SAP-Monitoring.
