Kapazitäten planen: So wird aus erwarteter Last ein belastbarer Plan

Montagmorgen, Vertriebsrunde. Der neue Großkunde ist unterschriftsreif. Wenn alles klappt, kommen in vier Wochen 8.000 zusätzliche Benutzer auf die Plattform. Sehr schön.

Mittwochnachmittag erfährt die IT davon. Das aktuelle System ist schon an normalen Monatsenden ziemlich beschäftigt. Eine notwendige Erweiterung der Datenbank braucht sechs Wochen Vorlauf. Das Limit des Cloud-Anbieters lässt sich nicht per freundlichem Zuruf erhöhen. Und ausgerechnet der Mitarbeiter, der den Lasttest beherrscht, hat in drei Wochen Urlaub.

Das Monitoring war die ganze Zeit grün. Es wusste nur nichts vom Vertrieb.

Genau deshalb ist Kapazitätsplanung mehr als das Beobachten von CPU, RAM und Festplatten. Wer Kapazitäten vernünftig planen will, muss erwarteten Geschäftsbedarf, technische Grenzen, Reserven, Vorlaufzeiten und konkrete Entscheidungen miteinander verbinden.

Die kurze Antwort

Kapazitätsplanung beginnt nicht beim Server, sondern bei der Frage: Welche Leistung müssen wir wann zuverlässig erbringen können?

Für jeden kritischen Dienst brauchen Sie im Grunde nur eine nachvollziehbare Kette:

1. erwarteter Bedarf,
2. zugesagte oder intern benötigte Leistung,
3. aktuelle Kapazität und messbare Entwicklung,
4. notwendige Reserve,
5. bekannte Grenzen und Vorlaufzeiten,
6. ein Auslöser, ab dem gehandelt wird,
7. eine vorbereitete Maßnahme mit Verantwortlichem und Termin.

Anhang A.8.6 der ISO 27001 verlangt, die Nutzung von Ressourcen zu überwachen und sie entsprechend den aktuellen und erwarteten Kapazitätsanforderungen anzupassen. Die Norm liefert dafür keine Universalformel. Sie erwartet, dass das Unternehmen sein Geschäft kennt und rechtzeitig handelt.

Beginnen Sie mit dem Dienst, nicht mit der CPU

Ein beliebter Einstieg lautet: „Welche technischen Werte können wir messen?“ Das ist nicht völlig falsch, kommt aber eine Station zu früh.

Beginnen Sie mit einem kritischen Dienst, den Kunden oder Mitarbeiter tatsächlich benötigen. Das kann ein Kundenportal, die Produktionssteuerung, die Lohnabrechnung, ein Ticketsystem oder eine zentrale Schnittstelle sein. Danach klären Sie:

• Wie viele Benutzer, Vorgänge oder Datenmengen verarbeitet der Dienst heute?
• Welche Leistung erwarten Kunden und Fachbereiche?
• Welche Spitzen sind normal?
• Welche außergewöhnlichen Ereignisse sind bereits absehbar?
• Welche Folgen hätte es, wenn die Leistung nicht reicht?

Erst dann übersetzen Sie diese Anforderungen in technische Größen. Für ein Kundenportal können das gleichzeitige Sitzungen, Anfragen pro Sekunde, Antwortzeiten, Datenbankverbindungen und Queue-Längen sein. Bei einer nächtlichen Verarbeitung sind Durchsatz, Laufzeit und das Alter des ältesten unbearbeiteten Auftrags möglicherweise aussagekräftiger als eine durchschnittliche CPU-Auslastung.

Das schützt vor der hübschen Bildschirmtapete: zehn grüne Infrastrukturwerte, während der eigentliche Geschäftsprozess längst im Rückstau steht.

Eine einfache Kapazitätsübersicht reicht für den Anfang

Sie brauchen nicht sofort ein gewaltiges Capacity-Management-System. Für den Einstieg genügt häufig eine Tabelle pro kritischem Dienst. Sie sollte mindestens diese Felder enthalten:

Diese Übersicht zwingt zu einer wichtigen Verbindung: Ein Messwert wird erst dann zum Kapazitätsmanagement, wenn er auf einen Bedarf, eine Entscheidung und eine rechtzeitige Handlung trifft.

Nachfrage ist nicht nur Wachstum

Viele Kapazitätspläne extrapolieren die Vergangenheit: Im letzten Quartal wuchs die Datenmenge um sieben Prozent, also rechnen wir weiter mit sieben Prozent. Das ist nützlich, aber nicht ausreichend.

Der zukünftige Bedarf entsteht auch durch Ereignisse, die kein Trenddiagramm vorhersagen kann:

