Wer den Begriff „Ausfall“ hört, nimmt vielleicht an, dass es sich um den totalen Zusammenbruch eines Service handelt, bei dem plötzlich kein einziges Element der Servicebereitstellungskette mehr verfügbar ist. Beschäftigt man sich jedoch mit der Anatomie der meisten Ausfälle, so ist ein Totalausfall selten (wenngleich nicht unmöglich).
In letzter Zeit haben wir einen Anstieg der so genannten „Funktionsausfälle“ festgestellt, bei denen vielleicht nur ein einziger Bereich eines Service nicht funktioniert, was aber Auswirkungen hat, die die gesamte Lieferkette stören. Dabei könnte es sich beispielsweise um ein fehlerhaftes Zahlungsgateway oder ein Problem mit einem Benutzerauthentifizierungsverfahren handeln. Diese Komponenten werden häufig von Dritten bereitgestellt und entziehen sich der Kontrolle des Service-Providers, können aber verheerende Auswirkungen auf die Servicebereitstellung haben.
Nur wenn Sie die Ursachen solcher Ausfälle genau kennen, können Sie sie wirksam eindämmen – sowohl aus der Perspektive des Service-Providers als auch aus der des Kunden. Wir möchten nun aufzeigen, wie ein tiefgehendes Verständnis der Entstehung von Ausfällen dazu beitragen kann, Ihr langfristiges Ausfallrisiko zu minimieren.
Das verstärkte Auftreten von Funktionsausfällen
Regelmäßige Hörer:innen des Podcasts „The Internet Report“ wissen, dass in den letzten Monaten vermehrt über Funktionsausfälle bei einigen der größten Internetdienste der Welt berichtet wurde. Für den User erscheinen diese Ausfälle oft so, als sei der Service „nicht erreichbar“; doch wenn man diesen Ausfällen auf den Grund geht, stellt man fest, dass häufig nur ein kleiner Teil der Applikation ausgefallen ist, z. B. ein Plug-in eines Drittanbieters, ein Zahlungsgateway oder der Authentifizierungsanbieter.
Im Zeitalter der verteilten Architektur bestehen die Services aus vielen verschiedenen Komponenten, die miteinander harmonieren müssen. Dieser Modus hat viele Vorteile, wie etwa optimierte Services und eine geringere Latenz. Ein Internet-Händler möchte z. B. vermutlich kein eigenes Zahlungsgateway betreiben. Und weshalb sollte er auch? Es ist nicht seine Kernkompetenz, es ist kritisch in puncto Sicherheit, und es ist fast immer billiger, eine Option eines Drittanbieters einzusetzen, die mit keinen Entwicklungs- oder laufenden Wartungskosten verbunden ist. Selbst die größten Technologieunternehmen der Welt greifen bei einigen Bestandteilen ihrer Apps auf Komponenten von Drittanbietern zurück. Es geht oft nicht um die Technologie an sich, sondern vielmehr um die Steigerung der Leistung und die Senkung der Betriebskosten.
Allerdings birgt dies auch gewisse Risiken. Diese Komponenten können zu einem Single-Point-of-Failure werden. Wenn sich beispielsweise ein User bei einem sozialen Netzwerk nicht authentifizieren kann, spielt es keine Rolle, ob das Messaging-Element des Dienstes noch einwandfrei funktioniert. Der User hat schlichtweg keinen Zugang dazu.
Wir haben auch Ausfälle erlebt, bei denen die Authentifizierung problemlos funktionierte und die App scheinbar normal lief. Dennoch führte der Ausfall eines Backend-Services dazu, dass der Service versagte, sobald ein Nutzer versuchte, eine konkrete Aktion wie das Senden einer Nachricht oder den Kauf eines Artikels durchzuführen.
Die meisten Service-Provider haben zwar eine gewisse Redundanz in ihre Services eingebettet, aber manchmal ist ein Failover-System aufgrund des Risiko-Ertrags-Verhältnisses schwer zu rechtfertigen. So ist beispielsweise die Einrichtung eines Backup-Zahlungsgateways eine teure, technisch komplexe Lösung, auf die viele Service-Provider unter Umständen verzichten. Ähnlich verhält es sich mit den Verbraucher:innenen, die selten zwei gleichartige Dienstleistungen kaufen, falls eine ausfällt.
Allerdings bedeutet das nicht, dass wir nichts unternehmen können, als mit den Schultern zu zucken und gelegentliche Ausfälle in Kauf zu nehmen, sei es von Seiten des Service-Providers oder des End Users.
Ein Ausfall muss verstanden werden
Was können Sie in solchen Situationen also unternehmen? Zunächst müssen Sie sich mit der Anatomie eines Ausfalls auseinandersetzen.
Beginnen Sie mit der Klärung des Störungsbereichs (also damit, wo das Problem tatsächlich aufgetreten ist und wer für die Lösung des Problems verantwortlich und rechenschaftspflichtig ist). Lag der Fehler beispielsweise bei einem Service eines Drittanbieters oder beim Rechenzentrum, das diesen Service hostet?
Es geht uns hier jedoch nicht um reine Schuldzuweisungen. Sie müssen die Auswirkungen dieses Versagens und die nachgelagerten Effekte verstehen, die es im Wiederholungsfall nach sich ziehen könnte. Ist der Service komplett ausgefallen oder gab es nur Leistungseinbußen? Welche Folgen hatte die erhöhte Latenz in einem bestimmten Bereich der Dienstleistungskette? Erst wenn Sie die Folgen eines Ausfalls genau kennen, können Sie sich Gedanken darüber machen, wie sich diese in Zukunft vermeiden oder die Auswirkungen abfedern lassen.
Als Unternehmen müssen Sie entscheiden, wo und wann eine Redundanz sinnvoll ist. Wie bereits erwähnt, ist es höchst unwahrscheinlich, dass Sie jemals zwei Zahlungsgateways haben werden, da dies in der Regel finanziell nicht tragbar ist. Denkbar wären jedoch zwei CDN-Provider oder eine Aufteilung auf verschiedene Regionen. Zwar wird dies mit Kosten für die Datenverarbeitung verbunden sein, aber das gehört zur Risikobewertung.
Auch die Kunden dieser Services müssen eine Risikobewertung vornehmen. Wie teuer ist ein solcher Ausfall, und wie viel würde es kosten, ihn zu beheben? Als Kunde eines Cloud-Service-Providers könnten Sie zum Beispiel vor der Entscheidung stehen, ob Sie in zwei einzelne Availability Zones investieren sollen. Dazu ist eine Kostenanalyse erforderlich: Wie hoch sind die zusätzlichen Datenverarbeitungskosten? Wie werden Sie die Daten zwischen den beiden Systemen synchronisieren? Sind mehrere Content Delivery Networks (CDNs) erforderlich? Wäre es aus finanzieller Sicht sinnvoller, auf einen Tier-2-Cloud-Provider zurückzugreifen?
All dies erfordert ein umfassendes Bild der gesamten Servicebereitstellungskette. Sie müssen wissen, weshalb dieser Ausfall aufgetreten ist, wie wahrscheinlich es ist, dass er in Zukunft auftritt, wie hoch Ihr Risiko ist und ob Sie Maßnahmen ergreifen wollen, um eine Wiederholung zu vermeiden.
Sie sollten die Mentalität der Fehlerermittlung und -behebung vermeiden und stattdessen eine kontinuierliche Verbesserung anstreben, bei der Sie potenzielle Probleme vorhersehen und entschärfen können, bevor sie auftreten.
In der Podcast-Folge „The Anatomy of an Outage“ erfahren Sie mehr über die Anatomie von Ausfällen und lernen einige Fallbeispiele aus der Praxis kennen.
Ermittlung der wichtigsten Informationen
Wir wollen also von dieser reaktiven Haltung wegkommen und in einen präventiven Modus übergehen, in dem das Unternehmen ständig nach Möglichkeiten sucht, die Performance des gesamten Netzwerks zu verbessern. Dazu müssen wir sicherstellen, dass wir uns auf die richtigen Daten konzentrieren.
Man gerät schnell in die Falle, alles im Griff haben zu wollen und jede einzelne Kennzahl zu erfassen, die man in die Finger bekommt. Das kostet nicht nur viel Zeit, sondern kann auch enorm teuer werden. Und sogar wenn Sie es sich leisten können, all diese Daten zu erfassen, erreichen Sie schon bald eine Größenordnung, in der Sie die Nadel im Heuhaufen suchen.
Entscheidend ist, dass Sie die für Ihr Unternehmen relevanten Informationen ermitteln, die es Ihnen ermöglichen, Ihre Abläufe mit Blick auf die Zukunft zu optimieren, weil Sie die Risiken und die Kosten/Vorteile der Bekämpfung potenzieller Probleme oder möglicher Lösungen genau kennen.
Ich hatte während meiner beruflichen Laufbahn einmal mit einem bekannten Unternehmen aus der Glücksspielbranche zu tun. Das Unternehmen hatte beschlossen, den Geschäftsbetrieb aus dem eigenen Rechenzentrum in die Cloud zu verlagern, also auf ein so genanntes „Lift and Shift“ seiner Infrastruktur zu setzen. Dem Unternehmen wurde versichert, dass eine einfache Replikation seiner derzeitigen Einrichtung in einer Cloud-Architektur die Kosten senken und die Leistung verbessern würde.
Als die Umstellung abgeschlossen war, stellte das Unternehmen jedoch zu seiner Überraschung fest, dass die Leistung trotz des Umstiegs auf eine modernere Hardware abgenommen hatte, weil die Architektur nicht an die Anforderungen der neuen Cloud-Infrastruktur angepasst worden war. Im Glücksspielsektor ist jede Art von Verzögerung in der App-Leistung äußerst kritisch, da die Kunden Wetten auf Live-Ereignisse platzieren und sofort auf Änderungen im Spiel reagieren wollen. Aber in der neuen Infrastruktur dauerte die Platzierung von Wetten doppelt so lange wie in der alten, was einige Kunden möglicherweise verärgerte.
Erschwerend kam hinzu, dass die Datenverarbeitungskosten des Unternehmens stiegen, weil es ein lokales System zur Cloud migriert hatte, ohne das Backend für die Cloud-Infrastruktur zu optimieren.
Um das Problem zu lösen, musste das Unternehmen den Blickwinkel ändern und die Lage neu analysieren. Zur Kostensenkung wurde der Code auf der Grundlage der Cloud-Plattform überarbeitet, allerdings nicht zulasten der Leistung. Vielmehr galt es, die Effizienz zu steigern. Hierfür musste das Unternehmen den Service aufteilen und die Cloud-Infrastruktur geografisch näher an die Nutzerbasis verlegen, damit die Verzögerung beim Platzieren von Wetten nicht so gravierend war.
Ermittlung der Kernproblematik
Dieses Beispiel führt uns wieder vor Augen, dass proaktiv eine Verbesserung angestrebt werden muss. Für ein Unternehmen ist es am wichtigsten, die Schwachstellen in diesem Umfeld zu erkennen. Wo befinden sich die potenziellen Engpässe?
Es geht nicht unbedingt darum, jeden einzelnen Single-Point-of-Failure aufzuspüren, sondern es soll vielmehr festgestellt werden, wo die Wahrscheinlichkeit einer Performance-Verschlechterung am größten ist. Wenn das erkannt wird, ist das auch der Bereich, der höchstwahrscheinlich versagt, denn bei jedem Ausfall ist ein Leistungsverlust der erste Hinweis. Dabei kommt es zu einer Verschlechterung und erneuten Übertragung, einer erhöhten Latenz und allen wichtigen Indikatoren eines Ausfalls.
Aber wenn Sie diese Engpässe feststellen können, bevor Probleme auftreten, wissen Sie, wo Sie mit der Optimierung ansetzen müssen. Hier bekommen Sie wahrscheinlich am meisten für Ihr Geld, was die IT-Ausgaben angeht. Und Sie verbringen einen Tag weniger damit, sich mit Kennzahlen zu beschäftigen und sich zu fragen, was nicht funktioniert hat.