世界を動かす技術を、日本語で。

複雑系の失敗のメカニズム (1998)

概要

  • 複雑システム は本質的に危険を内包
  • 多層的な 防御策 で失敗を防止
  • 単一障害 では大事故は起きず、複合的な小さな失敗が重なることで発生
  • 安全性 はシステム全体の特性であり、個々の要素ではない
  • 人間の 適応力 と経験が安全運用の鍵

複雑システムの本質的危険性

  • 複雑システム (例:交通、医療、発電)は、その性質上、不可避的に危険を内包
  • 危険の頻度は変えられるが、プロセス自体は 本質的・不可逆的な危険 性を持つ
  • この危険の存在が、防御策や安全対策の発展を促進
  • 技術的・人的・組織的・制度的防御策 の多層構造
    • 技術的バックアップや安全機能
    • 教育や知識による人的対策
    • 手順、認証、規則、チーム訓練などの組織的対策

失敗と防御のメカニズム

  • 多重防御 により、通常は事故発生を回避
  • 大事故には小さな失敗の 複合 が必要
  • 多くの初期的な失敗は設計上の安全機能で遮断
  • 運用現場での 実務者の対応 が事故への進行を阻止
  • システム内には常に 潜在的な失敗 が混在
    • 経済的コストや予防の困難さから、全ての潜在的失敗の排除は不可能
    • 技術や組織の変化により、潜在的失敗の内容も常に変動

システムの劣化運用と事故の発生

  • 複雑システムは 劣化状態 で稼働するのが常態
  • 多重冗長性や人間の適応力により、欠陥があっても機能維持
  • 事故調査では、過去にも「未遂事故」が頻発していた事実が明らかに
  • 外部者の後知恵バイアス により、事故前に劣化状態が認識できたはずと誤解されがち

事故原因と「根本原因」神話

  • 大事故は 複数の要因 が結合して発生
  • 各要因は単独では事故を引き起こすには不十分
  • 「根本原因」探しは 社会的・文化的な責任追及 であり、技術的理解には基づかない
  • 人間の認知は 後知恵バイアス に影響されやすく、事故後の評価が実態と乖離

実務者の二重役割と意思決定

  • 実務者は「生産」と「失敗防御」の 二重役割
    • 通常時は生産重視、事故後は防御重視
  • 実務者の行動は常に 不確実性下の賭け
    • 成功も失敗も「賭け」の結果であり、事故後にのみ失敗が強調されがち
  • 現場の意思決定 が組織の曖昧さ・矛盾を解消

人間の適応力と専門性

  • 実務者と現場管理者は、 生産最大化と事故最小化 のために絶えず適応
    • 脆弱部分の再構成
    • 重要リソースの重点配分
    • 回復・撤退経路の確保
    • 早期警戒と柔軟な生産調整
  • 専門性 は技術や人員の変化で常に変動
    • 専門家のリソース配分と後継育成が課題

変化が新たな失敗を生む

  • 事故率の低下が 新技術導入 を促進
    • 既存の小規模失敗を減らす一方、新たな大規模失敗のリスクを増加
    • 低頻度・高影響の新たな事故経路が発生しやすい
    • 事故が起きるまで新たな危険性が見えにくい

事故後対策と安全性の本質

  • 「人為的ミス」への対策は 活動の制限 に偏りがち
    • これによりシステムの結合度と複雑性が増加し、潜在的失敗も増加
  • 安全性はシステム全体の創発特性
    • 個人や装置、部門単位ではなく、全体の相互作用から生まれる
    • 安全は購入・製造できるものではなく、システムの一部として動的に維持される

安全創出の実践と経験

  • 安全な運用 は、現場の人々が不断の適応で実現
    • 日常業務の一部として、失敗を経験しつつ境界を見極める能力が重要
  • 経験を通じて、システムの限界や危険領域を体感し、より堅牢な運用へ発展

この内容は、複雑システムの本質的危険性と安全運用の課題、そして人間の役割についての理解を深めるための要点整理です。

Hackerたちの意見

