9.7 Kapazitätsplanung und Bedarfsprognose

Überblick und Motivation

Jedes System hat eine Decke. Rechenkerne gehen aus, Festplatten füllen sich, Verbindungspools erschöpfen, und eine Warteschlange, die beim Frühstück leer war, läuft beim Mittagessen über. Kapazitätsplanung ist die Disziplin, das Angebot an Rechenleistung, Speicher, und Netzwerk mit dem Bedarf abzugleichen, den Sie erwarten, mit genug Spielraum, dass ein normaler Tag nie nahe an die Decke kommt und ein schlechter Tag anmutig statt katastrophal versagt. Bedarfsprognose ist die andere Hälfte: vorherzusagen, wie viel Last kommt, wann, und warum, damit Angebot vor dem Bedarf ankommt statt nach dem Ausfall.

Dieses Kapitel sitzt zwischen zwei Nachbarn und bleibt zu beiden komplementär. Kapitel 3.5 deckt Skalierbarkeit als architektonische Eigenschaft ab: wie ein System gebaut ist, damit es überhaupt wachsen kann, durch Zustandslosigkeit, Sharding, und horizontale Skalierung. Kapitel 9.1 deckt Site Reliability Engineering (SRE) ab, das die Zuverlässigkeitsziele setzt, die Kapazität verteidigen muss. Hier nehmen Sie die Architektur als gegeben und die Ziele als fest, dann beantworten Sie eine quantitative Frage: wie viel von allem müssen Sie kaufen, reservieren, und in Reserve halten, damit das System seine Service Level Objectives (SLOs, die Zuverlässigkeitsziele aus Kapitel 9.1) durch vorhergesagten Bedarf und die Spitzen erfüllt, die Sie nicht vorhersagten. Autoskalierung und Leistungsengineering (Kapitel 2.16) sind Werkzeuge, die Sie hier nutzen, aber sie sind keine Ersatze für Planung, und sie mit Planung zu verwechseln ist ein häufiger und teurer Fehler.

Für große Teams hört Kapazität auf, eine Tabelle zu sein, die eine Ingenieurin führt, und wird zu einem geteilten Modell, von dem viele Dienste abhängen. Eine Plattform von Hunderten Diensten teilt endliche Pools: Datenbankverbindungen, Nachrichtenbroker-Durchsatz, Cloud-Kontokontingente, Netzwerk-Egress. Das Wachstum eines Teams kann das eines anderen aushungern, wenn niemand das Gesamtbild hält. In Unternehmensumgebungen zeigen sich Kapazitätsfehler entweder als verschwendete Millionen in leerlaufender Infrastruktur oder peinliche Ausfälle genau in den Momenten, die am meisten zählen. In Behörden schärfen sich die Einsätze weiter. Eine Steuerfrist, ein Leistungseinschreibungsfenster, oder eine Registrierungskampagne für öffentliche Gesundheit konzentriert den Bedarf einer Nation in ein paar Stunden, die Last ist gesetzlich vorgeschrieben statt optional, und die Öffentlichkeit erinnert sich an eine Seite, die unter einer Frist einknickte, die sie selbst setzte. Kapazitätsplanung ist, wie Sie diese Versprechen halten.

Kernprinzipien

Planen Sie Kapazität für vorhergesagten Bedarf plus absichtlichen Spielraum; laufen Sie nicht nahe Sättigung.
Trennen Sie Kapazitätsplanung, Autoskalierung, und Leistungsengineering; jede löst ein anderes Problem.
Prognostizieren Sie aus Trend, Saisonalität, bekannten Ereignissen, und Geschäftswachstum, nicht nur aus letzter Woche.
Finden Sie Ihre echten Grenzen durch Lasttests und Benchmarking, nicht durch Raten oder Warten, bis Produktion sie findet.
Behandeln Sie Latenz nahe Sättigung als Klippe, nicht als Hang; Auslastungsziele existieren wegen Warteschlangentheorie.
Kennen Sie Ihre harten Engpässe: Verbindungspools, Kontingente, und Einzelpunkte autoskalieren nicht.
Balancieren Sie Kosten gegen Zuverlässigkeit absichtlich, und überprüfen Sie Kapazität in regelmäßiger Kadenz statt nach einem Vorfall.

Empfehlungen

Kapazitätsplanung, Autoskalierung, und Leistungsengineering trennen

Diese drei Disziplinen werden oft verwechselt, und sie zu verwechseln führt dazu, den falschen Fix zu kaufen. Kapazitätsplanung ist die mittel-bis-langfristige Frage, wie viel Gesamtressource Sie über Wochen, Quartale, und Jahre bereitstellen, reservieren, und budgetieren müssen. Autoskalierung ist die kurzfristige, automatisierte Anpassung von Ressourcen, um Last minutengenau zu verfolgen: sie bewegt Sie innerhalb der Hülle, die Planung bereitstellte, kann aber kein Kontingent herbeizaubern, das Sie nie reservierten, eine kalte Datenbank aufwärmen, oder eine Komponente skalieren, die nur als einzelne Instanz läuft. Leistungsengineering (Kapitel 2.16) ändert die Form des Problems, indem es jede Arbeitseinheit günstiger macht, damit dieselbe Hardware mehr Bedarf bedient.

Die Unterscheidung ist praktisch. Wenn ein System unter Last langsam ist, fügt Autoskalierung Instanzen hinzu, Leistungsengineering macht jede Instanz schneller, und Kapazitätsplanung entscheidet, ob Sie sich die Instanzen leisten können und ob die nachgelagerte Datenbank die Verbindungen akzeptieren kann, die sie öffnen werden. Ein Team, das nur zu Autoskalierung greift, trifft eine harte Grenze, für die es nie plante; ein Team, das nur zu Leistungsengineering greift, optimiert Code, während das Kontokontingent es trotzdem deckelt. Sie brauchen alle drei, und Sie müssen wissen, welche ein gegebenes Problem verlangt.

