---
title: "Skalierbarkeit im RFP mit belastbaren Grenzen beantworten"
description: "Bilden Sie Last, Datenzustand und Nutzerabläufe nach, dann belegen Sie Betriebszone und Ausbaupfad ohne schützenswerte Systemdetails."
canonical: "https://zephior.com/de/insights/answer-an-rfp-scalability-question"
last-updated: 2026-09-05
---

# Skalierbarkeit im RFP mit belastbaren Grenzen beantworten

> Bilden Sie Last, Datenzustand und Nutzerabläufe nach, dann belegen Sie Betriebszone und Ausbaupfad ohne schützenswerte Systemdetails.

Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Veröffentlicht 2026-09-05; aktualisiert 2026-09-05. 15 Min. Lesezeit.

## Definition

Eine Skalierungsnachweisakte verbindet eine konkrete Vergabeanforderung mit einem überprüfbaren Last- und Kapazitätsergebnis. Sie hält Nutzerabläufe, Lasttreiber, Datenprofil, zeitlichen Verlauf, Systemgrenze, getestete Fassung, Vergleichbarkeit der Umgebung, Abnahmekriterien, Messwerte, Engpass, sichere Betriebszone, Überlastverhalten, Skalierungsschritt, Wirksamkeitszeit, Monitoring, Ausbauauslöser, Zuständigkeit und Freigabe fest. Beobachtete, berechnete, prognostizierte, geplante und noch ungeklärte Aussagen bleiben getrennt. Die Akte liefert dem Angebot eine sachliche Grundlage, ohne interne Adressen, Schutzschwellen oder eine angreifbare technische Topologie zu veröffentlichen.

## Problem

Der fiktive Landkreis Birkenhain beschafft ein digitales Bauantragsportal. In der Leistungsbeschreibung stehen 24.000 gleichzeitige Sitzungen, 180.000 Dokumentseiten pro Tag und kurzfristige Lastspitzen vor gesetzlichen Stichtagen. Ein Entwurf antwortet, die Lösung sei mandantenfähig, horizontal skalierbar und für beliebige Nutzerzahlen ausgelegt. Der beigefügte Test hat jedoch nur kleine PDF-Dateien hochgeladen, keine Planprüfung ausgelöst und nach zwölf Minuten geendet. Die Datenbank war fast leer. Angezeigt werden der Mittelwert der Antwortzeit und die erzeugten HTTP-Anfragen, nicht erfolgreich abgeschlossene Anträge. Niemand hat geprüft, wann weitere Kapazität tatsächlich nutzbar wird oder was bei Überlast mit bereits angenommenen Unterlagen geschieht.

## Perspektive

Eine Skalierbarkeitsaussage beginnt mit dem Fachvorgang des Auftraggebers. Zerlegen Sie Sitzungen, Uploads und Tagesmengen in Ankunftsraten, gleichzeitige Arbeit, Dateigrößen, Prüfungen, Suchzugriffe, Hintergrundaufgaben und externe Dienste. Testen Sie die angebotene Produktfassung mit einem repräsentativen Datenbestand und einem zeitlich passenden Lastprofil. Messen Sie erfolgreiche Vorgänge, Laufzeitverteilung, Fehler, Warteschlangen, Datenrichtigkeit und Ressourcendruck gemeinsam. Die Angebotsaussage nennt anschließend die belegte Betriebszone, ihre Bedingungen, die beobachtete Grenze und einen genehmigten Weg für zusätzliche Nachfrage.

## Lesen Sie Gleichzeitigkeit, Tagesmenge und Stichtag gemeinsam

Beginnen Sie mit der genauen Frage und suchen Sie alle zugehörigen Mengen in Leistungsbeschreibung, Falltypen, Schnittstellenanlage, Betriebszeiten, Migrationsdaten, Wertung, Vertragsentwurf und Bieterinformationen. Birkenhains 24.000 gleichzeitige Sitzungen sagen noch nicht, wie viele Personen gerade einen Antrag lesen, große Pläne hochladen oder eine Signatur auslösen. Die Tagesmenge von 180.000 Seiten kann gleichmäßig eintreffen oder in einem kurzen Stichtagsfenster. Beide Verteilungen benötigen andere Tests.

