Innovation mit lebenswichtigen Systemen

Jedes Unternehmen verfügt über eine „kritische“ Infrastruktur. Im Allgemeinen bedeutet dies, dass Teile (oder alle) des Geschäfts zum Erliegen kommen, wenn das System offline geht, bis die Techniker es wieder zum Laufen bringen können. Dies tritt häufig auf, wenn große Software-, Hardware- oder Netzwerk-Upgrades erforderlich sind: Neu bereitgestellte Systeme enthalten unerwartete Fehler, die einen Systemausfall verursachen, oder Benutzer machen Fehler mit dem neuen System, weil sie damit nicht vertraut sind, und die Produktivität wird unterbrochen, bis die Techniker können die Deployment-Bugs durcharbeiten oder die Benutzer schulen. In den meisten Fällen ist eine Zeit der Ausfallzeit oder verringerter Produktivität ein akzeptables Risiko im Austausch für das Versprechen einer verbesserten Leistung und Effizienz einer neuen Technologie, aber das ist nicht universell. Die meisten Unternehmen können sich eine gewisse Ausfallzeit leisten, ohne viel Umsatz zu riskieren oder ihre Kunden zu verärgern.

Aber was passiert, wenn es sich bei den Systemen, die Sie ändern müssen, um lebenswichtige Systeme handelt, bei denen der Lebensschutz von der zuverlässigen Nutzung des Systems abhängt?

Dieser Artikel entfernt sich von der traditionelleren Softwareentwicklung, mit der wir die meiste Zeit verbringen, und wirft stattdessen einen Blick auf die menschliche Komponente in lebenswichtigen Systemen. Meine Gedanken zu diesem Thema stammen aus meiner Erfahrung als Direktor der Informationstechnologie für einen 911-Krankenwagendienst, als Technologiespezialist für eine internationale humanitäre Katastrophenschutzorganisation und mit meinem Ph.D. in Human Systems Integration am Massachusetts Institute of Technology.

Bevor wir beginnen, möchte ich erklären, warum dies für Sie relevant sein könnte. Es mag zwar nicht offensichtlich sein, dass Ihr Projekt tatsächlich ein lebenswichtiges System beinhaltet, aber es ist viel wahrscheinlicher, als Sie vielleicht denken. Alle der folgenden Themen qualifizieren sich, sowie unzählige weitere Themen:

• Automobil. Arbeiten Sie an einem Projekt mit einem Fahrzeughersteller oder einem seiner Zulieferer? Von einem Startup für selbstfahrende Autos von der Universität rekrutiert? Automatisches Bremsen, Tempomat, Fahrspurregelung, Computer Vision, Hinderniserkennung, elektronische Motorsteuermodule usw. All dies ist ein lebenswichtiges System, bei dem ein Ausfall tödlich sein kann.
• Luftfahrt. Wenn Sie 30.000 Fuß in der Luft sind, kann fast jeder Systemausfall lebenskritisch sein. In Anbetracht der jüngsten Ereignisse mit der Boeing 737 MAX gibt es die offensichtlich lebenswichtigen Systeme des Autopiloten und der computergestützten Flugsteuerung, aber es gibt auch viele Dinge, an die Sie vielleicht nicht denken. Wenn zu Hause der Lüfter in Ihrer HLK-Anlage ausfällt und etwas Rauch erzeugt, öffnen Sie das Fenster oder gehen nach draußen, um frische Luft zu schnappen. Haben Sie schon einmal versucht, während eines Transatlantikflugs das Fenster zu öffnen und nach draußen zu gehen? Selbst die einfachsten Systeme, von den Steckdosen in der Bordküche bis zu den Bremsen an den Rädern des Getränkewagens, können in Flugzeugen lebenswichtig sein.
• Kommunikation. Die meisten Entwickler oder Ingenieure werden irgendwann in ihrer Karriere in der einen oder anderen Funktion an einem Kommunikationssystemprojekt arbeiten. Telekommunikation erscheint vielen zunächst nicht lebensnotwendig; Schließlich ging es der Zivilisation vor Telefon und Internet gut. Als jemand, der in Katastrophengebieten eingesetzt wurde, in denen die Telekommunikationsinfrastruktur zerstört wurde, möchte ich Ihnen sagen, was tatsächlich passiert: Menschen werden sehr krank oder verletzt und können nicht 911 anrufen; ältere Bewohner können ihre Kinder nicht anrufen, um sie zu bitten, ihre Rezepte in der Apotheke abzuholen; Einsatzkräfte können nicht mit ihren Dispatchern oder untereinander kommunizieren; und Menschen, die ihre Familienmitglieder nicht erreichen können, machen sich Sorgen und bringen sich in äußerst gefährliche Situationen, um sie zu finden. Kommunikationssysteme sind absolut lebenswichtig.

