なぜ複雑なシステムは破綻するのか？エンジニア必読の古典的名著（1998年）

1998年に発表された「How Complex Systems Fail」は、現代のソフトウェアエンジニアやシステム運用に携わる人にとって、今なお極めて重要な示唆を与えてくれるバイブル的存在です。この論文では、複雑なシステムがどのようにして崩壊へと向かうのか、そのメカニズムと人間側の要因について鋭く切り込んでいます。システム障害を減らし、より堅牢な設計を目指すすべてのエンジニアに、ぜひ一度読み返してほしい不朽の名作です。

前の投稿でも書いたかもしれないけど、このトピックならJohn Gallの本がすごくいいよ。General Systemantics [https://en.wikipedia.org/wiki/Systemantics (https://en.wikipedia.org/wiki/Systemantics)]

障害のない運用には、障害の経験が必要である。

これが私たちが「Chaos Engineering」を生み出した理由だよ。絶えず強制的に障害を起こすことで、その障害に耐えられるようなシステム作りを常に意識せざるを得なくなった。おかげで、特定の障害モードにおいて各システムの限界点がどこにあるのか、優れたデータを得られるようになったんだ。

障害の原因には共通のテーマがいくつかあると思うんだけど、うまく整理できてないんだよね。

提示されたリストはあくまで理由の羅列って感じで、もっと抽象的に「どう防ぐか」という指針を探しているんだ。

脳を働かせたいから、AIに考えさせるのは避けようと思ってる。

このトピックの決定版といえば『Normal Accidents』だね。現代版の解説としては『Meltdown』もおすすめ。

https://en.wikipedia.org/wiki/Normal_Accidents (https://en.wikipedia.org/wiki/Normal_Accidents)

https://en.wikipedia.org/wiki/Meltdown_(Clearfield_and_Tilcs... (https://en.wikipedia.org/wiki/Meltdown_(Clearfield_and_Tilcsik_book))

このドキュメントがいかに重要か、飽きるほど言ってる気がする。実際に複雑なシステムが崩壊していくのを長期間経験しないと、本当の価値は分からないものだよ。

よく引用されるこの話の核心は、「複雑なシステムにおける『根本原因分析』は無駄な努力だ」ということだ。例えば分散ロックシステムで何かがおかしくなると、デプロイメントシステム全体が準安定状態（メタステーブル）な障害に陥る。当然、「根本原因はロックシステムの回復力不足だ」と考えたくなる。でも、定義上、準安定的な障害は引き金となった条件が解決しても持続してしまう。これで「ロックの不具合」と「デプロイシステムの脆弱性」という2つの「根本原因」ができてしまったわけだ。探し続ければもっと出てくるよ。

でも、この文書で一番ガツンとくるのは、「複雑なシステムでは常にランダムな不具合が起きている」という指摘だ。「複雑なシステムは常に劣化したモードで動いている」んだよ。耐障害性のあるコンポーネントも大事だけど、システム全体をオーケストレーションするプロセスの回復力こそが、崩壊を防ぐ決め手になる。

実務者のすべての行動は賭けなんだ。どこかに刺青しておきたいくらいだよ。

Dietrich Dörnerの『The Logic of Failure』（1997年）を強くおすすめするよ。

「システムが機能し続けているのは、冗長性が多く、欠陥だらけでも人間がなんとか機能させているからだ。事故後の調査では、ほぼ例外なく、破局寸前の『プロト事故（ニアミス）』が何度も繰り返されていた事実が指摘される。表面的な事故が起きる前に、劣化した状態を認識すべきだったという議論は、たいていシステム性能に対する素朴な考えに基づいている。システムの運用は動的であり、コンポーネント（組織、人間、技術）は絶えず故障し、入れ替わっているのだ」

これはAdmiral Cloudbergが書いた国立空港での衝突事故の記事とすごく似ているね。

「複雑なシステムを見て、それが正確にどう壊れるかを予測できる人間などいない。しかし、十分なデータがあれば、労働安全分野で知られる『ハインリッヒの法則』によって予測が可能になる。これは重大事故1件につき約300件の『ニアミス』があるという法則で、最新版では、死亡事故1件に対して約3,000件のニアミスと、約30,000件の『リスクある行動』が伴うとされている。統計的に見れば、最初の死亡事故が起きる前に何百、何千ものリスクある行動やニアミスが発生しており、命が失われる前にリスクを特定する機会があるということだ」

https://admiralcloudberg.medium.com/reaping-the-whirlwind-in... (https://admiralcloudberg.medium.com/reaping-the-whirlwind-inside-the-potomac-river-midair-collision-0475416f2b0f)

これは本当に重要な研究だね。興味があってさらに深く掘り下げたいなら、「Safety II」という分野を調べてみるといい。Erik Hollnagel[1]かSydney Dekkerの本がおすすめ。以前、これがITセキュリティにどう適用できるかのプレゼンをまとめたことがあるんだ[2]。ざっくり言うとこんな感じ：

Safety I エラーから学ぶ、安全を「欠如」で定義、リアクティブ（事後対応的）なアプローチ、何がうまくいかなかったかを理解する、事故原因モデル、エラーの回避、損失の削減

Safety II 成功から学ぶ、安全を「存在」で定義、プロアクティブ（予防的）なアプローチ、何がうまくいっているかを理解する、成功を繰り返す、成功する行動を強化する、成功に基づいて新しいプロセスを作る

特にこの言葉をじっくり考えてみてほしい。「事故後に『根本原因』を特定するのは根本的に間違っている」。これは真実だよ。もしこの一文を本当に理解できたら、君はSafety IIをマスターしたと言える。電球が光るようにハッと気づき、二度と元には戻れなくなるはずだ。それは呪いのような、美しくも厄介な気づきだけどね。

[1] https://safety4sea.com/cm-safety-i-vs-safety-ii-an-overview (https://safety4sea.com/cm-safety-i-vs-safety-ii-an-overview)
[2] https://www.msoos.org/largefiles/safety2.pdf (https://www.msoos.org/largefiles/safety2.pdf)

この（素晴らしい）論文を読むたびに、最初のセクションの冒頭の一文にハッとさせられるんだ。

> 興味深いシステム（例：交通、医療、発電）はすべて、その性質上、本質的かつ避けられない危険を抱えている。

（強調は私によるもの）

これって誤字なのかな？ それとも私の無学な頭では理解できない書き方のルールなんだろうか。