Die Einführung kann auch Nachteile mit sich ziehen:

Transkript

1 6. Maximize Human Participation Die Vorgehensweise MAXIMIZE HUMAN PARTICIPATION ist genau das Gegenteil von MINIMIZE HUMAN INTERVENTATION und beschreibt das Vorgehen wie man erfahrene Benutzer ins System mit einbezieht um in einer Fehlersituation entsprechender und schneller zu interagieren. Dabei wird versuch das Expertenwissen von Systemdesignern, Operatoren und anderen Nutzern zu nutzen. Daraus ergeben sich folgende Vorteile: - Menschen können Sachverhalte im Grossen und Ganzen erfassen, welche eine Software nicht erkennen kann. Die Überlegenheit gegenüber der Software ermöglicht es Informationen herauszufiltern und anhand dieser Entscheidungen zu treffen. (Bsp. Ein ROLLBACK auf einer defekten Festplatte wird nicht den gewünschten Effekt erbringen.) - In gewissen Systemen, kann der Mensch das Vorgehen bei Fehlern besser abschätzen. (Bsp. Ein Pilot muss in einer Notsituation das System übersteuern können, unabhängig was das System für richtig befindet.) Die Einführung kann auch Nachteile mit sich ziehen: - Unerfahrene Benutzer können falsche oder sogar gefährliche Massnahmen einleiten. Daher macht es in gewissen Systemen keinen Sinn, wenn man die Fehlersituation überschrieben kann. (Bsp. Das Verhalten einer Mikrowelle sollte nicht beeinflusst werden können, da die Verletzungsgefahr viel zu gross ist.) Lösungsansatz: Zwar werden die PROCEDURAL ERRORS durch die Anwendung von MINIMIZE MUMAN INTERVENTATION verringert, jedoch benötigt das Recovery unter gewissen Umständen länger. Methoden wie CORRECTING AUDITS oder RECOVERY BLOCKS sind bewährte Vorgehensweisen um ein System Fehlertoleranter zu gestalten, aber der Mensch ist in der Lage Situationen schneller beurteilen zu können, das ihm unterumständen mehr Informationen zur Verfügung stehen. Damit der Benutzer möglichst schnell reagieren kann, gibt es ein paar Punkte zu beachten: - Informationen müssen möglichst einfach zugänglich sein. Die wichtigsten und effektivsten Informationen erscheinen zuoberst. - Timestamps und Sequenz Nummern helfen den Systemstatus nachzuvollziehen - Action Messages einführen, welche Aktionen überwachen. Es ist in jedem Fall zu bedenken wie stark ein Mensch in das Geschehen eingreifen darf. Nach einer Fehlersituation soll eine Analyse durchgeführt werden. Diese Analyse soll aufzeigen, wie förderlich der Eingriff des Benutzers für das System war. Dieses Wissen kann dazu benutz werden, um das System zu verbessern. 7. Maintenance Interface Nebst den für die eigentliche Arbeit notwendigen Mensch-Maschinen-Interaktionen, müssen auch Informationen für den Unterhalt des Systems ein- und ausgegeben werden. Diese Informationsflüsse sollten getrennt werden. Dies kann in verschiedenen Szenarien sehr wichtig sein. Wenn sich z.b. das System in einem Fehlerhaften Zustand befindet, überladen oder gar "abgestürzt" ist, muss die Administration immer noch möglich sein; so kann es sinnvoll sein, Maintenance Befehle prioritär zu behandeln. Auch für die Rechteverwaltung kann es notwendig sein, das Maintenance Interface vom normalen Userinterface zu trennen.

2 Im Maintenance Interface muss ein guter Mix gefunden werden, zwischen möglichst viel nützliche Informationen zur Verfügung stellen und die wichtigsten Informationen gut sichtbar zu machen. 10. Fault Observer Da jedes System potenzielle Faults beinhalten kann, wird jedes System irgendwie überwacht. Entweder von Personen oder anderen Systemen. Zum Beispiel auch ein Kühlschrank hat mindestens eine Person, welche sich um den Zustand des Geräts sorgt. Ein System wird nach folgenden Prinzipien gebaut: Minimize Human Intervention: Das System kann Fehler meistens besser verarbeiten als Menschen Falls ein, für das System nicht behandelbarer Fehler aufgetreten ist, möchte man entweder mit o Maximize Human Participation: den Profis eine gute Fehlerübersicht bieten, damit sie schnell eingreifen können o Oder mit Software Updates das System nachträglich robuster und fehlerfreier machen. Wenn das Pattern Minimize Human Intervention korrekt eingesetzt wird, probiert das System den Fehler selbstständig zu beheben. Dies ist in erster Linie gut, doch auch hier ist es angebracht, wenn zuständige Personen informiert werden. Sonst wäre es gar nicht möglich diesen Fehler mit einem neuen Software Update zu verbessern. Die Aufgaben eines oder mehrerer Fault Observers ist das Aufnehmen aller Fehler die im System passieren. Dies setzt voraus, dass alle Teilsysteme die Fehlererkennung und Fehlerbehebung machen, die Möglichkeit haben, ihre Fehler an den Fault Observer weiterzuleiten. Bis jetzt bekommt der Fault Observer alle Fehler, welche sich im System ereignet haben. Um die interessierten Parteien nun zu benachrichtigen wird das Publish-Subscriber Pattern eingesetzt. Durch dieses Pattern haben die Interessenten (egal ob Personen oder andere Systeme) die Möglichkeit, sich beim Fault Observer zu registrieren. Sobald jetzt ein Fehler von einer bestimmten Komponente beim Fault Observer gemeldet wird, informiert er alle seine Interessenten über das Maintenace Interface.