Schreiben Sie für jeden Fachvorgang einen beobachtbaren Beginn und Abschluss. Ein Bauantrag ist nicht fertig, sobald der Browser eine Upload-Annahme zeigt. Je nach angebotener Funktion können Virenprüfung, Formatkontrolle, Metadatenvalidierung, Speicherung, Indexierung, Kartenzuordnung und Benachrichtigung folgen. Entscheiden Sie, welcher Punkt für den Nutzer und die Vergabeanforderung zählt. Der technische Request ist nur eine Teilstrecke.

Fehlen Ankunftsraten, Dateiverteilung oder Verhaltensanteile, behandeln Sie diese Werte als offene Auftraggeberfakten oder genehmigte Bemessungsannahmen. Bilden Sie mindestens Normalbetrieb, typische Tageswelle, Stichtagsspitze und erwartetes Wachstum. Eine Annahme bekommt Quelle, Bandbreite, zuständige Person und spätesten Prüftermin. Sie darf nicht als gemessener Auftraggeberbedarf in die Antwort rutschen.

**Arbeitsmodell für die Birkenhainer Last**

| Vorgang | Lasttreiber | Repräsentative Prüfung |
| --- | --- | --- |
| Antragsentwurf öffnen | Gleichzeitige Sitzungen, Rollen und Bestandsumfang | Lesen und Berechtigungsprüfung bei gefülltem Datenbestand |
| Planunterlagen hochladen | Dateizahl, Größe, Format, Parallelität und Netzweg | Gemischte Dateien mit vollständiger Nachverarbeitung |
| Antrag prüfen und einreichen | Validierungen, Signatur und gleichzeitige Schreibzugriffe | Fachlicher Abschluss mit nachgelagerter Kontrolle |
| Behördenexport erzeugen | Stapelgröße, Stichtag und Konkurrenz zu Online-Arbeit | Export unter laufender Nutzerlast mit geprüftem Ergebnis |

## Ein fast leeres System liefert keinen Nachweis für das fünfte Betriebsjahr

Halten Sie Produktstand, aktivierte Module, Mandantenkonfiguration, Datenmodell, Suchindex, Speicherkondition und angebundene Dienste fest. Vergleichen Sie die Testumgebung mit dem angebotenen Betrieb nach den Merkmalen, die das Ergebnis verändern können. Dazu gehören Kapazitätsklasse, Region und Netzpfad, aber auch Datenalter, Rechteprüfung, Verschlüsselung, Protokollierung und Hintergrundarbeit. Beschreiben Sie Unterschiede sachlich, ohne einen internen Komponentenplan zu veröffentlichen.

Ein repräsentativer Datenbestand bildet Zahl und Verteilung von Verfahren, Beteiligten, Dokumenten, Versionen, Geodaten und Berechtigungen nach. Verwenden Sie dafür freigegebene synthetische oder ausreichend geschützte Daten. Die Prüfung braucht Eigenschaften und Beziehungen, keine echten Bauakten. Testen Sie übliche, große, unvollständige und zurückgewiesene Dokumente, weil Fehlpfade ebenfalls Ressourcen verbrauchen und Warteschlangen erzeugen.

Prüfen Sie den Lastgenerator unabhängig. Er muss geplante Raten, Verbindungen und Dateiübertragungen liefern können, ohne selbst CPU, Netzwerk oder Socket-Grenzen zu erreichen. Vergleichen Sie clientseitige Laufzeiten, serverseitige Beobachtungen und fachliche Abschlusszahlen. Ein Unterschied kann auf Netz, Zeitmessung oder unvollständige Abschlussdefinition hinweisen. Erst die geklärte Messkette darf in den Nachweis.

**Vergleich von Test und angebotenem Betrieb**

| Dimension | Festgehaltener Stand | Behandlung |
| --- | --- | --- |
| Produkt und Funktionen | Getestete Freigabe mit bezeichneten Fachpfaden | Abweichende Funktionen werden nicht mitbeansprucht |
| Datenvolumen und Beziehungen | Synthetischer Bestand nach dem prognostizierten Betriebsjahr | Verteilung und Erzeugungsrezept bleiben im Testnachweis |
| Externe Dienste | Getestete Identitäts-, Karten- und Signaturwege oder definierte Ersatzmodelle | Nicht echte Abhängigkeiten werden als Einschränkung genannt |
| Betriebsdetails | Prüfbare Umgebungsklasse und Vergleichsmerkmale | Adressen, Zugangsdaten und Schutzschwellen bleiben intern |