Bedarf aus Trend, Saisonalität, Ereignissen, und Geschäftswachstum prognostizieren

Eine Prognose, auf dem Durchschnitt letzter Woche gebaut, verpasst jeden interessanten Moment. Bauen Sie Ihre aus vier unterschiedlichen Komponenten. Der Trend ist die zugrunde liegende Richtung: wächst Bedarf, ist er flach, oder schrumpft er, und wie schnell? Saisonalität ist das sich wiederholende Muster: der tägliche Höchststand um 9 Uhr, die wöchentliche Flaute am Wochenende, der jährliche Anstieg vor den Feiertagen. Ereignisgesteuerte Spitzen sind die Einmalkonzentrationen: eine Produkteinführung, eine Marketingkampagne, eine Fernseherwähnung, eine Behördeneinreichungsfrist. Geschäftsgesteuertes Wachstum ist der Bedarf, den Ihre eigene Roadmap erzeugt: ein neuer Markt, eine große Kundinneneinführung, ein Feature, das Anfragen pro Sitzung verdreifacht.

Nutzen Sie für jedes die richtige Technik. Eine Zeitreihe historischer Last, in Trend und Saisonalität zerlegt, gibt Ihnen eine verteidigbare Baseline für stetigen Bedarf. Ereignisse können nicht aus Geschichte extrapoliert werden, weil sie keine Geschichte haben; sie kommen davon, mit dem Geschäft zu sprechen, die Roadmap zu lesen, und Marketing und Produkt zu fragen, was sie gerade einführen. Die schädlichsten Kapazitätsfehlschläge sind fast immer Ereignisse, von denen Engineering nie hörte. Die Heilung ist organisatorisch, nicht statistisch: ein stehender Kanal, wo Produkt, Marketing, und Betrieb kommende Spitzen weit genug im Voraus erklären, um für sie bereitzustellen.

Auslastungsziele setzen und die Warteschlangentheorie-Klippe respektieren

Der Instinkt, Infrastruktur bei 90% Auslastung “heiß” laufen zu lassen, um Geld zu sparen, ist eine Falle, und der Grund ist Warteschlangentheorie, in Kapitel 11.3 tief behandelt. Während sich eine Ressource voller Auslastung nähert, steigt Wartezeit nicht sanft und linear; sie explodiert. Ein Server bei 50% Auslastung hat komfortablen Spielraum; derselbe Server bei 90% kann Latenz sehen, mehrfach schlechter, und bei 95% kann die Warteschlange ganz durchgehen. Latenz nahe Sättigung ist eine Klippe, kein Hang, und Ihre Nutzerinnen fühlen die Klippe als Timeouts, Retries, und Fehler lange bevor die Ressource technisch “voll” ist.

Das ist, warum Kapazitätsplanerinnen Auslastungsziele weit unter 100% setzen, üblicherweise im 50%-bis-70%-Bereich für latenzempfindliche Dienste, höher für durchsatzorientierte Batch-Arbeit, die Warteschlangenbildung toleriert. Das Ziel ist keine Verschwendung; es ist der Preis vorhersagbarer Latenz. Wählen Sie das Ziel aus dem SLO: wenn Ihr Latenzziel streng ist, ist Ihre Auslastungsdecke niedriger, denn die Schwanzlatenz, die Warteschlangenbildung produziert, ist genau, was ein SLO sprengt. Spielraum und Sicherheitsmarge sind dieselbe Idee aus zwei Richtungen. Spielraum ist die Lücke zwischen normaler Last und Kapazität; Sicherheitsmarge ist diese Lücke, ausgedrückt als Versicherung gegen eine hoch laufende Prognose, ein Failover, das Last konzentriert, oder eine Spitze, die Sie nicht kommen sahen.

Echte Grenzen durch Lasttests und Benchmarking finden

Sie können nicht um eine Grenze herum planen, die Sie nicht gemessen haben. Lasttest treibt synthetischen oder wiedergegebenen Verkehr in ein System, um zu beobachten, wie sich Latenz, Durchsatz, und Fehlerrate verhalten, während Last steigt, und wo sie brechen. Benchmarking misst eine Komponente isoliert, um ihre Decke zu etablieren: Anfragen pro Sekunde pro Instanz, Schreibvorgänge pro Sekunde pro Datenbankknoten, Nachrichten pro Sekunde pro Broker-Partition. Gemeinsam sagen sie Ihnen die zwei Zahlen, die Planung braucht: wie viel eine Kapazitätseinheit liefert, und wo das gesamte System umfällt.

Führen Sie mehrere unterschiedliche Tests durch. Ein Lasttest rampt zu erwartetem Höchststand hoch und bestätigt, dass das SLO mit Spielraum hält. Ein Stresstest drückt über den Bruchpunkt hinaus, um zu sehen, wie das System versagt, denn ein System, das anmutig degradiert, ist sehr anders als eines, das kollabiert. Ein Soak-Test hält moderate Last für Stunden oder Tage, um Speicherlecks, Verbindungserschöpfung, und Festplattenfüllprobleme zutage zu fördern, die nur über Zeit erscheinen. Ein Spike-Test knallt Last plötzlich, um zu prüfen, ob Autoskalierung und Puffer sie absorbieren, bevor Nutzerinnen es bemerken. Testen Sie gegen produktionsähnliche Daten und Topologie, denn eine an einem Spielzeugdatensatz gemessene Grenze lügt. Führen Sie diese Tests erneut durch, wenn sich das System ändert, damit Ihre Zahlen das System beschreiben, das Sie haben, statt das, das Sie vor einem Jahr hatten.

Bereitstellungsstrategien absichtlich wählen

