Kapitel 1. Verstehen, Messen und Verbessern deiner Verfügbarkeit

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Es interessiert niemanden, ob dein System tolle Funktionen hat, wenn er es nicht benutzen kann.

Eines der wichtigsten Themen bei der Planung von skalierbaren Systemen ist die Verfügbarkeit. Es gibt zwar einige Unternehmen und Dienstleistungen, bei denen ein gewisses Maß an Ausfallzeiten zumutbar ist, aber die meisten Unternehmen können überhaupt keine Ausfallzeiten haben, ohne dass dies die Zufriedenheit ihrer Kunden und letztlich den Gewinn des Unternehmens beeinträchtigt.

Die folgenden grundlegenden Fragen müssen sich alle Unternehmen stellen, wenn sie herausfinden wollen, wie wichtig die Systemverfügbarkeit für sie und ihre Kunden ist. Diese Fragen und die unvermeidlichen Antworten darauf sind der Kern dessen, warum die Verfügbarkeit für hochskalierte Anwendungen entscheidend ist.

Warum bei dir kaufen?

Warum sollte jemand deine Dienstleistung kaufen, wenn sie nicht einsatzbereit ist, wenn er sie braucht?

Was denken deine Kunden?

Was denken oder fühlen deine Kunden, wenn sie deinen Service in Anspruch nehmen müssen und er nicht funktioniert?

Wie machst du deine Kunden glücklich?

Wie kannst du deine Kunden glücklich machen, deinem Unternehmen Geld einbringen und deine geschäftlichen Versprechen und Anforderungen erfüllen, wenn dein Service nicht funktioniert?

Damit deine Kunden zufrieden sind und mit deinem System arbeiten, muss es betriebsbereit sein. Es gibt einen direkten und sinnvollen Zusammenhang zwischen der Systemverfügbarkeit und der Kundenzufriedenheit.

Hochverfügbarkeit ist eine so wichtige Komponente beim Aufbau hochskalierbarer Systeme, dass wir diesem Thema in diesem Buch viel Zeit widmen werden. Wie baut man ein System (einen Dienst, eine Anwendung oder eine Umgebung) auf, das auch dann hochverfügbar ist, wenn eine Vielzahl von Anforderungen an es gestellt wird?

Verfügbarkeit vs. Verlässlichkeit

Verfügbarkeit und Zuverlässigkeit sind zwei ähnliche und doch sehr unterschiedliche Konzepte. Es ist wichtig, den Unterschied zwischen ihnen zu verstehen.

Zuverlässigkeit bezieht sich in unserem Zusammenhang allgemein auf die Qualität eines Systems. In der Regel ist damit die Fähigkeit eines Systems gemeint, durchgängig gemäß den Spezifikationen zu funktionieren. Du sprichst von zuverlässiger Software, wenn sie ihre Testsuiten besteht und im Allgemeinen das tut, was sie deiner Meinung nach tun sollte. Verlässlichkeit beantwortet die Frage:

"Ist die Antwort auf meine Anfrage korrekt?"

Verfügbarkeit bezieht sich in unserem Zusammenhang im Allgemeinen auf die Fähigkeit deines Systems, die Aufgaben zu erfüllen, zu denen es in der Lage ist. Ist das System da? Ist es betriebsbereit? Reagiert es? Wenn die Antwort "ja" lautet, ist es verfügbar. Die Verfügbarkeit beantwortet die Fragen:

"Bekomme ich eine Antwort?"

"Ist die Antwort rechtzeitig eingetroffen?"

Wie du sehen kannst, sind Verfügbarkeit und Zuverlässigkeit sehr ähnlich. Es ist schwer für ein System, verfügbar zu sein, wenn es nicht auch zuverlässig ist, und es ist schwer für ein System, zuverlässig zu sein, wenn es nicht auch verfügbar ist.

Im Folgenden wird erklärt, was wir meinen, wenn wir diese Begriffe verwenden:

Verlässlichkeit

Die Fähigkeit deines Systems, die vorgesehenen Operationen fehlerfrei auszuführen.

Verfügbarkeit

Die Fähigkeit deines Systems, bei Bedarf einsatzbereit zu sein, um diese Aufgaben zu erfüllen.

Ein System, das 2 + 3 addiert und 6 erhält, hat eine schlechte Zuverlässigkeit. Ein System, das 2 + 3 addiert und nie ein Ergebnis liefert, hat eine schlechte Verfügbarkeit. Die Zuverlässigkeit kann oft durch Testen behoben werden. Die Verfügbarkeit ist normalerweise viel schwieriger zu lösen.

Du kannst einen Softwarefehler in deine Anwendung einbauen, der dazu führt, dass 2 + 3 die Antwort 6 ergibt. Das lässt sich in einer Testsuite leicht feststellen und beheben.

Nehmen wir aber an, du hast eine Anwendung, die zuverlässig das Ergebnis 2 + 3 = 5 liefert. Jetzt stell dir vor, du lässt diese Anwendung auf einem Computer laufen, der eine schlechte Netzwerkverbindung hat. Das Ergebnis? Du führst die Anwendung aus, und manchmal liefert sie 5, manchmal aber auch gar nichts. Die Anwendung mag zuverlässig sein, aber sie ist nicht verfügbar.

Wir werden uns fast ausschließlich auf die Entwicklung hochverfügbarer Systeme konzentrieren. Wir gehen davon aus, dass dein System zuverlässig ist, dass du weißt, wie man Testsuiten erstellt und ausführt, und wir werden nur dann über Zuverlässigkeit sprechen, wenn sie einen direkten Einfluss auf deine Systemarchitektur oder die Verfügbarkeit hat.

Was ist die Ursache für schlechte Verfügbarkeit?

Was ist die Ursache dafür, dass eine Anwendung, die zuvor gut funktionierte, nun eine schlechte Verfügbarkeit aufweist? Es gibt viele mögliche Ursachen:

Erschöpfung der Ressourcen

Wenn du die Anzahl der Nutzer/innen oder die Datenmenge in einem System erhöhst, kann es passieren, dass die Ressourcen deiner Anwendung erschöpft werden, was zu einer langsameren und nicht mehr reagierenden Anwendung führt.

Ungeplante lastabhängige Änderungen

Wenn deine Anwendung immer beliebter wird, kann es sein, dass du den Code und die Anwendung ändern musst, um die erhöhte Belastung zu bewältigen. Diese Änderungen, die oft schnell und in letzter Minute mit wenig oder gar keiner Voraussicht oder Planung umgesetzt werden, erhöhen die Wahrscheinlichkeit, dass Probleme auftreten.

