Antwort

Geschichte der Frage:
Moderne Informationssysteme arbeiten oft unter Last, die Anzahl der Benutzer und das Datenvolumen wachsen. Das Geschäft verlangt nach hoher Leistung und Skalierbarkeit des Produkts, Fehlertoleranz und minimalen Ausfallrisiken.

Problem:
Anforderungen an die Leistung werden selten klar formuliert, oft nur formal: "arbeitet schnell" oder "skaliert auf 100.000 Benutzer". Unzureichend ausgearbeitete Kriterien führen dazu, dass Lösungen nicht überprüft, abgestimmt oder getestet werden können, und manchmal auch zu Ressourcenverschwendung.

Lösung:

1. Der Analyst initiiert die Zusammenarbeit mit Architekten/Infrastruktur zur Sammlung von Benchmarks und zur Analyse von Spitzenlasten.
2. In der Phase der Anforderungserhebung werden die Szenarien der Massenbenutzung konkretisiert: maximale Anzahl gleichzeitiger Benutzer, Transaktionsvolumen, SLA bezüglich der Reaktionszeit.
3. Es werden messbare nicht-funktionale Anforderungen formuliert: "Laden von 10 Mio. Positionen in 5 Sekunden bei 1000 gleichzeitigen Anfragen".
4. Zusätzlich werden Profilierungstools und Prototyping verwendet, um die tatsächliche Leistung zu bewerten.
5. Alle Parameter werden abgestimmt und an den Geschäftszielen (z. B. SLA des Kundenservices) ausgerichtet.

Schlüsselfeatures:

• Orientierung an messbaren Kriterien (konkrete Metriken, SLA)
• Interaktion mit Architekten und DevOps bezüglich Lasttests
• Balance zwischen "Ideal" und realen Geschäftsprioritäten

Fangfragen.

Kann man branchenübliche Metriken verwenden, ohne das Produkt zu analysieren?

Branchenübliche Metriken sind nützlich zur Orientierung, müssen jedoch an die Spezifika des Geschäfts und die Zielgruppe des Produkts angepasst werden. Andernfalls können wichtige Szenarien und Lasten übersehen werden.

Reicht die Belastung in der Entwicklungstests, um sicherzustellen, dass die Skalierbarkeit gewährleistet ist?

Nein, Testumgebungen unterscheiden sich oft erheblich von Produktionsumgebungen hinsichtlich der Infrastrukturparameter. Es ist notwendig, Lasttests durchzuführen, die der Realität so nahe wie möglich kommen, und diese regelmäßig zu wiederholen.

Ist es möglich, maximale Leistung ohne Beeinträchtigung der Geschäfts Funktionen zu realisieren?

Fast immer gibt es einen Kompromiss: Manchmal werden Einschränkungen eingeführt (z. B. Batchverarbeitung oder Limits für bestimmte Szenarien), um Stabilität und Budgetkonformität zu gewährleisten.

Häufige Fehler und Anti-Patterns

• Anforderungen "aus dem Bauch heraus" ohne Konkretheit
• Fehlende wiederholte Messungen nach Releases und Änderungen
• Ignorieren der Skalierbarkeit in der Entwurfsphase (Aufschub bis "wenn es viele Benutzer gibt")

Beispiel aus dem Leben

Negativer Fall: Im Lastenheft wurde "Arbeiten unter hoher Last" angegeben, aber keine Metriken definiert. Im Release dauerte das Laden von Daten Stunden, das Geschäft verlor Kunden. Vorteile: Schnelle Genehmigung der Anforderungen. Nachteile: Unvorhersehbares Verhalten des Systems unter Last.

Positiver Fall: Der Analyst forderte Geschäftsszenarien an, dokumentierte gemeinsam mit den Architekten die Limits und führte Lasttests durch. Im Release hielt das System der Spitzenlast während der Aktionen stand. Vorteile: Vorhersehbares Wachstum, erfolgreiche Durchführung von Marketingaktionen. Nachteile: Verzögerung des Releases aufgrund zusätzlicher Tests.