## Eine schnelle Annahme ist noch kein gespeicherter Bauantrag

Bestimmen Sie für jeden Vorgang, wann er fachlich vollständig und nachprüfbar ist. Ein Upload zählt erst dann als erfolgreich, wenn die vereinbarte Verarbeitung beendet und das Ergebnis wieder auffindbar ist. Trennen Sie angenommene, verarbeitete, abgelehnte, abgebrochene, wiederholte und doppelte Arbeit. Wiederholungen erhöhen die Verkehrszahl und können bei Überlast zusätzlich Druck erzeugen. Sie erhöhen nicht automatisch den nützlichen Durchsatz.

Erfassen Sie die Laufzeit als Verteilung. Median, p95 und p99 können je nach Auftraggeberziel unterschiedliche Teile des Nutzererlebnisses zeigen. Veröffentlichen Sie keine Perzentile ohne Grundgesamtheit, Fehlerbehandlung und Messpunkt. Wenn gescheiterte Vorgänge aus der Dauerstatistik verschwinden, kann die Kurve trotz schlechterem Dienst schneller wirken. Führen Sie Laufzeit, Erfolgsquote, fachliche Richtigkeit und Fehlerarten deshalb pro Laststufe zusammen.

Warteschlangen benötigen Anzahl und Alter. Ein Bestand von tausend Aufgaben kann stabil erscheinen, während die älteste Aufgabe immer länger wartet. Messen Sie Zufluss, Abfluss, ältestes Element und Zeit bis zur vollständigen Abarbeitung nach der Spitze. Ergänzen Sie knappe Ressourcen in einer freigabefähigen Kategorie wie Rechenarbeit, Arbeitsspeicher, Verbindung, Speicher, Fremdquote oder serialisierte Verarbeitung. So bleibt die Diagnose nützlich, ohne interne Angriffsflächen zu beschreiben.

## Die Lastform entscheidet, welchen Fehler der Test sichtbar macht

Planen Sie mehrere Versuchsarten nach dem Beschaffungsrisiko. Eine Stufenlast zeigt, wie sich Durchsatz und Laufzeit mit wachsendem Bedarf verändern. Ein Sprung prüft die Reaktion auf einen Stichtagsbeginn. Eine längere Belastung kann schleichende Speicher-, Verbindungs- oder Rückstandsprobleme zeigen. Kontrollierte Überlast legt offen, ob das System schützt, priorisiert, abweist oder unkontrolliert ausfällt. Die Erholungsphase prüft, was mit bereits angenommener Arbeit geschieht.

Legen Sie vor dem Start Zielwerte, Beobachtungsdauer, Wiederholungen, Abbruchgrenzen und Sicherheitsverantwortung fest. Ein Lasttest darf weder einen produktiven Dienst noch Fremdsysteme ohne Zustimmung gefährden. Produktionsnahe Umgebungen sind nützlich, wenn ihr Einsatz genehmigt und isoliert ist. Tests in Produktion benötigen eine eigene Risiko-, Datenschutz- und Betriebsfreigabe; eine Ausschreibung schafft diese Befugnis nicht.

Die ISO/IEC/IEEE-29119-Reihe beschreibt allgemeine Testbegriffe und Prozesse, nicht den passenden Lastwert für Birkenhain. ISO/IEC 25010 ordnet Leistungsfähigkeit in ein Produktqualitätsmodell ein, und ISO/IEC 25023 stellt Qualitätsmessungen bereit, ohne allgemeine Bestehenswerte vorzugeben. Verwenden Sie solche Quellen für eine saubere Methode. Die konkrete Akzeptanzschwelle kommt aus der Vergabeanforderung und der genehmigten Angebotsposition.

## Suchen Sie den Knick in der Kurve und prüfen Sie die Zeit danach

Tragen Sie je Stufe angebotene Last, fachliche Abschlüsse, Perzentile, Fehler, Warteschlangenalter und Ressourcendruck auf einer gemeinsamen Zeitachse zusammen. Der erste Warnpunkt kann auftreten, bevor Fehler steigen: zusätzlicher Bedarf bringt kaum mehr erfolgreiche Abschlüsse, das Ende der Laufzeitverteilung wächst oder Hintergrundarbeit sammelt sich. Nennen Sie die beobachtete Ursache nur so genau, wie Messung und Freigabe sie tragen.