Cloud-Anbieterinnen lassen Sie dieselbe Kapazität auf Weisen kaufen, die Preis gegen Flexibilität tauschen, und sie gut zu mischen ist, wo echtes Geld gespart wird. On-Demand-Kapazität ist flexibel und teuer: Sie zahlen vollen Satz für die Fähigkeit, jederzeit zu starten und zu stoppen, was zu unvorhersehbarer und kurzlebiger Last passt. Reservierte Kapazität (Verpflichtungen über ein oder drei Jahre, oder Sparpläne) ist pro Einheit günstiger im Austausch für ein Versprechen, sie weiter zu nutzen, was zu Ihrer stabilen Grundlast passt. Spot-Instanzen verkaufen überschüssige Kapazität mit tiefem Rabatt, können aber mit wenig Vorwarnung zurückgeholt werden, was zu fehlertoleranter, unterbrechbarer Arbeit wie Batch-Verarbeitung und zustandslosen Arbeitern passt.

Das Muster, das funktioniert, ist geschichtet. Decken Sie Ihre stetige Grundlast mit reservierter Kapazität für die niedrigsten Einheitskosten ab, absorbieren Sie tägliche und wöchentliche Variation mit On-Demand-Autoskalierung, und schieben Sie unterbrechbare Batch-Arbeit auf Spot, um den Rabatt zu ernten. Halten Sie einen warmen Pufferpool vorab bereitgestellter Kapazität für Dienste, die die Kaltstartverzögerung des Skalierens von null nicht tolerieren können, damit eine plötzliche Spitze bereite Kapazität trifft statt einer Warteschlange, während neue Instanzen hochfahren. Die richtige Mischung ist eine Portfolioentscheidung, und sie verschiebt sich, während sich Ihre Bedarfsform und die Preisgestaltung der Anbieterin ändern, überdenken Sie sie also.

Harte Engpässe kartieren, die nicht autoskalieren

Autoskalierung züchtet gefährliches Vertrauen, denn viele Grenzen sitzen nachgelagert von dem, was skaliert, und bewegen sich nicht, wenn es das tut. Datenbank-Verbindungspools sind das klassische Beispiel: skalieren Sie Ihre zustandslose Schicht von 10 auf 100 Instanzen, und jede öffnet Verbindungen zur selben Datenbank, die eine harte Obergrenze bei gleichzeitigen Verbindungen hat und neue abzulehnen beginnt. Cloud-Konten tragen Kontingente auf fast allem: Instanzen pro Region, IP-Adressen, API-Aufrufe pro Sekunde, Funktions-Konkurrenz. Jeder Einzelpunkt der Architektur, eine primäre Datenbank, ein Führungsknoten, ein geteilter Cache, ein lizenziertes Gerät, ist eine Decke, die horizontale Skalierung anderswo nicht anheben kann.

Machen Sie diese explizit. Halten Sie ein geschriebenes Inventar jeder harten Grenze zwischen einer Anfrage und ihrer Antwort: Poolgrößen, Kontingentwerte, Einzelinstanzkomponenten, Drittanbieter-Ratenlimits, Lizenzplatzanzahlen. Für jede, erfassen Sie den aktuellen Wert, aktuelle Nutzung, und die Last, bei der sie bindet. Dieses Inventar ist der Unterschied zwischen einem Kapazitätsplan, der das ganze System beschreibt, und einem, der nur die leichten, elastischen Teile beschreibt, während ein Verbindungspool still wartet, Ihre Einführung zu beenden. Erhöhen Sie Kontingente im Voraus, denn Kontingenterhöhungen der Anbieterin können Tage brauchen, genehmigt zu werden.

Für Spitzenereignisse bereitstellen, nicht nur den Durchschnitt

Durchschnitte verstecken die Momente, die zählen. Ein für mittlere Last dimensioniertes System versagt am Höchststand, und für viele Organisationen ist der Höchststand der ganze Punkt: der Einzelhandelsanstieg am größten Einkaufstag, die Streaming-Spitze bei einem Live-Finale, das Steuerportal an der Einreichungsfrist, die Leistungsseite, wenn Einschreibung öffnet. Planen Sie diese benannten Ereignisse individuell. Schätzen Sie den Höchststand aus dem Geschäft (erwartete gleichzeitige Nutzerinnen, Anfragen pro Sitzung, das Vielfache über einen normalen Tag), stellen Sie auf diesen Höchststand mit Spielraum bereit, lasttesten Sie auf diesem Niveau, und richten Sie die Kapazität vor dem Ereignis auf, statt während dessen zu hasten.

Behandeln Sie eine Einführung oder Frist als operatives Ereignis mit einem Runbook. Wärmen Sie Caches und Pufferpools vor, erhöhen Sie Kontingente im Voraus, frieren Sie riskante Bereitstellungen während des Fensters ein, und setzen Sie Menschen in Bereitschaft, die handeln können, falls sich die Prognose als niedrig erweist. Nach dem Ereignis, erfassen Sie den tatsächlichen Höchststand und wie nahe Sie Ihren Grenzen kamen, denn diese Zahl ist die beste Eingabe für den Plan des nächsten Jahres. Behördenfristen verdienen besondere Sorgfalt: sie sind selbst auferlegt, öffentlich bekannt, und unbeweglich, es gibt also keine Entschuldigung, überrascht zu sein, und keinen Weg, es zu verstecken, wenn Sie es sind.

Kapazität instrumentieren und in Kadenz überprüfen

Kapazitätsplanung läuft auf Daten, und die Daten kommen aus der Beobachtbarkeit von Kapitel 9.2. Verfolgen Sie Auslastung jeder eingeschränkten Ressource (CPU, Speicher, Festplatte, Netzwerk, Verbindungspools, Warteschlangentiefe) gegen ihre Grenze, damit Sie schrumpfenden Spielraum sehen können, bevor er verschwindet. Beobachten Sie Sättigungssignale direkt: Warteschlangenlängen, Wartezeiten, und Ablehnungsraten enthüllen die nahende Warteschlangenklippe. Trenden Sie diese über Wochen, um zu projizieren, wann eine Ressource ihre Decke bei aktueller Wachstumsrate erreicht, und alarmieren Sie auf die Projektion statt nur den aktuellen Wert, damit Sie vor der Wand bereitstellen statt an ihr.

