Mein 500-Millionen-Dollar-Fehler mit dem Mars-Rover

 (chrislewicki.com)
1 Punkte von GN⁺ 2023-11-29 | 1 Kommentare | Auf WhatsApp teilen
  • Im Februar 2003 stand der Spirit Mars Rover im JPL-Reinraum zwei Wochen vor dem Transport zum Startplatz, als ein Verkabelungsfehler an einer Break-out-Box ein 500 Millionen Dollar teures Raumfahrzeug hätte beschädigen können
  • Spirit und Opportunity waren eine Zwillingsmission von Mars-Rovern, in die die NASA fast 1 Milliarde Dollar investiert hatte; im Zeitplan gab es kaum Spielraum, einen größeren Defekt zu beheben
  • Unmittelbar nachdem ein elektrischer Impuls nicht in den Motor, sondern in Richtung des Raumfahrzeugs gegangen war, brach die Telemetrie ab, doch Schaden und Ursache waren nicht sofort eindeutig
  • Am nächsten Tag stellte sich heraus, dass der Verlust der Telemetrie durch das Entfernen der Messleitungen eines Fluke 87III-Multimeters verursacht worden war; die tatsächliche Überspannung blieb Gegenstand der Analyse des H-Bridge-Motortreiberkanals
  • Nach mehreren Wochen Analyse bewertete das Projekt die Hardware als Use As Is, korrigierte die Prozedur und führte denselben Test weiter durch; der betreffende Motor von Spirit arbeitete auf dem Mars später normal

Der Testunfall bei Spirit kurz vor dem Start

  • Im Februar 2003 stand der Spirit Mars Rover im Reinraum Building 179 High Bay 1 des NASA JPL zwei Wochen vor dem Transport nach Cape Canaveral
  • Spirit und Opportunity waren eine Zwillingsmission von Mars-Rovern und damals hochkomplexe Raumfahrzeuge, in die die NASA fast 1 Milliarde Dollar investiert hatte
  • In der Montage- und Testphase mussten vor dem endgültigen Verschließen auf der Erde alle Systeme des Raumfahrzeugs gründlich geprüft und ihre ordnungsgemäße Funktion bestätigt werden
  • Die beiden Rover enthielten insgesamt 62 brushed-type Motoren
    • Radantrieb und Lenkung
    • Steuerung des Roboterarms
    • Ausrichtung der Kameras
    • Ausrichtung der erdgerichteten Antenne
    • Entfaltungs- und Ausklappvorgänge nach der Landung
  • Das Testobjekt in dieser Nacht war der RAT-Revolve-Motor im Rock Abrasion Tool (RAT) am Ende von Spirits Roboterarm
    • Der RAT-Revolve-Motor dreht auf Marsgestein den Grinder und die Bürste

Das Verfahren zur Prüfung des Motorzustands per elektrischem Signal

  • Es war nicht praktikabel, Motoren nach jedem Umwelttest zu zerlegen und ihr Inneres zu inspizieren
  • Stattdessen wurde der Motor vom Raumfahrzeug getrennt und mit einem externen Netzteil sowie einem Strip-Chart-Recorder verbunden, um seine elektrische Leistung zu prüfen
  • Ein intakter Motor zeigt beim Spin-up einen sanft exponentiell abfallenden Strom; bei Auffälligkeiten erscheint ein Blip im Signal
  • Für den Test wurde eine Break-out-Box verwendet; bei falscher Verkabelung kann ein hoher Strom an die falsche Stelle gelangen und kritische Schäden verursachen
  • Bei der Vorprüfung wurden die Anschluss-Schnittstelle, die Einstellungen des Netzteils, die Konfiguration des Strip-Chart-Recorders und ein kurzer Testimpuls am Referenzmotor jeweils als korrekt bestätigt

Der elektrische Impuls in die falsche Richtung

  • In dem Moment, als Energie auf den RAT-Revolve-Motor gegeben wurde, zeigte das Strip-Chart ein ungewohntes Signal, das auch nicht dem typischen Muster eines defekten Motors entsprach
  • Eine Überprüfung entlang der Verkabelung zeigte, dass der elektrische Impuls wegen eines Fehlers an der Break-out-Box nicht in den Motor, sondern in die entgegengesetzte Richtung zur Steckerschnittstelle des Raumfahrzeugs gegangen war
  • Spirit stand zwei Wochen vor dem Transport für die Startvorbereitung; bei einem größeren Problem wäre keine Zeit für eine Wiederherstellung geblieben
  • Der Vorfall wurde sofort dem Test Conductor Leo gemeldet, und gleichzeitig kam die Rückmeldung, dass die Telemetrie des Raumfahrzeugs ausgefallen sei
  • Das Team führte umgehend die Notabschaltprozedur aus und erhielt die Anweisung, den Reinraum zu verlassen, damit der Hergang und mögliche Schäden bewertet werden konnten

Verlust der Telemetrie und erste Einschätzung

  • Unmittelbar nach dem Vorfall waren zwei Dinge klar
    • Ein großer elektrischer Impuls war an einer anderen Stelle als beabsichtigt eingegangen
    • Die Telemetrie des Raumfahrzeugs war unterbrochen
  • Der Zusammenhang zwischen beiden Ereignissen war zunächst nicht eindeutig
  • Das Team hielt es für wahrscheinlich, dass die elektrische Überspannung in die H-Bridge-Motortreiberschaltung gelangt war
    • Eine H-Bridge ist eine Schaltung zur Steuerung des Stromflusses
    • Sie war einer der Bereiche des Rovers, die wegen back-EMF dafür ausgelegt waren, zusätzliche Energie zu verkraften
  • Das Raumfahrzeug war bereits abgeschaltet, und das Team beschloss zu prüfen, ob sich das Problem durch erneutes Einschalten beheben ließ
  • Gegen Mitternacht erreichte die Unfallmeldung auch Projektmanager Pete; auf dem Spiel stand eine mögliche Neuplanung eines Projekts mit rund 1.000 Beteiligten

