Skip to content

Instantly share code, notes, and snippets.

@jahe
Created August 18, 2018 10:46
Show Gist options
  • Save jahe/2aa8d7d2508c359f2d858d3e4343f3d1 to your computer and use it in GitHub Desktop.
Save jahe/2aa8d7d2508c359f2d858d3e4343f3d1 to your computer and use it in GitHub Desktop.
Resilient Software Design

Fehlerszenarien

  • Nutzer bekommt nichts davon mit (bester Fall)
  • Anwendung läuft in einem definierten, reduzierten Service-Level weiter

Ziele von Software, damit sie einen Geschäftswert erzielt

  • Muss in Produktion laufen
  • Muss ordnungsgemäß funktionieren (Verfügbarkeit)

Verfügbarkeit = MTTF / (MTTF + MTTR)

  • MTTF (Mean Time To Failure) - durchschnittliche Zeit vom Beginn des Systems bis zum Auftreten des ersten an den Systemgrenzen sichtbaren Fehlers
  • MTTR (Mean Time To Recovery) - durchschnittliche Zeit vom Auftreten des Fehlers bis das System wieder ordnungsgemäß arbeitet

Verfübgarkeit ist also der Anteil der Zeit, in der das System ordnungsgemäß arbeitet.

Fehlertypen

  • Absturzfehler
  • Latenzfehler

2 Möglichkeiten die Verfügbarkeit zu erhöhen

  • Vergrößern von MTTF -> Die Wahrscheinlichkeit reduzieren, dass überhaupt ein Fehler auftritt
  • Reduzieren von MTTR -> Die Zeit für die Wiederherstellung nach Auftreten eines Fehlers verkürzen

In der Vergangenheit wurde sich primär auf den ersten Ansatz fokusiert, z.B. durch

  • HA-Hardware
  • Software-Clustering Dabei wurde die Software so entwickelt, als wären alle Bausteine, die sie zum ordnungsgemäßen Funktionieren benötigt, stets zu 100% verfügbar.

--> Funktioniert nur, solange die Anwendung isoliert läuft (also keine oder kaum entfernte Ressourcen, die für das Funktionieren benötigt werden und nur wenige Fehlerquellen, vor denen man die Anwendung schützen muss -> z.B. Ausfall von Hardware oder Absturz eines Prozesses)

Heutzutage ist aber fast jede Anwendung ein verteiltes System --> Und dabei gibt es beliebig viele Fehlerquellen ("Acht Irrtümer verteilten Rechnens")

--> Fehler in heutigen Anwendungen sind weder vermeidbar noch vorhersehbar, sondern der Normalfall. Konsequenzen:

  • Für eine hohe Verfügbarkeit muss man MTTR minimieren
  • Fehlerszenarien müssen auch auf Anwendungsebene adressiert werden

Resilient Software Design

  • Design der Bulkheads
  • Anwendung durch Resilience-Muster robust machen

Bulkhead

  • Kommt aus dem Schiffsbau (~ "Schottwand")
  • Elementarste Muster aus Reslilient Software Design
  • Das Muster besagt: "Eine Anwendung sollte niemals als Ganzes ausfallen. Deshalb zerlege die Anwendung in Teile (die Bulkheads) und isoliere diese so voneinander, dass keine kaskadierenden Fehler auftreten."

Kaskadierender Fehler - Fehler, der in einem Anwendungsteil auftritt und sich in andere Anwendungsteile fortpflanzt, sodass immer mehr Anwendungsteile vom ursprünglichen Fehler in Mitleidenschaft gezogen werden.

Umsetzung von Bulkheads

  • Schwierig, da Design-Entscheidung und keine konkrete Implementierungsanweisung
  • Für die Trennung/Isolation müssen die Bulkheads aber auch auf fachlicher Ebene entkoppelt sein
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment