deploy: 1cbe601

de/index.html

@@ -33,8 +33,8 @@ <h1 id=prinzipien-des-chaos-engineerings>PRINZIPIEN DES CHAOS ENGINEERINGS</h1>
 <p>Letzte Aktualisierung: März 2019</p>
 <p><em>Chaos Engineering führt Experimente auf einem System durch, um Vertrauen in das System aufzubauen auch unter widrigen Umständen in der Produktivumgebung zu bestehen.</em></p>
 <p>Die Fortschritte in verteilten und hoch-skalierten Software-Systemen verändern die Spielregeln im Software Engineering. Die IT-Industrie übernimmt schnell Methoden, um die Flexibilität in der Software-Entwicklung oder die Geschwindigkeit von Deployments zu erhöhen. Aus diesen Vorteilen erwächst eine dringend zu beantwortende Frage: Wie sehr können wir dem System vertrauen, das wir in die Produktivumgebung eingespielt haben?</p>
-<p>Selbst wenn alle einzelnen Services in einem verteilten System ordnungsgemäß funktionieren kann die Kommunikation zwischen diesen Services unerwartete Ergebnisse haben. Diese unerwarteten Ergebnisse sowie seltene, aber nachteilige Vorfälle in der Produktivumgebung machen verteilte Systeme inhärent chaotisch.</p>
-<p>Wir müssen Schwachstellen finden, bevor sie zu systemweiten Fehlverhalten führen. Schwachstellen im System können zum Beispiel folgende Dinge sein: unzureichende Ersatzkonfigurationen wenn ein Service nicht erreichbar ist, zu viele wiederholte Aufrufversuche durch ungenau konfigurierte TimeOuts, Ausfälle durch zu hohen Traffic auf eine Abhängigkeit, sich ausweitende Systemfehler wenn ein Single Point of Failure abstürzt, o.ä. Wir müssen die Schwachstellen mit den größten Auswirkungen proaktiv angehen bevor sie zu Problemen für unsere Kunden auf der Produktivumgebung führen. Wir müssen einen Weg finden, das eingebaute Chaos verteilter Systeme zu kontrollieren, um die Vorteile von erhöhter Flexibilität und Geschwindigkeit einzufahren während wir gleichzeitig Vertrauen in unsere Produktions-Deployments haben obwohl sie eine hohe Komplexität darstellen.</p>
+<p>Selbst wenn alle einzelnen Dienste in einem verteilten System ordnungsgemäß funktionieren kann die Kommunikation zwischen diesen Diensten unerwartete Ergebnisse haben. Diese unerwarteten Ergebnisse sowie seltene, aber nachteilige Vorfälle in der Produktivumgebung machen verteilte Systeme inhärent chaotisch.</p>
+<p>Wir müssen Schwachstellen finden, bevor sie zu systemweiten Fehlverhalten führen. Schwachstellen im System können zum Beispiel folgende Dinge sein: unzureichende Ersatzkonfigurationen wenn ein Dienst nicht erreichbar ist, zu viele wiederholte Aufrufversuche durch ungenau konfigurierte TimeOuts, Ausfälle durch zu hohen Traffic auf eine Abhängigkeit, sich ausweitende Systemfehler wenn ein Single Point of Failure abstürzt, o.ä. Wir müssen die Schwachstellen mit den größten Auswirkungen proaktiv angehen bevor sie zu Problemen für unsere Kunden auf der Produktivumgebung führen. Wir müssen einen Weg finden, das eingebaute Chaos verteilter Systeme zu kontrollieren, um die Vorteile von erhöhter Flexibilität und Geschwindigkeit einzufahren während wir gleichzeitig Vertrauen in unsere Produktions-Deployments haben obwohl sie eine hohe Komplexität darstellen.</p>
 <p>Ein empirisches, systembasiertes Vorgehen adressiert das Chaos in hoch-skalierten verteilten Systemen und erhöht unser Vertrauen, dass diese Systeme realistischen Bedingungen Stand halten. Wir lernen das Verhalten von verteilten Systemen kennen, indem wir sie in kontrollierten Experimenten beobachten. Das ist <em>Chaos Engineering</em>.</p>
 <h2 id=chaos-in-der-praxis>CHAOS IN DER PRAXIS</h2>
 <p>Man kann Chaos Engineering als die Durchführung von Experimenten betrachten, um Schwachstellen im System zu finden; genauer geht es um Schwachstellen in großen verteilten Systemen. Die Experimente laufen in vier Schritten ab:</p>
