航空機の冗長化設計をサーバー設計に持ち込む
はじめに
747のコックピットについて調べてたら、信頼性工学の話に行き着いた。
そしてサーバーの高可用性設計は、航空業界の思想を後から借りてきたものだ。
用語まで輸入してる。Redundancy、FMEA、Fail-safe、MTBF。全部元は航空・軍需・宇宙の言葉。
- 1920〜30年代 多発機。「1基止まっても飛べる」が要件化
- 1949年 米軍規格 MIL-P-1629 でFMEAが成文化
- 1960年代 アポロ計画。三重冗長と多数決
- 1974年 Tandem Computers が無停止コンピュータを商品化
- 1980年代〜 RAID、クラスタ、HA構成が一般化
人が死ぬ現場で数十年磨かれた思想を、ITが後から輸入した。だから元ネタの方が成熟してる。逆輸入する価値がある。
信頼性工学、これだけは覚えとくこと
1. 「壊れない」を目指すな。「壊れても動く」を作れ
部品の品質を上げる努力には天井がある。構成で守れば天井がない。
MTBFを2倍にするより、2重化する方が安いし確実。
2. 直列は掛け算、並列は足し算
| 構成 | 意味 | 計算 | 結果 |
|---|---|---|---|
| 直列 | どれか1つ壊れたら全滅 | 稼働率を掛ける | 99%×3 → 97%。増やすほど悪化 |
| 並列 | 1つ生きてれば動く | 故障率を掛ける | 1%×3 → 0.0001%。増やすほど改善 |
自分の構成が直列か並列か、それだけ見極める。
依存が1本増えるたびに、それは直列。
3. 単一障害点は「数」じゃなく「経路」で探せ
これがここでのメモの核心。後述。
4. 冗長度は「失う被害」で決める
747の実際の多重度。
| 系統 | 数 | 全滅したら |
|---|---|---|
| 油圧 | 4系統 | 操縦不能。墜落 |
| 発電機 | 4基＋APU＋外部電源 | 徐々に系統喪失 |
| 空調PACK | 3基 | 与圧喪失。降下すれば助かる |
| 姿勢基準装置 | 3セット | 計器不信 |
油圧4本、空調3基。この差が答え。
全部を最高冗長にすると、複雑さそのものが新しい故障要因になる。
5. 検知できない冗長は冗長じゃない
予備が壊れてることに気付かないまま本番が落ちたら、冗長化は無かったのと同じ。
これを潜在故障（latent failure）という。
航空機は飛行前点検で予備系を全部起動して確認する。
動かしてないものは動かない。
経路の話:日航123便
1985年。単独機として世界最悪の事故。
何が起きたか
- 7年前のしりもち事故の修理が不適切。リベットが規定3列に対し実質1列
- 金属疲労が進展し、後部圧力隔壁が破断
- 与圧空気が尾部へ噴出。垂直尾翼の約半分が吹き飛ぶ
- 同時に油圧4系統が全て切断
なぜ4系統あって全滅したか
747の油圧配管は、尾部で1箇所に集中して通っていた。
冗長化されていたはずの4系統が、同じ場所を通っていたために一撃で全滅した。
同じことが他でも起きてる
| 事故 | 機種 | 原因 | 結果 |
|---|---|---|---|
| 日航123便 1985 | 747 | 隔壁破壊 | 4系統全喪失。520名死亡 |
| UA232便 1989 | DC-10 | ファンディスク破裂 | 3系統全喪失。184名生存 |
| DHL貨物便 2003 | A300 | ミサイル被弾 | 3系統全喪失。着陸成功 |
| カンタス32便 2010 | A380 | エンジン破裂 | 多数損傷。全滅せず着陸 |
UA232便が重要。DC-10の設計者はファンディスク破裂を想定していた。
そして「破片が3系統全部を切る確率は10億分の1」と計算して許容した。
そして実際に起きた。
確率計算が間違っていたのではない。「同じ場所を通す」という前提が、破片の前では無意味だった。
冗長化が守るのは「部品がそれぞれ独立に壊れる」ケース。
守れないのが「1つの事象が広範囲を物理破壊する」ケース。
破片は「これは系統2だから避けよう」とは考えない。通り道にあるものを全部切る。
業界が出した結論
- 確率じゃなく物理で考える ロータバースト・ゾーン（破片飛散範囲）を定義し、その中に重要系統を通すことを禁止
- 経路を空間的に分離 上下左右前後に離す。同じトンネルを通させない
- 油圧ヒューズ 破断検知で自動的にその区間を切り離す
- 電気バックアップ RAT、電動アクチュエータ。787は油圧全滅でも一部の舵面が動く
サーバーに置き換える
AZ（Availability Zone）: クラウドのリージョン内にある、電源・冷却・ネットワークを共有しない独立した区画。同一リージョン内で数km以上離れている。
AZを3つに分けた。これでAZ障害は乗り切れる。
だがリージョンは1つ。事業者も1つ。
このとき分散の効果は、共有している一番上の層で頭打ちになる。
- AZを分けた → AZ障害まで守れる
- リージョンが同じ → リージョン全体の障害では全滅
- 事業者が同じ → コントロールプレーン障害では操作すらできなくなる
台数もAZ数も無関係。共有している最上位の層が、その構成の単一障害点。
123便の油圧4系統と同じだ。系統は独立していた。だが尾部という一点を共有していた。
重要なのは「何を分けたか」ではなく「何を共有し続けているか」。
どちらも「数」は足りていた。共有していた一点が全てを持っていった。
補足として、対策後の形も並べるならこれだ。
台数はどの段階でも無関係。経路が同じなら1発で全滅。
物理より厄介な単一障害点
実際に事故るのはこっち。
| SPOF | 何が起きるか |
|---|---|
| DNS | 何台生きてても名前が引けなければ到達不能 |
| 認証基盤 | IdPが死ねば全サービス同時停止 |
| 証明書 | 全台同じ日に切れる |
| 設定ファイル | 同じ間違った設定が全台に入ってる |
| デプロイパイプライン | 壊れたコードを全台に配る仕組み |
| 運用担当者 | その1人しか手順を知らない |
デプロイは冗長化が裏目に出る唯一のパターン
物理故障には10台が守ってくれる。
だが同じバグを含むコードを10台に配ったら、10台同時に死ぬ。
冗長化した数だけ被害が増える。
だからカナリアリリース、段階的展開、ロールバック手順がある。
航空機が異なるメーカーの部品をわざと併用するのと同じ理屈。同一設計は同一欠陥で同時死する。
対応表
構造・設計レベル
| 航空機 | サーバー / インフラ | 共通する原則 |
|---|---|---|
| 油圧4系統・発電機4基 | 複数ノード、複数インスタンス | 冗長化の基本。並列なら故障率は掛け算で下がる |
| 姿勢基準装置3セットで多数決 | Quorum、Raft、etcd の過半数合意 | 2重では「どちらが正しいか」判定できない。奇数にする |
| 配管を機体の左右上下に分散 | マルチAZ、マルチリージョン | 数ではなく経路 |
| ロータバースト・ゾーン | 障害ドメインの定義 | 「同時に壊れる範囲」を物理で線引きする |
| 油圧ヒューズ | サーキットブレーカー、Bulkhead | 壊れた部分を切って残りを守る |
| PACK3基、油圧4系統という差 | RTO/RPO による優先度分け | 冗長度は失った時の被害で決める |
| 異なるメーカーの部品を併用 | マルチクラウド、実装の多様化 | 同一設計は同一欠陥で同時死する |
| RAT（最後の非常電源） | 縮退モード、静的フォールバック | 全部落ちても最低限は返す |
| 全エンジン停止でも滑空できる | Graceful degradation | 機能を落として生き残る |
運用・監視レベル
| 航空機 | サーバー / インフラ | 共通する原則 |
|---|---|---|
| ダークコックピット（正常時は無灯） | アラート設計、正常時は静か | 常時警告が出てる状態は設計失敗 |
| 琥珀＝注意、赤＝緊急 | Severity の階層化 | 重要度を視覚で即判別させる |
| 飛行前点検で予備系を起動確認 | 定期フェイルオーバー試験 | 潜在故障。動かしてない予備は動かない |
| シミュレータでの定期緊急訓練 | カオスエンジニアリング、DR訓練 | 訓練してない手順は本番で動かない |
| 紙のチェックリスト | Runbook、Playbook | 緊急時は認知能力が落ちる。その場で考えさせるな |
| ステライルコックピット | 変更凍結期間、デプロイフリーズ | 高リスク時間帯に余計な操作を入れない |
| CRM（乗員資源管理） | インシデントコマンド体制 | 誰が判断し誰が手を動かすか事前に決める |
| 事故報告書の全世界公開 | ポストモーテムの共有 | 一件の失敗を全体の学習にする |
| 非懲罰的報告制度 | ブレームレス文化 | 罰すると隠す。隠されると学習できない |
| 耐空性改善命令 | パッチの強制適用 | 教訓を全台に確実に反映させる |
設計哲学レベル
| 航空機 | サーバー / インフラ | 共通する原則 |
|---|---|---|
| フェイルセーフ（安全側に倒れる） | Deny by default、書き込み拒否 | 迷ったら安全な方へ落ちる |
| フェイルオペレーショナル | HA構成、自動フェイルオーバー | 止めずに動かし続ける |
| フェイルソフト（性能低下で継続） | レートリミット、機能縮退 | 全滅より部分継続 |
| FMEA | 障害シナリオ分析 | 全要素に「これが消えたら?」を問う |
| 使用頻度の高い操作を手元に配置 | UI/CLI設計、危険操作にガード | 物理的距離が優先度を表す |
| ファイアハンドルの2段階動作 | 破壊的操作の二重確認、--force要求 | 致命的操作は意図の明示を要求する |
| 油圧を全喪失させない設計へ投資 | 復旧手順より予防に投資 | PCAは実用化されず、根本対策が選ばれた |
FMEA:全要素に「これが消えたら?」を聞く
Failure Mode and Effects Analysis（故障モード影響解析）。
1949年に米軍規格 MIL-P-1629 として成文化され、アポロ計画で本格運用された。今はISO規格。これも航空・軍需からの輸入品。
「これが壊れたら何が起きる?」を全構成要素に対して1つずつ聞く。
表の形
| 列 | 意味 |
|---|---|
| 構成要素 | 何が |
| 故障モード | どう壊れるか |
| 影響 | 何が起きるか |
| 発生頻度 | 起きやすさ |
| 検知性 | 気付けるか |
| 深刻度 | どれだけまずいか |
| RPN | 頻度 × 検知性 × 深刻度 |
| 対策 | どうするか |
RPN（Risk Priority Number）の大きい順に対策する。
インフラでやるとこうなる
| 構成要素 | 故障モード | 影響 | 検知 | 深刻度 | 対策 |
|---|---|---|---|---|---|
| DBプライマリ | プロセス停止 | 書き込み不可 | 即時 | 高 | 自動フェイルオーバー |
| DNS | 名前解決不能 | 全サービス到達不能 | 遅い | 最高 | セカンダリDNS、TTL短縮 |
| TLS証明書 | 期限切れ | 全接続拒否 | 切れるまで気付かない | 最高 | 自動更新、期限監視 |
| IdP | 認証不能 | ログイン全滅 | 即時 | 最高 | 緊急バイパス経路 |
| デプロイ基盤 | 不正な設定を配布 | 全台同時死 | 遅い | 最高 | カナリア、段階展開 |
| 運用担当A | 離職・病欠 | 復旧手順不明 | 事故時に判明 | 高 | Runbook化、複数人訓練 |
潜在故障:持ってることと、使えることは別
「使わないから壊れない」は間違い。使わなくても劣化する。
ゴムは硬化する。潤滑油は固着する。電池は自己放電する。接点は酸化する。可動部は動かさないと固まる。
動かさないことそのものが故障原因。
そして最悪なのは、壊れていることに誰も気付けない点。本番が落ちた瞬間に初めて分かる。これを潜在故障（latent failure）という。
ITでの対応物
| 対象 | 確かめ方 |
|---|---|
| バックアップ | 定期的に実際にリストアする |
| スタンバイDB | 定期的に昇格させる |
| フェイルオーバー | 本番で計画的に実行する |
| DR環境 | 定期的に切り替えて業務を通す |
| Runbook | 訓練で実際にコマンドを叩く |
| 連絡網 | 抜き打ちで疎通確認 |
Netflix の Chaos Monkey が本番サーバーをランダムに落とすのは、これが理由だ。
「壊れたら困る」を待つのではなく、平時に自分から壊して、予備系が本当に動くか確かめる。
RAT(非常発電装置)を定期展開するのと、思想として完全に同じ。
結論
確かめていないものは、持っていないのと同じ。
冗長化した数を数えても意味がない。その予備が今この瞬間に動くかどうか、確かめた日付を言えるか。それが可用性の実態だ。
本当の価値は「検知性」の列
見落とされるのは「壊れてることに気付けるか」。
- 証明書の期限切れ → 切れた瞬間まで誰も知らない
- 予備系の故障 → 本番が落ちるまで分からない（潜在故障）
- バックアップの破損 → リストアするまで分からない
航空機が飛行前点検で予備系を全部起動するのは、検知性を人工的に上げているから。
やる時のコツ
- 部品じゃなく「消えたら困るもの」から始める サーバー、ネットワーク、DNS、認証、証明書、デプロイ経路、人。
- 「壊れる」を広く取る 止まる / 遅くなる / 間違った答えを返す / 気付かないうちに壊れてる。3つ目が一番厄介。止まってくれた方がマシ
- 全部対策しようとしない RPNで並べて上から数件。油圧4本、空調3基の話と同じ
- 一度やって終わりにしない 構成が変わったら更新する。航空機も設計変更のたびにやり直す
運用者が知らないものは、疑えない
737 MAXで何が起きたか
2018年ライオンエア610便、2019年エチオピア航空302便。346名が死亡した。
原因は MCAS という自動補正システムの誤作動だった。
737 MAXは大型エンジンを前上方に搭載した結果、機首が上がりやすい特性が出た。MCASはこれを検知して、自動で機首を下げる。
問題はここだ。
- 機体には迎角センサーが左右2つある
- だがMCASは1つしか参照しない設計だった
- センサー1個の誤作動が、そのまま操縦を奪う
- さらにMCASの存在がマニュアルにほぼ記載されていなかった
パイロットは、自分の機体に何が積まれているかを知らなかった。
知らないものは疑えない
610便の乗員は、機首下げが20回以上繰り返される中で必死に引き戻し続けた。
だが何が起きているかを理解する手段がなかった。存在を知らないシステムは、原因候補にすら挙がらない。
そして事故後、ボーイングとFAAは運航を停止しなかった。手順通知だけを出した。
5ヶ月後、302便の乗員はその手順を知っていた。通知通りに実行した。
だが機体はすでに高速・機首下げ状態にあり、空気力に押されて手動トリムホイールが物理的に回せなくなっていた。手順は本番で動かなかった。
157名が亡くなった。
冗長化されていたのは物理層だけだった
センサーは2つあった。冗長化は物理的に用意されていた。
だがソフトウェアが1つしか読まなかった。
| 事故 | 用意されていたもの | 実際 |
|---|---|---|
| 日航123便 | 油圧4系統 | 経路が1つ |
| 737 MAX | AoAセンサー2つ | 参照が1つ |
リソースを冗長化しても、それを使う側が単一なら意味がない。
インフラで全く同じことが起きる
用意したのに使っていないパターン
- マルチAZにDBを置いたが、アプリの接続先がプライマリ固定
- LB配下に10台あるが、セッションが1台に固定
- 監視データを2系統で集めているが、アラート判定は片方だけ
- バックアップを2箇所に取っているが、リストア手順が片方しか書かれていない
「用意した」と「使っている」は別。
運用者が知らされていないパターン
| 知らされていないもの | 障害時に何が起きるか |
|---|---|
| なぜこの構成なのか | 触っていい部分が分からず手が止まる |
| どこが単一障害点か | 疑う場所が分からない |
| 過去に何が起きたか | 同じ障害を初めての障害として扱う |
| 自動化が裏で何をしているか | 意図しない動作を人為ミスと誤認する |
最後が一番危ない。自動化されたシステムが「善意で」何かをしているとき、運用者はそれを異常と判別できない。MCASそのものだ。
「知らされていない」は3種類ある
- 意図的に隠された 737 MAXがこれ。悪意ではなく「訓練コストを増やしたくない」という営業判断だった
- 伝えたつもりで伝わっていない ドキュメントには書いてある。だが誰も読んでいない。存在を知らないドキュメントは無いのと同じ
- 誰も知らない 作った人が退職した。判断理由が失われた。これが一番多い
対策
- 自動化には必ず可視化を付ける 自動でやるなら、やったことをログに残し通知する。「勝手に直った」は「何が起きたか誰も知らない」と同義
- 無効化手段を用意する MCASの修正で追加されたのがこれ。パイロットが常に上書きできる。自動化に人間が勝てない設計は危険
- 設計判断の理由を残す ADR(Architecture Decision Record)。「なぜこうしたか」は数年で必ず失われる
- 運用者を設計に参加させる 運用する人が設計を知らない体制そのものが欠陥
そして責任の話になる
事故が起きたとき、こう言われる。
「手順通りやらなかった」「オペレーションミスだ」
だが判断材料がなければ、正しい判断は不可能だ。
航空業界はここを50年かけて転換した。「なぜミスできる設計だったのか」を問うようになった。人を責めても再発は防げないからだ。
IT側はまだ「担当者のオペミス」で片付ける現場が多い。
結論
冗長化も、手順書も、自動化も、運用者が「何が起きているか分かる」ことを前提にしている。
その前提が崩れていたら、他がどれだけ完璧でも意味がない。
346名が亡くなったのは、センサーが壊れたからではない。
壊れたことを知る手段が、操縦席になかったからだ。
やること
構成図を出して、要素を1つずつ指で押さえて「これが消えたら何が死ぬ?」を聞く。
FMEAの本質はこれしかない。
聞く順番。
- 物理（ラック、電源、AZ、リージョン）
- ネットワーク（スイッチ、経路、帯域）
- 認証（IdP、証明書、鍵）
- 名前解決（DNS）
- デプロイ（CI/CD、設定配布）
- 人（属人化してる手順）
だいたい3〜6で出てくる。
そして出てきた全部を冗長化しようとするな。
油圧は4本、空調は3基。失った時の被害で優先順位を付ける。
IT側が借りきれてない3つ
構造の冗長化はコピーできてる。足りてないのは運用文化の方。
- 潜在故障の検査 予備系を定期起動する文化がまだ薄い
- 非懲罰的報告 制度として持ってる組織は少数
- 教訓の業界共有 航空は事故報告書を公開する。ITは社内で閉じがち
訓練されていない人間を前提に設計する
ここまでは運用者の話だった。ここでエンドユーザーの話をする。
航空機の乗客と、ITのエンドユーザーは同じ立場に置かれている。
- 専門知識がない
- 訓練を受けていない
- それでも最低限の操作を要求される
- 失敗すると失うのは自分
- 説明されても聞いていない
航空業界はこの前提を受け入れた上で設計している。
航空業界が採った4つの戦略
1. 説明はする。効果が薄くても続ける
全員が見ないと分かっていても、セーフティデモは毎便必ず流す。やらないよりは確実に生存率が上がるから。事故調査でも「デモを見ていた乗客の方が生存率が高い」という指摘が繰り返し出ている。
2. 説明に頼りきらない
聞いていなくても助かるように、座席のしおり、床面の誘導灯、乗員の誘導で多重化する。
3. 判断させない
緊急時、乗員は叫ぶ。「荷物を置け」「こっちへ来い」。どうすべきかを考えさせない。選択肢を与えない。
4. 失敗の被害を設計で抑える
聞いていなくても、座席は16Gの衝撃に耐える。内装は難燃素材で、燃えた時の有毒ガスまで規制されている。個人の行動に依存しない防御を先に置く。
ユーザーの「失敗」は何に対応するか
| ユーザー側で起きること | 何が起きているか | 有効な設計 |
|---|---|---|
| 振り込め詐欺 | 緊急時に判断を誤る。急かされると検証しない | 時間を挟む。高額振込の遅延、確認画面での警告、ATMでの通話制限 |
| フィッシング | 偽の指示に従う。見分けは人間には困難 | 本人に判断させない。パスキー、ドメイン照合を機械がやる |
| 簡単なパスワード | そもそも訓練されていない | 強度を人間に判斷させない。パスキー、パスワードマネージャ、バリデーション |
| アカウント情報の管理不備 | 平時は使わないものを、いざという時に使えない | リカバリーコードを事前に検証させる。多重の復旧経路 |
| 対策していない端末 | 設定は誰もしない | デフォルトで有効。OS標準で守る |
| 個人情報の意図しない公開 | 不可逆な操作を軽く実行してしまう | 公開範囲のデフォルトを閉じる。公開時に警告と猶予 |
| デマを信じる | 判断材料がないまま判断させられる | 出所の表示、ラベリング、一次情報への導線 |
| 権限の与えすぎ | 誰が何をできるかを考えていない | 危険な操作ができる人を事前に絞る |
| 復旧手段の喪失 | 締め出されてから気付く | 独立した復旧経路。使う前に一度検証させる |
共通する結論
ユーザーに正しい行動を期待する対策は、必ず失敗する
- 「強いパスワードを設定しましょう」 → 守られない
- 「怪しいリンクは踏まないで」 → 踏む
- 「公開範囲を確認して」 → 確認しない
航空機が「乗客が説明を聞く」前提で設計されていないのと同じだ。
セキュリティも「ユーザーが正しく行動する」前提で組んではいけない。
それでも説明はやめない
ここが重要だ。航空業界は全員が見ないと分かった上で、毎便必ず流し続けている。
効果がゼロではないからだ。
だから結論はこうなる。
教育は続ける。だが教育に依存しない
| 層 | 役割 |
|---|---|
| 説明・教育 | 効果はゼロではない。届く人には届く |
| デフォルトで安全 | 説明が届かない人を守る |
| 不可逆操作への摩擦 | 判断を誤っても取り返せる |
| 被害の上限 | 全部突破されても全損しない |
1枚では止まらない。重ねて止める。多層防御そのものだ。
非常口座席
- 15歳以上
- 重いドアを操作できる体力
- 乗務員の指示を理解できる言語能力
- 同伴者の介助が必要ないこと
そして必ず口頭で確認し、本人の同意を得る。「緊急時に手伝えますか」と聞く。
これは権限管理そのものだ。
危険な操作ができる立場に誰を置くかを事前に決めて、本人に自覚させる。
「権限を持っていることを本人が知らない」状態が、一番危ない。
それでも起きた後の設計
ここまでは「起こさない」「起きても飛び続ける」話だった。最後はそれでも起きた後だ。
ここが最も手薄になる領域でもある。
サバイバブル・クラッシュという考え方
墜落の多くは、人間が生き残れる衝撃の範囲内で起きている。
死因になるのは衝撃そのものより、その後に起きることだ。だからそこを設計する。
- 16G要件 座席が前方16Gに耐える。座席が壊れて投げ出されるのを防ぐ
- キャビン構造の保持 客室空間が潰れないように主構造を設計する
- 主脚の設計 胴体着陸時、脚が折れる方向を制御する。燃料タンクを突き破らない向きに壊れる
- エンジンの脱落設計 過大な力がかかったら主翼から離れて落ちる。翼を引き裂いて燃料タンクを破るより、捨てた方がいい
壊れ方を設計する。これが本質だ。
火災を遅らせる
墜落後の最大の死因は火災と煙だ。だからここに最も投資されている。
- 難燃性内装 燃焼試験に合格した素材のみ
- 有毒ガス規制 燃えにくいだけでなく、燃えた時に何が出るかまで規定
- 座席の火炎遮断層 クッション材への延焼を遅らせる
- 燃料タンクの不活性化 タンク上部の空間に窒素を注入し、爆発しない濃度に保つ。TWA800便事故(1996)を受けて義務化
90秒ルールの90秒は、この火災が致命的になるまでの猶予から逆算されている。
原因を残す:ブラックボックス
ここが航空業界の真骨頂だ。
- FDR 飛行データ記録装置。数千項目のパラメータを記録
- CVR 操縦室音声記録装置
要求性能が異常に高い。
| 条件 | 要求 |
|---|---|
| 衝撃 | 3400G |
| 火災 | 1100度で60分、260度で10時間 |
| 水圧 | 深度6000m相当で30日 |
| 圧壊 | 2270kgで5分 |
| 貫通 | 227kgの鋼杭を3mから落下 |
試験は空気砲で壁に撃ち込む。そして機体で最も壊れにくい尾部に搭載する。
機体が全損しても、記録だけは残るように設計されている。
そして守っているのは記録データだけだ。周辺回路は壊れてもいい。守る対象を極限まで絞っている。
一機の事故が、全世界の同型機を安全にする
- 独立した調査機関が調査する(運輸安全委員会、NTSB)
- 責任追及と原因究明を分離する
- 報告書は全世界に公開される
- 耐空性改善命令で全同型機に改修が強制される
この記事で挙げた設計の多くが、この経路で生まれた。
| 事故 | 生まれたもの |
|---|---|
| 日航123便 1985 | 油圧経路の分離、油圧ヒューズ |
| マンチェスター空港火災 1985 | 床面誘導灯、難燃素材の強化 |
| TWA800便 1996 | 燃料タンクの窒素不活性化 |
| テネリフェ 1977 | CRM訓練、無線用語の標準化 |
| エールフランス447便 2009 | ピンガーの長寿命化、ピトー管の改修 |
| 737 MAX 2018/2019 | MCASの両センサー参照、AoA警告の標準装備 |
IT側:全部が消えても残るもの
何を残すか
守る対象は極限まで絞る。全部残そうとすると、全部失う。
| 優先度 | 残すもの | 理由 |
|---|---|---|
| 最優先 | 何が起きたかの記録 | これが無いと原因が分からず、同じ障害を繰り返す |
| 最優先 | 構成の定義(IaC・設定) | これがあれば作り直せる。環境そのものより価値がある |
| 高 | データのバックアップ | ただしリストア検証済みのものだけが資産 |
| 高 | 復旧手順(Runbook) | 頭の中にしかないものは失われる |
| 中 | 連絡体制と権限情報 | 誰に何を頼めるか |
ブラックボックスの4条件を満たしているか
1. 対象と物理的に分離されているか
尾部に積む理由がこれだ。機首が潰れても残る場所を選んでいる。
- ログを監視対象と同じアカウント・同じリージョンに置いていないか
- バックアップを本番と同じ認証基盤の配下に置いていないか
- 同じ事業者に依存していないか
2. 書き込まれたら改変されないか
失うのは障害だけとは限らない。改竄、誤削除、ランサムウェアでも失う。
- 追記のみ(append-only)
- オブジェクトロック、WORM
- バージョニングとMFA Delete
3. 記録側が対象に依存していないか
FDRは機体の電源が落ちても記録を続ける独立電源を持つ。
- ログ転送がアプリケーションのプロセスに乗っていないか
- 障害時に転送経路ごと死なないか
- 落ちる直前の数分間が一番重要なのに、そこが欠ける設計になっていないか
4. 取り出せることを確認済みか
潜在故障の話だ。
- ログを実際に検索・取得したことがあるか
- バックアップを実際にリストアしたことがあるか
- いつ確認したかを言えるか
最も見落とされる生き証人
**CVR(操縦室音声記録装置)**に相当するものだ。
なぜ音声まで記録するのか。データだけでは「なぜそう判断したか」が分からないからだ。
FDRは何が起きたかを記録する。CVRは乗員が何を考えていたかを記録する。両方揃って初めて原因が分かる。
IT側での対応物はこれだ。
- インシデント対応中のチャットログ 何をどう判断したか
- タイムライン いつ何に気付き、何を試したか
- ADR なぜその設計にしたか
復旧が終わってから思い出そうとしても、もう思い出せない。
対応中に流れたSlackを保存しておけ。あれがCVRだ。
検査:今この瞬間に全部消えたら
本番環境が今この瞬間に全て消えたとして、何が手元に残るか。
- 消えた原因は分かるか
- 同じものを再構築できるか
- どの時点のデータまで戻れるか
- 誰がそれを実行できるか
4つとも答えられなければ、まだブラックボックスを積んでいない。
対応表
| 航空 | IT |
|---|---|
| 壊れ方を設計する | 障害時の縮退挙動を定義する |
| 火災を遅らせる | 被害の拡大を止める。サーキットブレーカー、隔離 |
| 90秒で脱出 | 復旧目標時間(RTO)を数字で決める |
| ブラックボックス | ログを障害の外側に保存する |
| 尾部に搭載 | 監視・ログ基盤を対象と同じ場所に置かない |
| 守るのは記録データだけ | 守る対象を絞る。全部を守ろうとしない |
| 責任追及と原因究明の分離 | ブレームレス・ポストモーテム |
| 報告書の全世界公開 | 障害報告の共有 |
| 耐空性改善命令 | 得た教訓を全システムに反映する |
結論
残すべきはシステムではない。システムを作り直せるものと、なぜ壊れたかの証拠だ。
環境は再構築できる。データは復元できる。
だがなぜ壊れたか分からなければ、作り直したものも同じように壊れる。
航空業界が3400Gと1100度に耐える箱を作ったのは、機体を守るためではない。
次の便に乗る人を守るためだ。
おわりに
747のコックピットは、スイッチ1個、ハンドルのロック1つ、パネルの配置1つに理由がある。
あの操縦席は、100年分の事故報告書が物理的に形になったもの。
だから航空事故報告書はインフラ屋の教材として本気で使える。NTSBのは全部公開されてる。
ここで扱った事故には、いずれも多くの犠牲がある。
日本航空123便は520名が亡くなった。ユナイテッド232便では112名が亡くなっている。
ここに書いた設計原則は、すべてその犠牲の上に得られたものだ。
航空業界が事故報告書を全世界に公開し続けているのは、二度と同じことを起こさないためだ。
教訓を技術として受け継ぐ意図でここにメモを残す。
日本航空は御巣鷹の事故を風化させないため、社内に安全啓発センターを設けて機体の残骸と遺品を保存・展示している。新人教育で必ず訪れる場所になっている。
- United 232便 油圧全喪失からエンジン推力だけで着陸を試みた
- British Airways 9便 火山灰で4発全停止からの再始動
- Qantas 32便 多重損傷を受けながら着陸に成功した設計改善の成果