データソース全体の整合性／クレンジングの重要性をNASAの事故に学ぶ

有名なソフトウェアのバグ事例の一つにNASAのマーズ・クライメート・オービターの事故というものがあるのだけれども、これをデータソース全体の整合性やクレンジングの重要性を説明する際に使うというのは良いアイデアだと思ったのでメモ。

マーズ・クライメート・オービターの事故

わりと有名な話。モジュール間インターフェースの単位整合性が取れていなかったというバグ。連携ソフトウェアの一部はデータをヤードとして扱い、一部はメートルとして扱っていたため、結果として火星探査機が火星に墜落したという話。失敗百選の分析はかなり興味深い。

データソース全体の整合性

上記のトラブルは歴史的には知っていたのだけれども、改めてデータソース全体の整合性を取ることの重要性を説明する際に使うのは賢いと思った。

1999 年、米航空宇宙局（NASA）のジェット推進研究所はデータソース全体の整合性をとることの重要性を嫌と言うほど理解しました。NASAと契約したロッキード・マーティン社は、火星探査機マーズ・クライメイト・オービターのスラスタを制御するアプリケーションを開発しました。その際に、そのアプリケーションはスラスタの推力の計算にヤード・ポンド法の単位である重量ポンドを採用したのですが、NASA 側が航行システムにデータを入力するときには、推力はメートル法の単位であるニュートンで指定されることを想定していたため、実際に必要な計算と処理されたデータに食い違いが発生し、オービターの航行システムは火星の軌道に乗るための正しい姿勢を取ることに失敗しました。こうして探査機は宇宙に消え、NASAは1億ドル以上の損害を被ったのです。高く付いたアクシデントは、データを処理する前に、測定単位の変換による適切な正規化をしていなかったことが原因です。
実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画

この説明はいつか使うためにストックしておこう。
ちなみにタイムスタンプのズレと、ロケール違いもよくあるミスである。これを忘れないようにする良い事例はないかなぁ。