3 Es ist möglich, mehrere Fault Observer in einem System einzusetzen. Falls dies jedoch gemacht wird sollte man darauf achten, dass die unterschiedlichen Fault Observer für Redundanz sorgen und Lastverteilung ermöglichen. Eine weiterer Vorteil, welcher mehrere Fault Observer bieten ist, dass jeder Observer für bestimmte Fehler zuständig gemacht werden kann. Die Systemgrenze für Fault Observers ist je nach Anwendung unterschiedlich. Man kann die Fault Observers innerhalb oder ausserhalb des Systems platzieren. Vorteile: Wenn jede Komponente ihre Fehler jeweils an alle anderen Komponenten weiterleiten würde, würde ein grosser Overhead entstehen. Durch den Fault Observer entsteht ein geregelter Ablauf Man hat die Möglichkeit an einer zentralen Stelle Logs zu führen. Es können auch andere Fault Tolerance Patterns beim Fault Observer eingesetzt werden, da sich der zentrale Punkt gut dafür eignet. Someone in Charge, Fault Correlation Es findet keine Code Dublication statt Es wird keine Verwirrung gestiftet indem der gleiche Fehler von unterschiedlichen Komponenten gemeldet wird

4 11. Software Updates Problem: Software wird über kurz oder lang ein Update erfahren um neue Features mehr Funktionalität einen Fault zu behandeln. Das Update betrifft Applikation Middleware (Supporting Software) OS Hardware Firmware Schaltet man das System während den Updates aus, entsteht Downtime was die Verfügbarkeit eines Systems mindert. Dies kann nicht akzeptiert werden Ziel: System und Applikationen müssen den Betrieb für Updates nicht stoppen. Mindset anwenden: Was kann schief gehen beim Update? Was sind die Failures? How to minimize installing time for minimal unavailability: Bestimmen wie die Änderungen ablaufen nach dem ersten Deploy. Bsp: Man muss zuerst eine Funktion adden bevor man ein Feauture adden kann Die längste unavailability Periode entsteht wenn eine komplett neue Version auf der gleichen infrastruktur installiert werden muss. Diese könnten nicht gleichzeitig laufen, wenn man nicht Vorsorgemassnahmen treffen würde. Besser für die unavailability ist der Fall wo die neue Software die alte SW erweitert und nach entfernen der alten SW lauffähig ist. Failover (36) (Redundantes aktiv Element wird passiv und übegibt aktiv Zustand) evtl Recovery Block (4) wenn Tests schief gehen zurück zur alten Version Bei Small Patches (61) braucht man umfangreiche Infrastruktur um Wechsel zu vereinfachen Tradeoff ist meistens -> Unavailability vs. Infrastruktur Updates auf den verschiedenen Levels (App, OS, Middleware, Hardware) benötigen auch meistens verschiedene Tools für die Levels. All diese Tools werden bei einer langlebigen SW irgendwan auch erneuert. Updates können Backward oder Forward Compatibel sein, daher müssen die dafür notwendigen Massnahmen getroffen werden ( NoOps, Regeln im Umgang mit fehlenden oder geänderten Attributen) - > Message Versioning (PT02) 2 Implementationen für Back- & Forward compatibility for messages Bei der Entwicklung des Updates sollte Maximizing Human Participation angewendet werden. Bei der Installation des Updates sollte Minimizing Human Participation angewendet werden. Bottom Line: Die Software muss von anfang an so designed werden, dass updates ohne Probleme durchgeführt werden können. Wird das System total neuinstalliert oder jeweils nur mit

5 Patches Teilbereiche saniert muss spezifiziert werden. Die Planned Downtime wegen Updates wird in den Reliability Kalkulationen meistens ausgelassen.