In der heutigen Welt der starken Abhängigkeit von Technologie könnten Projekte, die Sie nie für halbwegs wichtig gehalten haben, zu einer lebenswichtigen Komponente eines lebenswichtigen Systems werden.

Aber wenn es nicht kaputt ist, repariere es nicht

Haben Sie jemals das Wort „Heritage“ in Bezug auf ein technologisches System gehört oder verwendet? Es ist ein starkes Wort, das Gedanken an alte Traditionen, Abstammung und schwierige Zeiten der Vergangenheit hervorruft. In der Ingenieurswelt wird es verwendet, um Designs zu bezeichnen, die es schon lange gibt und die sich als zuverlässig erwiesen haben, und wird oft als wünschenswertes Merkmal zur Risikominderung angesehen. In Wirklichkeit ist es ein Euphemismus für archaische Technologie, die aus Risikoaversion nie aktualisiert wurde, und ist in Branchen allgegenwärtig, in denen Systemausfälle schwerwiegende Folgen haben können.

Diese Affinität zu traditioneller Software und Hardware hat einen guten Grund. Es ist bekannt, dass es funktioniert, es ist unwahrscheinlich, dass unbekannte Fehler auftreten, und seine Kosten sind stabil und vorhersehbar. Ein hervorragendes Beispiel ist die Raumfahrtindustrie: Das russische Raumschiff Sojus bringt seit über 50 Jahren Astronauten ins All, wurde während dieser Zeit nur geringfügig überarbeitet und wird weiterhin verwendet, weil es zuverlässig und sicher ist. Leider bedeutet dies, dass es im Vergleich zu modernen Designs auch äußerst ineffizient ist: Während die Sojus die NASA 81 Millionen US-Dollar pro Sitz kostet, um Astronauten mit ihrer historischen Hardware zur Raumstation zu fliegen, sollen SpaceX und Boeing Sitze für jeweils 58 Millionen US-Dollar anbieten mit ihren modernen Raketendesigns.

Es ist verständlich, dass nur wenige alte Systeme aufrüsten wollen, die noch funktionieren; Führungskräfte möchten kein Risiko eingehen, Techniker möchten sich nicht mit dem mysteriösen Server im Schrank herumschlagen, der eine Betriebszeit von 12 Jahren hat, und Kunden möchten nicht neue Designs erlernen müssen. Leider gibt es einen Wendepunkt zwischen Risikominimierung und Kosteneinsparungen: Herkömmliche Designs müssen irgendwann aktualisiert werden, selbst in Umgebungen mit hohem Risiko .

Der Rest dieses Artikels behandelt einige der wichtigeren Schritte in diesem Prozess, wenn Ihre Systeme lebenswichtig sind, wie sie beispielsweise von Ersthelfern, Militäreinheiten oder Flugzeugen verwendet werden.

Messing überzeugen

Meiner Erfahrung nach besteht der möglicherweise schwierigste Schritt des Prozesses darin, Entscheidungsträger und Interessengruppen davon zu überzeugen, dass Upgrades erforderlich sind. Systeme, die in lebenskritischen Umgebungen betrieben werden, unterliegen oft umfangreichen gesetzlichen Vorschriften und Organisationsrichtlinien, was bedeutet, dass Sie sie davon überzeugen müssen, dass sie nicht nur das Risiko eingehen und das Geld ausgeben sollten, sondern dass sie sich auch an etwas beteiligen sollten, das leicht mehrere sein können Jahre des bürokratischen Abschnürens. Der stärkste Widerstand, dem Sie begegnen werden, wird wahrscheinlich von der Rechtsabteilung kommen, die in entsetzlichen Details die potenzielle Haftung darlegen wird, der Sie die Organisation durch die Einführung neuer Technologien aussetzen werden. Sie haben Recht: Haftung ist ein wichtiges Thema , und wenn etwas kaputt geht und jemand verletzt wird oder stirbt, kann dies eine massive ethische, rufschädigende und finanzielle Belastung darstellen.

