バニラアイスクリームにアレルギーを示す車（2000）
(cs.cmu.edu)- 新しい Pontiac の所有者が、毎晩アイスクリームを買ったあと、バニラを選んだときだけ車のエンジンがかからないと General Motors Pontiac Division に苦情を申し立てた
- Pontiac の社長はその手紙を疑ったが、エンジニアを派遣し、現場でバニラ購入後の始動失敗が実際に再現された
- チョコレートとストロベリーを買った日には始動したが、バニラを買った日には再び失敗し、ばかげて見える条件が繰り返し確認された
- エンジニアは時刻、燃料の種類、往復時間、購入時間を記録するうちに、バニラだけは店の前にある別の冷蔵ケースから素早く買えるという動線の違いに気づいた
- 原因はアイスクリームの味ではなく、購入時間が短いためにエンジンが十分に冷えずに起きた vapor lock であり、奇妙な報告でも観察と再現によって検証すべきだ
Pontiac の奇妙な始動問題
- ある Pontiac の所有者は、General Motors の Pontiac Division に2通目の手紙を送った
- その家族は毎晩夕食後、デザートに食べるアイスクリームの味を投票で決めており、彼は毎回車で店へ行ってアイスクリームを買って帰っていた
- 新しい Pontiac を買ってから、特定の条件でだけ問題が繰り返し起きた
- バニラアイスクリームを買うと、店から戻ってきても車を始動できない
- 他の味を買うと、車は正常に始動する
- 彼は質問がばかげて聞こえるかもしれないと認めつつも、なぜ Pontiac はバニラを買ったときだけ始動しないのかと尋ねた
現地確認と再現の繰り返し
- Pontiac の社長は手紙を懐疑的に見たが、エンジニアを送って直接確認させた
- エンジニアは夕食直後に車の所有者と会い、一緒にアイスクリーム店へ向かった
- その日はバニラを買う日で、2人が車に戻ると実際にエンジンがかからなかった
- その後3日間、条件を変えて確認した結果は明確だった
- 初日にチョコレートを買ったときは車が始動した
- 2日目にストロベリーを買ったときも車は始動した
- 3日目にバニラを買ったときは再び始動に失敗した
観察記録から得られた手がかり
- エンジニアは、車がバニラアイスクリームにアレルギーを持っているという解釈を受け入れなかった
- 問題を解くまで訪問を続けることにし、さまざまなデータを記録した
- 時間帯
- 使用した燃料の種類
- 店までの往復時間
- 購入にかかった時間
- 決定的な手がかりは、バニラの購入時間が他の味より短いという点だった
- 店内レイアウトが時間差を生んでいた
- バニラは最も人気のある味なので、すぐ取れるよう店の前にある別の冷蔵ケースに置かれていた
- 他の味は店の奥の別カウンターにあり、味を探して会計するのにはるかに時間がかかった
本当の原因：vapor lock
- 問題の核心はアイスクリームの味ではなく、待ち時間の短さだった
- エンジニアは時間が原因だと把握したあと、原因として vapor lock を突き止めた
- vapor lock は毎日発生していたが、他の味を買うときは購入時間が長く、エンジンが十分に冷えて始動できていた
- バニラを買うときは購入時間が短すぎてエンジンがまだ熱く、vapor lock が解消されないため始動しなかった
教訓
- 一見ありえない問題でも、観察された事実は事実である可能性がある
- 荒唐無稽な症状に見えても、条件を繰り返し確認しデータを集めれば、本当の原因を見つけられる
1件のコメント
Hacker News のコメント
90年代後半、職場で似たようなことがあった。ある社員のマウスが一日の特定の時間帯だけ止まり、朝は問題ないのに昼ごろには動かなくなり、その後また動くようになっていた。
曇りの日は一日中まったく問題なかったが、晴れの日には同じ異常動作が繰り返される、というのが決定的な手がかりだった。結局、安物のボールマウスのプラスチック筐体が薄すぎて、晴れた日に日光が X/Y 軸センサーを LED よりも圧倒してしまい、太陽が動いて影ができてからようやく正常に戻っていたことが分かった。最初は突拍子もない話に思えたが、完全に筋の通った原因だった。
iOS 7.1.x 向け Pangu 脱獄の一部バージョンは、環境光センサーの値が特定のしきい値を下回ると起動中にクラッシュしていたようだ。正確な原因はまだ分からないが、Pangu に光センサーを触る不要なコードが入っていたらしい [1]
[1] https://www.reddit.com/r/jailbreak/comments/294wob/jailbreak...
[2] https://www.reddit.com/294wob/
あらゆる問題を確認した末、雨のときではなく、濃い霧や霧雨のときに問題が起きることが分かった。ケーブル会社の技術者が確認したところ、家の中は問題なく、幹線から家に引き込まれているケーブルにごく小さな傷があり、周囲の湿気が染み込んで接続を台無しにしていた。
氷受けがいっぱいになると赤外線ビームが遮られて製氷を止めるはずなのに、晴れた日のキッチンの明るい光がセンサーをだまして、氷を作り続けさせてしまう。そこで適当な雑誌を上に載せて、正しく動くようにしている。
ある日突然、グラフィカルな X クライアントアプリ関連のテストが断続的に失敗し始めたが、ほかの条件では再現しなかった。調べてみると、CI ジョブは社内のどこかに置かれたデスクトップマシン群で動いており、誰かがそのうちの1台にマウスを挿して棚の上に放置していた。マシンの負荷が高くなるとファンが速くなって振動が大きくなり、マウスがごくわずかに動き、理由は分からないがそれがテストに副作用を及ぼしていた。現場にもないマシンを SSH で診断できたので、かなり誇らしかった。
結局、太陽光パネルかオプティマイザー、インバーターが、ガレージドアのリモコンと干渉する無線周波数を出していた。日光があって発電しているとき、その干渉が homelink のガレージドアオープナーより強くなっていた。数年前、ガレージドアオープナーが突然うまく動くようになったのだが、数日後にインバーターが故障したからだと分かった。FCC 規則上は施工業者が直すべきなのかもしれないが、設置時に関係がこじれていたので、保証修理で相手にするくらいならリモコンを諦めたほうがいいと思っている。
サーバールームがあった時代に聞いた面白い逸話。友人の会社のサーバーが毎日午後5時ごろ再起動していて、OS側で考えられることをすべて確認しても原因が見つからなかった。
結局その時間にサーバーの前に立っていることにしたところ、清掃担当者が部屋に入ってきてサーバーラックの電源を抜き、掃除機を差して掃除したあと、再びサーバーラックを接続する場面を目撃した。
あるカメラは毎日ほぼ同じ時刻に再起動していたが、正確に同じ秒ではなく、ある日は19:12:10、翌日は2秒後、その翌日も2秒後というような明確なパターンがあった。調べてみると、日没時に街路の設備がカメラの前に影を落とし、ソフトウェアがそれを車両だと誤判定して分類情報を集め始めていた。影は実際の車両よりはるかに遅く動くため、フレーム外に出る前にメモリが枯渇し、システムが停止したあとウォッチドッグが再起動させていた。時刻のパターンは、太陽の角度が毎日変わり、影がアルゴリズムを少しずつ遅い時刻にだますようになっていたためだった。
[0] https://old.reddit.com/r/talesfromtechsupport/comments/5yrs1...
[1] https://www.goodreads.com/book/show/3227607-the-devouring-fu...
その時間帯に1週間座って待っていたところ、照明が暗くなって再起動が起きるのを見た。隣の事務所の弁護士が出勤して、PC、プリンター、コーヒーポットを同じ電源タップで同時に入れ、突入電流のためにサーバーがつながっていた回路の電圧が下がっていた。UPSはあったが、当時の民生用UPSは停電にしか対応しておらず、電圧が85Vまで下がるのを測定したし、実際に95V未満では再起動することがあった。
金曜の早い午後で、蒸し暑く、雷雨が来そうな天気だった。16時ごろ担当者が来て、17時に建物全体の電気を落とすので急いでほしいと言った。毎週金曜に省エネのため電源を落としており、よりによって毎週金曜16:30にDBのクリーンアップが予約されていた。そこで残り1時間で問題を直し、その週のスケジュールをキャンセルしてからDBサーバーを手動でシャットダウンした。毎週強制的に電源を落とすことで、Netwareサーバーと料金徴収ソフトウェアのDBサーバーに本番障害を起こしており、保守契約上、そのたびに私たちが直さなければならなかった。結局1か月ほど経ってようやく強制電源断を土曜朝にずらし、バックアップ作業の完了後にサーバーが正しくシャットダウンできるようになった。
80年代に義理の兄弟が乗っていたGMのミニバンを思い出す。GMの自動車エンジニアだった義父からもらった車だったが、ときどきランダムにエンジンがかからず、電装系全体が死んだように見えた。
義理の兄弟は車に詳しくない人だと思われていたため、義父はその不満を真剣に受け止めなかった。結局1か月間車を交換して乗ることになり、GM Technical Centerの駐車場で問題が再現された。周囲に集まったGMのエンジニアたちも、なぜ電装系が死んだように見えるのか突き止められず、義理の兄弟は無実を証明できた。
数時間後には何事もなかったかのようにエンジンがかかるので、サービスセンターでも診断できなかった。その後、オフロードキャンプ中にもエンジンがかからなくなり、生活に影響し始めた。結局、自宅の driveway でかからない状態のまま独立系の整備工場に牽引したところ、そこでも再現した。整備士はECUモジュールの交換、またはヒューズボックス自体の交換を提案した。ECUは数千ドルだが、ヒューズボックス交換は工賃込みで200ドル未満だったので後者を選んだ。6〜7年たった今もその車が主な唯一の車で、その後機械的な問題は一度も起きていない。
悪名高い時期のGM車が、人をおかしくさせる謎めいた電気系の問題を抱えるのは十分ありそうなことだ。
どこかでリレーが過熱して閉じたままになっていたのだと思うが、自分でデバッグすることもできず、自動車整備士だったいとこも見つけられなかった。大して頑張りはせず、そういうことが起きたらヒューズを抜いて、翌朝また差し込んでいた。
スターターはよく回ることが多いのだが、電子機器が変な状態にハマってしまい、バッテリーを外してハードリセットしないと解消しないことがあった。
以前の家で、電子機器に関する奇妙な反復現象を経験した。特定の曜日の深夜、固定された電子機器から、第二次世界大戦時の政治演説の録音のように聞こえる音がかすかに鳴っていた。
音があまりに小さくて発生源を特定しにくく、言葉も聞き取れなかったので、古い録音が四方から同時に聞こえてくるようだった。電源プラグを抜いても、家が停電しても続いた。自分がおかしくなっているのか、家にヒトラーの幽霊でも取りついたのかと思ったが、後で車のラジオで似たものを聞いて分かった。カトリック系AMラジオ局が同じ曜日の同じ時間にグレゴリオ聖歌と説教で放送開始しており、家の配線がどういうわけか AMラジオ受信機 のように動作して、一部の部品が無線信号に乗った音声を振動として出していたのだ。
息子がAmerican Truck SimulatorをプレイするたびにノートPCの画面が消え、画面が真っ黒な間にトラックが道路の外へ出てしまっていた。
私が同じノートPCでプレイしてもそんなことは起きなかったので、息子は自分が呪われていると確信していた。数日間繰り返された後、横でプレイしている様子を観察していて、息子の時計バンドが磁石式の金属バンドだと気づいた。手首の位置がノートPCの ホールセンサー に干渉し、蓋が閉じられたと判断させていたのだ。息子も私も妻も、彼が呪われていなかったと分かって安心した。
https://www.ifixit.com/News/33952/apple-put-a-hinge-sensor-i...
こういう話がCar Talkをあれほど面白くしていた。単に整備士が車を直す話ではなく、状況があまりに奇妙で特殊だから興味深かった。
長年働いてきた整備士たちが、こうしたおかしな状況をあまりにも多く見てきたせいで、むしろ普通のこととして受け止めているのを聞くのも大きな楽しみだったし、そのうえ語り手としても見事だった。
「ばかげて見える問題も時には本物だ」というのが教訓というより、私にとっての教訓は ユーザーの問題はたいてい実在するが、原因診断能力は信用するな ということだ。
手紙はアイスクリームが根本原因だとは主張しておらず、近接原因であることを非常に明確にしていた。Pontiacの社長とその「教訓」を書いた人は両者を混同したかもしれないが、調査したエンジニアはそうではなかった
開発業務の中でヘルプデスクも経験した身としては、ユーザーは任意の事実を問題の原因にしがちだ。「相関関係は因果関係だ」や post hoc ergo propter hoc のようなヒューリスティックは役に立つこともあるが、推論の代わりにしてしまうとよくない。ユーザーは自分が使っている物の動作原理を知らないため正しく診断するのが難しく、「そういうことは少し分かっている」と思っているユーザーほど、かえって扱いにくいことが多い
妻の車はいまウォッシャー液が不足しているのだが、走行中の特定の地点でだけ警告が出る。家からの特定の距離ではなく、正確な位置 だ。
最初はどこかへ行って戻ってくる時間のせいかと思ったが、それまでに5分走っていようが5マイルだろうが1時間だろうが60マイルだろうが、必ずその位置で画面表示と音の警告が出る。追加の手がかりは、その地点がほとんどの携帯電話・通信事業者にとって圏外エリアだということだけだ。ウォッシャー液を補充したので謎は潜伏期間に入ったが、すべての警告がそこで出るのか気になっている。その地点で車両テレメトリが何かに触発されて目を覚まし、何かを言っているようにも思える。
センサーを「十分な液体」から「不足」へ少し押しやるほどの奇妙な干渉を与えている可能性がある
単に容器の中で液体が動いている問題だ。今日は車が低液位ランプを点きっぱなしにしてくれるよう、フロントガラスを少し拭いた
コンピュータサイエンスの実習室で Java の課題をしていた夜、担当教授が通りかかって「そのマシンでは幸運を祈るしかないね」と言った
そのマシンは、ある時期から Java プログラムなら何でも実行できず派手に落ちたが、C++ や Python は問題なかった。最初は信じていなかった教授のプログラムも、そのマシンをクラッシュさせた。技術者と教授の2人で約2週間調べた結果、JVM が起動するたびに整数 12 を同じ RAM アドレスに割り当てており、そのハードウェアアドレスを含む RAM チップが故障していた。そのアドレスに割り当てようとするたびにクラッシュし、不良の RAM スティックを交換するとすぐに解決した
https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
結末はネタバレしないでおく。長く曲がりくねったデバッグの旅で、読む価値がある。HN の議論:
https://news.ycombinator.com/item?id=15845118
この話は交絡変数の面白い例である
因果推論において交絡変数とは、従属変数と独立変数の両方に影響し、見かけ上の関連を作る変数である。相関関係だけでは説明できない因果の概念であり、「相関関係は因果関係を意味しない」の重要な定量的理由の一つである
https://en.wikipedia.org/wiki/Confounding
統計モデルで表すと
S = f(H, I, T)のように見られる。Sは車が始動するかどうか、Hはエンジン温度、Iは選んだアイスクリームの種類、Tはアイスクリームを買うのにかかった時間である。Tが短いとエンジンがより熱い状態なのでベーパーロックに弱くなりSに影響し、バニラアイスクリームの位置が早く買えるようにしてIとも結びつく。そのためIとSの間に見かけ上の関係が生じるTがIに影響するのではなく、IがTに影響するのではないか？ アイスクリームの種類が店内でかかる時間を決めるのだから、そうだろう