Die sichere Angebotszone liegt unter der beobachteten Instabilität. Ihre Reserve berücksichtigt Schwankungen, ungeplante Wartung, veränderte Daten, ungleiche Verteilung, Skalierungsverzug und Fremddienste. Es gibt dafür keinen allgemein richtigen Prozentsatz. Halten Sie Annahmen und zuständige Entscheidung fest. Wenn der Versuch ohne Knick endet, ist sein höchster Punkt eine belegte Untergrenze der Fähigkeit und kein gemessenes Maximum.

Führen Sie den Versuch kontrolliert über die vorgesehene Zone hinaus. Prüfen Sie, ob neue Arbeit geordnet abgewiesen oder angenommen wird, ob wichtige Vorgänge Vorrang erhalten dürfen, ob Daten vollständig bleiben und ob Rückstände nach Lastabfall abgebaut werden. Google SRE empfiehlt, Kapazitätsgrenzen und Überlastverhalten zu testen, weil Wiederholungen und Ressourcenerschöpfung Fehler verstärken können. Der Angebotsnachweis muss dennoch das Verhalten der eigenen angebotenen Lösung belegen.

**Auswertung einer Birkenhainer Lastreihe**

| Phase | Beobachtung | Aussagegrenze |
| --- | --- | --- |
| Normale Tageswelle | Abschlüsse folgen der Ankunft; Laufzeit und Rückstand bleiben stabil | Normalbetrieb unter der getesteten Vorgangsmischung belegt |
| Stichtagsspitze | Zusätzliche Kapazität wird nach gemessener Verzögerung wirksam | Skalierungsreaktion unter diesen Bedingungen beobachtet |
| Überlaststufe | Planprüfung sammelt Rückstand, während Statusabrufe stabil bleiben | Hintergrundverarbeitung ist der erste festgestellte Grenzpfad |
| Entlastung | Angenommene Aufgaben werden ohne Verlust oder Doppelverarbeitung beendet | Erholung für den getesteten Verlauf nachgewiesen |

## Mehr Kapazität hilft erst, wenn sie Fachvorgänge übernimmt

Dokumentieren Sie den vollständigen Skalierungsablauf: Messsignal, Auswertefenster, Entscheidung, Anforderung zusätzlicher Kapazität, Bereitstellung, Bereitschaft, Verkehrs- oder Arbeitsübernahme und messbare Wirkung. Ein gestarteter Prozess ist noch keine wirksame Kapazität, wenn er Daten lädt, Partitionen übernimmt oder keine Aufträge erhält. Erfassen Sie die Zeit bis zur Entlastung. Prüfen Sie auch das Zurückfahren, damit offene Aufgaben nicht unterbrochen werden.

Zusätzliche parallele Verarbeitung kann auf feste Grenzen treffen. Gemeinsame Datenspeicher, geordnete Warteschlangen, Suchindizes, Lizenzkontingente, regionale Quoten und externe Schnittstellen wachsen nicht zwingend im selben Verhältnis. Der Azure Architecture Center beschreibt Skalierbarkeit als Verhältnis zwischen Durchsatzgewinn und Ressourcenzuwachs und weist auf Synchronisationspunkte hin. Das ist ein brauchbarer begrenzter Maßstab, aber keine Zusage linearer Skalierung für jede Anwendung.

Erfassen Sie für Bedarf oberhalb der belegten Zone einen Ausbaupfad. Dazu können eine geänderte Konfiguration, frühere Vorhaltung, eine Quotenanhebung, Datenaufteilung, zusätzliche Region oder Entwicklungsarbeit gehören. Jeder Schritt braucht Auslöser, Vorlauf, Kostenbehandlung, Lieferabhängigkeit, Abnahmetest und Entscheidungseigentümer. Eine geplante Produktänderung bleibt außerhalb der aktuellen Aussage, bis Entwicklung und Test sie belegen.

## Ein Diagramm ohne Versuchsakte ist nicht wiederholbar

Speichern Sie Testplan, Lastmodell, Datenerzeugung, Produktfassung, Umgebungsbeschreibung, Beginn und Ende, Generatorprotokolle, Messreihen, Rechenregeln, Abweichungen und Vorfälle. Halten Sie Wiederholungen und Streuung fest. IETF RFC 8239 gilt für Rechenzentrums-Netzwerkbenchmarks, fordert dort aber ausdrücklich wiederholte Ergebnisse und eine berichtete Methodik. Diese Idee lässt sich als begrenztes Vorbild nutzen; seine netzspezifischen Messgrenzen werden nicht auf ein Bauportal übertragen.