Egal, ob Sie bei einem Fortune-500-Konzern oder bei Ihrer örtlichen Freiwilligen Feuerwehr arbeiten, es geht immer um dasselbe: Geld. Unternehmen wollen es nicht verlieren, und gemeinnützige Organisationen haben von vornherein nicht viel zu tun. Der einzige zuverlässige Weg, den ich gefunden habe, um die Führung einer Organisation davon zu überzeugen, das Risiko einzugehen, ein lebenskritisches System zu ändern, besteht darin, zu demonstrieren, dass sie wahrscheinlich eher Geld verdienen/sparen als es verlieren werden oder dass sie es können Reduzieren Sie ihre Haftung, indem Sie ihre Technologie modernisieren und die Sicherheit verbessern.

Das bedeutet, dass Sie rechnen müssen. Wie hoch ist die Wahrscheinlichkeit, dass es aufgrund von Fehlern zu längeren Ausfallzeiten oder zukünftigen Abstürzen kommt (basierend auf früheren Bereitstellungen in Ihrer Organisation oder Daten von anderen Organisationen)? Was sind die erwarteten Auswirkungen, wenn es fehlschlägt, und was würde das kosten? Was sind umgekehrt die erwarteten Leistungs- oder Zuverlässigkeitsgewinne und was wären sie wert? Wenn Sie nachweisen können, dass Sie mit hoher Wahrscheinlichkeit die Nase vorn haben, stehen die Chancen gut, dass Sie grünes Licht bekommen.

Es geht nicht um dich

Sie kennen vielleicht den Ausdruck „von Ingenieuren für Ingenieure“, eine Redewendung, die darauf hindeutet, dass Ingenieure etwas gebaut haben, das von Menschen mit ähnlichen Qualifikationen wie ihren eigenen verwendet werden kann. Es kommt sehr häufig vor und war einer der Hauptauslöser für den Aufstieg von Computer-Usability-Studien in den frühen 1990er Jahren. Als Ingenieure haben wir oft andere mentale Modelle der Funktionsweise technologischer Systeme als der durchschnittliche Endbenutzer, was zu einer Tendenz führt, Systeme mit der Annahme zu entwerfen, dass der Endbenutzer bereits weiß, wie sie funktionieren. Bei herkömmlichen Systemen führt dies zu Fehlern und unzufriedenen Kunden; in lebenswichtigen Systemen kann es zum Tod führen.

Betrachten Sie den Fall von Air-France-Flug 447. Am 1. Juni 2009 war der Airbus A330 auf dem Weg von Rio de Janeiro nach Paris über dem Atlantik. Eiskristalle blockierten die Staurohre und verursachten Inkonsistenzen bei den Luftgeschwindigkeitsmessungen. Der Flugcomputer deaktivierte den Autopiloten und erkannte, dass er das Flugzeug selbst mit falschen Fluggeschwindigkeitsdaten nicht zuverlässig fliegen konnte. Es versetzte sich dann in einen „erweiterten Flugbereich“ -Modus, der es den Piloten ermöglichte, Manöver durchzuführen, die der Computer normalerweise nicht zulassen würde. Sie können sich vorstellen, dass die Ingenieure, die das System gebaut haben, dachten : „Wenn der Autopilot sich selbst ausschaltet, liegt das wahrscheinlich daran, dass es eine Situation gibt, in der die Piloten zusätzliche Kontrolle benötigen! ”

Dies ist der natürliche Gedankengang für die Ingenieure, die verstehen, welche Dinge dazu führen können, dass sich der Autopilot ausschaltet. Für die Piloten war dies nicht der Fall. Sie zwangen das Flugzeug in einen steilen Steigflug und ignorierten die „STALL“-Warnungen, bis es jegliche Fluggeschwindigkeit verlor und auf den Ozean stürzte. Alle 228 Passagiere und Besatzungsmitglieder wurden getötet. Während es mehrere Ideen über die genaue Motivation für ihre Aktionen gibt, ist die vorherrschende Theorie, dass die Piloten davon ausgegangen sind, dass der Flugcomputer Steuereingaben verhindern würde, die das Flugzeug blockieren würden (was für den normalen Flugbereich gilt), und dies nicht erkannt haben es war auf den erweiterten Hüllkurvenmodus umgeschaltet, weil sie das mentale Modell der Ingenieure der Logik, die die Entscheidungen des Computers steuerte, nicht teilten.

Dies ist zwar ein ziemlich umständlicher Weg, führt uns aber zu meinem Hauptpunkt: Die Aktionen, die Benutzer unter bestimmten Bedingungen ausführen sollen, müssen die Aktionen sein, die sich für den Benutzer natürlich anfühlen .

