Nachdem wir bereits in mehreren Artikeln auf die psychische Resilienz eingegangen sind, widmen wir uns diesmal der technischen Resilienz. Der Resilienzbegriff beschreibt im jeweiligen verwendeten Kontext den Widerstand vom Betrachtungsgegenstand gegen widere Einflüsse, die von einer idealen Funktionsumgebung abweichen. So beschreibt der Begriff der technischen Resilienz die Fähigkeit von technischen Systemen, bei Störungen bzw. Teilausfällen nicht vollständig zu versagen, sondern wesentliche Systemdienstleistungen aufrechtzuerhalten. Im Idealfall bedeutet das, dass an den Schnittstellen diese Fehlfunktion nicht bemerkt wird, oder es im schlechtesten Fall es zu einer kontrollierten Herabsetzung der Servicequalität kommt [1].
Um ein resilientes System zu entwickeln, gibt es einige Grundprinzipien, denen vor und während der Entwicklung des Systems Aufmerksamkeit geschenkt werden sollte. Eine spätere Integration von Maßnahmen zur Resilienzverbesserung können überaus kosten- und zeitintensiv werden.
Im Mittelpunkt der Resilienz steht die Isolation. Die Fehlerfälle im System müssen so zeitnah wie möglich vom Rest des Systems isoliert werden, da so eine Fehlerkaskade vermieden werden kann [1].
Um nach der Isolation des fehlerhaften Teilsystems die Störung zu beheben bzw. den Fehler abzuschwächen, ist die Einrichtung von Redundanzen ein ebenfalls wichtiger Schritt hin zu einem resilienten System. Diese redundanten Teilsysteme übernehmen für Zeit des Ausfalls die Aufgaben des gestörten Teilsystems [1]. Um sicherzustellen, dass die Redundanzen an geeigneter Stelle im System implementiert werden, sollte die vorangestellte Anforderungsanalyse unter keinen Umständen unterschätzt werden.
Um Fehlerkaskaden zu vermeiden kann sich eine lose Kopplung als sehr effektiv erweisen. Eine lose Kopplung bedeutet, dass es nur eine geringe Abhängigkeit von Systemkomponenten untereinander gibt. Diese kann beispielsweise in Form einer asynchronen Kommunikation erreicht werden. In der asynchronen Kommunikation wird die gesendete Information zwischengespeichert und dem Empfänger zu einem von ihm bestimmten Zeitpunkt zur Verfügung gestellt. Eine gleichzeitige Aktivität beider Seiten (synchrone Kommunikation) ist demnach nicht mehr notwendig [3]. Eine asynchrone Kommunikation ist zwar anspruchsvoller in beispielsweise Speicherbedarf, als eine synchrone Kommunikation, ist dabei jedoch nicht so anfällig gegenüber sich fortpflanzender Latenzfehler [1].
Ein klassisches Besispiel für ein nicht-resilientes System: Die Dominosteine
Den Fehlern, die im System auftreten, muss mit einer fixen Sicherheitsstrategie begegnet werden, dem sogenannten Fallback. Das Ziel des Fallbacks ist es, Fehler abzufedern und so den Komplettausfall des Systems zu verhindern. Insbesondere muss man sich beim Fallback darüber Gedanken machen, wie sich das System gegenüber dem Anwendererhalten soll, falls ein uneingeschränkter Zugriff auf alle Funktionen nicht mehr möglich ist. Eine Fallbackstrategie könnte beispielsweise in einer kontrollierten Herabsetzung der Servicequalität münden [1].
Für das Requirements-Engineering bedeutet das Entwickeln eines resilienten Systems zusätzliche Anforderungen und damit je nach Umgebung auch zusätzliche Stakeholder. Außerdem werden in der in der Literatur zu Resilienz-Engineering [2] vier wiederkehrende Indikatoren beschrieben, die essenziell für die Umsetzung und Betreibung eines resilienten Systems sind.
1. Engagement auf höchster Ebene, da die Sicherheit höher priorisiert werden muss als Effizienz
2. Bereitstellung ausreichender Ressourcen, um in kritischen Situationen richtig und angemessen reagieren zu können und den Entscheidungsdruck der Beteiligten zwischen Gründlichkeit und Effizienz zu senken.
3. Flexibler Handlungsspielraum mit klaren Handlungsgrenzen, um ein situationsgerechtes Handeln innerhalb eines abgesteckten Handlungsspielraums zu ermöglichen
4. Sicherheitsbewusstsein, Transparenz und Lernprozess, so dass kritische Situationen korrekt und im Idealfall proaktiv identifiziert werden (können).
Mit diesem Beitrag endet nun vorerst die Blogreihe zum Thema Resilienz. Wir haben noch viele weitere Interessante Themen und Beiträge in dem SOPHIST-Blog, vielleicht klicken Sie sich mal durch.
Ihre SOPHISTen
Quellen:
[1] Uwe Friedrichsen (2015): Eine kurze Einführung in Resilient Software Design.
Online verfügbar unter: https://jaxenter.de/unkaputtbar-einfuehrung-resilient-software-design-15119/, zuletzt geprüft 09.09.2019
[2] Federal Institute for Occupational Safety and Health (BAuA) (2014): Management Systems, Safety Culture and Resilience engineering: Comparison of Concepts. Online verfügbar unter https://www.hfes-europe.org/wp-content/uploads/2014/06/Adolph.pdf/, zuletzt geprüft am 09.09.19.
[3] dorianziefle (2010): Synchrone und asynchrone Kommunikation. Online verfügbar unter: https://dorinaziefle.wordpress.com/2010/01/30/synchrone-und-asynchrone-kommunikation/, zuletzt geprüft 09.09.19.
Bildquellen:
Titel: Control Room
Quelle: iStockphoto
Autor: Georgijus Pavlovas
Titel: Domino
Quelle: aboutpixel.de
Autor: Konstantin Gastmann