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