Foto: Guenter Albers - shutterstock.com
Vor einigen Jahren habe ich mir ein "intelligentes" Thermostat für mein Zuhause gegönnt. Ich wollte in der Lage sein, die Temperatur von unterwegs aus zu regeln und zu überprüfen. Schnell war das Teil eingerichtet und mit dem Cloud Backend des Herstellers verbunden. Alles gut also? Von wegen. Ein paar Wochen später erreichte mich eine E-Mail des Herstellers bezüglich eines bevorstehenden "Service Upgrades". Das sollte mehrere Monate dauern, in denen das Unternehmen seine Anwendung für mehrere Stunden am Stück zu verschiedenen Tageszeiten (die natürlich nicht genannt wurden) herunterfahren wollte.
Für die Unannehmlichkeiten entschuldigte man sich natürlich artig im Voraus. Mein "smartes" Thermostat sollte also zu scheinbar zufälligen Zeiten für mehrere Stunden am Stück ausfallen und das über Monate hinweg? Das war zu viel für mich. Am nächsten Tag tauschte ich das Produkt gegen das eines anderen Herstellers. Schlechter Service vertreibt die Kunden nachhaltig - Verfügbarkeit ist im digitalen Zeitalter essenziell.
Ein weiteres Beispiel aus der Praxis: Um bestimmte Leistungen zu erhalten, muss mein Sohn sein Einkommen bei der US-Regierung angeben. Dazu verwendet er eine Smartphone-App. Einmal pro Monat meldet er sich bei der Anwendung an, um seine Einnahmen für den Vormonat zu melden. Diese (iPhone-)Anwendung hat allerdings ein großes Manko: Sie funktioniert nur von Montag bis Freitag - und da nur zwischen 8 und 17 Uhr.
Eine SaaS-basierte Online-Anwendung, die nur zu "normalen" Geschäftszeiten funktioniert, ist aus Sicht der Anwender vieles, aber auch eher schwer zu benutzen. Warum sollte man die Nutzungszeiten für eine solche App einschränken? Es kann nur daran liegen, dass es sich um eine staatliche Einrichtung handelt. Wer sollte dort die App denn außerhalb der Geschäftszeiten bedienen oder einen Fehler beheben...?
Downtime bleibt Downtime
Zugegeben, die beiden genannten Beispiele sind Extremfälle. Aber sie verdeutlichen ein häufiges Problem bei vielen Online-Anwendungen: Die Betreiberunternehmen bestimmen Wartungsfenster - Zeiträume, in denen sie ihre Anwendungen regelmäßig vom Netz nehmen, um routinemäßige Wartungsarbeiten und Aktualisierungen durchzuführen. Dabei glauben nicht wenige Betriebe, dass solche geplanten Ausfallzeiten keine Ausfallzeiten sind. Allerdings könnte kaum etwas weiter von der Wahrheit entfernt sein. Ausfallzeit ist Ausfallzeit. Ob geplant oder ungeplant: Wenn Ihre Kunden Ihre Anwendung nutzen wollen und die aus irgendeinem Grund nicht verfügbar ist, handelt es sich um Downtime.
Ohne ein hohes Maß an Verfügbarkeit zu gewährleisten, können Sie moderne, digitale Online-Anwendungen und -Services nicht betreiben. Die Kunden erwarten heute, dass Services betriebsbereit sind, wenn sie ihn nutzen wollen und tolerieren keine Ausfallzeiten. Es ist schon schlimm genug, wenn ein Ausfall Ihre Verfügbarkeit beeinträchtigt. Wenn Sie Ihre Downtime in Form von Wartungsfenstern planen und ankündigen, steigt die Unzufriedenheit der Kunden nur noch weiter.
Dank der heute zur Verfügung stehenden Tools und Services für moderne Anwendungsentwicklung sollte es keinen Grund mehr dafür geben, dass eine digitale Anwendung eine Downtime für Wartung oder Upgrades benötigt. So gut wie jedes Upgrade kann heute ohne Ausfallzeiten vonstattengehen - selbst solche, die Änderungen am Datenbankschema und andere Datenmigrationsaufgaben nach sich ziehen. Auch Wartungsaufgaben können erledigt werden, während die Applikation weiterläuft.
Wartungsfenster gleich technische Schulden
Wenn Ihre Anwendung aufgrund eines historischen Architekturproblems tatsächlich Wartungsfenster benötigt, sollten Sie das als Problem betrachten. Es handelt sich um technische Schulden, die Ihre Anwendung aufweist und Ihrem Unternehmen Geld kostet. Sie sollten das Problem dringend angehen. Den Kunden ist es allerdings egal, warum Ihre Anwendung nicht funktioniert. Die interessiert nur, dass sie ausfällt. Wenn Ihre Applikation wächst und gedeiht, dürfte es auch immer schwieriger werden, regelmäßige Downtimes gegenüber den Kunden zu rechtfertigen. Der Aufbau von Systemen und Prozessen, die keine Wartungsfenster benötigen, fördert zudem die Etablierung von Best Practices für Entwicklung, Bereitstellung und Betrieb. Wir Entwickler neigen zu Faulheit, wenn wir Wartungsfenster zur Verfügung haben.
Zugegeben: Änderungen ohne Wartungsfenster zu entwerfen und zu implementieren, erfordert zusätzliche Zeit und Gehirnschmalz. Gleichzeitig fördert dies allerdings auch die Aufmerksamkeit für Details. Wenn die Entwickler über die betrieblichen Auswirkungen einer Änderung nachdenken müssen, treten in der Regel weniger betriebliche Probleme auf. Sind Sie hingegen abhängig von Wartungsfenstern, leiden Gesamtqualität und Verfügbarkeit.
Selbst wenn Sie gegenwärtig leicht identifizierbare Zeitfenster mit geringer Auslastung nutzen, um Ihre Applikation herunterzufahren: Niemand kann Ihnen garantieren, dass diese auch in Zukunft so zur Verfügung stehen. Eine internationale Expansion, die Ausweitung der Produktpalette oder die Erweiterung der Kundenbasis können beispielsweise schnell dazu führen, dass auch für Sie eine 24x7-Verfügbarkeit zur Pflicht wird.
Was Downtime kostet
Ein früherer Kunde von mir hat regelmäßig einmal pro Woche ein zweistündiges Wartungsfenster eingeplant, um Upgrades und Anpassungen durchzuführen. Das Problem: Das Wartungsfenster an sich stellt bereits eine erhebliche Beeinträchtigung der Verfügbarkeit dar. Ein zweistündiges Wartungsfenster hat eine maximale Verfügbarkeit von 98,8 % zur Folge. Im Vergleich zu anderen Online-Anwendungen ist das erschreckend niedrig. Der Amazon S3-Service garantiert beispielsweise eine Verfügbarkeit von 99,99 %. Die maximale Ausfallzeit beträgt 61 Sekunden - pro Woche. Damit Amazon S3 diese SLA durchgängig einhalten kann, verbietet es sich für AWS, Ausfallzeiten für Wartungsarbeiten einzuplanen. Jeder Ausfall würde dazu führen, dass die vertraglich vereinbarten SLAs nicht erfüllt werden.
Fällt Amazon S3 in einem bestimmten Monat nur 4,3 Minuten aus, erstattet AWS zehn Prozent der Speicherkosten für den gesamten Monat. Es handelt sich dabei also um eine beträchtliche Summe. Und das gilt nicht nur für S3, sondern für AWS insgesamt. Die Verfügbarkeits-Verpflichtung ist in den Köpfen der Mitarbeiter verankert. Sie bauen alles so, dass keine Downtime erforderlich ist, egal um welche Änderungen es dabei geht.
Es gehört auch zur Wahrheit, dass nicht jedes Unternehmen einen Verfügbarkeitsgrad von 99,99 % braucht, um erfolgreich zu sein. Aber selbst bei einem niedrigeren Prozentsatz bleibt wenig Raum für geplante Wartungsfenster, denn:
eine Verfügbarkeit von 99 % bedeutet eine maximale Ausfallzeit von 1,6 Stunden pro Woche.
eine Verfügbarkeit von 99,9 % bedeutet eine maximale Ausfallzeit von 10 Minuten pro Woche.
eine Verfügbarkeit von 99,99 % bedeutet eine maximale Ausfallzeit von weniger als 61 Sekunden pro Woche.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld. (fm)