Erhöhte Anzahl von beweglichen Teilen

Wenn eine Anwendung an Popularität gewinnt, ist es oft notwendig, mehr und mehr Entwickler, Designer, Tester und andere Personen mit der Arbeit an der Anwendung und ihrer Wartung zu beauftragen. Diese größere Anzahl von Personen, die an der Anwendung arbeiten, führt zu einer großen Anzahl von beweglichen Teilen, egal ob es sich dabei um neue Funktionen, geänderte Funktionen oder die allgemeine Wartung der Anwendung handelt. Je mehr Personen an der Anwendung arbeiten, desto mehr bewegliche Teile gibt es in der Anwendung und desto größer ist die Wahrscheinlichkeit, dass es zu fehlerhaften Interaktionen in der Anwendung kommt.

Externe Abhängigkeiten

Je mehr Abhängigkeiten deine Anwendung von externen Ressourcen wie SaaS-Diensten, Infrastruktur oder Cloud-basierten Diensten hat, desto mehr ist sie Verfügbarkeitsproblemen ausgesetzt, die durch diese Ressourcen verursacht werden.

Technische Schulden

Mit zunehmender Komplexität der Anwendung steigen in der Regel auch die technischen Schulden (d.h. die Ansammlung von gewünschten Softwareänderungen und ausstehenden Fehlerbehebungen, die sich oft im Laufe der Zeit ansammeln, wenn eine Anwendung wächst und reift). Technische Schulden erhöhen die Wahrscheinlichkeit, dass ein Problem auftritt.

Alle schnell wachsenden Anwendungen haben eines, einige oder alle dieser Probleme. So können potenzielle Verfügbarkeitsprobleme auch bei Anwendungen auftreten, die zuvor einwandfrei funktionierten. Die Probleme können sich schleichend einstellen oder plötzlich und ohne Vorwarnung auftreten.

Aber die meisten wachsenden Anwendungen werden irgendwann Probleme mit der Verfügbarkeit bekommen.

Verfügbarkeitsprobleme kosten dich Geld, sie kosten deine Kunden Geld, und sie kosten dich das Vertrauen und die Loyalität deiner Kunden. Dein Unternehmen kann nicht lange überleben, wenn du ständig Probleme mit der Verfügbarkeit hast.

Anwendungen zu entwickeln, die skalierbar sind, bedeutet, Anwendungen zu entwickeln, die für hohe Verfügbarkeit ausgelegt sind.

Verfügbarkeit messen

Die Messung der Verfügbarkeit ist wichtig, um dein System hochverfügbar zu halten. Nur wenn du die Verfügbarkeit misst, kannst du verstehen, wie deine Anwendung jetzt funktioniert, und untersuchen, wie sich die Verfügbarkeit deiner Anwendung im Laufe der Zeit verändert.

Das am weitesten verbreitete Verfahren zur Messung der Verfügbarkeit einer Webanwendung ist die Berechnung des Prozentsatzes der Zeit, in der sie für Kunden zugänglich ist. Wir können dies mit der folgenden Formel für einen bestimmten Zeitraum beschreiben:

Prozentuale Verfügbarkeit des Standorts = Gesamt_Sekunden_im_Zeitraum - Sekunden_system_ist_ausgefallen / Gesamt_Sekunden_im_Zeitraum

Lass uns ein Beispiel nehmen. Nehmen wir an, dass deine Website im April zweimal nicht erreichbar war: das erste Mal für 37 Minuten und das zweite Mal für 15 Minuten. Wie hoch ist die Verfügbarkeit deiner Website?

Anhand des folgenden Beispiels kannst du sehen, dass schon ein kleiner Ausfall Auswirkungen auf deinen Verfügbarkeitsanteil hat:

Gesamtzahl der Sekunden nach unten = (37 + 15) × 60 = 3.120 s

Gesamtzahl der Sekunden im Monat = 30 Tage × 86.400 s/Tag = 2.592.000 s

Prozentuale Verfügbarkeit des Standorts = Gesamt_Sekunden_im_Zeitraum - Sekunden_system_ist_ausgefallen / Gesamt_Sekunden_im_Zeitraum

Prozentuale Verfügbarkeit des Standorts = 2.592.000 s - 3.120 s / 2.592.000 s

Prozentuale Verfügbarkeit der Website = 99,8795

Deine Website ist zu 99,8795% verfügbar.

Die Neuner

Oft hört man, dass die Verfügbarkeit als "Neuner" bezeichnet wird. Dies ist eine Kurzform für die Angabe der hohen-Verfügbarkeitsrate. Tabelle 1-1 veranschaulicht, was das bedeutet. Eine Anwendung mit einer Verfügbarkeit von "2 Neunen" muss 99% der Zeit verfügbar sein. Das bedeutet, dass sie in einem typischen Monat 432 Minuten lang ausfallen kann und trotzdem das Ziel von 99 % Verfügbarkeit erreicht. Im Gegensatz dazu muss eine Anwendung mit "4 Neunen" 99,99 % der Zeit verfügbar sein, was bedeutet, dass sie in einem typischen Monat nur vier Minuten ausfallen kann.

Tabelle 1-1. Die Neuner
Neuner Prozentsatz Monatlicher Ausfall
2 Neunen 99% 432 Minuten
3 Neunen 99.9% 43 Minuten
4 Neunen 99.99% 4 Minuten
5 Neunen 99.999% 26 Sekunden
6 Neunen 99.9999% 2,6 Sekunden

Im vorangegangenen Beispiel sehen wir, dass die Website die 3 Neunen knapp verfehlt hat (99,8795% im Vergleich zu 99,9%). Bei einer Website, die eine Verfügbarkeit von 5 Neunen aufweist, darf es nur 26 Sekunden Ausfallzeit pro Monat geben.

Was ist eine angemessene Verfügbarkeitszahl, um dein System als hochverfügbar zu betrachten? Es ist unmöglich, diese Frage pauschal zu beantworten, denn sie hängt stark von deiner Website, deinen Kundenerwartungen, deinen Geschäftsanforderungen und deinen Geschäftserwartungen ab. Du musst für dich selbst herausfinden, welche Zahl für dein Unternehmen erforderlich ist.

Für einfache Webanwendungen wird oft eine Verfügbarkeit von 3 Neunen als akzeptabel angesehen. Tabelle 1-1 zeigt, dass dies 43 Minuten Ausfallzeit pro Monat bedeutet.