Fehlgeschlagener Neustart und die tatsächliche Ursache am nächsten Tag

  • Die standardmäßige Prozedur zum Einschalten des Raumfahrzeugs wurde erneut ausgeführt, doch auch nachdem Elektronik und Software hochgefahren waren, kehrte die Telemetrie nicht zurück
  • Im Rack der Bodensupport-Ausrüstung gab es eine rote Anzeige, die bei jedem Taktzyklus einen Puls erhielt und aufleuchtete; sie diente mit 8 Impulsen pro Sekunde wie ein robotischer Herzschlag
  • Das Netzteil zeigte die vertrauten Spannungsschritte und Stromänderungen, doch die Anzeige leuchtete nicht auf und es kam keine Telemetrie
  • Bei der erneuten Rekonstruktion der Ereignisfolge am nächsten Tag wurde ein digitales Fluke 87III-Multimeter zum entscheidenden Hinweis
  • Als am Vortag nach einem für den Test benötigten Multimeter gesucht wurde, hatte man die Messleitungen eines Multimeters entfernt, das in der Nähe des Raumfahrzeugs offenbar die Busspannung überwachte
    • Dieses Multimeter schloss tatsächlich den Stromkreis für die Telemetrieversorgung des Bodentests des Raumfahrzeugs
    • In dem Moment, als die Messleitungen entfernt wurden, wurde die Stromverbindung der Telemetrie unterbrochen

Spirit lebte, und die Hardware blieb im Einsatz

  • Das Team stellte das Multimeter wieder in seine ursprüngliche Funktion zurück und schaltete das Raumfahrzeug erneut ein
  • Die Telemetrie kam zurück, und es wurde bestätigt, dass Spirit nicht ausgefallen war
  • Der tatsächliche Verlust belief sich nur auf einige Stunden, und der Test wurde wieder aufgenommen
  • In den folgenden Wochen analysierte man den H-Bridge-Kanal des RAT-Revolve-Motors weiter; es folgten detaillierte Diskussionen über die Möglichkeit einer Thin-Film-Demetallisierung
  • Am Ende bewertete das Projekt die betreffende Hardware als Use As Is
  • Die Startvorbereitungen gingen weiter, und nach Spirits Ankunft auf dem Mars arbeitete der RAT-Revolve-Motor normal