Halten Sie Kapazitätsüberprüfungen in regelmäßiger Kadenz, monatlich oder vierteljährlich, statt nur nach einem Vorfall. In jeder Überprüfung, vergleichen Sie Prognose mit tatsächlichem Bedarf und korrigieren Sie das Modell, gehen Sie das Hartgrenzeninventar durch und prüfen Sie Spielraum gegen jede, schauen Sie auf kommende Ereignisse und Geschäftspläne, und entscheiden Sie, was zu reservieren, erhöhen, oder pensionieren ist. Halten Sie ein lebendes Kapazitätsmodell: ein einfaches Dokument oder eine Tabelle, die Bedarfstreiber auf Ressourcenbedarf abbildet, damit jeder fragen kann “was passiert mit der Datenbank, wenn sich der Verkehr verdoppelt” und eine Antwort vom Modell statt einem Ausfall bekommt. Das Modell ist nie perfekt, aber ein geschriebenes, regelmäßig korrigiertes Modell schlägt Intuition jedes Mal.

Abwägungen: Vor- und Nachteile

Ansatz	Vorteile	Nachteile
Hohes Auslastungsziel	Niedrigere Kosten pro Einheit; weniger Leerlaufkapazität	Latenz explodiert nahe Sättigung; kein Raum für Spitzen oder Failover
Großzügiger Spielraum	Vorhersagbare Latenz; absorbiert Spitzen und Failover	Höhere stetige Kosten; kann Ineffizienz verstecken
Reservierte Kapazität	Niedrigster Einheitspreis für stabile Grundlast	Verpflichtungsrisiko, falls Bedarf fällt oder sich verschiebt
On-Demand-Kapazität	Flexibel; passt variabler Last minutengenau an	Höchster Einheitspreis; kann das Budget überraschen
Spot-Instanzen	Tiefer Rabatt für unterbrechbare Arbeit	Ohne Vorwarnung zurückgeholt; ungeeignet für zustandsbehaftete oder latenzkritische Arbeit
Autoskalierung	Verfolgt Last automatisch innerhalb der Hülle	Kann reserviertes Kontingent nicht überschreiten; Kaltstarts; verdeckt nachgelagerte Grenzen
Pufferpool (warme Kapazität)	Absorbiert plötzliche Spitzen sofort	Bezahlt für Leerlaufkapazität zwischen Spitzen

Die zentrale Spannung ist Kosten gegen Zuverlässigkeit, und es gibt keine Einstellung, die beide optimiert. Fahren Sie schlank und Sie sparen Geld, bis der Tag, an dem eine Spitze eine gesättigte Ressource trifft und Latenz von der Warteschlangenklippe fällt. Fahren Sie großzügig und Sie schlafen gut, während Sie für Spielraum bezahlen, der die meiste Zeit leerläuft. Lösen Sie die Spannung mit dem SLO statt mit Angst oder Sparsamkeit. Stellen Sie genug Spielraum bereit, um das Zuverlässigkeitsziel durch vorhergesagte Höchststände plus eine Marge zu erfüllen, und nicht mehr, dann lassen Sie FinOps (Finanzoperationen für Cloud-Ausgaben, Kapitel 9.4) die Verschwendung jagen, die kein SLO verteidigt. Das Ziel ist absichtliche Balance: jeder Dollar Spielraum, absichtlich gekauft, um eine bekannte Menge Zuverlässigkeit zu kaufen, und jeder Dollar Verschwendung, absichtlich entfernt, weil er keine kauft.

Fragen zur Diskussion mit Ihrem Team