Geplante Ausfälle sind immer noch Ausfälle

Lass dir nicht einreden, dass deine Website hochverfügbar ist, wenn sie es nicht ist. Geplante und regelmäßige Wartungsarbeiten, bei denen deine Anwendung nicht verfügbar ist, zählen trotzdem zur Verfügbarkeit.

Hier ist ein Kommentar, den ich oft höre: "Unsere Anwendung schlägt nie fehl. Das liegt daran, dass wir regelmäßig eine Systemwartung durchführen. Indem wir wöchentlich zweistündige Wartungsfenster einplanen und die Wartung während dieser Fenster durchführen, halten wir unsere Verfügbarkeit hoch."

Hält diese Gruppe die Verfügbarkeit ihrer Anwendung hoch?

Lass es uns herausfinden:

Prozentuale Verfügbarkeit des Standorts = Gesamt_Stunden_im_Zeitraum - Stunden_system_ist_ausgefallen / Gesamt_Stunden_im_Zeitraum

Stunden_in_der_Woche = 7 Tage × 24 Stunden = 168 Stunden

hours_unavailable_each_week = 2 Stunden

Standortverfügbarkeit (keine Ausfälle) = 168 Stunden - 2 Stunden / 168 Stunden = 98,8%

Verfügbarkeit der Website (keine Ausfälle) = 98,8%

Ohne einen einzigen Ausfall der Anwendung kann diese Organisation bestenfalls eine Verfügbarkeit von 98,8 % erreichen. Das liegt sogar unter der Verfügbarkeit von 2 Neunen (98,8 % gegenüber 99 %).

Geplante Wartungsarbeiten schmerzen fast so sehr wie ungeplante Ausfälle. Wenn dein Kunde darauf angewiesen ist, dass deine Anwendung verfügbar ist, und sie ist es nicht, hat dein Kunde eine negative Erfahrung gemacht. Dabei spielt es keine Rolle, ob du den Ausfall geplant hast oder nicht.

Verfügbarkeit in Zahlen

Die Messung der Verfügbarkeit ist wichtig, um dein System jetzt und in Zukunft hochverfügbar zu halten. In diesem Abschnitt wurde ein gängiger Mechanismus zur Messung der Verfügbarkeit erörtert und es wurden einige Richtlinien dafür aufgestellt, was als angemessene Verfügbarkeit gilt.

Verbessere deine Verfügbarkeit, wenn sie nachlässt

Deine Anwendung ist betriebsbereit und online. Deine Systeme sind in Betrieb und dein Team arbeitet effizient. Alles scheint gut zu laufen. Die Besucherzahlen nehmen stetig zu, und deine Verkaufsorganisation ist sehr zufrieden. Alles ist gut.

Dann gibt es einen kleinen Ausrutscher. Dein System hat einen unvorhergesehenen Ausfall. Aber das ist in Ordnung, denn deine Verfügbarkeit war bis jetzt fantastisch. Ein kleiner Ausfall ist keine große Sache. Dein Datenverkehr nimmt weiter zu. Alle nehmen es mit einem Achselzucken hin - es war nur "eine dieser Sachen".

Dann passiert es wieder - ein weiterer Ausfall. Ups. Nun, okay. Insgesamt geht es uns immer noch gut. Kein Grund zur Panik; es war einfach nur "eines dieser Dinge".

Dann ein weiterer Stromausfall...

Jetzt ist dein Geschäftsführer ein wenig besorgt. Die Kunden beginnen zu fragen, was los ist. Dein Verkaufsteam macht sich langsam Sorgen.

Dann ein weiterer Stromausfall...

Plötzlich wird dein einst stabiles und betriebsbereites System immer instabiler; deine Ausfälle bekommen immer mehr Aufmerksamkeit.

Jetzt hast du echte Probleme.

Was ist passiert? Dein System hochverfügbar zu halten, ist eine schwierige Aufgabe. Was tust du, wenn die Verfügbarkeit nachlässt? Was tust du, wenn die Verfügbarkeit deiner Anwendung gesunken ist oder zu sinken beginnt und du sie verbessern musst, um deine Kunden zufrieden zu stellen ?

Wenn du weißt, was du tun kannst, wenn deine Verfügbarkeit nachlässt, kannst du verhindern, dass du in einen Teufelskreis von Problemen gerätst. Was kannst du tun, damit deine Verfügbarkeit nicht nachlässt? Einige wichtige Dinge sind:

  • Messe und verfolge deine aktuelle Verfügbarkeit

  • Automatisiere deine manuellen Prozesse

  • Automatisiere deine Einsatzprozesse

  • Verwalte und verfolge alle Konfigurationen in einem Verwaltungssystem

  • Erlaubt schnelle Änderungen und Experimente, mit einer einfachen Rollback-Funktion, falls ein Problem auftritt

  • Strebe danach, deine Anwendungen und Systeme kontinuierlich zu verbessern

  • Behalte die Verfügbarkeit im Auge, wenn sich deine Anwendung verändert und wächst

In den folgenden Abschnitten werden diese wichtigen Schritte näher erläutert.

Messe und verfolge deine aktuelle Verfügbarkeit

Um zu verstehen, wie es um deine Verfügbarkeit bestellt ist, musst du zunächst messen, wie hoch deine aktuelle Verfügbarkeit ist. Wenn du verfolgst, wann deine Anwendung verfügbar ist und wann nicht, erhältst du einen Prozentsatz der Verfügbarkeit, der dir zeigt, wie du über einen bestimmten Zeitraum hinweg abschneidest. Daran kannst du erkennen, ob sich deine Verfügbarkeit verbessert oder verschlechtert.

Du solltest deinen Verfügbarkeitsanteil kontinuierlich überwachen und die Ergebnisse regelmäßig melden. Außerdem solltest du wichtige Ereignisse in deiner Anwendung überlagern, z. B. wann du Systemänderungen und -verbesserungen durchgeführt hast. So kannst du sehen, ob es im Laufe der Zeit eine Korrelation zwischen Systemereignissen und Verfügbarkeitsproblemen gibt. Das kann dir helfen, Risiken für deine Verfügbarkeit zu erkennen.

