“Im Januar können wir wieder darüber reden, so kurz vor Weihnachten fasst kein Händler seinen Webshop an.” Es ging um eine potenziell dramatische Verbesserung der Performance eben solcher Webshops. Die Maßnahme wäre ziemlich risikoarm umzusetzen und auch schnell wieder rückgängig zu machen, falls nötig. Trotzdem: man macht die Änderung lieber nicht, es könnte ja etwas katastrophal schiefgehen.

Mal abgesehen von dem Einzelfall, was sagt uns diese vorweihnachtliche Risiko-Aversion über die IT?

1. Jede Änderung kann unübersehbare Ausfälle zur Folge haben, daher wird das Schlimmste angenommen.
2. Es dauert wahrscheinlich ziemlich lange, einen Ausfall zu kompensieren.

Das ist eine direkte Folge eines schwerfälligen Lieferprozesses: Ein Problem direkt in Produktion zu beheben ist zu risikoreich (obwohl man das außerhalb des Weihnachtsgeschäfts schon mal macht). Den Fix durch den normalen Lieferprozess zu schleusen, dauert zu lange. Wir brauchen ja eine Testumgebung, die mit realistischen Daten gefüllt ist, wir müssen Regressionstests machen usw.

Wie kann man die Situation verbessern?

Ein Risiko besteht immer aus Eintrittswahrscheinlichkeit und Schwere des Schadens. Im Straßenverker können Sie zum Beispiel die Wahrscheinlichkeit eines Unfalls verringern, indem Sie umsichtig fahren. Im Extremfall fahren Sie garnicht mehr Auto. Das entspricht ungefähr der Regel: “Vor Weihnachten keine Änderungen am Webshop machen”.

Auf der anderen Seite kann man den potenziellen Schaden begrenzen: Sie schnallen sich an und fahren ein Auto mit Airbag. Für einen Webshop gibt es einige Möglichkeiten, um die Höhe des Schadens zu begrenzen:

Probleme schnell beheben. Die Umsatzeinbuße fällt geringer aus, wenn wir das System in kurzer Zeit wieder aufstellen können. Dabei helfen Maßnahmen (Stichwort: DevOps), um Änderungen schnell und zuverlässig in Produktion zu geben. Automatisierter Aufbau von Umgebungen (Stichwort: infrastructure as code) hilft, Probleme wie z.B. Kapazitätsengpässe oder Hardwareausfälle schnell zu überwinden.

Die Auswirkungen eines Problems begrenzen. Facebook zum Beispiel liefert jede Software-Änderung gestaffelt aus: zuerst an die Mitarbeiter, dann an 2% der Facebook-Nutzer, dann an 100% der Nutzer. Auf jeder dieser Stufen werden negative Auswirkungen via Monitoring erkannt. Änderungen lassen sich einfach stoppen, es gibt sogar einen “Not-Aus-Knopf”.

Probleme frühzeitig erkennen. Wenn wir Anzeichen eines Ausfalls frühzeitig erkennen, können wir rechtzeitig gegensteuern. Ein durchdachtes Monitoring-Konzept kann z.B. helfen, eine Verschlechterung der Performance zu erkennen, und Gegenmaßnahmen einzuleiten, bevor ein sichtbares Problem für die Kunden des Webshops entsteht.

Die ersten beiden Möglichkeiten brauchen längerfristige Investitionen in den Lieferprozess und die Architektur des Systems. Falls bei Ihnen so kurz vor Weihnachten auch die Regel “Nichts Anfassen!” gelten sollte, können Sie zumindest noch in sinnvolles Monitoring investieren.

Matthias Berth