- 2003年2月、JPLのクリーンルームでSpirit Mars Roverは発射場への移送を2週間後に控えており、break-out-boxの接続ミスひとつで5億ドルの宇宙機を壊していた可能性があった
- SpiritとOpportunityは、NASAがほぼ10億ドルを投じた双子の火星ローバー・ミッションで、スケジュール上、大きな故障を修復する余裕はほとんどなかった
- 電気パルスがモーターではなく宇宙機側に入った直後にテレメトリが途絶えたが、損傷の有無と原因はすぐには確定しなかった
- 翌日、テレメトリ喪失はFluke 87IIIマルチメーターのリードを外したことが原因だと確認され、実際のサージはH-Bridgeモータードライバーのチャネル解析対象として残った
- プロジェクトは数週間の解析後、ハードウェアをUse As Isと判定し、手順を修正したうえで同じ試験を継続した。Spiritの当該モーターは火星で正常に動作した
打ち上げ直前のSpiritで起きた試験事故
- 2003年2月、NASA JPLのBuilding 179 High Bay 1クリーンルームで、Spirit Mars RoverはCape Canaveralへの移送を2週間後に控えていた
- SpiritとOpportunityは双子の火星ローバー・ミッションであり、当時NASAがほぼ10億ドルを投資した複雑な宇宙機だった
- 組み立て・試験段階では、宇宙機を地球上で最後に閉じる前に、すべてのシステムを徹底的に試験し、正常動作を確認する必要があった
- 2機のローバーには合計62個のbrushed-typeモーターが搭載されていた
- 車輪の駆動と操舵
- ロボットアームの制御
- カメラの照準合わせ
- 地球向けアンテナの指向
- 着陸後の展開・展張動作
- その夜の試験対象は、Spiritのロボットアーム先端にある**Rock Abrasion Tool（RAT）**内のRAT-Revolveモーターだった
- RAT-Revolveモーターは、火星の岩石上でgrinderとbrushを回転させる役割を持つ
モーターの状態を電気信号で確認する手順
- 環境試験のたびにモーターを分解して内部を検査する方法は実用的ではなかった
- 代わりに、モーターを宇宙機から切り離し、外部電源装置とstrip chart recorderに接続して電気的性能を確認した
- 正常なモーターでは、spin-up中に電流が滑らかな指数関数状に減少し、異常があると信号にblipが現れる
- 試験にはbreak-out-boxが使われ、接続を誤ると大電流が意図しない場所に流れ、致命的な損傷を引き起こす可能性があった
- 事前確認では、接続インターフェース、電源設定、strip chart設定、基準モーターに対する短いテストパルスのすべてが正常と確認された
誤った方向へ入った電気パルス
- RAT-Revolveモーターにエネルギーを送った瞬間、strip chartには見慣れない信号が現れ、故障したモーターの典型的な信号とも違っていた
- 配線をたどって確認すると、break-out-boxのミスにより、電気パルスがモーターではなく、コネクターインターフェースの反対方向である宇宙機側に入っている状態だった
- Spiritは打ち上げ準備のための移送を2週間後に控えており、大きな問題が起きれば復旧する時間はなかった
- 事故をすぐにテストコンダクターのLeoに知らせたところ、同時に宇宙機からのテレメトリが途絶えたという返答を受けた
- チームは直ちに緊急停止手順を実行し、事故の経緯と被害評価のため、クリーンルームから出るよう指示された
テレメトリ喪失と初期判断
- 事故直後に確認された事実は2つだった
- 大きな電気パルスが意図しない場所に入った
- 宇宙機のテレメトリが停止した
- 2つの出来事のつながりはすぐには明らかではなかった
- チームは電気サージがH-Bridgeモータードライバー回路に入った可能性が高いと見た
- H-Bridgeは電流の流れを制御する回路として扱われる
- back-EMFのため、ローバーで追加エネルギーに耐えられるよう設計された部分のひとつだった
- 宇宙機はすでに電源が切れており、チームは再通電で問題が解消するか確認することにした
- 真夜中近くにプロジェクトマネージャーのPeteにまで事故報告が上がり、約1,000人規模のプロジェクトの再計画の可能性がかかっていた
再起動失敗と翌日に判明した本当の原因
- 標準の宇宙機通電手順を再び実行したが、電子機器とソフトウェアが立ち上がった後もテレメトリは戻らなかった
- 地上支援機器ラックには、各クロックサイクルごとにパルスを受けて点灯する赤い表示灯があり、毎秒8回のロボットの心拍のように使われていた
- 電源装置は見慣れた電圧ステップと電流変化を示したが、表示灯は点灯せず、テレメトリも出なかった
- 翌日、出来事の順序を再検討していたところ、Fluke 87IIIデジタルマルチメーターが重要な手がかりになった
- 前日の試験に必要なマルチメーターを探していた際、宇宙機の近くでバス電圧を監視しているように見えたマルチメーターのリードを外していた
- このマルチメーターは実際には、宇宙機の地上試験テレメトリ電源回路を完成させていた
- リードを外した瞬間、テレメトリ電源の接続が切れた
Spiritは生きており、ハードウェアはそのまま使われた
- チームはマルチメーターを元の役割に戻し、宇宙機の電源を再び入れた
- テレメトリが復活し、Spiritが死んでいなかったことが確認された
- 実際の損失は数時間程度で、試験は再開された
- その後数週間にわたり、RAT-RevolveモーターのH-Bridgeチャネルを解析し、thin-film demetallizationの可能性について詳細な議論が続いた
- 最終的にプロジェクトは当該ハードウェアをUse As Isと判定した
- ローバーの打ち上げ準備は続けられ、Spiritが火星に到着した後、RAT-Revolveモーターは正常に動作した
失敗経験との向き合い方
- この出来事は、失敗経験の共有が、話す人と聞く人の双方にとって学びになり得るという信念につながった
- Planetary Resourcesでは、採用プロセスとチーム文化の中で、応募者に自分のfailure storyを共有するよう求めていた
- 危機のさなか、Ernieは「次に何かを大丈夫だと承認しなければならないとき、この感情を思い出せ」という言葉を残した
- 事故後、一部の人は危険な試験を中止すべきだと考えたが、モーターが火星で正常に動作するか確認する試験の重要性から、試験は続けられた
- プロジェクトマネージャーのPeteは同じ人物に試験のリードを続けさせ、「私たちは彼の教育費を払ったのであり、彼はこのミスを再び犯す可能性が最も低い人物だ」という趣旨で判断した
- その後、同じミスを繰り返さないよう手順を修正し、同じ試験を何度もやり直した
- この経験は、重要な承認や保証を行う際に、当時の恐怖と後悔を思い起こさせる基準点となった
1件のコメント
Hacker News のコメント
本当に文章がよく書けている
ソフトウェアエンジニアとしてキャリア初期に経験した似た出来事を、今でも思い出す。10年ほど前、コンサル先の顧客のWebサービスの新バージョンを数か月かけて作り、リリース当日のデプロイを担当した。当時の開発・デプロイ手順はほぼすべて手作業だった。可能な部分はスクリプトとSQLで自動化し、デプロイ直前の最後のテストをしようとEnterを押した瞬間、ついさっき本番の認証情報に切り替えたままだったことに気づいた
エラーが積み上がり、サービスが応答しなくなったので、データベースを吹き飛ばしたと確信したが、数時間前に誰かがリリースに備えてバックアップを完了してくれていたおかげで、大部分は復旧できた。それ以来、データベースや本番システムを扱うときは、慎重という言葉では足りないほどになり、二度と同じことはしないと誓った
テストスイートは実行中にテーブルを削除して再作成したり空にしたりするのだが、ある日リード開発者が本番DBでバグ修正の調査作業をしたあと、
make testを実行した。テストコードは環境変数をそのまま使ってDockerではなく本番に接続し、すぐにその本番テーブル群を何十回も削除して再作成した幸い、顧客サイトごとに中央DBと同期されるローカルDBがあり、接続が切れていても製品は動いていた。彼は3〜4日間の長時間勤務で、古いバックアップと顧客側のデータを組み合わせてマスターDBを再構築した
1秒後にまた表示され、単にビューが更新されただけだった。本当にひどいUIだった
製品のマーケティング文言を変えるために短い
UPDATEクエリを書いたが、すぐに終わらなかった瞬間にまずいと分かった。条件なしで全件を更新し、数千件の製品説明を変えてしまった。バックアップにアクセスできるDB管理者は別のタイムゾーンにいてすでに退勤しており、1時間以上電話した末に復旧できた帰り際のすばやい変更が、数時間がかりの後始末になった。マーケティングの友人は何度も謝っていたが、ミスは私のものだった。顧客から特に何も言われなかったのは、祝日の週末の金曜午後5時だったからだと思う
sudoコマンドを実行するとき、Enterを押す前に別の人がコマンドを確認しなければならないという方針があった。本番で行うすべての作業にも、似たような方針や慣行を適用できるインターンが本番データベースを消したのなら、悪いインターンではなく悪いプロセスだ、という言葉を思い出す
これがプロセスの問題なのか人の問題なのかは、正社員にはより多くを期待するという点もあって簡単には判断できないが、彼の立場に入り込んで読むと、何が起きたのかを悟った瞬間の恐怖と苦痛が伝わってきて、胸が詰まった。希望の光が一度消えたあとにまたよみがえる感覚まで含めて、それほど多くの人が依存するプロジェクトを任されたことはない
私の基準では、全員が英雄だ
事後分析の通話での第一声は「その取引を作った人を責めるつもりはない。正直なミスだった。代わりに、開発者が認証なしで本番の取引APIを叩けた理由を話し合おう」だった
個人を責めると、その人が解雇されるだけで組織全体は弱くなる。高価な教訓を学んだ唯一の人を手放すことになる。個人に責任を問うべきなのは、害を与えようとする意図があったときだけで、その場合は法律が介入し得る
数年後に退職するころには、その脆弱で不安定なサイトを、自動テスト、複数段階のバックアップ、複数データセンターにまたがるフェイルオーバーシステム、新規開発者向けの教育とオンボーディングを備えたシステムに変えていた。AWS初期だったので、本番サイトをワンクリックでデプロイできる時代ではなかった
その経験のおかげで、適切なバージョン管理、開発環境、Redis、シャーディングとクラスタリング、VM、PostgresとMySQLのレプリケーション、Wiki、monit、DNS、ロードバランサー、リバースプロキシなどを学んだ。二度とサイトを落としたくなかったからだ
WordPressの経験が少しある高校中退者に時給15ドルを払って本番Webサイトを任せた小さな会社だったが、ミスのあとも解雇せず、現場で学びながらシステムを改善する自由と信頼を与えてくれたことに、今でも感謝している
ルールが多くなりプロセスが良くなることが、常に良いとは限らない。時には官僚主義が、もともと遅いNASAをさらに遅くする。初のタイプのミッションでは、プロセスではなく人に依存し、リスクを取らなければならないことがある
つまり、筆者の能力の外で決まった部分があり、恐れていたようにローバーを壊した人物として永遠に記憶される可能性も同じようにあった
私の経験ともかなり重なる。大手航空会社で、最も難しく危険なプロジェクトを選んで担当することが多く、その一つがWebサイトの新しい決済プロバイダーを急いで実装する仕事だった。そのサイトは毎日、数百万ユーロ分のチケットを売っていた。
デプロイから数秒後、テスト環境と本番環境の違いを見落としていたことが分かり、重要な変数の一つが本番では空になっていることが判明した。ドキュメントをもっと読んで準備していれば予想できたことだったので、販売が完全に止まり、心臓が凍る思いをした。長いロールバック手順の末、数時間にわたって販売が停止し、怒った顧客が殺到し、数百万ユーロの損失が出た。
CEOをエレベーターでつかまえて、すべて自分の責任であり、解雇を含むあらゆる結果を受け入れると伝えたところ、彼は笑って「なぜ君を辞めさせるんだ？ たった今、君を教育するのに数百万を使ったところだ。昨日より仕事ができるようになったじゃないか」といった趣旨で答えた。この経験は、真のリーダーシップを含め、さまざまな面で自分を形作るものになり、その後、多くの高リスクプロジェクトを成功裏に終えた。
インターネット全体もしょっちゅう壊れている。Black Fridayの決済中にNikeのWebショップでエラーが出て、ヘルプデスクの解決策は「アプリを使ってください」というようなものだった。
実際には、停止時間がそのまま損失に変換されるわけではないと思う。初期のTwitterは人気とアーキテクチャのせいで頻繁に落ちていたが、人々がTwitterの利用をやめたわけではなかった。
オンラインサービスにおいて、停止は災害でも会社の終わりでもない。宇宙機器や、会社が破綻しかねない高頻度取引ソフトウェアなら話は別だが、だからこそより厳格なチェック機構が必要になる。理論上はそうだし、実際には、宇宙・高頻度取引業界で学ばれたベストプラクティスで作られた、ずさんなCRUD Webサービスにも劣る場合すらある。
本番デプロイには、副操縦士のように一緒に確認し、ロールアウトを止める権限を持つ人が必要かもしれないし、一般的なDevOpsの保護策も併せて必要だ。
高リスクプロジェクトを担当する人たちは過小評価されがちだ。多くの管理職は、期待値はプラスだが変動のある社員よりも、安定して何の価値も生み出さない社員を好む。
テレビ業界で働いている。30年前、小さな地方局での最初の仕事で、ニュース番組のテープオペレーターとして訓練を受けた。放送用テープは大きな山になって積まれており、再生用VTRは4台あった。私の仕事は各テープを入れ、1秒のプリロール位置に合わせることだった。
テープの再生が終わって取り出す時間になると、たった今終わったVTRではなく、現在放送中のVTRの取り出しボタンを押してしまうのは非常に簡単だった。私を訓練していた人は、私が取り出しボタンに手を伸ばすたび、歯を食いしばって息を吸い込む大きな警告音のような音を出した。その音のおかげで私は立ち止まり、二度三度確認してからテープを取り出した。
本当にうっとうしかったが、慎重になるよう条件づけるには効果的だった。局の方針では、生放送中に初めてテープを取り出すと無給で1日休み、2回目は保護観察、3回目は解雇だった。慢性的な不注意で職を失い、ニュース番組を台無しにした同僚も何人かいた。あのうっとうしいトレーナーのおかげで、確認してさらに確認する習慣を学び、放送中のテープを取り出したことは一度もなかった。
そのミスをした人は、二度と同じミスをしないという点には同意します。だから技術的にはミスをし、明らかにつらい思いをしている人を解雇するのは、たいてい悪手です。
ただ、それが「本当の」教訓だとは思いません。コストとリスクを考えれば、大きな電力サージでテストされる部品には、煙を出しやすい部品と互換性のない専用テストコネクタを用意すべきだ、というのが教訓です。
小さなブレッドボードのプロジェクトではなく、公式手続きのせいで時間も費用もかかり、ときには嘲笑も受ける政府機関の大勢の人が作った巨大プロジェクトです。「28歳に、ちょっとしくじれば爆発しかねない5億ドルのロボットを任せよう」という理屈は、かなり奇妙に聞こえます。
特にテスト中は、「通常構成」とは異なるカスタムケーブル、コネクタ、回路を扱うことが多いです。教訓は、重要な作業はできるだけ4-eyes原則で行うことだと思います。1人が作業し、もう1人が各ステップを確認してから進めるやり方は、記事にあるような「信じがたいミス」を見つけるのに非常に効果的です。
ただしスケジュールのプレッシャーなどで、常に2人が1つのテストを見られるわけではないため、現実にはこうしたミスが起こります。システム全体を堅牢にする必要があります。
コンピューティングにも、本番データベースやルーター設定に対して、アップグレードやマイグレーションの一部として一度だけ実行する似たような作業が多くあります。ときには、安全装置を作るコストが、最初から注意深く行うことより大きくなります。私たちは常に完全に注意できるわけではありませんが、安全装置も常に完全に作れるわけではなく、欠陥のある安全装置を信じて似たミスをすることもあります。
話の中の状況では、ハードウェア版ペアプログラミングのように、作業者のすることがすべて正しいかを検証することだけを担当するパートナーがいるべきだったのかもしれません。Maryのように役割を分担して助ける補助者ではなく、後ろについて確認することだけが唯一の任務である人です。
モーターコントローラのデータラインに入っていたら、何かが焼けていた可能性が高いです。コネクタの種類が違っていた可能性は排除できませんが、誤接続された2つのコネクタは同じ種類として割り当てられていたのは確かです。
特にコネクタには、すでに認証済みの製品、特定のディレーティング、ピン間隔、接地されたバックシェルといった保守的な要求が多くあります。結局、使われ在庫されるコネクタシリーズは数種類に限られ、どんなコストをかけても完全に重複しないようにするのは現実的ではありません。通常は同じ信号を標準化するか、重複しないようユニークにしようと試みます。
たとえば宇宙機の外部コネクタには、取り扱い中の短絡を防ぐためにソケット型コネクタが必要で、中間ハーネスは決して取り外されず、ピン型コネクタが対称に付くことがあります。そこでテスト用のブレークアウトボックスが必要になると、箱を逆向きに挿す機会が生まれます。
あるいはブレークアウトボックスの片側が100ピンコネクタで、もう片側を25台のテスト機器に接続しなければならないこともあります。選べる25種類の別々のコネクタがあるわけでもなく、すべてのテスト機器にカスタム要求を強制することもできません。
宇宙機は次第にローカルマイクロコントローラとローカル診断へ移行しているため、すべてのアナログ信号用のこうしたテスト機器は減りつつあります。モーターも今ならブラシレスである可能性が高く、こうしたブレークアウトボックスではなく、テスト時と飛行中のモータードライバのテレメトリに頼ったでしょう。
航空宇宙用コネクタも他業界と同様、発注時により構成可能になってきており、キーを追加して「同じ」コネクタが10個あっても正しい場所にしか挿さらないようにできます。それでも、すべてのテスト機器をそのように構成せよと求めるのは、依然として非現実的です。
記録として私の話も付け加えます。大学卒業後の最初の職場は、PHPとPerconaDB（MySQL）を使うコンテンツマーケティングのスタートアップでした。PHP経験は多くありませんでしたが、新人特有の根拠のない自信がありました。卒業後6か月間就職できなかったので、良い印象を与えたい気持ちも強かったです。
すべての顧客に新機能を有効にしつつ、明示的にオフを望む顧客だけを除外するよう、機能フラグを更新する仕事を任されました。フラグはデータベース内で、文字列配列の中に整数4と5として保存されていました。
必要な作業をするためにPHP関数array_reverseを使いましたが、ドキュメントを読んでいなかったため、第2引数がないとキーではなく値だけを反転することを知りませんでした。その結果、必要なものと正反対の形でデータベースを壊してしまい、奇妙なことにQAは通りました。
数時間後に判明しましたが、当時は片道3時間近くかけて通勤していたため、その時点ではすでに経営陣まで関与していました。逆方向のスクリプトで簡単に直せましたが、QAやDBバックアップの失敗など、複数の問題が明らかになりました。
翌日、リードアーキテクトが来て、PHPを扱う上での通過儀礼のようなミスで、自分もキャリア初期にやったことがあると言ってくれたのは、今でも覚えていますし感謝しています。結局解雇され、エンジニアとして成長する助けにはなりましたが、その瞬間とその後数週間は、確かにやる気をくじかれました。
array_reverseのミスで解雇したってこと？話は引き込まれるように書かれていたが、混乱するところもあった
このチームは1つのミスではなく、複数のミスをしたように見える。その結果が宇宙機に実際の損傷を与え得たのか、それとも宇宙機が起動しない理由をめぐって時間と混乱を浪費しただけなのかもはっきりしない
1つ目のミスは、マルチメーターが単に測定していただけでなく、回路を完成させていたことに気づいていなかった点だ。本当にひどい設計に聞こえるし、どうしてもそうする必要があったのなら、そのマルチメーターは絶対に触ってはいけなかった。1人のミスではなく、少なくとも2人、その人たちを管理する人、そしてそういうシステムを許した責任者まで関わる問題だ
2つ目のミスはブレークアウトボックス側だ。電力を宇宙機側へ誤って送ったと見なし、宇宙機が起動しないと、電力サージが宇宙機を損傷させたと結論づけたが、実際にどこへ流れ、何が損傷したのか確信できておらず、結局それは間違っていた
宇宙機が起動しなかった理由は、事故の前にマルチメーターを回路から外してしまったからだった。RAT-RevolveモーターHブリッジチャネルについて数週間の分析と薄膜の脱金属化の可能性の議論が続いたという文が、誤った電力サージがそのチャネルへ流れて損傷した可能性があると判断した、という意味なのかは今も混乱する
電力は実際にその回路へ入っており、損傷したかどうかを判断しようとしていた状況だった。ただしモータードライバーはモーターから戻ってくる電力に耐えられるはずなので、おそらく損傷していないと見たのだろう
機械・航空宇宙エンジニアとして、自分のいちばん怖い話が、無人の5億ドルのローバーのメインコンピューターが文鎮化しかけた、という程度であってほしい
私は人命を乗せるものについて安全クリティカルな承認を行う上級者だった。墜落事故の後、壊れた部品の写真を見ながら「これが自分の計算ミスだったら？」「自分のジョイントが滑ったのだったら？」「加速疲労寿命予測や応力腐食割れを扱う不適切な試験手順のせいだったら？」「量産投入を急いで出荷前に見つけられなかったものだったら？」といった感覚を受け止めなければならなかった
似た分野の失敗談を読むのは興味深いが、HNで公に共有される話を読むと、私には、仕事由来のPTSDは競争ではないのだと思わされる。人によっては、単に治療費がより多くかかるだけなのだ
そのエネルギーを、より良くなる方向に使えたのは幸いだが、誰もがトラウマに同じように反応するわけでもなく、そうした反応を比べるのも簡単ではない。たとえば採用時の質問として使うには、社会的な変数が多すぎると感じる
手順では拾えなかった細部だったとしても、良い手順を作る責任者は誰かしらいる。要因はいくつもあり得るが、最終的にはかなり直接的に責任を負う人が生まれるように見える
ソフトウェアエンジニアリングや社会全般のように、個人のミスが集団に帰属される文脈で考えると興味深い
共感力があり、「ロケットが上がった後どこに落ちるかは自分の部署の仕事ではない」という態度を取らないなら、かなりつらいこともあると思う。安全必須システムを作る人や、その余波に対処する人のためのピアサポートの集まりがあるといい。会社が常に良いカウンセリングを提供するとは限らない
工学協会や公認エンジニア組織が会費でこうしたサービスを提供することもできるだろうが、免許や公認資格を失うのを恐れて利用をためらう可能性もある。昔なら同僚と酒場で酔って吐き出していたのかもしれないが、アルコール依存や翌日の仕事への支障は良くないし、酒場文化も昔とは違う
NOAA-N Prime衛星が試験台に固定するボルトが十分でなかったために倒れた件を思い出します。
根本原因は、正確でなければ訂正してほしいのですが、衛星を固定するために使うX線検査ボルトが高価すぎたため、別のプロジェクトに「貸し出され」、戻されていない状態だったというものです。衛星を水平に反転させる際に床に落下し、修理費は1億3,500万ドルでした。
https://en.m.wikipedia.org/wiki/NOAA-19
最初から時系列ソートをもっときちんとしていれば、心配を避けられたという点が興味深いです。テストの読み取り値のタイムスタンプとテレメトリシステムの最後のタイムスタンプを比較していれば、テスト実行前にテレメトリがすでに失敗していたことが分かったはずです。
「少し前に宇宙機のテレメトリが全部途切れたようだ」といった不正確な表現ではなく、正確なタイムスタンプを使わなかったことも一因です。事故中の出来事が正確にどのようにつながっていたのかをきちんと確認すべきだ、という教訓です。異なる2つの信号を見て、特定方向の因果だと簡単に仮定してしまいますが、現実には逆の場合もあります。