• ein neuer Großkunde,
• eine Werbekampagne,
• ein Produktstart,
• eine Migration,
• die Zusammenlegung zweier Standorte,
• neue gesetzliche Aufbewahrungspflichten,
• eine neue Schnittstelle mit großen Datenmengen,
• saisonale Spitzen,
• eine Änderung im Geschäftsmodell,
• oder die Abschaltung eines Systems, dessen Last ein anderes übernehmen soll.

Kapazitätsplanung braucht deshalb einen Informationsweg aus Vertrieb, Projektmanagement, Produktentwicklung, Einkauf und Fachbereichen in den Betrieb. Das muss kein monatlicher Ausschuss mit zwölf Personen sein. Es muss aber klar sein, wer geplante Veränderungen meldet und wer ihre Auswirkungen bewertet.

Genau hier berührt das Thema das Änderungsmanagement. Eine wesentliche Änderung ist nicht nur technisch zu testen. Sie kann auch die bisherige Kapazitätsplanung unbrauchbar machen.

Reserve ist keine magische Prozentzahl

„Wir halten immer 20 Prozent frei.“ Klingt vernünftig, ist aber ohne Kontext nur eine Zahl mit Krawatte.

Die passende Reserve hängt davon ab,

• wie stark die Last schwankt,
• wie zuverlässig die Prognose ist,
• wie kritisch der Dienst ist,
• wie schnell zusätzliche Kapazität bereitsteht,
• welche Abhängigkeiten bestehen,
• und wie teuer Unter- oder Überkapazität wird.

Bei elastischen Cloud-Ressourcen kann eine geringere technische Reserve genügen, wenn Skalierung getestet ist, Quoten passen und die Rechnung nicht explodiert. Bei einem physischen Speichersystem mit drei Monaten Beschaffungszeit ist deutlich mehr Vorlauf nötig. Bei einer Internetleitung hilft Ihnen die theoretische Skalierbarkeit des Servers überhaupt nicht.

Auch Redundanz und Kapazität müssen zusammenpassen. Zwei Systeme mit jeweils 60 Prozent Last sehen komfortabel aus. Fällt eines aus, soll das andere plötzlich 120 Prozent tragen. Zweimal vorhanden ist noch lange nicht ausfallsicher.

Vorlaufzeiten entscheiden, wann Sie handeln müssen

Ein Grenzwert von 80 Prozent nützt wenig, wenn niemand berücksichtigt, dass die Gegenmaßnahme zwei Monate dauert. Gute Kapazitätsplanung rechnet rückwärts.

Nehmen wir an, ein Speichersystem wächst um fünf Terabyte pro Monat. In acht Monaten ist die sinnvolle Betriebsgrenze erreicht. Beschaffung, Lieferung, Einbau, Migration und Test benötigen zusammen vier Monate. Dann liegt Ihr Auslöser nicht bei 80 Prozent Belegung, sondern spätestens vier Monate vor der prognostizierten Grenze – plus einer Reserve für Verzögerungen.

Typische Vorlaufzeiten verstecken sich bei:

• Hardwarebeschaffung und Lieferzeiten,
• Freigaben und Budgets,
• Cloud-Quoten und Vertragsänderungen,
• zusätzlichen Lizenzen,
• Leitungsbestellungen,
• Datenbankmigrationen,
• Architekturänderungen,
• Lasttests und Abnahmetests,
• sowie der Verfügbarkeit von Spezialisten.

Wer diese Zeiten nicht erfasst, hat keinen Plan, sondern einen Messwert mit spätem Überraschungseffekt.

Ein Beispiel: Der Großkunde kommt

Zurück zum Kundenportal. Der Vertrieb erwartet 8.000 neue Benutzer. Nicht alle sind gleichzeitig aktiv. Das Produktteam rechnet aber am Monatsende mit 1.200 zusätzlichen parallelen Sitzungen und doppelt so vielen Berichtsläufen wie bisher.

Das Team geht nun nicht direkt einkaufen, sondern arbeitet die Kette ab:

1. Bedarf konkretisieren: Welche Funktionen nutzen die neuen Benutzer? Wann entstehen Spitzen? Welche Antwortzeiten sind zugesagt?
2. Ist-Zustand messen: Der letzte Lasttest zeigt, dass nicht der Webserver, sondern Datenbankverbindungen und Berichtserstellung begrenzen.
3. Entwicklung ergänzen: Auch ohne den Großkunden wächst die Nutzung um acht Prozent im Monat.
4. Ausfallfall mitdenken: Kann ein verbleibender Knoten die notwendige Last tragen, wenn ein anderer ausfällt?
5. Maßnahme auswählen: Datenbank skalieren, Berichtsläufe entzerren und die Zahl paralleler Berichte begrenzen.
6. Vorlauf berücksichtigen: Änderung, Test und Freigabe brauchen sechs Wochen.
7. Erfolg prüfen: Ein Lasttest bildet die erwartete Spitze plus begründete Reserve ab.