Jede Zahl im Angebot verweist auf einen eingefrorenen Ergebnissatz. Eine prüfende Person muss die Zahl einschließlich der Fehlerpopulation nachvollziehen können. Entfernte Intervalle, Testfehler und manuelle Korrekturen bleiben sichtbar. Wird eine Stufe durch den Lastgenerator verfälscht, wiederholen Sie sie oder begrenzen Sie die Aussage. Der beste Einzelversuch darf nicht ohne vorab festgelegte Auswahlregel die normale Fähigkeit repräsentieren.

Öffnen Sie die Akte nach relevanten Änderungen erneut. Dazu zählen Produktfreigabe, Datenmodell, Datei- oder Fallmix, Umgebungsklasse, Region, Fremddienst, Quote, Skalierungsregel und Beobachtungslücke. Eine neue Auftraggeberzahl oder ein anderer Stichtagsverlauf löst ebenfalls eine Prüfung aus. Ein älterer Test kann weiter passen, wenn diese Beziehung ausdrücklich bestätigt wird. Der gleiche Produktname reicht dafür nicht.

## Nennen Sie belegte Zone, Bedingungen und Ausbauweg

Beantworten Sie zuerst, ob und in welchem Umfang die angebotene Lösung das Mengengerüst trägt. Nennen Sie die Fachvorgänge, Testfassung, Daten- und Umgebungsnähe, Zeitprofil, erfolgreiche Abschlussmessung und belegte Zone. Erklären Sie die Skalierungsreaktion und das Verhalten oberhalb dieser Zone. Wesentliche Annahmen, Fremdgrenzen und spätere Nachweise gehören an die in den Vergabeunterlagen vorgesehene Stelle.

Für Birkenhain kann eine freigegebene Antwort etwa auf den getesteten Mix aus Lesen, Planupload, Validierung und Behördenexport verweisen, die betrachtete Datenpopulation benennen und Durchsatz, ausgewählte Laufzeitperzentile, Fehlergrenze, Skalierungszeit und Erholung berichten. Ein noch nicht direkt geprüfter Teil der 24.000 Sitzungen wird als Kapazitätsmodell mit geplantem Validierungspunkt bezeichnet. Die Formulierung verspricht weder beliebige Last noch einen Ausbau ohne Vorlauf.

Gleichen Sie den Text mit Service Levels, Preis, Betrieb, Support und Sicherheitsfreigabe ab. Der Test belegt Verhalten unter Bedingungen, schafft aber allein keine Vertragszusage. Performance- und Produktverantwortliche bestätigen Methode und Ergebnis. Betrieb genehmigt Reserve und Überlastweg. Informationssicherheit entscheidet über die offengelegte Tiefe. Finanzen und Vertrieb prüfen Kosten. Eine entsprechend bevollmächtigte Person gibt den genauen Angebotssatz frei.

**Freigabe der Skalierbarkeitsaussage**

| Inhalt | Fachliche Zuständigkeit | Freigabebedingung |
| --- | --- | --- |
| Lastmodell und Testergebnis | Performance-Test und Produkt | Quelle, Methode, Fassung, Abweichungen und Rohdaten sind verknüpft |
| Sichere Betriebszone | Betriebsverantwortung | Reserve, Monitoring, Überlast und Erholung sind tragbar |
| Ausbaupfad | Engineering, Lieferanten und Finanzen | Maßnahme, Vorlauf, Preis und Abnahmetest sind genehmigt |
| Wortlaut für den Auftraggeber | Angebotsfreigabe | Der genaue Satz bleibt innerhalb von Evidenz und Vertragsposition |

## Nützliche Ergebnisse