Benutzer können angewiesen werden, bestimmte Verfahren zu befolgen, aber sie werden sich einfach nicht immer an das Richtige erinnern oder verstehen, was unter Bedingungen mit hohem Stress passiert. Es liegt in Ihrer Verantwortung, Software, Steuerelemente und Schnittstellen auf eine intuitive Weise zu entwerfen, die Benutzer von Natur aus dazu bringt, die Dinge zu tun, die sie tun sollen.

Das bedeutet, dass es absolut entscheidend ist, dass die Endbenutzer in jede einzelne Phase des Design- und Entwicklungsprozesses einbezogen werden. Es können keine Annahmen darüber gemacht werden, was Benutzer wahrscheinlich tun werden; es muss alles evidenzbasiert sein. Wenn Sie Schnittstellen entwerfen, müssen Sie Studien durchführen, um die Denkmuster zu ermitteln, die sie bei Benutzern hervorrufen, und bei Bedarf anpassen. Wenn Sie Ihre neuen Systeme testen, müssen Sie sie mit echten Benutzern in realen Umgebungen unter realistischen Bedingungen testen. Und wenn Sie Ihre Designs ändern, müssen Sie diese Schritte leider noch einmal wiederholen.

Obwohl jedes komplexe System einzigartig ist, möchte ich vor allem drei Designüberlegungen erwähnen, die universell angewendet werden sollten:

• Steuerelemente sollten repräsentativ für die Aktionen sein, die sie aufrufen. Glücklicherweise ist dies ziemlich häufig, im Allgemeinen in Form der Auswahl relevanter Symbole für GUI-Schaltflächen oder relevanter Formen für physische Steuerelemente. Die Schaltflächen „Neue Datei“ verwenden ein leeres Blatt Papiersymbol, und Fahrwerkshebel in Flugzeugen haben einen Knopf in Form eines Rads. Es ist jedoch leicht, selbstzufrieden zu werden. Warum sehen wir immer noch 3,5-Zoll-Diskettensymbole für „Speichern“-Schaltflächen? Weiß jemand unter 25 überhaupt, was eine Diskette ist? Wir verwenden es weiterhin, weil wir es für repräsentativ halten, aber das ist es wirklich nicht mehr. Es erfordert ständige Anstrengungen, um sicherzustellen, dass die Darstellungen von Steuerelementen für Benutzer aussagekräftig sind, aber es ist auch notwendig und schwierig, dies mit Kontinuität in Einklang zu bringen.
• Wenn ein Warnsystem kaputt geht, muss es erkennbar sein. Wir verwenden häufig Warnleuchten, die bei einem Problem aktiviert werden, z. B. eine blinkende rote Anzeige. Es ist großartig, um die Aufmerksamkeit eines Benutzers zu erregen, aber was passiert, wenn das Licht ausbrennt? Die bei den Apollo-Mondmissionen eingesetzten Raumfahrzeuge hatten Dutzende von Warnlichtern für alle möglichen Systeme, aber sie funktionierten nicht auf herkömmliche Weise. Anstatt zu leuchten, wenn es ein Problem gab, blieben sie beleuchtet, wenn alles in Ordnung war, und gingen aus, wenn es ein Problem gab. Dadurch wurde sichergestellt, dass eine durchgebrannte Warnleuchte den Astronauten keinen möglicherweise tödlichen Systemfehler entgehen ließ. Ich sage nicht, dass Sie dieses Design verwenden sollten, da die Zuverlässigkeit von Glühbirnen seit den 1960er Jahren einen langen Weg zurückgelegt hat, aber es gibt eine Vorstellung davon, wie tiefgreifend einige Ihrer Planungen sein müssen. Wie oft ist ein System abgestürzt, ohne dass Sie davon wussten, weil die Protokollierung oder Benachrichtigungen nicht richtig funktionierten?
• Modusübergänge müssen für den Benutzer offensichtlich sein. Was passiert, wenn ein Airbus A330 vom normalen Steuerungsmodus in den erweiterten Steuerungsmodus übergeht, ohne dass der Benutzer es bemerkt, und das Flugzeug plötzlich Dinge tut, die der Benutzer nicht für möglich gehalten hätte? Was passiert, wenn ein selbstfahrendes Auto seinen Autopiloten deaktiviert und dem Benutzer unerwartet die volle Kontrolle überlässt? Was passiert, wenn es einen größeren Modus- oder Funktionswechsel gibt, der eine sofortige Änderung der Benutzeraktionen erfordert, der Benutzer jedoch ein oder zwei Minuten braucht, um herauszufinden, was gerade passiert ist? Während in einem komplexen System eine Vielzahl von Betriebsmodi erforderlich sein kann, können die Modi nicht ohne angemessene Benachrichtigung, Erklärung und Interaktion mit dem Benutzer dabei wechseln.