Als Nächstes musst du dir darüber im Klaren sein, wie deine Anwendung unter dem Gesichtspunkt der Verfügbarkeit funktionieren soll. Ein Werkzeug, das dir bei der Verwaltung der Anwendungsverfügbarkeit helfen kann, sind Service-Tiers. Dabei handelt es sich um eine Kennzeichnung der Dienste, die angibt, wie wichtig ein Dienst für den Betrieb deines Unternehmens ist. Die Verwendung von Service-Tiers ermöglicht es dir und deinen Teams, zwischen geschäftskritischen Diensten und solchen, die zwar wertvoll, aber nicht unbedingt notwendig sind, zu unterscheiden. In Kapitel 7 gehen wir näher auf die Service-Tiers ein.

Schließlich erstellst du eine Risikomatrix und pflegst sie unter . Mit diesem Werkzeug kannst du dir einen Überblick über die technischen Schulden und die damit verbundenen Risiken in deiner Anwendung verschaffen. Risikomatrizen werden in Kapitel 9 ausführlicher behandelt.

Da du nun eine Möglichkeit hast, deine Verfügbarkeit zu verfolgen und dein Risiko zu identifizieren und zu steuern, solltest du deine Risikomanagementpläne regelmäßig überprüfen.

Außerdem solltest du Pläne zur Risikominderung erstellen und umsetzen, um die Risiken deiner Anwendung zu verringern. So erhältst du eine Reihe konkreter Aufgaben, die du und deine Entwicklungsteams umsetzen können, um die risikoreichsten Teile deiner Anwendung zu bewältigen. Dies wird in Kapitel 9 ausführlich behandelt.

Automatisiere deine manuellen Prozesse

Um die hohe Verfügbarkeit von zu gewährleisten, musst du unbekannte Ergebnisse und Variablen entfernen. Die Durchführung von manuellen Operationen ist eine gängige Methode, um variable Ergebnisse und/oder unbekannte Ergebnisse in dein System einzufügen.

Du solltest niemals einen manuellen Vorgang auf einem Produktionssystem durchführen.

Wenn du eine Änderung an deinem System vornimmst, kann diese Änderung dein System verbessern oder es gefährden. Wenn du nur wiederholbare Aufgaben verwendest, hast du die folgenden Vorteile:

  • Die Fähigkeit, eine Aufgabe zu testen, bevor sie umgesetzt wird. Zu testen, was passiert, wenn du eine bestimmte Änderung vornimmst, ist entscheidend, um Fehler zu vermeiden, die zu Ausfällen führen.

  • Die Möglichkeit, die Aufgabe so zu optimieren, dass sie genau das tut, was du willst. So kannst du Verbesserungen an der geplanten Änderung vornehmen, bevor du sie tatsächlich vornimmst.

  • Die Möglichkeit, die Aufgabe von einer dritten Partei überprüfen zu lassen. Das erhöht die Wahrscheinlichkeit, dass die Aufgabe keine unerwarteten Nebenwirkungen hat.

  • Die Möglichkeit, die Aufgabe unter Versionskontrolle zu stellen. Mit Versionskontrollsystemen kannst du bestimmen, wann, von wem und aus welchen Gründen die Aufgabe geändert wird.

  • Die Möglichkeit, die Aufgabe auf verwandte Ressourcen anzuwenden. Eine Änderung an einem einzelnen Server, die die Funktionsweise dieses Servers verbessert, ist großartig. Die Möglichkeit, dieselbe Änderung konsequent auf alle betroffenen Server anzuwenden, macht die Aufgabe noch nützlicher.

  • Die Fähigkeit, alle zusammenhängenden Ressourcen einheitlich handeln zu lassen. Wenn du ständig "einmalige" Änderungen an Ressourcen wie z. B. Servern vornimmst, werden die Server anfangen zu driften und sich unterschiedlich verhalten. Das macht es schwierig, problematische Server zu diagnostizieren, weil es keine Basiserwartungen für den Betrieb gibt, die du zum Vergleich heranziehen kannst.

  • Die Fähigkeit, wiederholbare Aufgaben durchzuführen. Wiederholbare Aufgaben sind prüfbare Aufgaben. Prüfbare Aufgaben sind Aufgaben, die du später auf ihre positiven oder negativen Auswirkungen auf das System als Ganzes analysieren kannst.

Es gibt viele Systeme, bei denen niemand Zugang zur Produktionsumgebung hat. Punkt. Der einzige Zugang zur Produktion erfolgt über automatisierte Prozesse und Verfahren. Die Eigentümer dieser Systeme sperren ihre Umgebungen aus den oben genannten Gründen ab.

Zusammenfassend lässt sich sagen: Wenn du eine Aufgabe nicht wiederholen kannst, ist es keine nützliche Aufgabe. Es gibt viele Bereiche, in denen die Wiederholbarkeit von Änderungen dazu beiträgt, dein System und deine Anwendung stabil zu halten. Dazu gehören Änderungen an der Serverkonfiguration, Leistungsoptimierungen und -anpassungen, der Neustart von Servern, der Neustart von Aufträgen und Aufgaben, das Ändern von Routing-Regeln sowie das Aktualisieren und Bereitstellen von Softwarepaketen. Im Folgenden sehen wir uns einige Beispiele für wiederholbare Aufgaben an, die du durchführen solltest.

Automatisierte Einsätze

Durch die Automatisierung von Deployments garantierst du, dass Änderungen im gesamten System einheitlich angewendet werden und dass du ähnliche Änderungen später mit bekannten Ergebnissen anwenden kannst. Außerdem werden Rollbacks zu bekannten guten Zuständen mit automatisierten Deployment-Systemen zuverlässiger.

Konfigurationsmanagement

Anstatt eine Konfigurationsvariable im Kernel eines Servers zu verändern, solltest du einen Prozess verwenden, um die Änderungen automatisch durchzuführen.

Schreibe zumindest ein Skript, das die Änderung vornimmt, und checke dieses Skript dann in dein Software Change Management System ein. So kannst du dieselbe Änderung an allen Servern in deinem System einheitlich vornehmen. Wenn du einen neuen Server zu deinem System hinzufügen oder einen alten ersetzen musst, erhöht sich die Wahrscheinlichkeit, dass du den neuen Server sicher und mit minimalen Auswirkungen zu deinem System hinzufügen kannst, wenn du eine bekannte Konfiguration hast, die du anwenden kannst.

Noch besser - und im Einklang mit den bewährten Methoden des modernen Konfigurationsmanagements - ist mit dem Konzept "Infrastructure as Code". Infrastructure as Code bedeutet, dass du deine Infrastruktur in einer standardisierten, maschinenlesbaren Spezifikation beschreibst und diese Spezifikation dann an ein Infrastrukturwerkzeug weitergibst, das deine Infrastruktur und deine Konfiguration entsprechend der Spezifikation erstellt und/oder aktualisiert. Mit Tools wie Puppet und Chef lässt sich dieser Prozess einfacher verwalten.