Wissen wir tatsächlich die Last, bei der jeder unserer harten Engpässe bindet, oder nehmen wir an, dass Autoskalierung uns retten wird? Die meisten Teams können Ihnen sagen, dass ihre Instanzen autoskalieren, und die meisten können Ihnen nicht das Gleichzeitige-Verbindungen-Limit ihrer primären Datenbank sagen, das API-Ratenlimit ihrer wichtigsten Drittanbieterin, oder das Kontokontingent, das ihre Funktions-Konkurrenz deckelt. Das sind die Grenzen, die Einführungen beenden, und sie bewegen sich nicht, wenn die zustandslose Schicht skaliert. Bringen Sie das geschriebene Inventar harter Grenzen, falls Sie eines haben, und falls nicht, ist diese Abwesenheit die Erkenntnis. Für jede Grenze wollen Sie drei Zahlen: die Decke, heutige Nutzung, und das Bedarfsniveau, bei dem sie sich treffen. Wo auch immer Sie nicht alle drei produzieren können, haben Sie einen Engpass, den Sie per Hoffnung verwalten.
Wann haben wir zuletzt auf das Niveau unseres schlimmsten kommenden Höchststands lasttest, auf produktionsähnlichen Daten, und hielt das SLO mit Spielraum? Ein Kapazitätsplan ist ein Satz Behauptungen darüber, wie sich das System unter Last verhält, und eine ungetestete Behauptung ist eine Vermutung im Anzug. Der zählende Höchststand ist nicht der Durchschnitt letzten Monats, sondern die nächste Einführung, der Feiertag, oder die Frist, und der Test bedeutet nur etwas, wenn Daten und Topologie Produktion ähneln, denn eine an einem Spielzeugdatensatz gemessene Grenze lügt. Bringen Sie die Ergebnisse Ihrer jüngsten Stress- und Soak-Tests, einschließlich wo das System brach und wie es versagte, als es das tat. Wenn die ehrliche Antwort ist, dass Sie das System nie absichtlich zu seinem Bruchpunkt trieben, dann werden Sie diesen Punkt in Produktion entdecken, zur schlechtestmöglichen Zeit, mit zusehenden Nutzerinnen.
Wie sagen Produkt, Marketing, und Betrieb Engineering von einer Spitze, bevor sie passiert, und wie weit im Voraus? Die teuersten Kapazitätsfehlschläge sind keine Modellierungsfehler; sie sind Ereignisse, von denen Engineering nie hörte, bis der Verkehr ankam. Eine Prognose kann Trend und Saisonalität aus Geschichte extrapolieren, aber ein Ereignis hat keine Geschichte, es kann also nur von den Menschen kommen, die es planen. Bringen Sie die letzten drei Bedarfsspitzen und fragen Sie für jede, wie viele Tage Vorwarnung Engineering bekam und ob das genug war, um Kapazität zu reservieren und lasttest. Der Beleg, den Sie wollen, ist ein stehender Kanal mit einer Vorlaufzeit lang genug, um dagegen bereitzustellen, denn Cloud-Kontingenterhöhungen allein können Tage brauchen. Wenn der Kanal nicht existiert, ist Ihr Kapazitätsplan blind für genau die Momente, für die er existiert, zu schützen.
Welches Auslastungsziel läuft jeder latenzempfindliche Dienst tatsächlich, und können wir diese Zahl zu seinem SLO statt einem Kostenziel zurückverfolgen? Das zählt, weil der Druck, Infrastruktur heiß zu fahren, konstant ist und von dem Teil der Organisation kommt, der die Rechnung sieht, aber nicht die Warteschlangenklippe, sofern das Ziel also nicht aufgeschrieben und aus dem Latenzziel gerechtfertigt ist, driftet es nach oben, bis eine Spitze die Kante findet. Die konkurrierenden Überlegungen sind echtes Geld auf einer Seite und Schwanzlatenz auf der anderen, und die ehrliche Position ist, dass Spielraum unter 100% der Preis vorhersagbarer Latenz ist, keine zu trimmende Verschwendung. Bringen Sie die aktuelle Auslastung Ihrer obersten paar Dienste, das SLO, das jeder verteidigt, und die Latenz, die Sie bei dieser Auslastung unter Last maßen, damit die Diskussion aus Beleg statt Instinkt argumentiert. In einer Unternehmens- oder Behördenplattform, wo ein geteilter Pool viele Dienste unterstützt, einigen Sie sich zentral auf das Ziel und erfassen Sie, wer es ändern darf, denn ein einzelnes Team, das still seine Decke erhöht, kann eine Ressource, von der andere abhängen, für alle über die Klippe drücken.
Was ist unsere Mischung aus reservierter, On-Demand-, und Spot-Kapazität, wann haben wir sie zuletzt überdacht, und passt sie noch zur Form unseres Bedarfs? Die Mischung ist, wo sich die größten anhaltenden Einsparungen und die größte anhaltende Verschwendung beide verstecken, denn eine zu On-Demand-Sätzen bezahlte stabile Grundlast verbrennt jede Stunde Geld, während eine überverpflichtete reservierte Position für Kapazität bezahlt, die Bedarf seither überwachsen hat oder unterschritten hat. Die Spannung ist Kosten gegen Flexibilität und Verpflichtungsrisiko: reservierte Kapazität ist pro Einheit am günstigsten, bindet Sie aber, Spot ist noch günstiger, kann aber ohne Vorwarnung zurückgeholt werden, und On-Demand kauft Freiheit zu einem Aufpreis. Bringen Sie die aktuelle Aufteilung nach Kosten, die Bedarfskurve, die sie abdecken soll, und die Rückholrate und den Explosionsradius jeglicher Spot-Arbeitslasten, damit der Raum sehen kann, ob unterbrechbare Arbeit wirklich unterbrechbar ist. In Unternehmens- und Behördenumgebungen, binden Sie die reservierten Verpflichtungen an den Beschaffungs- und Budgetzyklus, denn mehrjährige Verpflichtungen und Sparpläne sind finanzielle Verbindlichkeiten, die Finanzen und Prüfung gegen vorhergesagten Bedarf gerechtfertigt sehen wollen, nicht gegen die Bequemlichkeit des letzten Quartals.
Wenn ein benanntes Spitzenereignis kommt, wer besitzt Vorwärmen, Kontingenterhöhungen, Bereitstellungseinfrieren, und den Go-No-Go-Ruf, und ist das als ein Runbook aufgeschrieben, das wir geübt haben? Spitzenereignisse sind die Momente, die Kapazitätsplanung zu schützen existiert, und sie scheitern am häufigsten nicht, weil der Plan falsch war, sondern weil niemand rechenschaftspflichtig war, ihn unter Druck am Tag auszuführen. Die hier konkurrierenden Überlegungen sind Geschwindigkeit und Autonomie gegen Koordination: Teams wollen weiter ausliefern, doch eine riskante Bereitstellung während des Anstiegsfensters kann Monate Bereitstellung zunichtemachen, jemand muss also die Autorität halten, einzufrieren und die Einführung zu stoppen. Bringen Sie das Runbook für Ihr nächstes großes Ereignis, die Vorlaufzeiten für Kontingenterhöhungen und Pufferpool-Aufwärmung, und die Aufzeichnung, wer jede Rolle letztes Mal hielt und ob die Übergaben hielten. Für eine Behördenfrist, die selbst auferlegt, öffentlich bekannt, und unbeweglich ist, benennen Sie die rechenschaftspflichtige Besitzerin und den Eskalationspfad explizit, denn es gibt keine Option, Last abzuwerfen oder Bürgerinnen zu bitten, später wiederzukommen, und ein Höchststand, den niemand besitzt, ist ein Höchststand, den niemand verteidigen wird, wenn er ankommt.