- Jede Mengenangabe des Auftraggebers wird einer fachlichen Operation, einer Zeiteinheit, einem Datenprofil und einer Quelle zugeordnet.
- Gleichzeitige Sitzungen, Ankunftsrate, offene Verbindungen, Anfragen und abgeschlossene Vorgänge werden nicht miteinander verwechselt.
- Der Nachweis bezeichnet Produktfassung, Funktionsumfang, Umgebungsklasse, Datenzustand, Fremdsysteme, Testdauer und Wiederholungen.
- Erfolgreicher Durchsatz zählt nur vollständig abgeschlossene und überprüfte Fachvorgänge.
- Perzentile, Fehlerarten, Warteschlangenalter, Datenintegrität und knappe Ressourcen werden für jede Laststufe zusammen gelesen.
- Die sichere Betriebszone besitzt eine begründete Reserve unterhalb der ersten Instabilität.
- Der Skalierungspfad beschreibt Auslöser, Verzögerung, feste Grenzen, Zustandsübernahme, Fremdabhängigkeiten und Kostenwirkung.
- Überlast, Abweisung, Priorisierung und spätere Abarbeitung werden als Verhalten erklärt und getestet.
- Der freigegebene Text ist prüfbar, vertrags- und preisverträglich und schützt betriebliche Sicherheitsinformationen.

## Ablauf

1. **Anforderung und Angebotsstand festhalten.** Sichern Sie Wortlaut, Mengengerüst, Definitionen, Wertungszweck, Los, Leistungsstand, Vertragsbezug, Antwortstelle und aktuelle Fassungen.
2. **Fachliche Lastobjekte bilden.** Ordnen Sie Sitzungen, Antragsschritte, Uploads, Prüfungen, Suchen, Bescheide, Exporte und Fremdaufrufe nach Häufigkeit und Zeitverlauf.
3. **Daten- und Umgebungsnähe bewerten.** Vergleichen Sie Fassung, Funktionen, Datenvolumen, Berechtigungen, Netzwege, Speicherkondition, Partner und Skalierungsregeln mit dem Angebot.
4. **Erfolg und Abbruch vorab definieren.** Legen Sie Fachabschluss, Laufzeitperzentile, Fehler, Datenprüfung, Warteschlange, Ressourcengrenze und sichere Abbruchbedingungen fest.
5. **Last stufenweise und zeitgerecht ausführen.** Prüfen Sie Normalbetrieb, Stichtagsrampe, Spitzenhaltezeit, kurzen Sprung, längere Belastung, kontrollierte Überlast und Erholung.
6. **Betriebszone und ersten Engpass bestimmen.** Suchen Sie den Punkt, an dem zusätzlicher Bedarf weniger Abschluss, längere Enden der Verteilung oder wachsende Rückstände erzeugt.
7. **Kapazitätsschritt praktisch prüfen.** Messen Sie Auslöser, Bereitstellungs- und Aufwärmzeit, Verkehrsübernahme, Zustandsarbeit, Quoten, Kosten und Rückkehr zum Normalstand.
8. **Aussage begrenzen und freigeben.** Gleichen Sie Ergebnis, Service Level, Preis, Sicherheit und Ausbauplan ab und verwenden Sie nur den genehmigten Wortlaut.

## Wichtige Entscheidungen

- Welche fachliche Leistung muss unter der genannten Last vollständig beendet werden?
- Welcher Zeitraum und welcher Ankunftsverlauf liegen hinter Tagesmenge, Spitzenlast und Wachstum?
- Wie verteilen sich Lesen, Schreiben, Upload, Validierung, Suche, Karte, Benachrichtigung und Stapelverarbeitung?
- Welche Dateigrößen, Dokumentarten, Projektstrukturen, Berechtigungen und Bestandsdaten bestimmen die Arbeit?
- Welche Aufgaben laufen nach einer sichtbaren Bestätigung weiter?
- Welche Identitäts-, Karten-, Signatur-, Scan- oder Zahlungsdienste begrenzen den Gesamtvorgang?
- Entsprechen getestete Fassung, Region, Konfiguration und Umgebung der angebotenen Lösung?
- Was zählt als fachlich erfolgreicher Abschluss und was als Ablehnung, Wiederholung oder Duplikat?
- Welche Perzentile, Fehlerschwellen und Datenprüfungen markieren das Ende der akzeptablen Zone?
- Welches Signal zeigt den ersten Engpass, und wurde die Lastquelle selbst ausgeschlossen?
- Wie verhält sich der Dienst oberhalb der vorgesehenen Last und wie arbeitet er angenommene Vorgänge ab?
- Wer darf technische Evidenz, Ausbaukosten, Vertragsaussage und Offenlegung genehmigen?

## Risiken

