„Kein großes Problem“, dachte ich, „ich kann ja noch 30 Minuten stehen“. Doch dann kam die zweite Durchsage:
Aufgrund technischer Probleme funktioniert die Klimaanlage heute nur in der Hälfte der Wagen.
Das wäre kein Problem, wenn man in einem ICE die Fenster öffnen könnte. Da es aber eine schlechte Idee ist, offene Fenster zu haben, wenn der Zug mit 300 km/h fährt, ist das Öffnen der Fenster in ICE-Zügen nicht möglich.
Wenn die Klimaanlage nicht funktioniert, kann die Temperatur an Bord eines ICE-Zuges im Sommer leicht auf 50°C oder mehr ansteigen. Glauben Sie mir, das ist kein Ort, an dem man sich wohlfühlt.
Während ich zufällig in einem der Waggons stand, die eine funktionierende Klimaanlage hatten, machte mich diese Situation wütend. Und warum? Weil ich weiß, dass dies ein systemisches Problem ist: Die Klimaanlage ist nur für Außentemperaturen bis 32°C ausgelegt. Und raten Sie mal, was passiert, wenn die Fahrgäste von einem Wagen ohne Klimaanlage in einen Wagen mit Klimaanlage umsteigen? Ganz einfach: eine andere Klimaanlage schaltet sich ab, weil sie mit der Situation nicht zurechtkommt.
Wenn Sie mich fragen, entspricht das Design (vielleicht auch die Implementierung, aber ich bin kein Ingenieur) der Klimaanlage des InterCity Express nicht dem Standard an Zuverlässigkeit, Qualität und Anspruch an Perfektion, den man von einem Produkt „Made in Germany“ erwartet.
In unserer Welt des Software-Engineerings im Allgemeinen und bei Webanwendungen mit hohen Nutzerzahlen im Besonderen ist Zuverlässigkeit der Aspekt der Softwarequalität, der sich mit Fragen wie „Hält die Anwendung hohen Belastungen stand?“ oder „Funktioniert die Anwendung auch in ungewöhnlichen Situationen noch korrekt?“ beschäftigt.
Das Umfeld, zum Beispiel die Größe und das Verhalten der Nutzerschaft, einer Webanwendung ändern sich ständig. Was gestern noch ausreichend war, kann morgen schon unzureichend sein. Capacity Planning ist unser Werkzeug, um heute zu erkennen, dass wir unsere Anwendung weiter skalieren müssen, damit sie auch morgen noch ihre funktionalen Anforderungen und Qualitätsziele erfüllen kann.
Product Owner und die Entwickler haben manchmal nur eine vage Service-Level-Vereinbarung wie zum Beispiel
Der Webserver muss N Anfragen pro Sekunde beantworten können.
Zählt das Ausliefern eines HTTP 500 (Internal Server Error) Statuscodes als Beantwortung einer Anfrage? Technisch gesehen schon, aber es wird den Produktverantwortlichen wahrscheinlich nicht glücklich machen.
Außerdem sind nicht alle Anfragen hinsichtlich des Ressourcenverbrauchs gleich teuer: Das Ausliefern statischer Assets ist billiger als das Ausführen komplexer Geschäftslogik. Das bedeutet, dass eine sinnvolle Service-Level-Vereinbarung dies berücksichtigen und ein messbares Leistungsziel festlegen muss.
Eine solche Service-Level-Vereinbarung ist etwas, zu dem sich die Entwickler verpflichten können und für das sie das System entwerfen können. Stellen Sie sich die Schuldzuweisungen vor, die entstehen könnten, wenn der Product Owner die Qualitätsziele nur vage formuliert.
Der Datenverkehr kann manchmal sporadisch und unvorhersehbar sein. Um sich auf periodische Spitzen vorzubereiten, müssen Sie wissen, wie viele Anfragen pro Sekunde ein Server bewältigen kann, bevor seine Leistung unter einen bestimmten Schwellenwert sinkt. Mit diesem Wissen können Sie Alarme in Ihrer Systemüberwachung konfigurieren. Sie werden auch wissen, welche Auswirkungen zu erwarten sind, wenn Sie einen neuen Server hinzufügen. Kombiniert werden diese beiden Aspekte Sie hoffentlich rechtzeitig darauf aufmerksam machen, dass Sie mehr Maschinen benötigen.
Wenn periodische Spitzen zur „neuen Normalität“ werden (idealerweise sogar schon vorher), muss das Service-Level-Agreement zwischen dem Business Owner und den Entwicklern neu verhandelt werden, da die ständige Bewältigung einer deutlich höheren Last möglicherweise nicht dadurch erreicht werden kann, dass „einfach“ mehr Hardware auf das Problem geworfen wird, sondern eher durch ein Refactoring der Software selbst, für das die Entwickler Zeit und Budget benötigen.
Die Klimaanlage des InterCity Express wurde vor Jahrzehnten für eine maximale Außentemperatur von 32°C ausgelegt. Heutzutage sind Temperaturen über 32°C keine periodischen Spitzen mehr und die Anforderungen an das Klimasystem sollten aktualisiert werden. Der Business Owner hat beschlossen, die alten Klimaanlagen nicht zu aktualisieren und stattdessen die Kunden schwitzen zu lassen.
In unserer Welt der Softwareentwicklung sollte es viel einfacher sein, alte Komponenten zu ersetzen und das System an neue Anforderungen anzupassen, als alte Hardware zu ersetzen.