Branchenperspektive

Startup. Ihre knappste Ressource ist Engineering-Aufmerksamkeit, halten Sie Kapazitätsplanung also günstig und stützen Sie sich auf die Elastizität der Cloud-Anbieterin für tägliche Variation. Das eine, das Sie nicht überspringen können, ist eine geschriebene Liste der harten Grenzen, die nicht autoskalieren: Ihre primäre Datenbankverbindungsdecke, Ihr wichtigstes Drittanbieter-Ratenlimit, und die Kontokontingente, die Sie unter einer plötzlichen Feature- oder Presse-Spitze träfen. Lasttesten Sie auf ein Vielfaches Ihres normalen Höchststands auf produktionsgroßen Daten vor Ihrem ersten echten Anstieg, denn das zerbrechliche Vertrauen, das Autoskalierung Ihnen gibt, ist genau, was bricht, wenn eine Datenbank Verbindungen ablehnt.

Kleinunternehmen. Sie haben keine Kapazitätsspezialistin und ein enges Budget, behandeln Sie das also als Kauf-und-Konfigurations-Problem statt ein Modellierungsprojekt. Bevorzugen Sie verwaltete Dienste, die Skalierung für Sie absorbieren, setzen Sie Ausgabenalarme und einfache Auslastungs-Dashboards, damit eine außer Kontrolle geratene Rechnung oder eine sättigende Ressource früh sichtbar ist, und kennen Sie die wenigen benannten Ereignisse (ein saisonaler Ansturm, eine große Kundin, die live geht), die Ihr Jahr definieren werden. Reservieren Sie Kapazität für Ihre stetige Grundlast, um die Rechnung zu kürzen, und widerstehen Sie, Prognosemaschinerie zu bauen, die Sie nicht pflegen können, wenn sich die Bedarfsform kaum bewegt.

Großunternehmen. Das Problem ist ein geteilter, endlicher Satz Pools hinter Hunderten Diensten, Kapazität wird also Portfolio-Governance: ein gepflegtes Hartgrenzeninventar, zentral aus SLOs abgeleitete Auslastungsziele, und eine absichtliche Mischung aus reservierter, On-Demand-, und Spot-Kapazität, gegen Live-Preisgestaltung überdacht. Standardisieren Sie die Last-, Stress-, Soak-, und Spike-Tests, damit jedes Team auf dieselbe Weise auf produktionsähnlichen Daten misst, und führen Sie Kapazitätsüberprüfungen in einer Kadenz durch, die schrumpfenden Spielraum fängt, bevor ein Vorfall es tut. Budgetieren Sie die Koordination explizit, denn das Wachstum eines Teams kann das eines anderen aushungern, wenn niemand das ganze Modell hält.

Behörde. Bedarf ist oft gesetzlich in eine unbewegliche, öffentlich bekannte Frist konzentriert, planen Sie also speziell für diesen benannten Höchststand und stellen Sie eine breite Sicherheitsmarge bereit, denn Sie können keine Last abwerfen oder Bürgerinnen bitten, später wiederzukommen. Beschaffungsregeln formen Bereitstellung: mehrjährige reservierte Verpflichtungen und Anbieterinnenkontingentvereinbarungen müssen gegen vorhergesagten Bedarf gerechtfertigt werden und Prüfung überleben, halten Sie die Prognose, den Lasttest-Beleg, und das Hartgrenzeninventar also dokumentiert und verteidigbar. Veröffentlichen Sie realistische Erwartungen, wo Sie können, erhöhen Sie Anbieterinnenlimits weit vor dem Fenster, und erfassen Sie den echten Höchststand jedes Zyklus, denn öffentliche Rechenschaftspflicht bedeutet, dass ein Portal, das unter einer Frist einknickt, die es selbst setzte, ein Fehlschlag ist, den das ganze Land sieht.

Beispiele

Startup. Ein zehnköpfiges Startup betreibt eine Verbraucherapp auf autoskalierender Cloud-Infrastruktur und fühlt sich sicher, weil die Instanzanzahl mit Last wächst. Ihr erstes Fernsehfeature verdreifacht Verkehr binnen einer Stunde, die zustandslose Schicht skaliert wunderschön, und die App fällt trotzdem um: jede neue Instanz öffnete Datenbankverbindungen, bis die Datenbank ihre Verbindungsdecke traf und begann, sie abzulehnen. Die Lektion formt ihre Praxis neu. Sie fügen einen Verbindungspooler vor der Datenbank hinzu, schreiben jede harte Grenze zwischen einer Anfrage und einer Antwort auf, und lasttesten auf ein Vielfaches ihres normalen Höchststands auf einem produktionsgroßen Datensatz. Sie decken ihre stetige Grundlast mit einer reservierten-Kapazität-Verpflichtung für den Rabatt ab und halten einen kleinen warmen Pufferpool, damit die nächste Spitze bereite Kapazität trifft. Die Änderungen kosten eine Woche und verwandeln ihr zerbrechliches Vertrauen in einen Plan, den sie verteidigen können.

Großunternehmen. Ein globaler Einzelhändler behandelt seinen größten Verkaufstag als das Kapazitätsereignis des Jahres. Monate im Voraus baut ein funktionsübergreifendes Team eine Bedarfsprognose aus Trend und Saisonalität vergangener Jahre plus dem Merchandising-Plan, übersetzt die Prognose in Ressourcenbedarf durch ein Kapazitätsmodell, und stellt auf den prognostizierten Höchststand mit großzügigem Spielraum bereit. Sie lasttesten, stresstesten, soak-testen, und spike-testen den vollen Pfad auf produktionsähnlichen Daten, erhöhen jedes relevante Cloud-Kontingent Wochen im Voraus, wärmen Caches und Pufferpools vor, und frieren riskante Bereitstellungen für das umgebende Fenster ein. Reservierte Kapazität deckt die stabile Grundlast für Kosten ab, On-Demand-Autoskalierung absorbiert die tägliche Kurve, und unterbrechbare Batch-Arbeit läuft auf Spot. Beobachtbarkeit verfolgt jede eingeschränkte Ressource gegen ihre Grenze in Echtzeit während des Ereignisses, mit Alarmen auf projizierte Sättigung statt aktuellem Wert. Der Tag vergeht ohne Drama, was genau das Ergebnis ist, das die Planung kaufte.