- Die Zahl aller Konten wird als Zahl gleichzeitig arbeitender Personen ausgegeben.
- Ein schneller Lesezugriff verdeckt langsame Upload-, Prüf- und Schreibpfade.
- Kleine gleichartige Dateien bilden Planarchive, Bildseiten und fehlerhafte Unterlagen nicht ab.
- HTTP-Antworten werden gezählt, obwohl Hintergrundprüfung oder Speicherung später scheitert.
- Der Mittelwert bleibt niedrig, während ein relevanter Anteil sehr lange wartet.
- Fehlerhafte Vorgänge fehlen in der Laufzeitstatistik und lassen das Ergebnis besser erscheinen.
- Eine kurze Messung endet vor wachsenden Warteschlangen, Speicherproblemen oder verzögerter Indexierung.
- Die Skalierung reagiert erst nach Überschreiten des zugesagten Zielwerts.
- Eine Lizenz, ein Fremddienst oder eine feste Datenkomponente begrenzt trotz zusätzlicher Rechenleistung.
- Der Nachweis veröffentlicht interne Schwellen und Verbindungen, die für die Bewertung nicht nötig sind.
- Eine neue Produktfassung übernimmt einen alten Test, obwohl sie Lastpfad oder Datenmodell verändert.

## Kennzahlen

- Lastannahmen mit Quelle, Zeitraum, Einheit, Unsicherheit und Freigabedatum
- fachlich erfolgreiche Abschlüsse je Operation und Messintervall
- p50-, p95- und p99-Dauer für Antrag, Upload, Prüfung, Suche und Statusabruf
- technische Fehler, fachliche Ablehnungen, Abbrüche, Wiederholungen und Duplikate
- Anzahl und Alter offener Hintergrundaufgaben während Last und Erholung
- Datenvollständigkeit und Konsistenz nach Spitzen- und Überlastversuchen
- zusätzlicher nützlicher Durchsatz je Kapazitätsschritt
- Zeit vom Skalierungsauslöser bis zur messbaren Entlastung
- Angebotsaussagen mit aktueller Nachweisakte und zuständiger Freigabe
- Behauptungen unbegrenzter Skalierung im freigegebenen Angebot; Zielwert null

## Häufige Fragen

### Sind 24.000 registrierte Nutzer dasselbe wie 24.000 gleichzeitige Nutzer?

Nein. Erfassen Sie aktive Sitzungen, Ankunftsraten, gleichzeitig laufende Operationen und fachliche Abschlüsse getrennt. Das Verhältnis ergibt sich aus dem tatsächlichen Verhalten.

### Reicht ein Lasttest mit kleinen Testdateien?

Nur wenn kleine Dateien das angebotene Nutzungsspektrum belegen. Sonst benötigen Sie eine dokumentierte Größen-, Format- und Fehlerverteilung samt nachgelagerter Verarbeitung.

### Warum genügt die mittlere Antwortzeit nicht?

Der Mittelwert kann langsame Enden und ausgefallene Vorgänge verdecken. Zeigen Sie geeignete Perzentile, Fehler, Grundgesamtheit und fachlichen Abschluss je Laststufe.

### Muss die gesamte technische Architektur ins Angebot?

Prüfen Sie die Vergabeunterlagen und den genehmigten Offenlegungsweg. Beschreiben Sie Systemgrenze, Umgebungsnähe, Messmethode und Ausbauprinzip in der geforderten Tiefe. Konflikte mit Sicherheitsvorgaben benötigen eine Klärung oder einen geschützten Austausch vor der Freigabe.

### Beweist automatische Skalierung unbegrenzte Kapazität?

Nein. Auslösung, Bereitstellung, Aufwärmen, Zustandsarbeit, Quoten, feste Komponenten, Fremddienste und Kosten begrenzen den Vorgang. Berichten Sie die getestete Wirkung.

### Darf eine kleinere Testumgebung hochgerechnet werden?

Nur mit offengelegten Annahmen, nachgewiesenen Proportionalitäten, Behandlung fester Grenzen und einem genehmigten Validierungspunkt. Eine bloße Multiplikation ist kein Messwert.

### Wann verliert ein Performance-Test seine Aussagekraft?

Prüfen Sie ihn nach Änderungen an Produkt, Daten, Lastmix, Umgebungsklasse, Abhängigkeiten, Quoten, Skalierungsregeln oder Messung erneut. Das Datum allein entscheidet nicht.

### Ist der Kapazitätsnachweis bereits ein Service Level?