Außerbetriebnahme lebenswichtiger Systeme

In Übereinstimmung mit den Best Practices der Branche ist eine Beta-Phase entscheidend für den Einsatz neuer lebenswichtiger Systeme. Tests Ihrer neuen Technologie haben Ihnen möglicherweise dabei geholfen, die meisten Fehler und Benutzerfreundlichkeitsprobleme zu beheben, aber es können versteckte Gefahren auftauchen, wenn sie zusammen mit anderen Systemen in realen Umgebungen verwendet werden muss. In der Systems-Engineering-Disziplin wird dies als „Emergenz“ bezeichnet. Emergente Eigenschaften sind „unerwartete Verhaltensweisen, die aus der Interaktion zwischen den Komponenten einer Anwendung und ihrer Umgebung resultieren“ und von Natur aus in einer Laborumgebung im Wesentlichen unmöglich zu erkennen sind. Indem Sie eine repräsentative Gruppe von Endbenutzern einladen, Ihr neues System unter sorgfältiger Aufsicht zu testen, können viele dieser Eigenschaften erkannt und auf negative Folgen hin bewertet werden, die bei einer vollständigen Bereitstellung auftreten können.

Ein weiteres Thema, das in Architekturdiskussionen mit meinen Kunden oft auftaucht, ist das eines stufenweisen Rollouts. Dies ist die Wahl zwischen dem allmählichen Ersetzen von Elementen eines bereits bestehenden Systems durch Elemente eines neuen Systems, bis schließlich alles ersetzt ist, oder dem Ändern von allem auf einmal. Beides hat Vor- und Nachteile: Ein schrittweiser Rollout ermöglicht eine allmähliche Gewöhnung der Benutzer an das neue Design und stellt sicher, dass Änderungen in überschaubarem Umfang erfolgen und die Benutzer nicht überfordert werden; Andererseits kann es den Prozess über längere Zeiträume hinausziehen und zu einem ständigen Übergangszustand führen. Sofortige Rollouts sind insofern vorteilhaft, als sie „das Pflaster abreißen“ und die Dinge beschleunigen, aber die plötzlichen drastischen Änderungen können die Benutzer überwältigen.

Bei lebenskritischen Systemen habe ich festgestellt, dass stufenweise Rollouts im Allgemeinen sicherer sind, da sie eine inkrementelle Bewertung einzelner Komponenten in einer Produktionsumgebung ermöglichen und kleinere Umkehrungen ermöglichen, wenn etwas zurückgesetzt werden muss. Dies ist jedoch im Einzelfall zu prüfen.

Normalisierung der Abweichung

OK, Ihre Benutzertests haben Ihnen also geholfen, ein intuitives System zu entwerfen, Ihre Betaphase hat aufkommende Probleme identifiziert, Ihre schrittweise Einführung ermöglichte es den Benutzern, sich mit dem Design vertraut zu machen, und alles läuft reibungslos. Du bist fertig, oder? Leider nicht.

Probleme mit Ihrem System werden unweigerlich auftreten, daran führt kein Weg vorbei. Wenn Benutzer auf diese Probleme stoßen, entwickeln sie häufig Problemumgehungen, anstatt das Problem dem Technikteam zu melden. Die Problemumgehungen werden zur Standardpraxis, die als „Tipps“ von Veteranen bis zu Anfängern weitergegeben wird. Die Soziologin Diane Vaughan prägte einen Ausdruck, um dieses Phänomen zu beschreiben: „Normalisierung der Abweichung“. Benutzer gewöhnen sich so sehr an abweichendes Verhalten, dass sie sich nicht daran erinnern, dass es tatsächlich abweichend ist.

Das klassische Beispiel ist das Space Shuttle Challenger: Es wurde regelmäßig beobachtet, dass eine Komponente in den Feststoffraketen-Boostern während des Starts erodierte, und obwohl jeder wusste, dass das Erodieren von Raketenkomponenten eine schlechte Sache ist, kam es so oft vor, dass regelmäßig Ausnahmegenehmigungen ausgestellt und in Betracht gezogen wurden normal. Am 28. Januar 1986 führte das Problem, von dem alle ursprünglich wussten, dass es nicht zugelassen werden sollte, das sie aber normalisiert hatten, zur Explosion von Challenger und zum Tod von sieben Astronauten.

