Stille und unbekannte Heldinnen und Helden gibt es viele. In diesem Artikel geht es um einen von ihnen - und was Unternehmen und IT-Verantwortliche von ihm noch heute lernen können, dass Scheitern nichts Schlimmes sein muss.
Kennen Sie den Namen Richard Koos? Falls nicht, sind Sie in guter Gesellschaft. Koos bekleidete während der Mercury-, Gemini- und Apollo-Weltraummissionen der USA eine außerhalb der NASA eher wenig bekannte und im Vergleich zu den „Rockstars“ der Weltraumfahrt, den Astronauten, nicht sehr glamouröse Stellung. Seine Position lautete „Simulation Supervisor“, kurz SimSup. Und ohne ihn hätte die Mondlandung sehr wahrscheinlich nie stattgefunden.
Zwar sind eine ganze Menge Menschen für den Erfolg eines so großen Projekts wie der Mondlandung verantwortlich – von den Ingenieuren und Arbeitern, die die Raketen zusammenbauen über die Programmiererinnen und Programmierer, die mit der Entwicklung der Hard- und Software für die Mondfähre echtes Neuland betraten bis hin zu den Besatzungen von Bodenstationen in aller Welt. Jeder einzelne dieser Bereiche hält genug fesselnde Geschichten für mehrere abendfüllende Filme bereit. An schillernden Namen mangelt es nicht – egal ob es sich um einen Wernher von Braun handelt, eine Margaret Hamilton, Katherine Johnson oder eben um Figuren wie Armstrong, Collins und Aldrin.
Die Geschichte, um die es hier gehen soll, und deren Implikationen noch heute eine Rolle spielen, trägt sich elf Tage vor dem eigentlichen Start der Apollo 11-Mission zu. Die Gruppe um SimSup Koos hatte einen einzigen Zweck: Die Besatzungen von Mondfähre und Mission Control in den drei Monaten vor dem Start in realitätsnahen Simulationen gnadenlos durch die Mangel zu drehen. Arbeitstage von 16 Stunden waren keine Seltenheit und ließen die Beteiligten „in einem Zustand jenseits bloßer Erschöpfung“ zurück, wie sich Gene Kranz (unter anderem Flight Director während der Mondlandung und auch bei der späteren Mission von Apollo 13) in seinen Memoiren mit dem Titel „Failure is not an Option“ schreibt.
So anstrengend und nervenaufreibend die Simulationen auch waren, die Koos und seine Kollegen entwickelten – sie waren auch sportlicher Wettkampf. Ein Szenario erfolgreich gemeistert zu haben war Grund zu Feiern. Doch wer übermütig wurde, konnte sich sicher sein, in einer kommenden Simulation rigoros zurechtgestutzt zu werden. Zuweilen zog Koos alle Register und präsentierte den Astronauten und Controllern gleichzeitig verschiedene Probleme mit der Elektronik und der Funkverbindung zur simulierten Landefähre. Zuweilen, so erinnert sich Kranz, hatten die Besatzungen echte Probleme, nicht den Anschluss zu verlieren. An einem besonders heftigen Tag hatte SimSup das Spiel gewonnen, und zwar haushoch. Die erste Landungssimulation war ein Erfolg. Doch zwei folgende Simulationen resultierten in einem Absturz. Das dämpfte den Übermut, der Koos bereits mehrfach aufgefallen war, deutlich.
Es war der eigentlich letzte Simulationslauf vor dem Start der Mondmission. Doch auch wenn die große Mehrheit der offenen Probleme gelöst war und dies die letzte Probe war, stellte das für Koos keinen Grund dar, Milde walten zu lassen. Vor Beginn eines Landeanfluges gab er seinen Mitarbeitern die Anweisung „Laden sie Fall Nummer 26“. Er hatte einen Plan. „Schauen wir mal, was die Jungs über Programm-Alarme wissen.“ Während eines Landeanfluges erhielt der „Guidance and Navigation Officer“ eine Alarmmeldung mit dem Code „1201“. Niemand hatte diese Meldung zuvor gesehen. Außerhalb von Softwaretests am Boden war sie noch nie aufgetaucht. Eine Rückfrage des „Guidance & Navigation“-Spezialisten an das angeschlossene Entwicklungsteam lieferte eine zu diesem Zeitpunkt wenig hilfreiche Antwort: „Aus irgendeinem Grund ist der Computer gerade wahnsinnig beschäftigt. Er hat keine Zeit, alle Tasks zu erledigen“. Schnell kam die Erkenntnis: Für diesen Fall gibt es keinen Plan, keine Prozedur.
Da der Landeanflug eine extrem kritische Phase ist, blieb nicht viel Zeit für eine Entscheidung. So meldete sich der verwirrte Controller bei seinem Flight Director, der die finalen und unangefochtenen Entscheidungen traf: „Flight, irgendetwas stimmt mit dem Computer nicht – ich habe hier einen Haufen Programm-Alarme. Ich glaube wir sollten abbrechen. Abbruch!“ Aufgeschreckt durch das gefürchtete Wort „Abbruch“ meldete sich der für die Kommunikation mit dem Astronauten zuständige Mitarbeiter „Flight, befehlen wir einen Abbruch?“ Kranz entschied schnell: „Bestätigt, CapCom. Abbruch!“
In der Nachbesprechung folgte dann der Schock. Einige der Anwesenden waren sauer auf Koos, weil er ihnen die Landung und damit die erfolgreiche Generalprobe verweigert hatte.
Koos, der wie Kranz schreibt, „einen Verstand hatte, der so rasiermesserscharf war, dass man erst lange nach dem Stoß merkt, dass man blutet“, überraschte alle Anwesenden mit der Ankündigung: „Das war kein Abbruch-Szenario.“. An Kranz gewandt sagte er „Du hast eine der fundamentalsten Mission Control – Regeln verletzt, die besagt, dass du zwei Schlüsselkriterien brauchst, um einen Abbruch zu befehlen. Und du hattest nur eins.“ Das dürfte gesessen haben. Mit einem mehr als schlechten Gefühl in der Magengrube gestand man die Niederlage ein. SimSup hatte dieses letzte Spiel gewonnen. Doch die Spezialisten für die Software des Navigationscomputers nahmen sofort die Arbeit auf. Schnell war eine Liste mit Alarmcodes zusammengestellt, die ein Abbruchkriterium darstellten Für den brutalen Weckruf waren sie Koos letztlich dann doch dankbar.
„Wenn die Generalprobe schiefgeht, dann wird die Premiere um so besser“, lautet ein alter Aberglaube aus der Schauspielerei. Und diese sollte sich auch hier beweisen. So spuckte der Computer beim Landeanflug auf die Mondoberfläche mehrere Fehlermeldungen aus: 1202 und 1201. Keine davon stand auf der Liste harter Abbruchkriterien und die Landung wurde fortgesetzt. Der Rest ist Geschichte.
Vielleicht erwarten Sie jetzt, dass dieser Artikel mit einer Variation von „und deshalb sind Notfallübungen so wichtig – machen Sie doch im Unternehmensnetz für die IT auch mal welche“ schließt. Das wäre aber zu einfach. Was diese Episode aus der Geschichte verdeutlich ist, dass die meisten Dinge nicht so einfach sind wie sie auf den ersten Blick erscheinen.
Technik ist eine wichtige Komponente – ohne sie sind viele Dinge schlichtweg unmöglich. Was aber nicht nur in der verpatzten Generalprobe gefehlt hat, sondern auch immer wieder als Faktor bei brandaktuellen Sicherheitsvorfällen eine Rolle spielt, sind die entsprechenden Prozesse. Beides bildet eine untrennbare Einheit. Wenn hinter der besten Technik kein passender Prozess steht, dann nützt die Technik wenig. Ebenso kann ein Prozess ohne entsprechende Mittel für die technische Umsetzung nie funktionieren. Dem Controller fiel 1969 auf, dass er keinen Prozess hatte welcher in einem solchen Fall zur Anwendung kommen sollte. Er hat nur die Information bekommen, dass der Computer ein Problem hatte und nicht mehr alle Aufgaben erfüllen konnte die ihm gestellt wurden. Der Experte am Boden sowie die Astronauten flogen praktisch blind ins Ungewisse. Und da der Computer einer der zentralen Bestandteile der Mondlandung war, ergibt sich aus einem Computerproblem schnell ein globales Problem für die gesamte Mission. Das wussten auch alle anderen Anwesenden – und so wurde aus einem unvollständigen Lagebild und einem fehlenden Prozess ein Befehl, der im Ernstfall die gesamte Mission hätte scheitern lassen – eventuell sogar mit tödlichem Ausgang, denn ein Abbruch während des Landeanfluges war eines der Albtraumszenarien. Jeder Teil der Abbruchsequenz muss hundertprozentig korrekt ablaufen, wenn man keinen Absturz oder eine Kollision mit dem Raumschiff in der Mondumlaufbahn riskieren wollte.
Genau dieselben Mechanismen kommen auch bei jedem größeren IT-Sicherheitsvorfall zum Tragen. Wenn der Ernstfall eintritt, dann sind definierte Prozesse und klar geregelte Kompetenzen das Wichtigste. Und in dieser fehlgeschlagenen Übung gab es nur eines davon.
Schwachstellen aufzudecken ist das einzige Ziel von Übungen. Das galt damals und das gilt bis heute. Immer nur Dinge zu proben, die schon immer gut liefen bringt einen nicht unbedingt weiter, auch wenn es sich vielleicht gut anfühlt, Erfolg zu haben. Die Komfortzone zu verlassen ist aber das eigentliche Ziel. Natürlich fühlt es sich nicht gut an, eigene Schwächen aufgezeigt zu bekommen. Aber gerade im Kontext eines Unternehmens ist der beste Zeitpunkt dafür eine Übung. Bei einem echten Angriff auf das Unternehmensnetzwerk ist es dafür zu spät. Gleiches gilt für das Lernen aus Übungen. Das muss so schnell wie irgend möglich erfolgen. Bleibt dieser Lerneffekt aus, ist die Katastrophe vorprogrammiert. Schonungslose Ehrlichkeit – auch sich selbst gegenüber – ist der einzige Ausweg. Durchweg berichteten alle Beteiligten, dass sich der echte Mondflug fast wie eine Übung anfühlte – nur die anwesenden Pressevertreter und das Fernsehprogramm erinnerten daran, dass es nun wirklich darauf ankam und dies der „real deal“ war.
Geht etwas schief, dann ist das jedem bewusst und es lässt sich auch nicht wegdiskutieren. Hier passt ein weiteres Zitat aus der Autobiographie des Flight Controllers, mit dem ich hier abschließen will: „Es gibt keine Ausreden. Wenn man versagt hat, gibt es nur zwei Antwortmöglichkeiten. Entweder „Ich hatte Unrecht“ oder „Ich weiß es nicht, aber ich werde es herausfinden“.
Bildnachweis:
Fig. 1: Steven Michael / Flickr
Fig. 2: Brett Sayles / Pexels