前に別の投稿でこれをシェアしたかもしれないけど、ジョン・ギャルの本はこのテーマについてすごく良いよ。「General Systemantics」ってやつね。[https://en.wikipedia.org/wiki/Systemantics]

ギャルの法則は俺のお気に入りの一つで、ソフトウェア開発で何十年も経験してきたけど、これは本当にその通りだと思う。> 「機能する複雑なシステムは、必ず機能する単純なシステムから進化している。ゼロから設計された複雑なシステムは決して機能せず、動作させるためにパッチを当てても無理。動作する単純なシステムからやり直さなければならない。」 — ジョン・ギャル, Systemantics (1975)

失敗のない運用には、失敗の経験が必要だ。これが我々がカオスエンジニアリングを作った理由だ。常に失敗を強制することで、その失敗に対抗するシステムを作り続けることができ、特定の失敗モード内での異なるシステムの tipping point についての素晴らしいデータを得ることができた。

これを自分の作業しているシステムに適用するのはいつも苦労してる。システムが失敗すると、誰かが死ぬ可能性があるけど、実際には入院以上のことは起きたことがない。それを避けるために、失敗モデリングやテストに膨大な努力を費やしているけど、未知の未知を排除することはできない。そのギャップが何度かトップニュースになったことがある。

それよりもずっと普遍的で複雑な問題なんだよね。学校や教育全般が苦しんでいる大きな問題の一つは、環境があまりにも安全すぎること。子供たちが失敗から学ぶ方法が少なすぎるんだ。問題を解決しようとする試みは、「さあ、みんなで安全に倒れよう、そしてそこから学ぼう!」みたいに見えるけど、全然うまくいかない。リアルな失敗は予期しないもので、自分の決断に関連していて、本当に痛い思いをしないと学べないんだよね。追記:ちなみに、これが若者のメンタルヘルス危機の主な原因だと確信してる。

失敗の理由にはいくつかの共通テーマがあると思うけど、具体的に掴むのが難しい。これは理由のリストみたいだけど、もっと抽象的な方向性を探しているんだ。--- AIにそれをやらせて、自分の神経を刺激するのは避けたいと思ってる。

失敗を防ぐためのレシピは存在しないってのが、ポイントの一部だと思う。失敗は、事前に明らかではない形で多くの出来事が重なって起こるカスケードだから。そういうふうに[サイト?記事?]を読んだ。

このテーマに関する決定的な作品は「Normal Accidents」で、現代版は「Meltdown」にあるよ。[https://en.wikipedia.org/wiki/Normal_Accidents] [https://en.wikipedia.org/wiki/Meltdown_(Clearfield_and_Tilcs...]

この文書がどれだけ重要か、俺はいつも繰り返してるけど、複雑なシステムが実際に失敗するまで長い経験を積まないと、その重要性を理解するのは難しい。よく言われるサブテキストは、「根本原因分析」は、少なくとも複雑なシステムにおいては無駄な努力だってこと。例えば、分散ロックシステムで何かがうまくいかなくなると、全体のデプロイメントシステムがメタ安定状態に入ってしまう。自然に、根本原因はロックシステムのレジリエンシーのように見える。でも、メタ安定状態の失敗は、引き金となる条件が解決された後も持続するものだから、定義上は根本原因が二つあることになる。ロックの失敗とデプロイメントシステムの故障のメタ安定性。探し続ければもっと見つかるよ。でも、俺にとってこの文章で一番の衝撃は、複雑なシステムでは常にランダムなことが失敗しているっていうさらなる観察だ。「複雑なシステムは劣化モードで動作する」。レジリエントなコンポーネントは良いけど、全体のプロセスのレジリエンシーが、システム全体をオーケストレーションしているかどうかが、物事が爆発するかどうかを決定するんだ。実践者の行動はすべてギャンブルだ。どこかにそれを刻んでおきたいな。

「この文書がどれほど重要か、私は何度も言ってるけど、実際に複雑なシステムが失敗するのを長い間経験しないと、その重要性は理解しづらいよね。もしそのワインに合うチーズが欲しいなら、この記事は『グラグ脳の開発者』と一緒に読むといいよ。」

根本原因分析って、組織の儀式みたいなもので、みんなが何かをしている気分にさせるだけ。エンジニアリングよりも政治的な側面が強いんだよね。プロセス自体が役に立たないことが多くて、正しい根本原因すら特定できてないことがほとんど。要するに、設計が悪いシステムはどこかで失敗するってこと。氷山の一角として考えるか、雷は同じ場所に二度落ちないっていう別の比喩でもいい。頑丈でよく設計されたシステムは、もろくて設計が悪いシステムとは全然違う。もろいシステムはランダムな失敗を示すし、それを追いかけるのは逆効果だよね。確かに、かなり複雑で信頼性の高いシステムもある。内燃機関や車、飛行機(まあ、ちゃんと設計されたやつね)なんかがその例。そこからさらに大きなシステム、例えば都市の交通システムを構築すると、物事が「失敗」するスケールに達するんだ。どこかのバスや電車が正しい時間に駅に着かないのは、バスが故障したり、渋滞があったりするから。でも、やっぱりよく設計されたシステムはそういうことに強い。システムを構成するパーツはよく理解されているから、その結果としての信頼性も理解できる。ソフトウェアに関しては、あまりうまく設計・構築されていないことが多い。適当に組み合わせているだけで、失敗した時に驚くんだ。そして「複雑なシステムだから」と言い訳をする。多くの場合、他の分野に比べて私たちの規律やスキルが不足しているだけで、システムがそれほど複雑だというわけではない。追記:機械システム、例えばエンジンはソフトウェアよりも基本的にシンプルだと言う人もいるけど、ベアリングを見てみて。たった一つのベアリングでも、信じられないくらい複雑なシステムなんだ。ベアリングの故障は統計的な出来事で、早く故障するものもあれば、遅く故障するものもある。エンジンに使われるベアリングには何世代ものノウハウが詰まってる。機械エンジニアは一般的に、よく理解された部品や設計を使って、設計しているエンジンの要件を満たすために余裕を持たせている。ソフトウェアでは、よく「ベアリング」を再発明したり、新しい未検証の設計を選んだりして、性能や故障モードを十分に理解しないまま作ってしまう。そして、どう使うべきか、いつ使うべきかのパターンも知らないまま。だから、「車」が変な方法で故障する時に驚くんだ。新しい設計に対して、機械エンジニアが使う基準でテストすることもない。彼らは、デザインが大きなシステムの一部として受け入れられる前に、何百万回もサイクルをこなすウィジェットがいっぱいの部屋を持っている。私たちは「YOLO」でやっちゃうんだよね。

「根本原因分析」、特に複雑なシステムに関しては、愚かな試みだよ。正しく理解されている場合は別だけど、実際にはそうでないことが多い。根本原因分析の正しい目的は、この失敗がこのシステムについて何かを変える必要があるかどうかを答えることなんだ。もし答えが「はい」なら、変える必要があるものがその失敗の「根本原因」と呼ばれる。もちろん、厳密に言えばそれは誤称だけど、実際の質問に対して間違った答えを出したわけではない。

Hacker Newsで議論の続きを見る