Update _index.de.md

Service replaced by Dienste - better wording

content/_index.de.md

@@ -11,9 +11,9 @@ Letzte Aktualisierung: März 2019
 
 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?
 
-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.
+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.
 
-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.
+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.
 
 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 *Chaos Engineering*.
 
@@ -39,7 +39,7 @@ Durch die Fokussierung auf die Verhaltensmuster des Systems während der Experim
 
 ### Variiere die Simulation von echten Vorfällen aus dem produktiven Betrieb 
 
-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.
+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.
 
 ### Mache Experimente auf der Produktivumgebung