Umgang mit Erfahrungen des Scheiterns

  • Dieser Vorfall führte zu der Überzeugung, dass das Teilen von Erfahrungen des Scheiterns sowohl für die erzählende als auch für die zuhörende Person lehrreich sein kann
  • Bei Planetary Resources wurden Bewerber im Einstellungsprozess und in der Teamkultur gebeten, ihre eigene Failure Story zu teilen
  • Mitten in der Krise sagte Ernie: „Wenn du das nächste Mal etwas als in Ordnung freigeben sollst, erinnere dich an dieses Gefühl.“
  • Nach dem Vorfall waren einige der Meinung, man müsse den riskanten Test einstellen, doch wegen der Wichtigkeit, zu prüfen, ob der Motor auf dem Mars normal arbeiten würde, wurde der Test fortgesetzt
  • Projektmanager Pete ließ dieselbe Person den Test weiter leiten und entschied sinngemäß: „Wir haben sein Lehrgeld bezahlt, und er ist jetzt die Person, die diesen Fehler am wenigsten wahrscheinlich noch einmal macht.“
  • Anschließend wurde die Prozedur geändert, damit derselbe Fehler nicht erneut auftrat, und derselbe Test wurde mehrfach wiederholt
  • Diese Erfahrung wurde zu einem Bezugspunkt, der bei wichtigen Freigaben oder Zusicherungen die damalige Angst und Reue wieder ins Gedächtnis ruft

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-29
Hacker-News-Kommentare

  • Der Artikel ist wirklich gut geschrieben.
    Als Software Engineer erinnert mich das immer noch an etwas Ähnliches, das mir früh in meiner Karriere passiert ist. Vor etwa zehn Jahren baute ich über mehrere Monate für einen Beratungskunden eine neue Version seines Webservices und war am Launch-Tag für das Deployment zuständig. Damals waren Entwicklungs- und Deployment-Prozesse fast komplett manuell. Die Teile, die möglich waren, hatte ich mit Skripten und SQL automatisiert, und in dem Moment, als ich für den letzten Test direkt vor dem Deployment Enter drückte, merkte ich, dass ich gerade auf die Produktions-Credentials umgestellt hatte.
    Als sich Fehler häuften und der Service nicht mehr reagierte, war ich überzeugt, die Datenbank zerstört zu haben. Aber weil ein paar Stunden zuvor jemand zur Vorbereitung des Launches ein Backup abgeschlossen hatte, ließ sich das meiste wiederherstellen. Seitdem ist „Vorsicht“ für meinen Umgang mit Datenbanken und Produktionssystemen noch viel zu schwach formuliert, und ich schwor mir, so etwas nie wieder zu tun.

    • Auch bei uns gibt es wegen unserer Event-Sourcing-Architektur nur selten direkten Zugriff auf die Produktionsdatenbank. Wenn es nötig ist, öffnet ein Shell-Skript einen Tunnel über einen Bastion Host und setzt die Standard-Umgebungsvariablen für die Postgres-Client-Konfiguration.
      Unsere Testsuite löscht während der Ausführung Tabellen und erstellt sie neu oder leert sie. Eines Tages führte der Lead Developer nach einer Bugfix-Recherche auf der Produktions-DB make test aus. Der Testcode folgte einfach den Umgebungsvariablen und verband sich nicht mit Docker, sondern mit der Produktion – und löschte und erstellte diese Produktionstabellen sofort Dutzende Male neu.
    • Vor etwa zehn Jahren arbeitete ich als Berater irgendwo, wo ein interner Mitarbeiter eines anderen Produkts gleichzeitig in zwei verschiedenen Fenstern in der Entwicklungs-DB und der Produktions-DB eingeloggt war und versehentlich die Produktionsdatenbank löschte. Beim Wiederherstellungsversuch stellte sich heraus, dass die Backups seit Monaten fehlschlugen – und damit wurde ziemlich klar, warum sie Consultants angeheuert hatten, um beim neuen Produkt zu helfen.
      Zum Glück gab es an jedem Kundenstandort eine lokale DB, die mit der zentralen DB synchronisiert wurde, sodass das Produkt auch bei unterbrochener Verbindung weiterlief. Er arbeitete drei bis vier Tage lang lange Schichten und rekonstruierte die Master-DB aus einem alten Backup und den Kundendaten.
    • Ich habe einmal aus Visual Studio heraus eine Migration auf der Produktionsdatenbank ausgeführt. Rückblickend wäre das wiederherstellbar gewesen, aber in dem Moment, als in der Baumansicht von VS alle Tabellen zu verschwinden begannen, blieb mir fast das Herz stehen.
      Eine Sekunde später tauchten sie wieder auf; die Ansicht hatte sich nur aktualisiert. Wirklich eine furchtbare UI.
    • Vor etwa 15 Jahren, kurz bevor ein langes Wochenende begann und ich gerade gehen wollte, bat mich eine befreundete Marketing-Mitarbeiterin um eine schnelle Änderung auf einer Kundenseite. Wir waren eine kleine Firma mit etwa 15 Leuten und hatten mehr Kunden, als wir stemmen konnten, deshalb hatte ich Zugriff auf die Produktionsdatenbank, den ich eigentlich nicht hätte haben sollen.
      Um den Marketingtext eines Produkts zu ändern, schrieb ich eine kurze UPDATE-Query. Als sie nicht sofort fertig war, wusste ich, dass ich Mist gebaut hatte: Ich hatte ohne Bedingung alles aktualisiert und damit Tausende Produktbeschreibungen geändert. Der DBA mit Zugriff auf die Backups war in einer anderen Zeitzone und schon im Feierabend; nach über einer Stunde Telefonieren konnten wir es wiederherstellen.
      Aus einer schnellen Änderung auf dem Weg nach draußen wurden mehrere Stunden Schadensbegrenzung, und meine Freundin aus dem Marketing entschuldigte sich immer wieder, aber der Fehler war meiner. Dass von Kunden kaum etwas kam, lag meiner Meinung nach daran, dass es Freitag um 17 Uhr vor einem Feiertagswochenende war.
    • An einem Arbeitsplatz vor etwa 20 Jahren gab es die Regel, dass bei einem sudo-Befehl eine andere Person den Befehl prüfen musste, bevor man Enter drückte. Eine ähnliche Regel oder Praxis lässt sich auf alles anwenden, was in Produktion passiert.

  • Mir fällt der Satz ein: Wenn ein Praktikant die Produktionsdatenbank löscht, ist das kein schlechter Praktikant, sondern ein schlechter Prozess.
    Ob das hier ein Prozessproblem oder ein menschliches Problem ist, lässt sich wegen der höheren Erwartungen an Festangestellte nicht leicht beurteilen. Aber als ich mich in seine Lage versetzte, kam beim Lesen die Angst und der Schmerz hoch, die man in dem Moment spürt, in dem man begreift, was passiert ist. Einschließlich dieses Gefühls, wenn ein Hoffnungsschimmer scheitert und dann doch wieder auflebt. Ich habe noch nie ein Projekt verantwortet, von dem so viele Menschen abhängen.
    Nach meinem Maßstab sind sie alle Helden.

    • Bei einer großen Investmentbank berührte ein Testskript versehentlich die Produktion und erzeugte fingierte FX-Test-Trades im Wert von mehreren Millionen Dollar.
      In der Postmortem-Telko lautete der erste Satz: „Wir werden nicht der Person die Schuld geben, die diese Trades erzeugt hat. Es war ein ehrlicher Fehler. Lasst uns stattdessen besprechen, warum ein Entwickler ohne Authentifizierung die Produktions-Trading-API ansprechen konnte.“
    • Bei solchen organisatorischen Fehlern sollte man nicht Einzelpersonen die Schuld geben. Ich sehe zwei Prozessprobleme: Wenn man den Stecker falsch herum anschließen konnte, hätte man das entweder von vornherein unmöglich machen oder das Risiko identifizieren und mindestens zwei Personen die Richtung prüfen lassen müssen. Und Werkzeuge wie das verwendete Multimeter sollten niemals getrennt werden.
      Wenn man Einzelpersonen beschuldigt, wird nur diese Person gefeuert und die gesamte Organisation wird schwächer. Man schickt damit die einzige Person weg, die eine teure Lektion gelernt hat. Einzelpersonen sollte man nur dann verantwortlich machen, wenn sie die Absicht hatten, Schaden anzurichten; dann kann auch das Rechtssystem eingreifen.
    • An meinem ersten Tag im ersten Webentwicklungsjob nach der Schule habe ich die Produktionswebsite lahmgelegt. Zehntausende Besucher waren betroffen und alle Sales-Leads standen still, aber wir brachten sie innerhalb weniger Minuten wieder hoch und ich überstand einen harten Moment, während das ganze Team und der CEO im Nebenraum zusahen.
      Als ich ein paar Jahre später ging, hatten wir diese fragile, instabile Website in ein System mit automatisierten Tests, mehrstufigen Backups, Failover über mehrere Rechenzentren sowie Training und Onboarding für neue Entwickler verwandelt. Das war in den frühen AWS-Zeiten, als Produktionssites noch nicht per Ein-Klick-Deployment ausgerollt wurden.
      Durch diese Erfahrung lernte ich saubere Versionsverwaltung, Entwicklungsumgebungen, Redis, Sharding und Clustering, VMs, Replikation mit Postgres und MySQL, Wikis, monit, DNS, Load Balancer, Reverse Proxies und mehr. Denn ich wollte die Site nie wieder zum Absturz bringen.
      Es war eine kleine Firma, die einem Highschool-Abbrecher mit ein bisschen WordPress-Erfahrung 15 Dollar pro Stunde zahlte und ihm die Produktionswebsite anvertraute. Aber sie feuerten mich nach dem Fehler nicht, sondern gaben mir das Vertrauen und die Freiheit, vor Ort zu lernen und das System zu verbessern. Dafür bin ich bis heute dankbar.
    • Dieser Fall ist anders. Es war ein maßgeschneiderter Einzel-Rover, der zum ersten Mal seinen Namen trug, und es gab bereits alle möglichen Prozesse, aber man kann nicht alles vorhersehen. Wahrscheinlich haben sie den Prozess danach verbessert, aber man sollte nicht vergessen, dass es auch für sie das erste Mal war.
      Mehr Regeln und bessere Prozesse sind nicht immer nur gut. Manchmal macht Bürokratie die ohnehin langsame NASA noch langsamer. Bei einer Mission ihrer Art muss man sich manchmal auf Menschen statt auf Prozesse verlassen und Risiken eingehen.
    • Ich kann nicht anders, als darüber nachzudenken, was passiert wäre, wenn der Rover tatsächlich zerstört worden wäre. Dass es verhindert wurde, wirkt wie reines Glück, und es hätte genauso gut sein können, dass er an einen anderen falschen Leiter ohne Schutzschaltung angeschlossen worden wäre.
      Mit anderen Worten: Ein Teil der Entscheidung lag außerhalb der Fähigkeiten des Autors, und es bestand genauso die Möglichkeit, dass er, wie befürchtet, für immer als die Person in Erinnerung geblieben wäre, die den Rover ruiniert hat.

  • Das deckt sich stark mit meinen eigenen Erfahrungen. Bei einer großen Fluggesellschaft habe ich mir oft die schwierigsten und riskantesten Projekte ausgesucht, und eines davon war, sehr schnell einen neuen Payment Provider für die Website zu implementieren. Die Seite verkaufte jeden Tag Tickets im Wert von mehreren Millionen Euro.
    Wenige Sekunden nach dem Deployment fiel auf, dass ich einen Unterschied zwischen Test- und Produktionsumgebung übersehen hatte und eine zentrale Variable in Produktion leer war. Mit mehr Dokumentation und Vorbereitung hätte man das vorhersehen können; der Verkauf kam komplett zum Stillstand und mir rutschte das Herz in die Hose. Nach einem langen Rollback-Prozess war der Verkauf mehrere Stunden unterbrochen, wütende Kunden häuften sich, und es entstand ein Schaden in Millionenhöhe.
    Ich fing den CEO im Aufzug ab und sagte ihm, es sei vollständig mein Fehler und ich würde alle Konsequenzen akzeptieren, einschließlich einer Entlassung. Er lachte und antwortete sinngemäß: „Warum sollte ich Sie gehen lassen? Wir haben gerade Millionen dafür ausgegeben, Sie auszubilden. Sie können Ihre Arbeit jetzt besser als gestern.“ Diese Erfahrung war in vielerlei Hinsicht prägend, auch in Bezug auf echte Führung, und danach brachte ich viele weitere Hochrisiko-Projekte erfolgreich zu Ende.

    • Die Formulierungen sind zu glatt, und Details wie der direkte Gang zum CEO oder die Kombination aus „Top-Performer“ und „das Unternehmen hat Millionen verloren“ wirken etwas unplausibel; es fühlt sich an, als sei es von einem LLM geschrieben oder zumindest ausgeschmückt worden.
    • Bei Buchungsseiten von Fluggesellschaften habe ich oft das Gefühl, dass sie mehr als die Hälfte der Zeit irgendwo kaputt sind. Nicht unbedingt komplett leer, aber häufig so kaputt, dass man kein Ticket buchen kann; da wäre mir ein leerer Bildschirm fast lieber. Dann verschwende ich wenigstens keine 30 Minuten.
      Das Internet insgesamt ist auch oft kaputt. Beim Bezahlen im Nike-Webshop am Black Friday gibt es Fehler, und die Lösung des Helpdesks lautet dann: „Benutzen Sie die App.“
    • Der Verlust war vielleicht nicht so groß, wie man denkt. Da einige Stunden lang niemand Tickets kaufen konnte, hat man theoretisch den Umsatz von mehreren Millionen in diesem Zeitraum verloren, aber das setzt voraus, dass die Leute es später nicht noch einmal versuchen.
      In der Praxis glaube ich nicht, dass Ausfallzeit eins zu eins in Verlust umgerechnet wird. Das frühe Twitter war wegen seiner Popularität und Architektur häufig down, aber die Leute haben deshalb nicht aufgehört, Twitter zu benutzen.
      Bei Online-Diensten ist ein Ausfall nicht automatisch eine Katastrophe oder das Ende des Unternehmens. Anders ist es bei Raumfahrtgerät oder High-Frequency-Trading-Software, die eine Firma ruinieren kann; deshalb sollte es dort strengere Kontrollmechanismen geben. Theoretisch jedenfalls; in der Praxis ist es manchmal schlechter als ein schlampiger CRUD-Webservice, der nach Best Practices gebaut wurde, die man aus der Raumfahrt- oder HFT-Branche gelernt hat.
    • Als Verantwortlicher einer Fluggesellschaft hätte ich mir vermutlich eine Reaktion gewünscht, die eher dem Geist einer Post-Mortem-Analyse nach einem Flugunfall entspricht. Es sollte darum gehen, systemische Ursachen zu finden und zu beheben.
      Für Produktions-Deployments braucht man vielleicht jemanden, der wie ein Co-Pilot mitprüft und die Befugnis hat, den Rollout zu stoppen, zusammen mit den üblichen DevOps-Schutzmechanismen.
    • Das erinnert an den alten Witz, der mit „Warum sollte ich Sie entlassen? Wir haben gerade Millionen für Ihre Ausbildung ausgegeben!“ endet.
      Menschen, die Hochrisiko-Projekte übernehmen, werden oft unterschätzt. Viele Manager bevorzugen Mitarbeiter, die zuverlässig keinerlei Wert schaffen, gegenüber solchen mit positivem Erwartungswert, aber hoher Varianz.

  • Ich arbeite in der TV-Branche. In meinem ersten Job bei einem kleinen Regionalsender vor 30 Jahren wurde ich als Tape Operator für die Nachrichtensendung eingelernt. Die Sendebänder lagen in großen Stapeln herum, und es gab vier Wiedergabe-VTRs. Meine Aufgabe war es, jedes Band einzulegen und auf den Punkt eine Sekunde vor dem Start vorzuspulen.
    Wenn ein Band abgespielt war und herausgenommen werden sollte, war es sehr leicht, statt beim gerade beendeten VTR die Auswurftaste des gerade auf Sendung befindlichen VTR zu drücken. Derjenige, der mich einarbeitete, gab jedes Mal, wenn ich zur Auswurftaste griff, ein lautes Warnsignal von sich, indem er die Zähne zusammenbiss und scharf einatmete. Dieses Geräusch brachte mich dazu, innezuhalten, zwei- und dreimal zu prüfen und erst dann das Band herauszunehmen.
    Es war wirklich nervig, aber wirksam, um mich zur Vorsicht zu konditionieren. Die Senderregel lautete: Beim ersten Auswerfen eines Bandes während einer Live-Sendung gab es einen unbezahlten freien Tag, beim zweiten Mal Bewährung, beim dritten Mal die Entlassung. Einige Kollegen verloren wegen chronischer Unachtsamkeit ihren Job und ruinierten Nachrichtensendungen. Dank dieses nervigen Trainers lernte ich, zu prüfen und noch einmal zu prüfen, und ich habe nie ein Band während der Ausstrahlung ausgeworfen.

    • Das erklärt, warum die alten Pannensammlungen aus dem Fernsehen, die Anfang der 80er beliebt waren, oft genau so aussahen: Ein Reporter sagt etwas, während im Hintergrund völlig falsche Bilder laufen.

  • Ich stimme zu, dass jemand, der so einen Fehler gemacht hat, denselben Fehler nie wieder macht. Deshalb ist es normalerweise eine schlechte Entscheidung, jemanden zu entlassen, der technisch einen Fehler gemacht hat und offensichtlich darunter leidet.
    Aber ich sehe darin nicht die „eigentliche“ Lehre. Wenn man Kosten und Risiko berücksichtigt, lautet die Lehre: Bauteile, die mit großen Stromspitzen getestet werden, sollten dedizierte Teststeckverbinder bekommen, die nicht mit rauchanfälligen Teilen kompatibel sind.
    Das ist kein kleines Breadboard-Projekt, sondern ein riesiges Projekt, das von vielen Menschen in einer Regierungsbehörde gebaut wurde, wo formale Verfahren viel Zeit und Geld kosten und manchmal auch verspottet werden. Die Logik „geben wir einem 28-Jährigen einen 500-Millionen-Dollar-Roboter, der explodieren kann, wenn man einmal abrutscht“ klingt sehr merkwürdig.

    • Dass es so konstruiert sein sollte, dass man es nicht falsch einstecken kann, stimmt. Tatsächlich vermute ich, dass das meiste so entworfen war, aber es können trotzdem Fehlkonfigurationen entstehen, die in der Entwurfsphase nicht bedacht wurden.
      Besonders bei Tests hat man oft mit kundenspezifischen Kabeln, Steckverbindern und Schaltungen zu tun, die von der „normalen Konfiguration“ abweichen. Die Lehre ist meiner Ansicht nach, wichtige Arbeiten möglichst nach dem Vier-Augen-Prinzip durchzuführen. Ein Vorgehen, bei dem eine Person die Arbeit macht und eine andere jeden Schritt überprüft, bevor es weitergeht, ist sehr effektiv darin, solche „dummen Fehler“ wie im Artikel abzufangen.
      Allerdings können wegen Termindruck und Ähnlichem nicht immer zwei Personen einen Test begleiten, daher passieren solche Fehler in der Realität. Man muss das Gesamtsystem robust machen.
    • Das dachte ich anfangs auch. Allerdings ist diese Entscheidung schwierig, wenn es sich um Einmal-Equipment handelt, das nur einen einzigen Testzyklus durchläuft.
      Auch im Computing gibt es viele ähnliche Arbeiten, die als Teil eines Upgrades oder einer Migration an Produktionsdatenbanken oder Router-Konfigurationen genau einmal ausgeführt werden. Manchmal sind die Kosten für Sicherheitsvorkehrungen höher, als von Anfang an vorsichtig zu sein. Wir sind nicht immer perfekt vorsichtig, aber auch Sicherheitsvorkehrungen werden nicht immer perfekt gebaut, und manchmal vertrauen wir auf fehlerhafte Sicherheitsvorkehrungen und machen dadurch ähnliche Fehler.
      In der geschilderten Situation hätte es möglicherweise so etwas wie Pair Programming in Hardwareform geben müssen: einen Partner, dessen einzige Aufgabe es ist zu verifizieren, dass alles, was der Autor tut, korrekt ist. Nicht eine Assistenz, die wie Mary mit aufgeteilten Rollen hilft, sondern eine Person, deren einzige Aufgabe es ist, mitzugehen und zu prüfen.
    • Wenn man genau liest, ging die Leistung in die Leistungs-Ausgangsleitungen der H-Brücke, und die H-Brücke ist robuste Elektronik, sodass am Ende nichts beschädigt wurde. Das Abschalten war irrelevant.
      Wäre sie auf die Datenleitungen des Motorcontrollers gelangt, wäre sehr wahrscheinlich etwas durchgebrannt. Man kann nicht ausschließen, dass die Steckverbindertypen unterschiedlich waren, aber die beiden falsch verbundenen Steckverbinder waren definitiv demselben Typ zugeordnet.
    • Als die Menschheit zum ersten Mal auf dem Mond landete, lag das Durchschnittsalter der Ingenieure im Mission Control bei 28 Jahren.
    • Da ich in dieser Branche arbeite, kann ich erklären, wie so etwas passieren kann. Selbst bei teuren Projekten kann man nicht überall eindeutige Steckverbinder erzwingen. Anforderungen konkurrieren miteinander.
      Insbesondere bei Steckverbindern gibt es viele konservative Anforderungen: bereits zertifizierte Produkte, bestimmte Deratings, Pin-Abstände, geerdete Backshells und Ähnliches. Am Ende gibt es nur einige wenige Steckverbinder-Serien, die verwendet und bevorratet werden, und es ist unabhängig von den Kosten unrealistisch, sie vollständig überschneidungsfrei zu machen. Normalerweise versucht man, gleiche Signale zu standardisieren oder sie eindeutig und ohne Überschneidungen zu gestalten.
      Zum Beispiel benötigen externe Steckverbinder eines Raumfahrzeugs buchsenartige Steckverbinder, um Kurzschlüsse während der Handhabung zu verhindern, während ein Zwischenkabelbaum nie entfernt wird und pinartige Steckverbinder symmetrisch angebracht sein können. Wenn dann eine Breakout-Box für Tests benötigt wird, entsteht die Möglichkeit, die Box verkehrt herum anzustecken.
      Oder eine Seite der Breakout-Box hat einen 100-Pin-Steckverbinder, und die andere Seite muss mit 25 Testgeräten verbunden werden. Es gibt keine 25 unterschiedlichen Steckverbinder zur Auswahl, und man kann auch nicht allen Testgeräten kundenspezifische Anforderungen aufzwingen.
      Raumfahrzeuge bewegen sich zunehmend in Richtung lokaler Mikrocontroller und lokaler Diagnose, sodass solche Testgeräte für alle analogen Signale seltener werden. Auch Motoren wären heutzutage eher bürstenlos, und statt einer solchen Breakout-Box würde man sich bei Tests und im Flug auf die Telemetrie des Motortreibers verlassen.
      Auch Steckverbinder in der Luft- und Raumfahrt werden, wie in anderen Branchen, zum Zeitpunkt der Bestellung stärker konfigurierbar; man kann Keys hinzufügen, sodass selbst bei 10 „gleichen“ Steckverbindern jeder nur an seinen vorgesehenen Platz passt. Trotzdem ist es weiterhin unrealistisch, zu verlangen, dass jedes Testgerät so konfiguriert wird.

  • Der Vollständigkeit halber füge ich auch meine Geschichte hinzu. Mein erster Job nach dem College war bei einem Content-Marketing-Startup, das PHP und PerconaDB (MySQL) verwendete. Ich hatte nicht viel PHP-Erfahrung, aber das unbegründete Selbstvertrauen eines Berufseinsteigers. Außerdem hatte ich nach dem Abschluss sechs Monate lang keinen Job gefunden und wollte unbedingt einen guten Eindruck machen.
    Ich bekam die Aufgabe, ein Feature-Flag so zu aktualisieren, dass eine neue Funktion für alle Kunden aktiviert wird, außer für diejenigen, die ausdrücklich deaktiviert bleiben wollten. Die Flags waren in der Datenbank als die Ganzzahlen 4 und 5 innerhalb eines String-Arrays gespeichert.
    Um die nötige Arbeit zu erledigen, verwendete ich die PHP-Funktion array_reverse, las aber die Dokumentation nicht und wusste daher nicht, dass ohne zweites Argument nur die Werte umgedreht werden, nicht die Keys. Im Ergebnis wurde die Datenbank genau entgegengesetzt zu dem verändert, was nötig gewesen wäre, und seltsamerweise kam es durch die QA.
    Ein paar Stunden später wurde es bemerkt, und da ich damals fast drei Stunden pro Strecke pendelte, war zu diesem Zeitpunkt bereits das Management involviert. Es ließ sich mit einem umgekehrten Skript leicht beheben, aber dabei kamen mehrere Probleme ans Licht, etwa QA und fehlgeschlagene DB-Backups.
    Am nächsten Tag kam der Lead Architect zu mir und sagte, das sei eine Art Initiationsritus bei der Arbeit mit PHP und er selbst habe zu Beginn seiner Karriere denselben Fehler gemacht. Daran erinnere ich mich bis heute und bin ihm dankbar. Letztlich wurde ich entlassen, und obwohl es mir geholfen hat, als Ingenieur zu wachsen, waren dieser Moment und die Wochen danach definitiv entmutigend.

    • Sie haben dich wegen dieses array_reverse-Fehlers entlassen?

  • Die Geschichte war fesselnd geschrieben, aber auch verwirrend
    Dieses Team scheint nicht einen Fehler gemacht zu haben, sondern mehrere. Unklar ist auch, ob das Ergebnis das Raumfahrzeug tatsächlich hätte beschädigen können oder ob nur Zeit und Verwirrung darüber verschwendet wurden, warum es sich nicht einschalten ließ
    Der erste Fehler war, nicht zu wissen, dass das Multimeter nicht nur gemessen, sondern den Stromkreis geschlossen hat. Das klingt nach einem wirklich schlechten Design, und wenn es unbedingt so sein musste, hätte dieses Multimeter niemals angerührt werden dürfen. Das ist nicht der Fehler einer einzelnen Person, sondern ein Problem, in das mindestens zwei Personen, deren Vorgesetzte und die Verantwortlichen verwickelt sind, die ein solches System zugelassen haben
    Der zweite Fehler lag bei der Breakout-Box. Man ging davon aus, dass Strom fälschlich in Richtung des Raumfahrzeugs geschickt worden war, und als sich das Raumfahrzeug nicht einschalten ließ, schloss man, dass eine Spannungsspitze es beschädigt habe. Tatsächlich war man sich aber nicht sicher, wohin der Strom geflossen war und was beschädigt wurde, und lag am Ende falsch
    Der Grund, warum sich das Raumfahrzeug nicht einschalten ließ, war, dass das Multimeter vor dem Vorfall aus dem Stromkreis entfernt worden war. Der Satz, dass wochenlange Analysen des H-Brücken-Kanals des RAT-Revolve-Motors und Diskussionen über eine mögliche Dünnschicht-Entmetallisierung folgten, ist für mich weiterhin verwirrend: Bedeutet das, dass man annahm, die fehlgeleitete Spannungsspitze sei durch diesen Kanal geflossen und könnte ihn beschädigt haben?

    • Außerdem fehlt, dass der Telemetrieverantwortliche Leo den Telemetrieverlust erst meldete, als er dem Erzähler sagte, dass dieser einen Fehler gemacht hatte. Hätten nicht alle Tests abgesagt werden müssen, bis die Telemetrie wieder da war?
    • Das Raumfahrzeug selbst ließ sich ganz normal einschalten. Weil das Multimeter den Telemetrie-Stromkreis verbunden hatte, erhielt man nur keine Informationen, bis dieser Stromkreis wiederhergestellt war
      Der Strom ist tatsächlich in diesen Stromkreis geflossen, und man versuchte zu beurteilen, ob er beschädigt worden sein könnte. Allerdings sollte der Motortreiber Strom aushalten können, der vom Motor zurückkommt, also ging man wohl davon aus, dass er nicht beschädigt wurde

  • Als Maschinenbau- und Luft- und Raumfahrtingenieur wünschte ich, meine schlimmsten Geschichten wären nur solche, in denen der Hauptcomputer eines unbemannten 500-Millionen-Dollar-Rovers beinahe gebrickt worden wäre
    Ich war leitend dafür zuständig, sicherheitskritische Freigaben für Dinge zu erteilen, die Menschenleben tragen. Ich musste mit dem Gefühl umgehen, nach einem Absturz Fotos zerbrochener Teile anzusehen und zu denken: „Was, wenn meine Berechnung falsch war?“, „Was, wenn meine Verbindung verrutscht ist?“, „Was, wenn es an einem ungeeigneten Testverfahren zur Vorhersage beschleunigter Ermüdungslebensdauer oder zu Spannungsrisskorrosion lag?“, „Was, wenn wir es vor der Auslieferung nicht entdeckt haben, weil die Produktionsfreigabe überstürzt wurde?“
    Es ist interessant, Berichte über Fehlschläge in ähnlichen Bereichen zu lesen, aber die Geschichten, die öffentlich auf HN geteilt werden, lassen mich denken, dass arbeitsbedingte PTSD kein Wettbewerb ist. Für manche Leute kostet die Behandlung einfach nur mehr

    • Mir fällt eine Passage aus einem Roman einer Autorin ein, die ich mag. Sie kommt, nachdem ein Schweißausbilder eine ziemlich wörtliche Post-mortem-Anekdote zu gefälschten Sicherheitsprüfungen erzählt hat

      He gathered his breath. “This is the most important thing I will ever say to you. The human mind is the ultimate testing device. You can take all the notes you want on the technical data, anything you forget you can look up again, but this must be engraved on your hearts in letters of fire.

      “There is nothing, nothing, nothing more important to me in the men and women I train than their absolute personal integrity. Whether you function as welders or inspectors, the laws of physics are implacable lie-detectors. You may fool men. You will never fool the metal. That’s all.”

      He let his breath out, and regained his good humor, looking around. The quaddie students were taking it with proper seriousness, good, no class cut-ups making sick jokes in the back row. In fact, they were looking rather shocked, staring at him with terrified awe.
      -- Lois McMaster Bujold, Falling Free

    • Zum letzten Absatz hatte ich denselben Gedanken. Die Stelle im Original, in der es heißt: „Ich bin sofort wieder in diesem Moment — der Raum, das Licht, der Stuhl, auf dem ich saß, der Tisch, das absackende Gefühl im Magen …“, klang wie eine Traumareaktion
      Es ist gut, dass er diese Energie nutzen konnte, um besser zu werden, aber nicht alle reagieren auf Trauma auf dieselbe Weise, und solche Reaktionen lassen sich auch nicht leicht vergleichen. Als Einstellungsfrage zum Beispiel scheint mir das zu viele soziale Variablen zu haben
    • Bei dem Teil „nach einem Absturz Fotos zerbrochener Teile anzusehen und zu denken: ‚Was, wenn meine Berechnung falsch war?‘“ frage ich mich, ob das am Ende zwangsläufig auf irgendjemanden zurückfällt
      Selbst wenn es ein Detail war, das die Verfahren nicht erfassen konnten, gibt es doch jemanden, der dafür verantwortlich ist, gute Verfahren zu schaffen. Es kann viele Faktoren geben, aber letztlich scheint es doch jemanden zu geben, der ziemlich unmittelbar Verantwortung trägt
      Interessant, wenn man darüber im Kontext von Software Engineering oder der Gesellschaft insgesamt nachdenkt, wo individuelle Fehler einem Kollektiv zugerechnet werden
    • Ich wünsche mir aufrichtig, dass es in der Luft- und Raumfahrt mehr Menschen wie dich gibt und weniger von denen, die das MCAS der Boeing 737 MAX erdacht, implementiert und freigegeben haben
    • Es überrascht mich, dass es keine Gruppenberatung für Ingenieure gibt, oder dass sie, falls es sie gibt, schwer zu finden ist. Ich arbeite zwar nicht in einem Hochrisikobereich, war aber oft in der Rolle, mir die Geschichten von Leuten aus der Luftfahrt oder dem Bahnbereich anzuhören
      Wenn man empathisch ist und nicht die Haltung einnimmt „wo die Rakete nach dem Start herunterkommt, ist nicht Sache meiner Abteilung“, kann das ziemlich belastend sein. Es wäre gut, Peer-Support-Gruppen für Menschen zu haben, die sicherheitskritische Systeme bauen oder mit deren Nachwirkungen umgehen. Unternehmen bieten nicht immer gute Beratung an
      Ingenieurverbände oder Kammern für zugelassene Ingenieure könnten solche Dienste vielleicht über Mitgliedsbeiträge anbieten, aber manche würden sie möglicherweise aus Angst meiden, ihre Lizenz oder Zulassung zu verlieren. Früher hat man sich vielleicht mit Kollegen in einer Bar betrunken und es dort verarbeitet, aber Alkoholabhängigkeit oder beeinträchtigte Arbeit am nächsten Tag sind nicht gut, und die Barkultur ist auch nicht mehr wie früher

  • Das erinnert an den Vorfall, bei dem der Satellit NOAA-N Prime umkippte, weil nicht genügend Bolzen vorhanden waren, um ihn am Prüfstand zu befestigen.
    Die eigentliche Ursache war – korrigiert mich, falls das nicht stimmt –, dass die Röntgenprüf-Bolzen, mit denen der Satellit befestigt wurde, so teuer waren, dass sie an ein anderes Projekt „ausgeliehen“ und nicht wieder zurückgebracht worden waren. Als der Satellit in die Horizontale gedreht wurde, fiel er auf den Boden; die Reparaturkosten beliefen sich auf 135 Millionen Dollar.
    https://en.m.wikipedia.org/wiki/NOAA-19

    • Wenn in einem Erratum oder Anhang zum Drehverfahren „Bolzen prüfen“ ergänzt wird, ist dann ein wenig Sarkasmus erlaubt?

  • Interessant ist, dass man die Sorge hätte vermeiden können, wenn man von Anfang an die chronologische Sortierung besser vorgenommen hätte. Hätte man den Zeitstempel der Testmesswerte mit dem letzten Zeitstempel des Telemetriesystems verglichen, hätte man erkannt, dass die Telemetrie bereits vor der Testausführung ausgefallen war.
    Dass statt eines exakten Zeitstempels eine ungenaue Formulierung wie „es scheint, als sei gerade eben die gesamte Telemetrie des Raumfahrzeugs ausgefallen“ verwendet wurde, war ebenfalls Teil der Ursache. Die Lehre daraus ist, dass man sauber überprüfen muss, wie die Ereignisse während eines Vorfalls tatsächlich miteinander verknüpft waren. Wenn man zwei verschiedene Signale sieht, nimmt man leicht eine Kausalität in eine bestimmte Richtung an, aber in der Realität kann es genau umgekehrt sein.