Behörde. Eine nationale Steuerbehörde betreibt ein Einreichungsportal, dessen Bedarf gesetzlich in die Tage vor einer unbeweglichen Frist konzentriert ist, wenn ein ganzes Land gleichzeitig einreicht. Die Behörde plant speziell für diesen Höchststand statt für einen Jahresdurchschnitt, der bedeutungslos wäre. Sie schätzt gleichzeitige Einreicherinnen aus vergangenen Jahren und Bevölkerungsdaten, stellt auf diesen Höchststand mit breiter Sicherheitsmarge bereit, denn es gibt keine Option, Last abzuwerfen oder Bürgerinnen zu bitten, später wiederzukommen, und lasttestet auf die projizierte Konkurrenz auf realistischen Daten. Das Team hält ein geschriebenes Inventar jedes Kontingents und Einzelfehlerpunkts, erhöht Limits mit Anbieterinnen weit vor dem Fenster, und setzt Auslastungsziele niedrig genug, dass die Warteschlangenklippe weit vom Fristanstieg entfernt bleibt. Nach jeder Einreichungssaison erfassen sie den echten Höchststand und wie viel Spielraum übrig blieb, das Modell des nächsten Jahres speisend. Die Öffentlichkeit sieht ein Portal, das an dem Tag oben bleibt, für den es entworfen wurde, was der ganze Punkt des Versprechens der Institution ist.

Geschäftsnutzen: Motivation, ROI und Gesamtbetriebskosten

Die Rendite auf Kapazitätsplanung erscheint als zwei vermiedene Kosten, die in entgegengesetzte Richtungen ziehen, was die Disziplin wertvoll macht. Unterbereitstellung kostet Ausfälle, und Ausfälle während Spitzenereignissen kosten am meisten: verlorener Umsatz, verlorene Transaktionen, und Reputationsschaden genau, wenn das Publikum am größten ist. Eine Einzelhandelsseite, an ihrem größten Tag unten, oder ein Behördenportal, das an seiner Einreichungsfrist kollabiert, bezahlt für Jahre Planung in einer einzigen schlechten Stunde. Überbereitstellung kostet den umgekehrten Weg, in Cloud-Rechnungen für Kapazität, die leerläuft, und im Unternehmensmaßstab läuft ein paar Punkte chronischer Überbereitstellung über eine Flotte zu Millionen Dollar jährlich auf. Kapazitätsplanung ist die Praxis, die die absichtliche Mitte findet: genug, um das SLO durch Höchststände zu verteidigen, nicht mehr als das.

Die Übernahmekosten sind meist Disziplin statt Werkzeug. Sie bauen eine Bedarfsprognose, schreiben Ihre harten Grenzen auf, führen Lasttests in einer Kadenz durch, mischen Ihre Bereitstellungsstrategien, und halten regelmäßige Kapazitätsüberprüfungen. Die Gesamtbetriebskosten (TCO) verbessern sich von beiden Seiten gleichzeitig: weniger kapazitätsgetriebene Vorfälle senken die Kosten von Ausfallzeit und Notfallreaktion, und kontinuierliches Rightsizing plus eine vernünftige reserviert-und-Spot-Mischung senken die stetige Infrastrukturrechnung. Um den Fall gegenüber Führung zu machen, verbinden Sie Kapazität mit den Zahlen, die sie bereits beobachten. Binden Sie Unterbereitstellung an verlorenen Umsatz pro Stunde Höchststand-Ausfallzeit und an SLO-Verletzungen mit vertraglichen Strafen, und binden Sie Überbereitstellung an den FinOps-Verschwendungsbericht aus Kapitel 9.4. Das Argument ist keine abstrakte Umsicht; es ist Geld auf beiden Seiten eines Wählers, den Sie absichtlich einstellen können.

Anti-Muster und Fallstricke

Autoskalierung als Plan: elastischen Instanzen vertrauen, während ein Datenbankverbindungspool, Kontokontingent, oder Einzelpunkt still das ganze System deckelt.
Heiß fahren, um Geld zu sparen: 90%-plus Auslastung anvisieren und die Warteschlangenklippe treffen, wo Latenz explodiert und das SLO bricht.
Durchschnitte statt Höchststände: für mittlere Last dimensionieren, sodass das System genau am Spitzenereignis versagt, das seinen Bau rechtfertigte.
Nur aus Geschichte prognostizieren: Trend und Saisonalität extrapolieren, während die Einführung oder Kampagne verpasst wird, von der Engineering nie erzählt wurde.
Ungetestete Grenzen: um einen Bruchpunkt herum planen, den niemand gemessen hat, ihn dann in Produktion zur schlechtesten Zeit entdecken.
Spielzeugdaten-Lasttests: Kapazität auf unrealistischen Daten und Topologie messen, Zahlen produzierend, die über das echte System lügen.
Kein Hartgrenzeninventar: Kontingente, Pools, und Einzelpunkte per Erinnerung und Hoffnung statt einer geschriebenen, gepflegten Liste verwalten.
Alles-reservieren oder Nichts-reservieren: zu reservierter Kapazität überverpflichten, die Bedarf überwächst oder unterschreitet, oder volle On-Demand-Sätze für eine stabile Grundlast bezahlen.
Kapazitätsüberprüfung nur nach Vorfällen: Planung als reaktive Feuerbekämpfung statt einer regelmäßigen Kadenz behandeln, die vor Bedarf bereitstellt.

