re·sil·ience (rĭ-zĭl′yəns), noun

  1. The ability to recover quickly from illness, change, or misfortune; buoyancy.
  2. The property of a material that enables it to resume its original shape or position after being bent, stretched, or compressed; elasticity.

http://www.thefreedictionary.com/resilience [1]

Der erste Schritt in Richtung Resilient Software Design ist, zu akzeptieren, dass jede Software “fehlerhaft” ist.  Erst wenn man akzeptiert, dass Fehler auftreten werden, ist man in der Lage darüber nachzudenken, wie man dieser Tatsache begegnen kann, um stabile, robuste, verlässliche Softwaresysteme zu erschaffen. Frei übersetzt nach Micheal T. Nygard [4] benötigt Unternehmenssoftware die folgende Eigenschaft: Software muss zynisch sein. Zynische Software erwartet immer das Schlimmste und ist nicht überrascht, wenn der schlimmste Fall auch eintritt. Zynische Software vertraut nicht einmal sich selbst; sie erstellt interne Barrieren um sich selbst vor Fehlern zu schützen. Zynische Software lehnt es ab mit anderen Systemen eine zu intime Beziehung einzugehen, da sie verletzt werden könnte.

Wenn ich hier von Fehlern spreche, dann sind es nicht nur Bugs im Code die zu Systemabstürzen führen, sondern auch Fehler, die man bei der Erstellung der Softwarearchitektur und dem Design der Systemkommunikation gemacht hat, indem man eine Entscheidung getroffen hat, die zwar den funktionalen Anforderungen genügt, jedoch zu Systemausfällen führen kann und damit auch zwangsläufig zu Systemausfällen führt. Daher sollte man stets sowohl in der Softwarearchitektur und dem Design als auch bei der Implementierung immer einen Blick in Richtung Systemstabilität werfen.

Uwe Friedrichsen zitiert die folgenden Fehlertypen, die man bei Resilient Software Design berücksichtigen sollte und verweist darauf, dass man sich nicht nur auf die “einfachen” Absturzfehler beschränken darf [2, 3]:

  1. Crash Failure (Absturzfehler)
    ein System antwortet permanent nicht mehr, hat bis zum Zeitpunkt des Ausfalls aber korrekt gearbeitet
  2. Omission Failure (Auslassungsfehler)
    ein System reagiert auf (einzelne) Anfragen nicht, sei es, dass es die Anfragen nicht erhält oder keine Antwort sendet
  3. Timing Failure (Antwortzeitfehler)
    die Antwortzeit eines Systems liegt außerhalb eines festgelegten Zeitintervalls
  4. Response Failure (Antwortfehler)
    die Antwort, die ein System gibt, ist falsch
  5. Byzantine Failure (Byzantinischer/zufälliger Fehler)
    ein System gibt zu zufälligen Zeiten zufällige Antworten („es läuft Amok“)

 

Wie gesagt, shit happens … und das ist auch der Grund, weshalb wir uns mit Resilient Software Design beschäftigen sollten. In einem meiner nächsten Artikel möchte ich das Thema vertiefen und mich dabei auf den Punkt “Verfügbarkeit” (Availability) konzentrieren.

Literatur:

[1] American Heritage® Dictionary of the English Language, Fifth Edition. Copyright © 2011 by Houghton Mifflin Harcourt Publishing Company. Published by Houghton Mifflin Harcourt Publishing Company. All rights reserved.

[2] U. Friedrichsen, ‘Unkaputtbar, Eine kurze Einführung in Resilient Software Design’, Business Technology, no. 414, 2014 [Online]. Available: https://www.codecentric.de/files/2015/02/Sonderdruck_Codecentric_BT4_14_27964_mon.pdf. [Accessed: 04- Aug- 2015]

[3] U. Friedrichsen, ‘Eine kurze Einführung in Resilient Software Design’, jaxenter.de, 2015. [Online]. Available: https://jaxenter.de/unkaputtbar-einfuehrung-resilient-software-design-15119. [Accessed: 04- Aug- 2015]

[4] M. Nygard, Release it!. Raleigh, N.C.: Pragmatic Bookshelf, 2007.

Grafiken: