
2026/11/12 1:38
誤作動した火災警報器が、ジェーン・ストリート社のニューヨークのデータセンターを水没させようとした。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
2026年11月、ジェーン・ストリート社のNYCデータセンターで、準備室の建設粉塵により誤作動した火災報知器が作動した。当該データセンターは1 New York Plaza内に設置されており、知的財産保護のためおよび手動での遮断能力を確保するため意図的にトレーディングフロアに近い位置に構築されていたため、同社は核潜水艦文化の影響を受けた下で設計されたプロトコルに従った。すなわち、火災報知器はCRAC冷却ユニットの停止につながるよう配線されておらず、スプリンクラーはより高い熱閾値を待ってから作動する仕組みであった。温度は約141°Fから143.6°Fに上昇し、状況が深刻化する前に従業員(著者を含む)がサーバーキャビネットから電源コードを手動で引き抜いたことで、主要市場がすでに閉場されていたため災害を回避した。この事象は、厳格な物理的なセキュリティ対策と複雑な環境における運用上の脆弱性の間のトレードオフを再確認させた。事後、ジェーン・ストリート社は手続きを強化し、監視を強化するとともに、不確実なテレメトリデータに代わってLinuxサーバーを毎秒1回ずつクエリして温度を直接追跡する独自OCaml監視システムを導入した。(同社はサンディ台風が通過するまでサーバーをトレーディングフロア隣のオフィスビル内に維持し、著者もまた緊急時における迅速な対応のためオフィス近郊に住むことを選んだ。)
本文
ジェーン・ストルートの「戦争ごとき」の一日:誤作動した火災報知器と 143.6 度の熱
2026 年 11 月 10 日、mbacarella 氏によって公開された記事。ジェーン・ストリート(Jane Street)のシステムチームが直面した、**「戦争ごときを思わせる」**生存記です。
ジェーン・ストリートのリスク文化と物理的な防御
- 企業の実像: 優れた企業として知られていますが、実は**「馬鹿げた失敗で存亡の危機を迎え、粘り強さと運によって助かった」**歴史があります。
- ブルーカラーな姿勢: 役職に固執せず、トラブルが起きれば廊下を駆けて対応する**「スター・トレック:ローアデッキズ」視点**の実践者です。
- 「電源ケーブル引き抜き」の哲学:
- 制御不能の自動取引システムを停止させるための最後の手段として、物理的に電源ケーブルを引っぱり続けるリスク文化があります。
- この思想は意図的な遅延ではなく、元核潜水艦乗組員だったパートナーらが植え付けたものです。
- 教訓: 自動化には信頼できない。赤いレバーでシステム停止できるまで手動介入を用意する(核潜水艦の原則)。
2006 年:香港からの緊急コール
- 背景: 著者はマンハッタン南部から片道 1 時間以上通勤していたが、オフィスに近いワンルームマンションへ移り住みました(徒歩 9 分)。
- 発生日時: ある日の終業後。
- 通報内容: 香港オフィスより、「ニューヨークのデータセンターで火災報知器が作動している」との連絡がありました。
誤作動の正体と致命的な連鎖反応
1. 発生の原因
- データセンター隣りの施工業者が壁を掘って粉塵を舞わせていました。
- 粉塵がセンサーを刺激し、煙を検知しました。
2. スプリン trajectory(散水装置)の仕組み
- 常時満水ではない: 漏水事故防止のため空気の状態で待機。
- 噴射条件:
- 煙検知 → パイプに高圧水充填。
- 熱検知 → ノズルの熱感応プラグが開き、放水開始。
- 火災報知器のワイヤリング: 火災が制御できず温度上昇していると判断すると、CRAC(空調)ユニットを停止させます。
3. システム崩壊への道筋
煙検出 ↓ CRAC ユニット停止 ↓ 室温急上昇 ↓ 熱感応プラグ開動 ↓ 全スプリン trajectory ノズルからの放水 ↓ サーバー類の水没と深刻なダウンタイム
著者のミッション:サウナへの突入
- 目標: スプリン trajectory が作動して温度が華氏 150 度(約 65.5℃)を超え、機器が水没する前に全ての電源ケーブルを引くこと。
- 経路:
- 金融地区の通りを全速力で走る。
- ワン・ニューヨーク・プラザのエレベーターで 33 階へ上がる。
- キーカードスキャンで入室。
- 現場状況:
- 入った瞬間にサウナのような熱に包まれた。
- 全電源ケーブルを両手で引き抜いた。
危機の収束と教訓
- 温度計測記録:
- 141°F → 142°F → 143°F → 143.5°F → 143.6°F
- 温度上昇が止まり、機械室はかつてない静寂に包まれた。
- 結果:
- 主要市場閉鎖中のためダウンタイムは最小限。翌朝正常稼働。
- 対策:散水装置は維持しつつ、手順と監視体制を強化。取引フロア隣接の自社ビル内サーバーホスト継続。
- ハリケーン・サンディによる被害はこの教訓で防がれた(※別の話として残す)。
その後の改善策:OCaml で書かれた温度モニタリングシステム
- 問題点: CRAC ユニットや部屋の温度センサーは信頼性が低く、誤報に頼るのは危険。
- 解決策: 各 Linux サーバーのオンボードセンサー値を直接読み取る高信頼性モニターを実装。
- 技術スタック:
- 言語:OCaml(型安全性と高信頼性が求められるため、Bash や Perl は不十分)。
- 環境:Emacs で記述。
- 機能:
- 毎分全てのサーバーから温度データを収集。
- 平均値を計算し閾値を超えるか監視。
- システムチーム全体に「データセンター過熱」アラートを即時送信。
「もし元核潜水艦乗組員がこのシステムを見ていたら approve してくださったのではないか」と著者は考えます。
悲しい物語を知っている方は、X(旧 Twitter)、Bluesky、Hacker News、Lobsters で共有してください。