Reifegradmodell

Stufe 1, Beginnen: Kapazität ist reaktiv und Ad-hoc. Teams fügen Ressourcen hinzu, nachdem sie ausgehen, vertrauen darauf, dass Autoskalierung alles handhabt, und haben keine Prognose, kein Hartgrenzeninventar, und keine Lasttests. Spitzenereignisse werden mit Hoffnung getroffen, und Ausfälle während Einführungen und Fristen werden als Pech behandelt.
Stufe 2, Entwickeln: Grundlegende Praktiken erscheinen, variieren aber nach Team. Manche Überwachung zeigt Auslastung, manches Lasttesten geschieht vor großen Ereignissen, wichtige Kontingente sind bekannt, und eine grobe Prognose existiert stellenweise, aber das Modell wird nicht gepflegt, nachgelagerte Engpässe werden oft verpasst, und Spielraum wird nach Faustregel statt aus dem SLO gesetzt.
Stufe 3, Standardisieren: Kapazitätsplanung ist eine dokumentierte Disziplin, organisationsweit durchgesetzt. Eine Bedarfsprognose kombiniert Trend, Saisonalität, Ereignisse, und Geschäftswachstum; ein geschriebenes Hartgrenzeninventar wird gepflegt; Auslastungsziele leiten sich aus SLOs ab; Last-, Stress-, Soak-, und Spike-Tests laufen in einer Kadenz gegen produktionsähnliche Daten; und Bereitstellung mischt reserviert, On-Demand, und Spot absichtlich. Ein stehender Kanal trägt Ereigniswarnungen von Produkt und Marketing zu Engineering.
Stufe 4, Steuern: Kapazität wird gegen Baselines gemessen und gesteuert. Prognose wird jeden Zyklus mit tatsächlichem Bedarf verglichen und der Fehler wird verfolgt und heruntergetrieben; Auslastung, Sättigungssignale, und Spielraum gegen jede harte Grenze werden getrendet und als Projektionen statt aktuelle Werte alarmiert; Spitzenereignisse werden hinterher gegen den echten beobachteten Höchststand überprüft; und Bereitstellungsmischung, reservierte-Verpflichtung-Abdeckung, und Kosten-pro-SLO werden als Kennzahlen berichtet, die Go-oder-No-Go-Entscheidungen toren. Daten, nicht Intuition, entscheiden, was zu reservieren, erhöhen, oder pensionieren ist.
Stufe 5, Orchestrieren: Kapazitätsplanung wird kontinuierlich verbessert und über die Organisation integriert. Prognosen werden automatisch validiert und verfeinert, Sättigung wird projiziert und dagegen bereitgestellt, bevor sie ankommt, Bereitstellungsmischungen werden gegen Live-Preisgestaltung optimiert, Spitzenereignisse laufen von geübten Runbooks, und Kosten und Zuverlässigkeit werden absichtlich gegen das SLO über die ganze Plattform balanciert. Das Kapazitätsmodell ist ein geteilter, adaptiver Aktivposten, der die Flotte neu balanciert, während sich Bedarfsform und Anbieterinnenpreisgestaltung verschieben.

Diskussionsideen

Was ist Ihr aktuelles Auslastungsziel für latenzempfindliche Dienste, und können Sie es aus Ihrem SLO und dem Warteschlangenverhalten statt aus einem Wunsch, Geld zu sparen, rechtfertigen?
Welche Ihrer Komponenten können überhaupt nicht autoskalieren, und was passiert mit dem Rest des Systems, wenn eine von ihnen sättigt?
Wenn sich Ihr Verkehr nächstes Quartal verdoppelte, welche Ressource trifft zuerst ihre Decke, und wie viele Tage Vorlaufzeit würden Sie brauchen, sie zu erhöhen?
Wie entscheiden Sie die Mischung aus reservierter, On-Demand-, und Spot-Kapazität, und wann haben Sie sie zuletzt gegen Ihre tatsächliche Bedarfsform überdacht?
Wenn ein Spitzenereignis kommt, wer besitzt Vorwärmen, Kontingenterhöhungen, und die Go-No-Go-Entscheidung, und ist das als Runbook aufgeschrieben?
Feuern Ihre Kapazitätsalarme auf projizierte Sättigung Wochen im Voraus, oder nur auf aktuelle Auslastung, sobald die Wand bereits nah ist?

Wichtigste Erkenntnisse

Kapazitätsplanung gleicht Angebot mit vorhergesagtem Bedarf mit absichtlichem Spielraum ab; sie unterscheidet sich von Autoskalierung (kurzfristig, innerhalb der Hülle) und Leistungsengineering (günstigere Arbeitseinheiten).
Prognostizieren Sie aus Trend, Saisonalität, bekannten Ereignissen, und Geschäftswachstum, und holen Sie Ereigniswarnungen von Produkt und Marketing, denn Ereignisse haben keine Geschichte zu extrapolieren.
Respektieren Sie die Warteschlangentheorie-Klippe (Kapitel 11.3): Latenz explodiert nahe Sättigung, setzen Sie Auslastungsziele also aus Ihrem SLO und halten Sie echten Spielraum.
Finden Sie Grenzen durch Last-, Stress-, Soak-, und Spike-Testen auf produktionsähnlichen Daten, und halten Sie ein geschriebenes Inventar harter Engpässe, die nicht autoskalieren.
Mischen Sie reservierte, On-Demand-, und Spot-Kapazität mit warmen Pufferpools, planen Sie benannte Spitzenereignisse individuell, und überprüfen Sie Kapazität in einer Kadenz statt nach Ausfällen.

Referenzen und weiterführende Literatur

Betsy Beyer, Chris Jones, Jennifer Petoff, und Niall Richard Murphy (Hrsg.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, und Stephen Thorne (Hrsg.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott und Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment und Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management