Als Administrator eines lebenswichtigen Systems liegt es an Ihnen, solche Vorkommnisse zu verhindern. Untersuchen Sie, wie Ihre Benutzer mit dem System interagieren. Beschatten Sie sie ein paar Tage lang und sehen Sie, ob sie unerwartete Problemumgehungen verwenden. Versenden Sie regelmäßig Umfragen, um nach vorgeschlagenen Änderungen und Verbesserungen zu fragen. Widmen Sie Zeit und Mühe der Verbesserung Ihres Systems, bevor Ihre Benutzer Wege finden, die Probleme ohne Sie zu umgehen.

Training für Leistung unter Druck

Häufig kommt es zu Ausfällen in lebenswichtigen Systemen, wenn Nutzer unter Stress, Adrenalinschüben und Tunnelblick leiden. Es ist den Piloten der Air France 447 passiert, es ist Sanitätern passiert, die sich nicht erinnern können, wie sie ihren Herzmonitor bei ihrem ersten Patienten mit Herzstillstand bedienen sollen, und es ist Soldaten passiert, die ihre Funkgeräte nicht richtig bedienen können, während sie unter Beschuss stehen.

Ein Teil dieses Risikos wird durch die Verwendung von intuitiven Designs, wie zuvor besprochen, gemildert, aber das allein reicht nicht aus. Besonders in Umgebungen, in denen Hochstress-Szenarien zwar vorkommen, aber selten vorkommen, ist es wichtig, Ihre Benutzer nicht nur in der Bedienung Ihres Systems zu schulen, sondern auch darin, unter solchen Bedingungen klar zu denken. Wenn sich Benutzer Handlungen in Bezug auf den Betrieb von Geräten merken, können sie mit unerwarteten Ausfällen nicht umgehen, weil die gelernten Handlungen möglicherweise nicht mehr angemessen sind; Wenn sie trainieren, unter Stress logisch und klar zu denken, können sie auf sich ändernde Umstände reagieren und Ihrem System helfen, am Leben zu bleiben, wenn etwas kaputt geht.

Fazit

Offensichtlich ist die Entwicklung, Bereitstellung und Wartung lebenswichtiger Software viel komplexer, als in einem einzigen Artikel beschrieben werden kann. Diese Überlegungen können Ihnen jedoch helfen, eine bessere Vorstellung davon zu bekommen, was Sie erwartet, wenn Sie über die Arbeit an einem solchen Projekt nachdenken. Zusammenfassend:

• Innovation ist notwendig, auch wenn alles rund läuft
• Es ist schwer, Führungskräfte davon zu überzeugen, dass sich das Risiko lohnt, aber Zahlen lügen nicht
• Endbenutzer müssen in jeden Schritt des Prozesses einbezogen werden
• Testen und wiederholen Sie Tests mit echten Benutzern in realen Umgebungen unter realistischen Bedingungen
• Gehen Sie nicht davon aus, dass Sie es beim ersten Mal richtig gemacht haben; Auch wenn es funktioniert, kann es unentdeckte Probleme geben, von denen Ihre Benutzer Ihnen nichts mitteilen.
• Schulen Sie Ihre Benutzer nicht nur in der Verwendung des Systems, sondern auch darin, klar zu denken und sich unter Stress anzupassen.

Abschließend möchte ich anmerken, dass in komplexen sicherheitskritischen Systemen irgendwann etwas schief gehen wird, egal wie viel Planung, Tests und Wartung Sie betreiben. Wenn diese Systeme lebenswichtig sind, ist es durchaus möglich, dass ein Ausfall zum Verlust von Leib oder Leben führen kann.

Für den Fall, dass eine solche Tragödie mit etwas passiert, für das Sie verantwortlich sind, wird dies eine erdrückende Last auf Ihrem Gewissen sein, und Sie werden wahrscheinlich denken, dass Sie es hätten verhindern können, wenn Sie mehr Aufmerksamkeit geschenkt oder härter gearbeitet hätten. Vielleicht stimmt das, vielleicht auch nicht, aber es ist unmöglich, alle möglichen Ereignisse vorherzusehen.

Arbeiten Sie akribisch, werden Sie nicht übermütig, und Sie werden die Welt zu einem besseren Ort machen.