Resilienz: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 130: | Zeile 130: | ||
* [[Fehlertolerantes Regelsystem]] | * [[Fehlertolerantes Regelsystem]] | ||
* [[Menschlicher Fehler]] | * [[Menschlicher Fehler]] | ||
[[Kategorie:Fehlermanagement]] | [[Kategorie:Fehlermanagement]] | ||
Version vom 3. März 2024, 13:04 Uhr
topic - Kurzbeschreibung
Beschreibung
Anhang
Siehe auch
Links
Weblinks
TMP
Besonderes Schutzziel im Zuge der DSGVO
Resilienz (Systemtheorie)
Resilienz beschreibt die Fähigkeit eines Systems, sich angesichts geänderter äußerer Effekte selbst zu erhalten.[1] Dies kann je nach Disziplin durch unterschiedliche Fähigkeiten erreicht werden.[2] Die System- und Komplexitätsforschung bemüht sich daher um eine einheitliche Definition des vielerorts als relevantes Forschungsfeld eingestuften Begriffs.[3]
Demnach kann Resilienz unabhängig von domänenspezifischen Definitionen in
- Erhalt der Struktur und des Funktionsumfangs (starke Resilienz),
- Erhalt des Funktionsumfangs (schwache Resilienz),
- Anpassung von Struktur und Funktionsumfang (starke Adaption),
- Anpassung des Funktionsumfangs (schwache Adaption)
unterschieden werden.[4]
Die Resilienz eines Systems wird in der Regel als Prozess eines offenen Systems betrachtet, in dem die Abwägung von Optimierungskonflikten (Trade-offs) erfolgt. Damit ist die Betrachtung resilienter Systeme mit Konnektivität, seinem Verständnis als lernende Entität sowie einer durch Diversität gespeisten Redundanz verbunden.[5]
Organisatorische Resilienz
https://de.wikipedia.org/wiki/Organisatorische_Resilienz Als Organisatorische Resilienz[6] bezeichnet der Standard BS65000(2014) der British Standards Institution (BSI), die Fähigkeit eines Unternehmens, auch in einem komplexen und dynamischen Umfeld den Wandel vorauszusehen, zu überleben und zu wachsen. BS65000(2014) dient Unternehmen als Leitfaden zu Generierung von Maßnahmen zur Widerstandsfähigkeit und definiert die Bedeutung der Resilienz, stellt die wichtigsten Komponente der organisatorischen Resilienz dar und unterstützt Unternehmen dabei, ihre Resilienz zu messen.
Merkmale
Eine resiliente Organisation[7] erkennt man an einigen wesentlichen Merkmalen ihres Betriebs: Sie ist anpassungsfähig mit einer agilen Führungsspitze, die selbstbewusst leitet. Sie profitiert insbesondere von:
- Strategischer Anpassungsfähigkeit
- Durch sie bleibt die Organisation unter geänderten Bedingungen erfolgreich handlungsfähig, auch wenn dies bedeutet, dass sie sich von ihrem Kerngeschäft entfernen muss.
- Agilem Führungsstil
- Mit ihm können abgewogene Risiken selbstbewusst eingegangen und rasch in der gebotenen Weise sowohl auf Chancen als auch Bedrohungen reagiert werden.
- Solider Unternehmensführung
- Sie demonstriert ein Verantwortungsbewusstsein auf allen Ebenen einer Organisation, das auf einer Kultur des Vertrauens, der Transparenz und Innovation basiert und so gewährleistet, dass die Organisation ihrer Vision und ihren Werten weiterhin treu bleibt.
BSI-Studie
Auf Basis einer international durchgeführten Befragung von 411 Managern versucht die von der BSI beauftragte Economist Intelligence Unit der Zeitschrift The Economist, Merkmale resilienter Organisationen aus Managementsicht zu ermitteln.[8] Dabei setzten die Befragten Resilienz – also die Fähigkeit, sich erfolgreich von Krisen zu erholen – mit Langlebigkeit, Krisenfestigkeit, Resistenz oder Immunität der Organisation gegenüber den Strategien von Konkurrenten sowie schwankenden Marktanforderungen – also mit proaktivem Verhalten zur Krisenvermeidung – gleich. Als besonders kritisch werden dabei vor allem in den Vereinigten Staaten und Asien Reputationsrisiken wahrgenommen.
Wichtigste Voraussetzungen für eine so verstandene Resilienz sind aus Sicht der Befragten das Verständnis für Kundenanforderungen (65 %: sehr wichtig) und die Qualifikation der Mitarbeiter (59 %: Sehr wichtig) genannt, gefolgt von dynamischer und agiler Führung (57 %) und IT-Sicherheit (50 %).[9]
Siehe auch
Robustheit gegen Benutzungsfehler
In der Technik, besonders in der Datenverarbeitung, bedeutet Robustheit gegen Benutzungsfehler, vormals als „Fehlertoleranz“ (von Vorlage:LaS ‚erleiden‘, ‚erdulden‘) bezeichnet, die Eigenschaft eines technischen Systems, seine Funktionsweise auch aufrechtzuerhalten, wenn unvorhergesehene Eingaben oder Fehler in der Hard- oder Software auftreten.
Robustheit gegen Benutzungsfehler erhöht die Zuverlässigkeit und Ausfallsicherheit eines Systems, wie es beispielsweise in der Medizintechnik oder in der Luft- und Raumfahrttechnik gefordert ist. Robustheit gegen Benutzungsfehler ist ebenso eine Voraussetzung für Hochverfügbarkeit, die insbesondere in der Telekommunikationstechnik eine wichtige Rolle spielt.
Ansätze auf verschiedenen Ebenen
Robustheit gegen Benutzungsfehler gemäß der Neufassung der DIN EN ISO 9241-110 kann auf verschiedenen Ebenen erreicht werden. Je nach Einsatzgebiet (PC, Medizintechnik, Weltraumtechnik usw.) sind verschiedene Ansätze sinnvoll, auch Kombinationen bieten sich oft an.
Robustheit gegen Benutzungsfehler in Hardware
Hardware, d. h. eine elektronische Schaltung, kann z. B. durch Hinzufügen von „heißer“ Redundanz fehlertolerant gemacht werden. „Kalte“ Redundanz benötigt hingegen den Eingriff eines anderen Systems (Operator, Software etc.) und erfüllt daher allein nicht die Fehlertoleranz-Anforderung.
Laufen z. B. zwei Implementierungen einer Schaltung parallel (dual modular redundancy, DMR), so kann eine Entscheidungseinheit einen Fehler durch Vergleichen der Ausgänge der beiden Komponenten feststellen, jedoch nicht korrigieren. Fügt man eine weitere Instanz der Komponenten hinzu (triple modular redundancy, TMR), so kann eine Entscheidungseinheit einen Fehler auch korrigieren. Wird die fehlerhafte Einheit als defekt markiert, ist ein Fehler weiter erkennbar (wie bei DMR). Wenn für den sicheren Betrieb eines Systems das Vorhandensein einer TMR gefordert ist, arbeitet man mit 4 oder mehr redundanten Komponenten.
Robustheit gegen Benutzungsfehler in Software
Auf Software-Ebene kann Fehlertoleranz durch folgende Maßnahmen erreicht werden:
- Design-Diversität: verschiedene Implementierungen eines Algorithmus laufen parallel
- Daten-Diversität: die Eingabedaten werden leicht modifiziert mehrfach bearbeitet (z. B. gut gegen Rundungsfehler)
- Temporale Diversität: ein Algorithmus wird mit denselben Daten mehrfach aufgerufen (z. B. gut gegen kurzzeitige Hardwarefehler)
Robustheit gegen Benutzungsfehler in Benutzerschnittstellen
Häufig verursachen fehlerhafte Benutzereingaben, also menschliches Versagen, abnorme Betriebszustände. Robustheit gegen Benutzungsfehler ist daher eines der Gestaltungsprinzipien für Dialoge nach EN ISO 9241, Abschnitt 110 (Grundsätze der Dialoggestaltung). Ein Dialog ist robust gegen Benutzungsfehler (vormals fehlertolerant), wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand durch den Benutzer erreicht werden kann:
- Unterstützung bei der Entdeckung und Vermeidung von Eingabefehlern (Plausibilisierung)
- Keine Systemabbrüche oder undefinierten Systemzustände
- Fehlererläuterungen zu Korrekturzwecken
- Zusätzlicher Darstellungsaufwand zur Fehlerlokalisierung
- Automatische Fehlerkorrektur mit Information
- Aufschiebbare Fehlerbehandlungen
- Zusätzliche Erläuterungen auf Anforderung
- Prüfung und Bestätigung vor Ausführung
- Fehlerbehebung ohne Zustandsänderung des Dialogs
Die potentiellen Fehler, die Besucher verursachen oder die ihnen begegnen können, lassen sich wie folgt klassifizieren:
- Vermeidbare Fehler
Diese Art von Fehlern treten aufgrund mangelnder Beschäftigung mit dem Benutzerverhalten auf und wären bei sorgfältiger Auseinandersetzung mit der Zielgruppe und ihrem typischen Nutzungsverhalten vermeidbar. Typisch vermeidbare Anwenderfehler auf Websites sind Navigationsfehler oder fehlerhafte Eingaben auf Formularen. Durch umfangreiche Tests vor dem Launch einer Website oder Anwendung könnten viele dieser Fehler vermieden werden.
- Bekannte, nicht vermeidbare Fehler
Nicht alle bekannten Fehler lassen sich vermeiden. Ein Vertippen mit der Tastatur, ein versehentliches Abschicken eines Formulars, das noch nicht vollständig ausgefüllt war, sind nur zwei Beispiele für Fehler, mit denen man rechnen muss, weil sie sich nicht ausschließen lassen. Für alle vorhersehbaren Fehler muss es deshalb einfache, klar erkennbare Korrekturmöglichkeiten geben.
- Nicht antizipierbare Fehler
In diese Klasse von Fehlern fallen all diejenigen, welche aufgrund unerwarteten Benutzerverhaltens passieren oder durch schwer identifizierbare Programmierfehler verursacht werden. Meist führen diese Fehler zu undurchsichtigen Programmverhalten, die für den Benutzer nicht verständlich sind.[10] Ein typischer Fall wäre zum Beispiel ein Fehler durch die Verwendung von nicht normalisierten Uhrzeiten. Bei der Umstellung von Sommer- auf Normalzeit wird so die Stunde 2 doppelt durchlaufen, wodurch eigentlich eindeutige Zeitstempel eventuell doppelt auftreten können oder Zeitmessungen scheinbar zu einer früheren Zeit enden als sie begonnen haben. Dieses Verhalten tritt nur einmal im Jahr auf und ist an den restlichen Tagen des Jahres nicht reproduzierbar. Die Lösung ist in solchen Fällen üblicherweise die Verwendung der UTC oder der normalisierten Lokalzeit (lokale Zeit ohne Sommerzeit-Verschiebung).
Stufen der Robustheit gegen Benutzungsfehler
In der Regel werden folgende Stufen der Fehlertoleranz unterschieden:
| Stufe | Verhalten des Systems |
|---|---|
| go | System reagiert sicher und korrekt. |
| fail-operational | System fehlertolerant ohne Leistungsverminderung |
| fail-soft | Systembetrieb sicher, aber Leistung vermindert |
| fail-safe | Nur Systemsicherheit gewährleistet |
| fail-unsafe | unvorhersehbares Systemverhalten |
Reaktion und Korrektur von Fehlern
Bei der Reaktion oder Korrektur von Fehlern unterscheidet man die zwei Prinzipien der Vorwärts- und der Rückwärtsfehlerkorrektur.
Vorwärtsfehlerkorrektur
Bei der Vorwärtsfehlerkorrektur versucht das System, so weiterzumachen als ob kein Fehler aufgetreten wäre, indem es etwa fehlerhafte Eingabewerte durch Erfahrungswerte aus der Vergangenheit oder Eingabewerte von korrekt funktionierenden Eingabeschnittstellen ausgleicht oder im Moment des Auftretens eines Fehlers sofort mit korrekt funktionierenden Ersatzsystemen weiterarbeitet. Fehler bleiben bei der Vorwärtsfehlerkorrektur normalerweise unsichtbar für Anwender.
Rückwärtsfehlerkorrektur
Bei der Rückwärtsfehlerkorrektur versucht das System bei Auftreten eines Fehlers in einen Zustand vor diesem Auftreten zurückzukehren, etwa in den Zustand direkt vor einer fehlerhaften Berechnung, um diese Berechnung erneut auszuführen. Genauso ist aber auch ein Zustandswechsel in einen Notbetrieb oder z. B. ein Neustart des Systems möglich. Kann eine fehlerhafte Berechnung erfolgreich wiederholt werden, bleibt auch bei der Rückwärtsfehlerkorrektur der Fehler für den Anwender unsichtbar. Oft ist aber nur ein Weiterbetrieb mit Leistungseinbußen oder eingeschränkter Funktionalität möglich und der Fehler somit sichtbar.
Externe Korrektur
In der Weltraumtechnik wird eine Fehlerkorrektur durch die Auswertung von Satelliten-Telemetriedaten in der Bodenstation durch Systemexperten und Umschaltung der Funktionen durch Telekommandos durchgeführt. Seit den enormen Fortschritten bei der Bord-Datenverarbeitung (schnelle Prozessoren, große Datenspeicher, intelligente Software-Konzepte) wird die Datenauswertung und Umschaltung zur Fehlerkorrektur mehr und mehr autonom vom Satellitensystem selbst ausgeführt.
Wegen der erforderlichen umfangreichen Überprüfungsmaßnahmen eines komplexen Bordsystems und dem damit verbundenen Zeit- und Kostenaufwand wird die zunehmende Autonomie in Hinsicht auf Fehlerkorrektur nur in kleinen Schritten realisiert, denn anders als bei Systemen auf der Erde kann eine falsche Fehlerkorrektur zum kompletten Verlust eines Satelliten führen.
Siehe auch
- ↑
- ↑ Vorlage:Literatur
- ↑ Vorlage:Literatur
- ↑ Vorlage:Literatur
- ↑ Vorlage:Literatur
- ↑
- ↑
- ↑ Organisational Resilience: Building an enduring enterprise, 2015, Abruf 15. April 2016
- ↑ Organisational Resilience, S. 7.
- ↑ Vorlage:Webarchiv. Abgerufen am 27. Oktober 2012.