Dann nimmst du diese Spezifikation und checkst sie in dein Versionskontrollsystem ein, damit Änderungen an der Spezifikation genauso verfolgt werden können wie Änderungen am Code. Wenn du die Spezifikation durch das Infrastruktur-Tool laufen lässt, wird deine Live-Infrastruktur bei jeder Änderung an der Spezifikation aktualisiert.

Wenn jemand eine Änderung an der Infrastruktur oder ihrer Konfiguration vornehmen muss, muss er die Änderung an der Spezifikation vornehmen, die Änderung in die Versionskontrolle einchecken und dann die Änderung über das Infrastruktur-Tool "verteilen", um deine Live-Infrastruktur entsprechend zu aktualisieren. Auf diese Weise kannst du:

  1. Stelle sicher, dass alle Komponenten der Infrastruktur eine einheitliche, bekannte und stabile Konfiguration haben.

  2. Verfolge alle Änderungen an der Infrastruktur, damit sie bei Bedarf rückgängig gemacht werden können, oder hilf bei der Korrelation mit Systemereignissen und Ausfällen.

  3. Erlaube einen Peer-Review-Prozess, ähnlich wie bei einer Codeüberprüfung, um sicherzustellen, dass Änderungen an deiner Infrastruktur korrekt und angemessen sind.

  4. Erlaubt das Erstellen von doppelten Umgebungen, um Tests, Staging und Entwicklung mit einer Umgebung zu unterstützen, die mit der Produktionsumgebung identisch ist.

Diese Art von Prozess gilt für alle Infrastrukturkomponenten. Dazu gehören nicht nur Server und ihre Betriebssystemkonfiguration, sondern auch andere Cloud-Komponenten, VPCs, Load Balancer, Switches, Router, Netzwerkkomponenten und die Überwachung von Anwendungen und Systemen.

Damit Infrastructure as Code Management sinnvoll ist, muss es bei allen Systemänderungen eingesetzt werden, und zwar ständig. Es ist niemals akzeptabel, das Infrastrukturmanagementsystem zu umgehen, um eine Änderung vorzunehmen, egal unter welchen Umständen. Niemals.

Du würdest dich wundern, wie oft ich eine E-Mail mit einem Betriebsupdate erhalten habe, in der stand: "Wir hatten gestern Abend ein Problem mit einem unserer Server. Wir sind an die Grenze der maximalen Anzahl offener Dateien gestoßen, die der Server verarbeiten kann. Deshalb habe ich die Kernelvariable angepasst und die maximale Anzahl der offenen Dateien erhöht, so dass der Server wieder funktioniert."

Das heißt, sie funktioniert korrekt, bis jemand die Änderung versehentlich überschreibt, weil die Änderung nicht dokumentiert wurde. Oder bis einer der anderen Server, auf denen die Anwendung läuft, das gleiche Problem hat, aber diese Änderung nicht vorgenommen wurde .

Oder jemand nimmt eine andere Änderung vor, die die Anwendung kaputt macht, weil sie nicht mit der undokumentierten Änderung übereinstimmt, die du gerade vorgenommen hast.

Konsistenz, Wiederholbarkeit und unbeirrbare Liebe zum Detail sind entscheidend dafür, dass ein Konfigurationsmanagementprozess funktioniert. Und ein standardisierter und wiederholbarer Konfigurationsmanagementprozess, wie wir ihn hier beschreiben, ist entscheidend dafür, dass dein skaliertes System hochverfügbar bleibt.

Veränderungsexperimente und hochfrequente Veränderungen

Ein weiterer Vorteil eines hochgradig wiederholbaren, automatisierten Prozesses für Änderungen und Upgrades an deinem System ist, dass du mit Änderungen experimentieren kannst. Angenommen, du möchtest eine Konfigurationsänderung an deinen Servern vornehmen, von der du glaubst, dass sie die Leistung deiner Anwendung verbessern wird. Mit einem automatisierten Änderungsmanagementprozess kannst du Folgendes tun:

  • Dokumentiere deinen Änderungsvorschlag.

  • Überprüfe die Änderung mit Personen, die sich auskennen und Vorschläge und Verbesserungen machen können.

  • Teste die Änderung auf Servern in einer Test- oder Staging-Umgebung.

  • Setze deine Änderungen schnell und einfach um.

  • Überprüfe die Ergebnisse schnell. Wenn die Änderung nicht zu den gewünschten Ergebnissen geführt hat, kannst du schnell zu einem bekannten guten Zustand zurückkehren.

Der Schlüssel zur Umsetzung dieses Prozesses ist ein automatisierter Änderungsprozess mit Rollback-Funktionen und die Möglichkeit, kleine Änderungen an deinem System einfach und häufig vorzunehmen.1 Ersteres ermöglicht es dir, Änderungen konsequent durchzuführen; letzteres erlaubt es dir, zu experimentieren und fehlgeschlagene Experimente rückgängig zu machen, ohne dass dies Auswirkungen auf deine Kunden hat.

Automatisierte Prüfung der Zulässigkeit von Änderungen

Durch einen automatisierten Änderungs- und Bereitstellungsprozess,2 kannst du eine automatische Prüfung aller Änderungen durchführen. Du kannst eine Browsertest-Anwendung für Webanwendungen verwenden oder ein synthetisches Überwachungssystem einsetzen, um die Kundeninteraktion mit deiner Anwendung zu simulieren.

Wenn du bereit bist, eine Änderung in die Produktion zu übernehmen, kannst du dein Verteilungssystem die Änderung zunächst automatisch in eine Test- oder Staging-Umgebung übertragen lassen. Dann kannst du diese automatisierten Tests laufen lassen und überprüfen, ob die Änderungen deine Anwendung nicht beschädigt haben.

Wenn diese Tests erfolgreich sind, kannst du die Änderungen automatisch und auf konsistente Weise in deiner Produktionsumgebung einsetzen. Je nachdem, wie deine Tests aufgebaut sind, solltest du in der Lage sein, sie auch regelmäßig in deiner Produktionsumgebung laufen zu lassen, um sicherzustellen, dass keine Änderungen dort etwas kaputt machen.

Wenn du den gesamten Prozess automatisierst, kannst du dich darauf verlassen, dass eine Änderung keine negativen Auswirkungen auf deine Produktionssysteme haben wird.