@@ -51,7 +51,7 @@ <h3 id=formuliere-eine-hypothese-über-das-verhalten-im-stabilen-zustand>Formuli
 <p>Konzentriere dich besser auf messbaren System-Output als auf die inneren Eigenschaften des Systems. Messungen des System-Outputs über einen begrenzten Zeitraum können als Proxy für den stabilen Zustand angesehen werden. Interessante Metriken, die den stabilen Zustand repräsentieren können unter anderem sein: der Durchsatz des Gesamtsystems, die durchschnittliche Latenz, Fehlerraten, o.ä.
 Durch die Fokussierung auf die Verhaltensmuster des Systems während der Experimente verifiziert Chaos Engineering, dass das System funktioniert und validiert nicht wie es funktioniert.</p>
 <h3 id=variiere-die-simulation-von-echten-vorfällen-aus-dem-produktiven-betrieb>Variiere die Simulation von echten Vorfällen aus dem produktiven Betrieb</h3>
-<p>Chaos-Variablen repräsentieren echte Vorfälle aus dem produktiven Betrieb des Systems. Priorisiere die Vorfälle entweder nach ihrem Schadenspotential oder nach der geschätzten Häufigkeit. Betrachte Vorfälle, die verschiedene Ursachen haben wie solche, die durch Hardware-Fehler verursacht werden (z.B. kaputte Server) solche, die durch Software-Fehler verursacht werden (z.B. ungültig formatierte Service-Antworten) oder solche, die zwar keine Fehler, aber besondere Vorkommnisse darstellen (z.B. Lastspitzen). Jeder Vorfall, der das System aus dem stabilen Zustand bringen kann ist eine potentielle Variable in einem Chaos Experiment.</p>
+<p>Chaos-Variablen repräsentieren echte Vorfälle aus dem produktiven Betrieb des Systems. Priorisiere die Vorfälle entweder nach ihrem Schadenspotential oder nach der geschätzten Häufigkeit. Betrachte Vorfälle, die verschiedene Ursachen haben wie solche, die durch Hardware-Fehler verursacht werden (z.B. kaputte Server) solche, die durch Software-Fehler verursacht werden (z.B. ungültig formatierte Dienste-Antworten) oder solche, die zwar keine Fehler, aber besondere Vorkommnisse darstellen (z.B. Lastspitzen). Jeder Vorfall, der das System aus dem stabilen Zustand bringen kann ist eine potentielle Variable in einem Chaos Experiment.</p>
 <h3 id=mache-experimente-auf-der-produktivumgebung>Mache Experimente auf der Produktivumgebung</h3>
 <p>Systeme verhalten sich abhängig von Umgebung und Systemzugriffsmustern unterschiedlich. Da sich die Nutzungsmuster jederzeit ändern können ist eine Stichprobenentnahme tatsächlicher Zugriffe der einzige Weg den Zugriffspfad zuverlässig zu erfassen. Im Chaos Engineering werden Experimente bevorzugt direkt auf der Produktivumgebung durchgeführt, um zu garantieren, dass das System in realistischer Art und Weise ausgeführt wird und die Ergebnisse hohe Relevanz für das tatsächlich in der Produktivumgebung laufende System haben.</p>
 <h3 id=automatisiere-experimente-um-sie-kontinuierlich-durchzuführen>Automatisiere Experimente, um sie kontinuierlich durchzuführen</h3>