Die meisten SAP-Operations-Teams sind sehr gut darin, zu überwachen, was gerade passiert. Sie setzen Schwellenwerte und Alerts, reagieren auf Incidents und optimieren Konfigurationen auf Basis des beobachteten Systemverhaltens. Deutlich seltener werden dieselben Monitoring-Daten genutzt, um eine andere Frage zu beantworten: Was werden wir in sechs Monaten benötigen, und wann müssen wir den Prozess starten, um diese Kapazität rechtzeitig bereitzustellen?
Bei der Kapazitätsplanung geht es darum, den zukünftigen Infrastrukturbedarf anhand aktueller Trends zu prognostizieren. Monitoring-Daten liefern genau die Grundlage dafür, doch nur wenige Teams nutzen sie systematisch für diesen Zweck. Ohne Kapazitätsplanung entsteht häufig dasselbe Muster: Ein Engpass wird erst sichtbar, wenn er bereits kritisch ist. Die notwendige Erweiterung muss dann unter Zeitdruck umgesetzt werden, obwohl Beschaffungs- und Bereitstellungszeiten länger sind als die verbleibende Zeit.
Der Unterschied zwischen Monitoring und Kapazitätsplanung
Monitoring beantwortet die Frage, was gerade passiert. Kapazitätsplanung beantwortet die Frage, wann die aktuellen Bedingungen zu einem Engpass werden. Beides basiert auf denselben Daten, aber die Analyse verfolgt ein anderes Ziel.
Ein Performance-Problem betrifft die Gegenwart: Der HANA-Speicher ist zu 89 % ausgelastet und erfordert sofortige Aufmerksamkeit. Ein Kapazitätsproblem betrifft die Zukunft: Die HANA-Speicherauslastung ist innerhalb von vier Monaten von 62 % auf 74 % gestiegen. Bei gleichbleibender Entwicklung wird sie im März 86 % erreichen. Ein Performance-Problem ist auch ohne Trendanalyse sichtbar. Ein Kapazitätsproblem wird erst sichtbar, wenn jemand die Entwicklung über einen längeren Zeitraum betrachtet.
Diese Unterscheidung ist wichtig, weil die Reaktionszeiten völlig unterschiedlich sind. Ein Performance-Problem lässt sich manchmal innerhalb weniger Stunden durch Tuning, einen Neustart eines Services oder die Umverteilung von Ressourcen beheben. Ein Kapazitätsproblem erfordert dagegen häufig Beschaffung, Infrastruktur-Provisioning oder Vertragsänderungen. Diese Prozesse dauern Wochen oder sogar Monate. Wenn aus einem Kapazitätsproblem ein sichtbares Performance-Problem wird, ist es häufig bereits zu spät, es über den normalen Beschaffungsprozess zu lösen.
Die Kennzahlen, die Kapazitätsentscheidungen bestimmen
HANA-Speicher und Datenbank-Rechenleistung
Die maximale HANA-Speicherauslastung als Prozentsatz des Allocation Limits ist einer der wichtigsten Kapazitätsindikatoren in S/4HANA-Umgebungen. Entscheidend ist weder die aktuelle Auslastung noch der Tagesdurchschnitt. Relevant ist der Höchstwert während des Lastspitzenereignisses einer Periode, beispielsweise der Monatsabschluss für eine monatliche Analyse oder der Jahresabschluss für eine jährliche Betrachtung. Genau diese Last muss die Infrastruktur ohne Engpass bewältigen können.
Werden die maximalen Speicherauslastungen über sechs bis zwölf Monate erfasst, entsteht ein Trend, der zeigt, ob das System schrittweise immer mehr seines verfügbaren Kapazitätspuffers verbraucht. Eine Entwicklung von 65 % beim Monatsabschluss im Januar auf 73 % im Juni und 80 % im Oktober liefert bereits ein klares Bild. Ein komplexes Modell ist nicht erforderlich, um abzuschätzen, wann die Entscheidungsschwelle von 85 % erreicht wird.
Die CPU-Thread-Auslastung während besonders intensiver Batch-Verarbeitungen ist ein zweiter wichtiger Indikator. Sind während des Batch-Laufs zum Jahresabschluss sämtliche verfügbaren HANA-Ausführungs-Threads ausgelastet, besteht im gleichen Zeitfenster kein Kapazitätspuffer mehr für zusätzliche analytische Workloads. Eine solche Thread-Sättigung ist in Tagesdurchschnittswerten kaum sichtbar. Sie zeigt sich nur in der Spitzenauslastung während des konkreten Ereignisses, das sie verursacht.
Verbleibende Storage-Kapazität
Das Wachstum des Datenvolumens gehört zu den am besten prognostizierbaren Kapazitätskennzahlen in einer SAP-Umgebung. Es wird hauptsächlich durch das Transaktionsvolumen bestimmt, das sich meist langsam und kontinuierlich verändert. Fragen Sie M_DISK_USAGE zwölf Wochen lang einmal pro Woche ab und erfassen Sie die Größe der DATA-Komponente. Teilen Sie die Veränderung im betrachteten Zeitraum durch die Anzahl der Wochen, um die wöchentliche Wachstumsrate zu erhalten. Diese Rate kann anschließend in die Zukunft extrapoliert werden, um zu bestimmen, wann der Storage zu einem Engpass wird.
Die Berechnung ist einfach: Verfügbare Storage-Kapazität minus aktuelles Datenvolumen, geteilt durch die wöchentliche Wachstumsrate, ergibt die Anzahl der Wochen bis zur Ausschöpfung der aktuellen Kapazität. Sobald 80 % dieses Zeitpuffers aufgebraucht sind, sollte der Erweiterungsprozess beginnen. Die verbleibenden 20 % schaffen einen Puffer für eine mögliche Beschleunigung des Wachstums und für Beschaffungszeiten.
Beim Log-Volumen sieht die Situation anders aus. Es wächst nicht direkt mit dem Datenvolumen, sondern mit der Anzahl der Schreibtransaktionen und der Häufigkeit der Log-Backups. Verdoppelt ein Unternehmen sein Transaktionsvolumen, ohne die Frequenz der Log-Backups anzupassen, kann der Druck auf das Log-Volumen deutlich schneller steigen als auf das eigentliche Datenvolumen. Deshalb sollten die Häufigkeit der Log-Backups und die Auslastung des Log-Volumens gemeinsam überwacht werden. Steigt das Transaktionsvolumen deutlich, sollte auch das Backup-Intervall neu bewertet werden.
Kapazitätspuffer der Applikationsserver
Die Auslastung der Dialog-Workprozesse pro Instanz, gemessen am 95. Perzentil der Spitzenzeiten über rollierende 30-Tage-Zeiträume, zeigt, ob sich die Applikationsserver-Schicht einer Sättigung nähert. Das 95. Perzentil ist aussagekräftiger als der Durchschnitt, weil es die hohen Lastsituationen erfasst, die Anwender tatsächlich wahrnehmen, ohne dass einzelne sehr kurze Spitzen die Analyse verzerren.
Eine Instanz, deren 95. Perzentil innerhalb von sechs Monaten von 68 % auf 78 % gestiegen ist, stellt heute noch keinen Notfall dar. Sie ist jedoch ein Kapazitätsthema für den nächsten Budgetzyklus. Eine Instanz, die bereits bei 85 % liegt und weiter wächst, verfügt über deutlich weniger Puffer und erfordert eine frühere Entscheidung.
Die Lizenzkapazität ist eine nicht technische Dimension, die Teams häufig überrascht. Named-User-Lizenzen oder Concurrent-Access-Lizenzen haben eine Obergrenze. Wird diese erreicht, kann die Bereitstellung neuer Benutzer verlangsamt oder vollständig blockiert werden. Deshalb sollte monatlich verglichen werden, wie viele Benutzer lizenziert und wie viele bereits provisioniert sind. In Unternehmen mit kontinuierlichem Personalwachstum schließt sich die Lücke zwischen verfügbaren und provisionierten Lizenzen häufig mit einer gut prognostizierbaren Geschwindigkeit.
Ein Wachstumsmodell aus Monitoring-Daten entwickeln
Der Referenzzeitraum ist wichtiger als das Modell
Eine Wachstumsprognose auf Basis von nur 30 Tagen ist nicht zuverlässig. In den ersten 30 Tagen nach einem Go-live können initiale Datenladungen die Wachstumsrate künstlich erhöhen. Ein 30-Tage-Zeitraum mitten im Geschäftsjahr enthält möglicherweise keinen Monatsabschluss und damit auch nicht das Lastmuster, das die größten Spitzen verursacht. Die Prognose wird dadurch falsch, und die daraus abgeleitete Entscheidung ebenfalls.
Ein Referenzzeitraum von sechs Monaten ist das Minimum für ein belastbares Wachstumsmodell. Er umfasst mindestens zwei vollständige Geschäftszyklen mit vergleichbaren Workload-Phasen, Monatsabschlüsse an mehreren Vergleichspunkten und genügend Daten, um zwischen einem linearen Wachstumstrend und saisonalen Schwankungen unterscheiden zu können. Für die Kapazitätsplanung rund um den Jahresabschluss ist ein Zwölf-Monats-Zeitraum, der auch den Jahresabschluss des Vorjahres enthält, erheblich zuverlässiger als jede Prognose, die ausschließlich auf dem vorhergehenden Quartal basiert.
Das Modell selbst muss nicht komplex sein. Eine lineare Regression auf die monatlichen Spitzenwerte der Speicherauslastung liefert eine Steigung, die der monatlichen Wachstumsrate entspricht. Wird diese Steigung auf den aktuellen Wert und den verbleibenden Abstand zur Entscheidungsschwelle angewendet, lässt sich abschätzen, wie viele Monate bis zum Handlungsbedarf verbleiben. Sobald die Monitoring-Daten vorhanden sind, lässt sich diese Berechnung problemlos in einem Tabellenblatt durchführen.
Saisonale Effekte und sprunghafte Veränderungen
Wachstumsmodelle auf Basis linearer Trends unterschätzen die Anforderungen zum Jahresende, wenn der Referenzzeitraum keine vergleichbaren Hochlastphasen enthält. Die Lastspitze eines Monatsabschlusses im Juni ist nicht mit der Spitze beim Jahresabschluss im Dezember vergleichbar. Eine Prognose, die ausschließlich Daten von Juni bis Oktober verwendet, berücksichtigt den Dezember-Peak überhaupt nicht.
Eine Möglichkeit zur Korrektur ist die Berechnung eines saisonalen Faktors anhand historischer Daten. Wie hoch war in den Vorjahren das Verhältnis zwischen der Spitzenauslastung im Dezember und der entsprechenden Auslastung im vorhergehenden Oktober? Dieser Faktor kann auf die für Oktober prognostizierte Auslastung angewendet werden, um den Dezemberwert abzuschätzen. Das Ergebnis ist nicht exakt, aber deutlich zuverlässiger als die Annahme, dass Dezember dieselbe Last wie Oktober aufweisen wird.
Sprunghafte Veränderungen, beispielsweise der Go-live einer neuen Business Unit, die Aktivierung einer großen Integration oder ein zweistelliges Mitarbeiterwachstum in einem stark nutzerabhängigen Prozess, erzeugen plötzliches Wachstum, das ein lineares Trendmodell nicht vorhersehen kann. Im Monitoring zeigt sich ein solcher Sprung durch eine deutlich beschleunigte Wachstumsrate innerhalb einer bestimmten Woche. In diesem Fall sollte die Prognose anhand der Wachstumsrate nach der Veränderung neu berechnet werden, anstatt weiterhin den historischen Durchschnitt zu verwenden.
| Achtung: Wachstumsprognosen, die die Wachstumsraten vor und nach einer sprunghaften Veränderung mitteln, unterschätzen den zukünftigen Bedarf. Wenn das Datenvolumen sechs Monate lang um 8 GB pro Monat wächst und nach dem Go-live einer neuen Integration plötzlich auf 22 GB pro Monat steigt, ist ein Durchschnitt von 15 GB in beide Richtungen irreführend: Er überschätzt das historische Wachstum und unterschätzt das zukünftige Wachstum. Für die neue Prognose sollte der Referenzzeitraum segmentiert und die Phase vor der Veränderung ausgeschlossen werden. |
|---|
Die Vorlaufzeit ist der eigentliche Engpass
Wie früh eine Kapazitätsentscheidung getroffen werden muss, hängt vor allem von der Vorlaufzeit für die Erweiterung ab. Diese unterscheidet sich erheblich je nach Infrastrukturtyp.
Bei On-Premise-Hardware benötigen Speichererweiterungen und zusätzliche Applikationsserver-Nodes typischerweise acht bis zwölf Wochen vom Auftrag bis zur tatsächlich installierten Kapazität. Bei Storage-Erweiterungen sind die Zeiträume ähnlich. Diese Angaben setzen voraus, dass der Beschaffungsprozess ohne Verzögerungen verläuft. Budgetfreigaben können mehrere zusätzliche Wochen verursachen.
Bei Hyperscaler-Deployments und RISE with SAP erfordert der Wechsel eines Instance-Typs ein geplantes Wartungsfenster und einen Neustart. Die technische Änderung selbst kann nach der Freigabe teilweise innerhalb weniger Tage erfolgen. Der größte Teil der Vorlaufzeit entsteht durch Change-Management- und Genehmigungsprozesse, nicht durch die Bereitstellung der Hardware. Bei einfachen Prozessen sind zwei bis vier Wochen üblich. Unternehmen mit formellen Change-Management-Zyklen benötigen jedoch teilweise sechs bis acht Wochen von der Entscheidung bis zur Umsetzung.
Die Beschaffung zusätzlicher Lizenzen hängt vom jeweiligen Vertrag ab, dauert für neue Lizenzvolumen aber selten weniger als drei Wochen. Noch länger kann es dauern, wenn eine Vertragsänderung erforderlich ist. Zusätzliche Named-User-Lizenzen im Rahmen eines Enterprise Agreements können zudem eine Freigabe durch das Management und eine rechtliche Prüfung erfordern.
Deshalb muss rückwärts gerechnet werden. Wenn die Entscheidungsschwelle für den HANA-Speicher bei 85 % maximaler Auslastung liegt und die Beschaffung zusätzlicher On-Premise-Speicherkapazität zehn Wochen dauert, sollte die Planung beginnen, sobald der Trend zeigt, dass die 85-%-Marke in vierzehn Wochen erreicht wird. Nicht erst zehn Wochen vorher. Die zusätzlichen vier Wochen sind der Puffer für Abstimmungen, Business Case, Budgetfreigabe und die eigentliche Initiierung des Beschaffungsprozesses.
| In der Praxis: Definieren Sie die Entscheidungsschwelle und die Beschaffungsvorlaufzeit für jede Kapazitätsdimension, bevor Sie sie tatsächlich benötigen. Sobald ein Monitoring-Trend den Handlungsbedarf signalisiert, sollte das Team sofort wissen, welcher Schritt folgt und wer ihn freigeben muss. Den Beschaffungsprozess erst während einer akuten Kapazitätskrise zu klären, kostet zusätzliche Wochen, obwohl die verfügbare Vorlaufzeit bereits in der ursprünglichen Planung berücksichtigt wurde. |
|---|
Monitoring-Trends in Budgetargumente übersetzen
Finance- und IT-Verantwortliche treffen Infrastrukturentscheidungen nicht anhand von HANA-Speicherprozenten oder Auslastungswerten der Dialog-Workprozesse. Sie entscheiden anhand von Kosten, Zeitplan und Konsequenzen. Eine Kapazitätsplanung, die tatsächlich zu einer Entscheidung führt, sollte deshalb drei Punkte enthalten: den verbleibenden Kapazitätspuffer in Monaten, die Kosten der notwendigen Erweiterung und die betrieblichen Folgen, falls die Erweiterung nicht innerhalb dieses Zeitfensters erfolgt.
Für jede Kapazitätsdimension, die innerhalb der kommenden zwölf Monate voraussichtlich an eine Grenze stößt, sollten genau diese drei Informationen bereitgestellt werden. HANA-Speicher: sieben Monate Puffer bei der aktuellen Wachstumsrate, Erweiterungskosten von X, Konsequenz ohne Erweiterung ist das Risiko eines ungeplanten Notfalls während des Finanzabschlusses im nächsten Jahr. Storage: elf Monate verbleibende Kapazität, Erweiterungskosten von Y, Konsequenz ist eine Überschreitung der verfügbaren Storage-Kapazität und die Notwendigkeit einer kurzfristigen Archivierung zu einem Zeitpunkt, an dem das Team bereits mit anderen Prioritäten ausgelastet ist. Mit diesen Angaben kann eine IT-Leitung eine konkrete Entscheidung treffen. Gleichzeitig gibt es für jede Entscheidung eine klare Deadline.
Die Monitoring-Daten liefern die Zahlen. Die Kapazitätsplanung übersetzt sie in eine Form, die rechtzeitig zu einer Budgetposition und einem Auftrag führt, bevor der vorhandene Kapazitätspuffer aufgebraucht ist.
Monitoring ohne Kapazitätsplanung ist von Natur aus reaktiv. Es löst Alerts aus, wenn eine Situation bereits problematisch geworden ist. Kapazitätsplanung macht Monitoring-Daten dagegen proaktiv nutzbar. Trends werden analysiert, um Entscheidungen zu identifizieren, die getroffen werden müssen, bevor die aktuelle Entwicklung zum nächsten Incident führt.
Welche Infrastruktur eine SAP-Umgebung in zwölf Monaten benötigt, lässt sich bereits heute in den Monitoring-Daten erkennen. Entscheidend ist, ob dieses Signal früh genug die Personen erreicht, die tatsächlich handeln können. Das hängt davon ab, ob das Unternehmen Kapazitätsplanung als regelmäßigen Bestandteil des SAP-Betriebs versteht oder erst dann darauf reagiert, wenn genau die Kennzahl kritisch wird, die durch die Planung frühzeitig erkannt werden sollte.
Redpeaks bietet Trendanalysen für HANA-Speicher, Storage, Rechenleistung und Work-Process-Metriken sowie konfigurierbare Kapazitätsprognosen auf Basis rollierender Referenzzeiträume.