Damit entsteht eine belastbare Entscheidung. „Wir werfen vorsichtshalber noch zwei Server drauf“ wäre schneller gesagt, hätte das eigentliche Nadelöhr aber nicht beseitigt.

Welche Maßnahmen es außer „mehr kaufen“ gibt

Kapazität lässt sich erhöhen. Bedarf lässt sich aber auch besser verteilen oder senken. Typische Möglichkeiten sind:

• vertikal oder horizontal skalieren,
• Last verteilen,
• Verarbeitung in Queues entkoppeln,
• Caching einsetzen,
• Abfragen und Code optimieren,
• Batchläufe zeitlich verschieben,
• unwichtige Last begrenzen oder priorisieren,
• alte Daten archivieren oder löschen,
• unnötige Dienste abschalten,
• Cloud-Quoten rechtzeitig erhöhen,
• und Benutzer bei außergewöhnlichen Lasten kontrolliert warten lassen, statt das ganze System umzuwerfen.

Welche technische Lösung passt, behandelt unser Artikel zu den Werkzeugen für Kapazitätsmanagement nach A.8.6. Dort geht es um Infrastruktur-Monitoring, APM, Observability, Lasttests, Autoscaling und weitere Technik. Hier geht es bewusst um den Plan, der diesen Werkzeugen sagt, was überhaupt ausreichend ist.

Kapazitätsplanung, BCM und Architektur gehören zusammen

Kapazitätsplanung fragt nach ausreichender Leistung im normalen und erwartbaren Betrieb. Business Continuity Management fragt zusätzlich, wie kritische Leistungen unter gestörten Bedingungen weitergehen oder wieder anlaufen. Die sichere Systemarchitektur bestimmt, ob Skalierung, Lastverteilung und Ausweichbetrieb technisch überhaupt möglich sind.

Auch Logging und Monitoring liefern wichtige Daten. Sie ersetzen aber nicht die geschäftliche Einordnung. Ein Alarm kann melden, dass eine Queue wächst. Er weiß nicht, ob morgen eine Kampagne startet, welcher Rückstand akzeptabel ist oder wie lange die Beschaffung einer Erweiterung dauert.

Deshalb sollte ein Kapazitätsreview nicht nur Diagramme betrachten. Es sollte auch neue Kunden, Projekte, Änderungen, Ausfallannahmen, Lieferzeiten und bekannte Risiken berücksichtigen.

Wann die Planung überprüft werden sollte

Ein starres Pflichtintervall nennt die ISO 27001 nicht. Legen Sie ein Intervall fest, das zur Dynamik des Dienstes passt, und ergänzen Sie ereignisbezogene Auslöser.

Ein neuer Blick ist insbesondere sinnvoll, wenn:

• ein wichtiger Kunde oder Dienst hinzukommt,
• die Nutzung deutlich schneller wächst als erwartet,
• Architektur oder Infrastruktur geändert werden,
• ein Lieferant seine Leistung oder Grenzen ändert,
• Last- oder Wiederanlauftests überraschende Ergebnisse liefern,
• ein Engpass oder Ausfall auftritt,
• oder sich Wiederanlauf- und Leistungsziele ändern.

Dokumentieren Sie anschließend nicht seitenlang, dass man sich getroffen hat. Halten Sie fest, welche Annahmen geprüft wurden, welche Grenze sich nähert, welche Entscheidung getroffen wurde und wer bis wann handelt.

Typische Fehler

Der erste Fehler ist die reine Rückspiegelplanung. Vergangene Messwerte werden hochgerechnet, aber geplante Kunden, Projekte und Kampagnen erfährt die IT erst, wenn der Termin feststeht.

Der zweite Fehler ist eine Reserve ohne Begründung. Pauschale 20 Prozent können übertrieben, zu knapp oder an der falschen Stelle sein.

Der dritte Fehler ist eine Warnung ohne Handlung. Das Monitoring verschickt seit sechs Monaten täglich dieselbe Meldung. Irgendwann wird sie Teil der Büroeinrichtung.

Der vierte Fehler ist, nur Durchschnittswerte zu betrachten. Kritische Spitzen, lange Warteschlangen und langsame Einzelprozesse verschwinden darin erstaunlich zuverlässig.

Und der fünfte Fehler ist, Kapazität nur im Normalbetrieb zu planen. Wenn ein redundantes System beim Ausfall der Hälfte nicht mehr genügend Leistung hat, war es womöglich redundant beschafft, aber nicht redundant geplant.

Interesse geweckt?

Sie möchten aus Geschäftsbedarf, Messwerten und technischen Grenzen einen belastbaren Kapazitätsplan machen? Sprechen Sie mit uns. Wir helfen Ihnen, ein schlankes Vorgehen aufzubauen, das zu Ihren Diensten und Risiken passt.