Nein. Er zeigt getestetes Verhalten. Ziel, Messregel, Ausnahmen, Rechtsfolge, Preis und Vertragsvollmacht benötigen eine gesonderte Freigabe.


## Primärquellen

- [ISO/IEC 25010:2023 zum Produktqualitätsmodell](https://www.iso.org/standard/78176.html), Internationale Organisation für Normung
- [ISO/IEC 25023:2016 zur Messung der System- und Softwareproduktqualität](https://www.iso.org/standard/35747.html), Internationale Organisation für Normung
- [ISO/IEC 25030:2019 als Rahmen für Qualitätsanforderungen](https://www.iso.org/standard/72116.html), Internationale Organisation für Normung
- [ISO/IEC 25040:2024 als Rahmen für Qualitätsbewertungen](https://www.iso.org/standard/83467.html), Internationale Organisation für Normung
- [ISO/IEC/IEEE 29119-1:2022 zu Grundbegriffen des Softwaretestens](https://www.iso.org/standard/81291.html), Internationale Organisation für Normung
- [ISO/IEC/IEEE 29119-2:2021 zu Software-Testprozessen](https://www.iso.org/standard/79428.html), Internationale Organisation für Normung
- [ISO-Übersicht zur Normenreihe ISO/IEC/IEEE 29119](https://committee.iso.org/sites/jtc1sc7/home/projects/flagship-standards/isoiecieee-29119-series.html), Internationale Organisation für Normung
- [NIST SP 500-307 zur Beschreibung von Cloud-Service-Messgrößen](https://www.nist.gov/publications/cloud-computing-service-metrics-description-0), National Institute of Standards and Technology
- [Google-SRE-Empfehlungen zu Kapazitätsplanung und Überlast](https://sre.google/sre-book/service-best-practices/), Google Site Reliability Engineering
- [Google-SRE-Kapitel zu Kaskadenfehlern und Lastabweisung](https://sre.google/sre-book/addressing-cascading-failures/), Google Site Reliability Engineering
- [Google-SRE-Kapitel zu verlässlichen Produkteinführungen unter Last](https://sre.google/sre-book/reliable-product-launches/), Google Site Reliability Engineering
- [Azure Well-Architected-Leitfaden für Performance-Tests](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-test), Microsoft Learn
- [Azure Well-Architected-Leitfaden für Kapazitätsplanung](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/capacity-planning), Microsoft Learn
- [Azure Well-Architected-Leitfaden für Performance-Ziele](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-targets), Microsoft Learn
- [Azure Architecture Center zur horizontalen Skalierung](https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/scale-out), Microsoft Learn
- [OpenTelemetry-Konventionen für HTTP-Messgrößen](https://opentelemetry.io/docs/specs/semconv/http/http-metrics/), OpenTelemetry
- [IETF RFC 8239 zur Benchmark-Methodik für Rechenzentren](https://datatracker.ietf.org/doc/html/rfc8239), Internet Engineering Task Force
- [Britischer Procurement Act 2023, Section 23 zu Zuschlagskriterien](https://www.legislation.gov.uk/ukpga/2023/54/section/23), UK Legislation
- [Aktueller britischer Leitfaden zur Bewertung von Angeboten](https://www.gov.uk/government/publications/procurement-act-2023-guidance-documents-procure-phase/assessing-competitive-tenders-html), UK Cabinet Office
- [Richtlinie 2014/24/EU über die öffentliche Auftragsvergabe](https://eur-lex.europa.eu/eli/dir/2014/24/oj/deu), Europäische Union
- [§ 31 VgV zur Leistungsbeschreibung](https://www.gesetze-im-internet.de/vgv_2016/__31.html), Bundesministerium der Justiz und Bundesamt für Justiz
- [Französischer Code de la commande publique, Artikel R2152-7](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000045739587), Légifrance


## Weiterführende Artikel

- [Was belegt ein unabhängiger Prüfbericht im Angebot wirklich?](https://zephior.com/de/insights/use-third-party-assurance-in-a-bid)
- [Responsible AI im RFP mit Kontrollprüfungen belegen](https://zephior.com/de/insights/answer-an-rfp-responsible-ai-question)
- [Eine belegbare Executive Summary für Angebote schreiben](https://zephior.com/de/insights/align-an-executive-summary-with-bid-evidence)
- [Wie lässt sich eine Service-Level-Leistung im Angebot belegen?](https://zephior.com/de/insights/evidence-service-level-performance-in-a-bid)