Verbessere deine Systeme

Jetzt, wo du ein System zur Überwachung der Verfügbarkeit, eine Möglichkeit zur Verfolgung von Risiken und Abhilfemaßnahmen in deinem System und eine Möglichkeit zur einfachen und sicheren Anwendung konsistenter Änderungen an deinem System hast, kannst du dich auf die Verbesserung der Verfügbarkeit deiner Anwendung selbst konzentrieren.

Überprüfe regelmäßig deine Risikomatrix und deine Sanierungspläne. Mach die Überprüfung zum Teil deines Postmortem-Prozesses. Führt Projekte durch, die die in eurer Matrix identifizierten Risiken mindern sollen. Führe diese Änderungen automatisiert und sicher durch, indem du die zuvor besprochenen Sicherheitstests anwendest. Überprüfe, wie sich deine Verfügbarkeit durch die Maßnahmen verbessert hat. Setze den Prozess fort, bis deine Verfügbarkeit das Niveau erreicht hat, das du willst und brauchst.

Behalte den Überblick über die Verfügbarkeit in deiner sich verändernden und wachsenden Anwendung

Wenn dein System wächst, musst du einen immer größeren Datenverkehr und höhere Datenanforderungen bewältigen. Ein Großteil der Inhalte in diesem Buch soll dir dabei helfen, Probleme mit der Anwendungsverfügbarkeit und Skalierbarkeit zu lösen, wenn deine Anwendung wächst und sich verändert. Vor allem der Umgang mit Fehlern bei der Skalierung wird in Kapitel 2 behandelt. Service Tiers, die du verwenden kannst, um die wichtigsten Dienste zu identifizieren, die sich auf die Verfügbarkeit auswirken, werden in Kapitel 7 behandelt. Die Verwaltung von Service Level Agreements (SLAs) wird in Kapitel 8 behandelt.

In der Regel wird sich deine Anwendung ständig ändern. Daher müssen sich auch deine Risiken, Abhilfemaßnahmen, Notfälle und Wiederherstellungspläne ständig ändern.

Wenn du weißt, was du tun kannst, wenn deine Verfügbarkeit nachlässt, kannst du vermeiden, in einen Teufelskreis von Problemen zu geraten.

Fünf Schwerpunkte zur Verbesserung der Anwendungsverfügbarkeit

Die Entwicklung einer skalierbaren Anwendung mit hoher Verfügbarkeit ist nicht einfach und kommt nicht von selbst. Probleme können auf unerwartete Weise auftauchen und dazu führen, dass deine gut funktionierende Anwendung für alle oder einige deiner Kunden nicht mehr funktioniert.

Diese Verfügbarkeitsprobleme entstehen oft dort, wo du es am wenigsten erwartest, und einige der schwerwiegendsten Verfügbarkeitsprobleme können aus extrem harmlosen Quellen stammen.

Niemand kann vorhersehen, woher die Probleme kommen werden, und kein noch so großer Test wird alle Probleme finden. Viele davon sind systemische Probleme, nicht nur Code-Probleme.

Um diese Verfügbarkeitsprobleme zu finden, müssen wir einen Schritt zurücktreten und einen systemischen Blick auf deine Anwendung und ihre Funktionsweise werfen. Hier sind fünf Dinge, auf die du beim Aufbau eines Systems achten kannst und solltest, um sicherzustellen, dass die Verfügbarkeit auch bei steigender Nutzung hoch bleibt:

  • Bauen mit Blick auf das Scheitern

  • Immer an die Skalierung denken

  • Risiko abmildern

  • Verfügbarkeit überwachen

  • Reagiere auf Verfügbarkeitsprobleme in einer vorhersehbaren und definierten Weise

Schauen wir uns jedes dieser Elemente einzeln an.

Schwerpunkt Nr. 1: Bauen mit dem Ziel des Scheiterns

Wie Werner Vogels, CTO von Amazon, sagt: "Alles schlägt ständig fehl." Plane ein, dass deine Anwendungen und Dienste fehlschlagen. Es wird passieren. Und jetzt geh damit um.

Angenommen, deine Anwendung schlägt fehl, wie wird sie fehlschlagen? Wenn du dein System aufbaust, solltest du bei allen Aspekten deines Systementwurfs und -aufbaus die Verfügbarkeit berücksichtigen.

Entwurf

Welche Designkonstrukte und -muster hast du in Betracht gezogen oder verwendest du, um die Verfügbarkeit deiner Software zu verbessern?

Durch die Verwendung von Designkonstrukten und -mustern, wie z. B. einfache Fehlerabfangung tief in deiner Anwendung, Wiederholungslogik und Unterbrecher, kannst du Fehler abfangen, wenn sie die kleinste verfügbare Teilmenge der Funktionalität betreffen. So kannst du das Ausmaß eines Problems eingrenzen und dafür sorgen, dass deine Anwendung auch dann noch nützliche Funktionen bietet, wenn ein Teil der Anwendung fehlschlägt.

Abhängigkeiten

Was tust du, wenn eine Komponente, von der du abhängig bist, fehlschlägt? Wie versuchst du es erneut? Was tust du, wenn das Problem ein nicht behebbarer (harter) Ausfall ist und nicht ein behebbarer (weicher) Ausfall?

Circuit-Breaker-Muster sind besonders nützlich für den Umgang mit Abhängigkeitsfehlern, weil sie die Auswirkungen eines Abhängigkeitsfehlers auf dein System verringern können. Ohne einen Circuit-Breaker kann die Leistung deiner Anwendung aufgrund eines Abhängigkeitsfehlers sinken (z. B. weil eine unzumutbar lange Zeitspanne benötigt wird, um den Fehler zu erkennen). Mit einem Circuit-Breaker kannst du "aufgeben" und eine Abhängigkeit so lange nicht mehr nutzen, bis du sicher bist, dass die Abhängigkeit wiederhergestellt ist.

Kunden

Was tust du, wenn sich eine Komponente, die ein Kunde deines Systems ist, schlecht verhält? Kannst du eine übermäßige Belastung deines Systems bewältigen? Kannst du den übermäßigen Datenverkehr drosseln? Kannst du mit Datenmüll umgehen, der übertragen wird? Was ist mit übermäßigen Daten?

