1. Software, welche Immun gegen Fehler ist, kann nicht existieren. Der Versuch solche zu erreichen ist zum Scheitern verurteilt. Es sollte daher versucht werden Software nicht immun gegen Fehler zu machen, sondern sie so robust zu gestalten das Fehler keine schwerwiegenden Auswirkungen haben.

2. „Resilience“ – Robustheit – meint, wenn Fehler auftreten sollte die Software in der Lage sein sich von diesen zu erholen. Ferner sollte die Zeit die für diese „Erholung“ erforderlich ist möglichst kurz und die Zeit zwischen den Fehlern möglichst lang sein.

3. Fehler können mannigfaltige Formen annehmen.

   ◦ Einfacher Fall: Service ist nicht verfügbar (down).

   ◦ Komplexer: Der Service ist verfügbar, aber ein benötigter anderer Service ist nicht verfügbar.

   ◦ Komplexer: Der Service ist grundsätzlich funktionsfähig, die Latenz ist aber so hoch das Kunden entweder Aufgeben oder sogar Timeouts auftreten.

4. Fehler lassen sich kategorisieren in „known unknowns“ – Fehler, welche beim Design des Services berücksichtigt werden (Datenbank nicht erreichbar, Netzwerkfehler, usw.) Und „unknown unknowns“ – Fehler, welche beim Design des Services, aus welchen Gründen auch immer (Vergessen, Unvorhersehbar), nicht berücksichtigt wurden.

5. Folgende Methoden zur Steigerung der Resilience stehen zur Verfügung:

   ◦ Saubere Infrastruktur: Continuous Delivery Pipeline; Monitoring, Logging, Tracking; Tests (unit tests, integration tests, consumer driven contract tests, functional tests, performance tests); Everything as Code (auch Konfigurationen, Skripte, Images versioniert in einem VCS vorhalten)

   ◦ Circuit Breaker (Timeouts und Thresholds müssen angemessen gewählt werden, damit kein zusätzliches Ausfallrisiko erzeugt wird)

   ◦ Isolierung (Eventing anstatt synchroner Kommunikation; erforderliche Daten selbst vorhalten)

   ◦ Feature Toggles (erlauben das schnelle Abschalten fehlerhafter Funktionen)

   ◦ Skalierbarkeit von Services bei der Entwicklung berücksichtigen (ist paralleler Datenbank-/Dateisystem-/Ressourcenzugriff möglich; Autoscaling Support in der Cloud; verschiedene Avalability Zones/Datacenter)

   ◦ Caching

6. Wichtig ist das Monitoring von Services, es sollten fortgeschrittene Methoden zur Auswertung von Logginginformationen genutzt werden. Ein informatives Logging sollte bei der Entwicklung von Services von Anfang an berücksichtigt werden. Zusätzlich sollte das passende Medium und Maß an Alerting gewählt werden, damit wichtige Informationen nicht übersehen werden.

7. Es sollten Pläne für „disaster recovery“ zur Verfügung stehen:

   ◦ Rollback (vollständig automatisiert; blue green deployment)

   ◦ forward fixes (in der Praxis häufig nicht anwendbar)

   ◦ Eskalationspläne

8. Stuff happens – Deal with it/Automate as much as possible/Implement only what you need

(Rechtsklick -> Ziel speichern unter)

Kernaussagen (PDF)