Manchmal können Denial-of-Service-Angriffe aus "freundlichen" Quellen kommen. Zum Beispiel kann ein Kunde deiner Anwendung einen plötzlichen Anstieg der Aktivitäten feststellen, der einen erheblichen Anstieg des Anfragevolumens an deine Anwendung erfordert. Oder ein Fehler in der Anwendung deines Kunden kann dazu führen, dass er deine Anwendung in einem unannehmbar hohen Maß aufruft. Was tust du, wenn das passiert? Bringt der plötzliche Anstieg des Datenverkehrs deine Anwendung zum Erliegen? Oder kannst du das Problem erkennen und die Anfragerate drosseln, um die Auswirkungen auf deine Anwendung zu begrenzen oder zu beseitigen?

Fokus #2: Immer an die Skalierung denken

Nur weil deine Anwendung jetzt funktioniert, heißt das nicht, dass sie auch morgen noch funktioniert. Die meisten Webanwendungen haben ein steigendes Verkehrsaufkommen. Eine Website, die heute eine bestimmte Menge an Datenverkehr generiert, könnte schon bald deutlich mehr Datenverkehr generieren, als du erwartest. Wenn du dein System entwickelst, baue es nicht für den heutigen, sondern für den morgigen Datenverkehr.

Konkret könnte das bedeuten:

  • Architekt in der Lage, die Größe und Kapazität deiner Datenbanken zu erhöhen.

  • Überlege dir, welche logischen Grenzen für die Skalierung deiner Daten bestehen. Was passiert, wenn deine Datenbank an die Grenzen ihrer Leistungsfähigkeit stößt? Erkenne diese Grenzen und beseitige sie, bevor deine Nutzung sie erreicht.

  • Baue deine Anwendung so auf, dass du problemlos zusätzliche Anwendungsserver hinzufügen kannst. Das bedeutet oft, dass du darauf achten musst, wo und wie der Status verwaltet wird und wie der Datenverkehr weitergeleitet wird.

  • Leite den statischen Datenverkehr an Offline-Anbieter um. So kann dein System nur den dynamischen Datenverkehr verarbeiten, für den es ausgelegt ist. Der Einsatz externer Content Delivery Networks (CDNs) kann nicht nur den Datenverkehr reduzieren, den dein Netzwerk bewältigen muss, sondern auch die Größenvorteile nutzen, die CDNs bieten, um statische Inhalte schneller zu deinen Kunden zu bringen.

  • Überlege, ob bestimmte dynamische Inhalte tatsächlich statisch erzeugt werden können. Oft sind Inhalte, die dynamisch erscheinen, in Wirklichkeit statisch und die Skalierbarkeit deiner Anwendung kann erhöht werden, indem du diese Inhalte statisch machst. Diese "dynamischen Daten, die statisch sein können", sind manchmal dort versteckt, wo du sie nicht erwartest.

Schwerpunkt #3: Risiken mindern

Um ein System hochverfügbar zu halten , muss das Risiko aus dem System entfernt werden. Oft hätte die Ursache eines Systemausfalls als Risiko erkannt werden können, bevor der Ausfall tatsächlich eintrat. Die Identifizierung von Risiken ist eine wichtige Methode zur Erhöhung der Verfügbarkeit. Alle Systeme sind mit Risiken behaftet. Es besteht das Risiko, dass:

  • Ein Server wird abstürzen

  • Eine Datenbank wird beschädigt

  • Eine zurückgegebene Antwort wird falsch sein

  • Eine Netzwerkverbindung schlägt fehl

  • Eine neu eingesetzte Software wird fehlschlagen

Um ein System verfügbar zu halten, muss das Risiko beseitigt werden. Aber je komplizierter die Systeme werden, desto weniger ist das möglich. Um ein großes System verfügbar zu halten, musst du dir darüber im Klaren sein, welches Risiko du eingehst, wie viel Risiko akzeptabel ist und was du tun kannst, um dieses Risiko zu mindern.

Wir nennen das Risikomanagement. Wir werden in Kapitel 9 ausführlich über Risikomanagement sprechen. Risikomanagement ist das Herzstück beim Aufbau hochverfügbarer Systeme.

Ein Teil des Risikomanagements ist die Risikominderung. Risikominderung bedeutet zu wissen, was zu tun ist, wenn ein Problem auftritt, um die Auswirkungen des Problems so weit wie möglich zu reduzieren. Bei der Risikominderung geht es darum, sicherzustellen, dass deine Anwendung so gut und so vollständig wie möglich funktioniert, auch wenn Dienste und Ressourcen fehlschlagen. Bei der Risikominderung geht es darum, sich Gedanken darüber zu machen, was schiefgehen kann, und schon jetzt einen Plan aufzustellen, damit du in der Lage bist, mit der Situation umzugehen, wenn sie tatsächlich eintritt.

Die vorangegangene Seite ist ein Beispiel für Risikominderung; der Prozess der Identifizierung des Risikos, der Festlegung von Maßnahmen und der Umsetzung dieser Maßnahmen ist das Risikomanagement.

Dieser Prozess deckt oft unbekannte Probleme in deiner Anwendung auf, die du sofort beheben willst, anstatt zu warten, bis sie auftreten. Außerdem können Prozesse und Verfahren zur Behandlung bekannter Fehlermodi entwickelt werden, sodass die Kosten eines Fehlers in Bezug auf Dauer oder Schweregrad reduziert werden.

Verfügbarkeit und Risikomanagement gehen Hand in Hand. Beim Aufbau eines hochverfügbaren Systems geht es vor allem um Risikomanagement.

Fokus #4: Verfügbarkeit überwachen

Du kannst nicht wissen, ob es ein Problem in deiner Anwendung gibt, wenn du es nicht sehen kannst. Achte darauf, dass deine Anwendung richtig instrumentiert ist, damit du sehen kannst, wie sie sich aus externer Sicht und durch interne Überwachung verhält.

Die richtige Überwachung hängt von den Besonderheiten deiner Anwendung und deinen Bedürfnissen ab, aber in der Regel umfasst sie einige der folgenden Funktionen:

Server Überwachung

Um den Zustand deiner Server zu überwachen und sicherzustellen, dass sie weiterhin effizient arbeiten.

Überwachung von Konfigurationsänderungen

Du kannst deine Systemkonfiguration überwachen und feststellen, ob und wann sich Änderungen an deiner Infrastruktur auf deine Anwendung auswirken.

Überwachung der Anwendungsleistung

Du kannst in deine Anwendung und deine Dienste hineinschauen, um sicherzustellen, dass sie wie erwartet funktionieren.

Synthetische Tests

Um in Echtzeit zu prüfen, wie deine Anwendung aus der Perspektive deiner Nutzer/innen funktioniert, um Probleme zu erkennen, bevor sie von den Kunden tatsächlich wahrgenommen werden.

Alerting

Das zuständige Personal zu informieren, wenn ein Problem auftritt, damit es schnell und effizient gelöst werden kann und die Auswirkungen auf deine Kunden minimiert werden.

Es gibt viele gute Überwachungssysteme, sowohl kostenlose als auch kostenpflichtige Dienste. Ich persönlich empfehle New Relic. Es bietet alle oben genannten Überwachungs- und Alarmierungsfunktionen. Als Software-as-a-Service (SaaS)-Angebot kann es deine Überwachungsbedürfnisse in so ziemlich jeder Größenordnung unterstützen, die deine Anwendung benötigt.

Nachdem du mit der Überwachung deiner Anwendung und Dienste begonnen hast, solltest du nach Trends in deiner Leistung suchen. Wenn du die Trends erkannt hast, kannst du nach Ausreißern suchen und sie als potenzielle Verfügbarkeitsprobleme behandeln. Du kannst diese Ausreißer nutzen, indem du dir von deinen Überwachungs-Tools eine Warnung schicken lässt, wenn sie erkannt werden, bevor deine Anwendung fehlschlägt. Außerdem kannst du verfolgen, wie dein System wächst, und sicherstellen, dass dein Skalierbarkeitsplan weiterhin funktioniert.

Lege interne, private Betriebsziele für die Kommunikation zwischen den Diensten fest und überwache sie kontinuierlich. Wenn du ein Leistungs- oder Verfügbarkeitsproblem feststellst, kannst du schnell diagnostizieren, welcher Dienst oder welches System dafür verantwortlich ist, und das Problem beheben. Außerdem kannst du "Hot Spots" erkennen - Bereiche, in denen deine Leistung nicht so gut ist, wie sie sein könnte - und Entwicklungspläne aufstellen, um diese Probleme zu lösen.

Schwerpunkt Nr. 5: Reagiere auf Verfügbarkeitsprobleme auf vorhersehbare und definierte Weise

Überwachungssysteme sind nutzlos, wenn du nicht darauf vorbereitet bist, auf die auftretenden Probleme zu reagieren. Das bedeutet, dass du benachrichtigt wirst, wenn Probleme auftreten, damit du Maßnahmen ergreifen kannst. Außerdem solltest du Prozesse und Verfahren einführen, die dein Team befolgen kann, um Probleme zu diagnostizieren und häufige Fehlerszenarien einfach zu beheben.

Wenn zum Beispiel ein Dienst nicht mehr reagiert, kannst du eine Reihe von Maßnahmen ergreifen, um den Dienst wieder ansprechbar zu machen. Dazu gehören z. B. die Durchführung eines Tests, um das Problem zu diagnostizieren, der Neustart eines Daemons, der dafür bekannt ist, dass der Dienst nicht mehr reagiert, oder der Neustart eines Servers, wenn alles andere fehlschlägt. Wenn du Standardprozesse für häufige Fehlerszenarien hast, wird die Zeit, in der dein System nicht verfügbar ist, verkürzt. Außerdem können diese Prozesse deinen Technikteams nützliche Diagnoseinformationen liefern, die ihnen helfen, die Ursache für häufige Probleme zu finden.

Wenn ein Alarm für einen Dienst ausgelöst wird, müssen die Eigentümer dieses Dienstes als Erste benachrichtigt werden. Schließlich sind sie für die Behebung von Problemen mit ihrem Dienst verantwortlich. Aber auch andere Teams, die eng mit dem gestörten Dienst verbunden und von ihm abhängig sind, möchten möglicherweise über Probleme informiert werden, wenn sie auftreten. Wenn ein Team zum Beispiel einen bestimmten Dienst nutzt, möchte es vielleicht wissen, wenn dieser Dienst fehlschlägt, damit es seine Systeme während des Ausfalls des abhängigen Dienstes aktiv halten kann.

Diese Standardprozesse und -verfahren sollten Teil eines Online-Support-Handbuchs sein, das allen Teammitgliedern, die für den Bereitschaftsdienst zuständig sind, zur Verfügung steht. Diese Support-Artefakte sollten auch Kontaktlisten für die Eigentümer der zugehörigen Dienste und Systeme enthalten sowie Kontakte, die angerufen werden können, um das Problem zu eskalieren, wenn eine einfache Lösung nicht möglich ist. Es gibt SaaS-Anwendungen, mit denen die Verwaltung und Versionierung dieser Supportdokumente automatisiert werden kann und die bei Ereignissen auf Abruf zur Verfügung stehen.

All diese Prozesse, Verfahren und Support-Handbücher sollten im Voraus vorbereitet werden, damit deine Bereitschaftskräfte bei einem Ausfall genau wissen, was sie unter verschiedenen Umständen tun müssen, um den Betrieb schnell wiederherzustellen. Diese Prozesse und Verfahren sind besonders nützlich, weil Ausfälle oft zu ungünstigen Zeiten auftreten, z. B. mitten in der Nacht oder am Wochenende - Zeiten, in denen dein Bereitschaftsteam vielleicht nicht mit höchster geistiger Effizienz arbeitet. Diese Empfehlungen werden deinem Team helfen, intelligentere und sicherere Schritte zu unternehmen, um dein System wieder betriebsbereit zu machen.

Vorbereitet sein

Niemand kann voraussehen, wo und wann Verfügbarkeitsprobleme auftreten werden. Aber du kannst davon ausgehen, dass sie auftreten werden, vor allem, wenn dein System auf größere Kundenanforderungen und komplexere Anwendungen skaliert. Der beste Weg, um die Wahrscheinlichkeit und Schwere von Problemen zu verringern, ist es, sich im Voraus auf Verfügbarkeitsprobleme vorzubereiten. Die Informationen in diesem Kapitel, einschließlich der fünf Schwerpunkte, bieten eine solide Strategie, um deine Anwendungen hochverfügbar zu halten.

1 Laut Werner Vogels, CTO von Amazon, hat Amazon im Jahr 2014 50 Millionen Deployments auf einzelnen Hosts durchgeführt. Das ist etwa eine pro Sekunde.

2 Das kann, muss aber nicht, ein moderner kontinuierlicher Integrations- und Bereitstellungsprozess(CI/CD) sein.

Get Architecting for Scale, 2. Auflage now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial