フォールトトレランス - yuuk1's Digital Garden

# フォールトトレランス ## 定義フォールトトレランス(fault tolerance)とは、**障害(fault)が存在するにもかかわらず、システムが指定されたサービスの提供を継続する能力**である。Heimerdinger+Weinstock 1992([[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]])は「フォールトトレランスは冗長性管理(redundancy management)である」と定式化し、以下の6アクションで構成されると整理した: | アクション | 定義 | |---|---| | 障害検知(Detection) | 障害が発生したことを判定する | | 障害診断(Diagnosis) | 障害の原因またはサブシステムを特定する | | 障害封じ込め(Containment) | 障害の伝播を防ぐ | | 障害マスキング(Masking) | 障害コンポーネントにもかかわらず正しい値を保証する | | 障害補償(Compensation) | 障害サブシステムの出力を補う | | 障害修復(Repair) | 障害をシステムから除去する | ディペンダビリティ達成の4手段(障害回避・障害除去・フォールトトレランス・障害回避的措置)の中で、フォールトトレランスは実行時の手段である([[ディペンダビリティ]]参照)。 ### 基本的な障害・失敗の定義(Heimerdinger+Weinstock 1992) - **失敗(failure)**: システムが提供するサービスが仕様への準拠から逸脱すること - **障害(fault)**: 構成要素/サブシステム/相互作用システムの失敗として定義。「一人の障害は別の人の失敗」——観測レベルによって同じ事象が障害にも失敗にもなる - **症状(symptom)**: システム境界における障害の観測可能な影響 - **障害軌跡(fault trajectory)**: 連続的にトリガーされる障害の連鎖(連鎖反応) ### 冗長性の分類 - **空間冗長(space redundancy)**: 別物理コピーの提供。持続的障害・マスキングに向く - **時間冗長(time redundancy)**: 時間軸をずらして再実行。一時的障害に有効 - **設計多様性(design diversity)**: コモンモード設計障害への唯一の対策——異なるアルゴリズム/物理原理による複数実装 ### ソフトウェア冗長化がハードウェア冗長化と異なる理由ハードウェアの空間冗長(同一部品の複製)は部品ごとの独立した物理的劣化・製造ばらつきを前提に機能するが、ソフトウェアの単純複製は機能しない。[[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] はその理由を明快に述べる――「ソフトウェアの障害はほとんどが仕様・設計上の欠陥に起因するため、同じ入力に対しては単純複製された版も同じ誤った出力で応答する。複製された欠陥は同時に励起され、全版が同時に故障する」(§14.3.2)。これがハードウェアの空間冗長とソフトウェアの空間冗長の決定的な違いである。この問題への対策として提案されたのが設計多様性(design diversity、本 concept「冗長性の分類」節)――独立した開発チームによる機能的等価版の並立――だが、同章 §14.7 の実験(20版のアビオニクスアプリケーション)は、独立開発によっても版間の故障相関が消えないこと(9版同時故障の期待8回に対し実測約105回)を定量的に示した。すなわちソフトウェアでは「冗長化すれば独立に故障する」という前提そのものが検証を要する経験的主張であり、ハードウェアの空間冗長のように設計上自動的に成立するものではない。 ### 障害封じ込め領域(Fault Containment Regions, FCR) 障害の伝播を構造的に防ぐための設計手法。共通依存関係を排除した領域境界を設ける。超高信頼設計では各 FCR が物理的・電気的に隔離されたプロセッサ・メモリ・電源・クロック・通信リンクを持つ。 ### カバレッジ(Coverage) 「障害が発生したときにシステム失敗が起きない確率」の非形式的尺度。マルコフモデルで定量化。各障害・修復アクションが新しい状態へ遷移する過程として表現される。 ### Saltzer & Kaashoek(2009)の fault / error / failure 連鎖モデル Saltzer & Kaashoek はモジュール境界を基準に fault(障害)・error(誤り)・failure(故障)を定義する。障害(fault)は問題を引き起こす可能性のある潜在的な欠陥・不完全さ・欠点であり、実際に問題を起こしたかどうかは問わない(タイヤのケーシングの弱い箇所が例)。障害が活性化(active)すると誤り(error)——データ値や制御信号の誤った値——が生じ、活性化していない障害は潜在(latent)状態にある。誤りが検知・マスクされないままモジュール境界外に現れると、そのモジュールの故障(failure)になる。ここで「あるサブシステムの故障は、それを含む上位サブシステムから見れば障害である」という入れ子構造が明示され、フラットタイヤの発見(下位サブシステムの故障を検知した誤り)と、それによって約束に遅れること(上位サブシステムの故障)という具体例で説明される。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 8 Fault Tolerance - Reliable Systems from Unreliable Components]] §8.1.1) さらに誤りは、一時的障害(transient fault、雷やコズミックレイなど一過性の外部事象による)と持続的障害(persistent fault、再試行しても誤りを出し続ける)に対応して、ソフトエラー(再試行でマスクできた誤り)とハードエラー(再試行してもマスクできない誤り)に分類される。誤り潜伏時間(latency、障害の活性化から検知・故障までの時間)が長いほど、2つ目の誤りが重なって単一誤りマスキング機構が破綻するリスクや、誤りが伝播して封じ込めが困難になるリスクが増す。(Source: 同上 §8.1.1) 本書はこの誤りをさらに、検知可能/検知不能、検知済み/未検知、マスク可能/不能、マスク済み/未マスク、許容/未許容という対をなす下位区分の連鎖として分類する(図8.3の誤り分類木)。この分類は §8.1.2 で定式化される耐障害性モデル構築プロセスの骨格そのものであり、「未検知の誤りを検知可能にする」「検知可能な誤りにマスク手続きを設計する」という段階的な改善の道筋を与える。(Source: 同上 §8.3.1, §8.3.2) ### 耐障害設計プロセス(§8.1.2)——安全網アプローチ Saltzer & Kaashoek は耐障害設計を7段階の反復プロセスとして提示する: (1) 耐障害性モデルの構築(すべての潜在的障害を洗い出し、リスクを見積もり、リスクが高い箇所に検知手続きを設計する)、(2) モジュール性による高リスク誤りの封じ込め、(3) 時間的冗長性(同一構成要素での再試行)・空間的冗長性(異なる構成要素での実行)による誤りのマスク手続きの設計、(4) 改善を反映したモデルの更新、(5) 未許容の障害確率が十分低くなるまでの反復、(6) 現場でのログ観察(マスクされた誤りの件数の追跡、故障の事後分析)、(7) ログと事後分析報告に基づくモデルの改訂。このプロセス全体は「安全網アプローチ(safety-net approach)」と呼ばれ、「明示せよ(be explicit)」「反復を前提に設計せよ(design for iteration)」「安全余裕の原則(safety margin principle)」「掘り続けの原則(keep digging principle)」「大胆な単純化を採用せよ(adopt sweeping simplifications)」という5つの設計原則の組み合わせとして定式化される。(Source: 同上 §8.1.2) ## 横断的知見 - **Heimerdinger+Weinstock 1992 の「error 廃棄」は Avizienis 2004 の「error 存続」と緊張関係にある**: 1992 年報告書は fault/failure の2項を明確化するために error を fault に吸収した。一方、Avizienis 2004([[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]])は fault → **error** → failure の3段連鎖モデルを保持した。実務上 error は「システム状態の誤り」という受動的概念として有用で、オンライン障害予測研究(Salfner+ 2010)もこの3段モデルを基盤とする。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]], [[A Survey of Online Failure Prediction Methods]]) - **障害回避的措置(fault evasion)は 1992 年に命名された先回り型フォールトトレランスであり、2020年代の AIOps 予防的管理と同型**: Heimerdinger+Weinstock は「仕様違反なしに異常挙動を検知し、失敗に至る前に再構成する」実践を *fault evasion* と命名した。これは Notaro+ 2021([[A Survey of AIOps Methods for Failure Management]])の AIOps proactive カテゴリ(prevention + online prediction)、および Salfner+ 2010 の [[プロアクティブ障害管理]] 4段モデルと概念的に同型である。30年前に命名された概念が AIOprs として再構成されている。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[A Survey of AIOps Methods for Failure Management]], [[A Survey of Online Failure Prediction Methods]]) - **「受け入れテスト対比較」という2検知手法の区別は、現代の単一/多数投票型レプリカ設計の直接の祖型である**: 受け入れテストは単一プロセッサで機能する汎用検知(ただし診断不可)、比較はペアワイズと投票による障害診断が可能。これは LLM 訓練クラスタでの故障マシン検知([[Minder]]: メトリクス類似度比較)やチェックポイント整合性検証([[チェックポイント]])の設計パターンの元型と見なせる。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] §4.3-§4.4) - **DDIA 2E(2026)の fault/failure 区別は、Heimerdinger+Weinstock(1992)の枠組みを 34 年後の一般読者向け教科書がほぼそのまま踏襲していることを示す**: DDIA 第2章は「障害(fault)はシステムの一部分が正しく動作しなくなること、失敗(failure)はシステム全体が要求されたサービス提供を止めること」と定義し、実際に Heimerdinger+Weinstock 1992 を参考文献として引く。「1台のディスクだけで構成されたシステムでは、そのディスクの障害がシステム全体の失敗そのものだが、複数ディスク構成なら1台の障害は上位システムから見た障害にとどまる」という DDIA の例は、本 concept の定義節が示す「一人の障害は別の人の失敗」——観測レベルによって同じ事象が障害にも失敗にもなる——を具体的なストレージの文脈で言い換えたものである。学術的な dependability の分類が一般向け教科書の標準語彙として定着していることが確認できる。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] "Reliability and Fault Tolerance") - **DDIA のカオスエンジニアリング/障害注入は、カバレッジ(coverage)をマルコフモデルで解析的に求める代わりに経験的に検証する立場を取る**: 本 concept の定義節が示す「カバレッジ」(障害発生時にシステム失敗が起きない確率)は 1992 年時点ではマルコフモデルによる定量化が想定されていた。DDIA 2E は同じ問題意識——フォールトトレランス機構が実際に正しく動作するかの確信を高めること——に対し、プロセスをランダムに強制終了するなど意図的に障害率を上げる障害注入(fault injection)と、それを体系化したカオスエンジニアリングという経験的・実験的アプローチを提示する。数千コンポーネントを持つ現代の大規模システムでカバレッジのマルコフモデル計算が実用上困難である(本 concept の未解決の問い参照)ことへの、実務上の代替解と位置づけられる。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "Coverage", [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] "Fault Tolerance") - **DDIA のハードウェア障害率の実データは、1992 年の抽象的な障害分類に定量的な裏付けを与える**: DDIA 2E はハードディスクの年間故障率 2〜5%、SSD の年間故障率 0.5〜1%(ただし訂正不能エラーは新しいドライブでも年1回程度発生しハードディスクより高い)、CPU コア約1,000台に1台が製造欠陥により誤った計算結果を返す、ECC メモリでも年1%超のマシンが訂正不能エラーに遭遇するといった具体的な発生率を示す。1992年の概念枠組みは「障害がどのように分類されるか」を扱ったが「どの程度の頻度で起きるか」は扱わなかった——両者を組み合わせることで、空間冗長・時間冗長といった冗長性設計が対処すべき障害率の桁感が得られる。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] "Hardware and Software Faults") - **DDIA 第9章は「なぜクォーラムがフォールトトレランスの基本手段になるか」を、1992 年の冗長性分類の分散システム版として補強する**: 本 concept の「冗長性の分類」節(空間冗長・時間冗長・設計多様性)は単一システム内の部品冗長を主眼とするが、DDIA 第9章は分散システムにおいて「ノードは自身の判断すら信用できない」ため、フォールトトレランスの意思決定を単一ノードでなく過半数の合意(クォーラム)に委ねる必要があると論じる。これは空間冗長(複数ノードへの複製)を前提としつつ、その冗長化された複数の観測をどう単一の決定に集約するかという、1992 年の枠組みが明示的に扱わなかった「合意」の層を補う。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "冗長性の分類", [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "The Majority Rules") - **フェンシングトークンは「障害マスキング」でなく「障害封じ込め」の分散版として位置づけられる**: 本 concept が整理する 6 アクション(検知・診断・封じ込め・マスキング・補償・修復)のうち、DDIA 第9章が詳述するフェンシングトークン機構は、ゾンビ化した旧リース保持者(すでに障害と診断されたノード)が新たな書き込みで被害を及ぼすのを防ぐ点で「障害封じ込め(Containment)」に相当する。ただし対象は単一システム内のコンポーネント境界でなく、分散システムのノード間の時間的順序(古いトークン vs 新しいトークン)である点で、1992 年の FCR(障害封じ込め領域)が想定する物理的・電気的な隔離とは異なる次元の封じ込めを実現している。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "障害封じ込め領域", [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Fencing off zombies and delayed requests") - **[[@2013__CACM__The Tail at Scale]] は「レイテンシばらつき」を、本 concept の6アクション(検知・診断・封じ込め・マスキング・補償・修復)のうち主に「補償(Compensation)」と「マスキング(Masking)」に相当する形で扱う——ただし対象は障害でなくレイテンシという性能次元である**: Heimerdinger+Weinstock 1992 のフォールトトレランス6アクションは「障害コンポーネントの存在下で正しい値を保証する」ことを目的とするが、tail-tolerant 技術(ヘッジリクエスト・タイドリクエスト)は「一部のレプリカが遅くても全体としてのレイテンシを保証する」ことを目的とする。ヘッジリクエストが複数レプリカへ同じリクエストを送り最速の応答を採用する構造は、空間冗長(space redundancy、本 concept「冗長性の分類」節)をレイテンシ次元に転用したものであり、著者ら自身が本文中で「フォールトトレラントコンピューティングと同様のアプローチ(analogous to fault-tolerant computing)」と明言している。DDIA のフォールトトレランス論(冗長化・クォーラム)が「正しさ」を守るのに対し、tail-tolerant 技術は「応答性」を守るという直交する目的のために同じ冗長性の道具立てを使う点が、本 concept とtail-tolerant 技術群([[テールレイテンシ耐性技術]])の分岐点である。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "冗長性の分類", [[@2013__CACM__The Tail at Scale]] 本文 pp.74, 80) - **[[@2013__CACM__The Tail at Scale]] は「カバレッジ」概念のレイテンシ版を、明示的な確率モデルではなくファンアウト数×外れ値頻度の実測グラフとして提示する**: 本 concept の「カバレッジ」節は障害発生時にシステム失敗が起きない確率をマルコフモデルで定量化する手法を扱うが、DDIA と同様、tail-tolerant 技術群も解析的なカバレッジ計算ではなく実測に基づく評価を採用する。ただし DDIA のカオスエンジニアリング(意図的な障害注入による経験的検証)とは異なり、本論文はサービスのスケール(ファンアウト数)と単一コンポーネントの外れ値頻度という2変数から、サービスレベルで一定レイテンシを超える確率を導出する解析的なグラフ(Figure「Probability of one-second service-level response time」)を示す点で、障害の世界の「カバレッジのマルコフモデル」に最も近いレイテンシ版の定量枠組みを提供する。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "Coverage", [[@2013__CACM__The Tail at Scale]] 本文 p.76) - **カオスエンジニアリングの実践者自身が、カバレッジの解析的計算を放棄し経験的信頼感に置き換える理由を一人称で説明する**: 既出の横断的知見は DDIA の記述をもとに「カオスエンジニアリングはカバレッジのマルコフモデル計算の実務上の代替解」だと位置づけたが、これは第三者による解釈だった。[[Casey Rosenthal]](元 Netflix カオスチーム責任者)は『SREの探求』14章で「システムの定常状態を中断させかねない要素について解決策を探し始めると全く切りがない」「絶対確実を求めることはできないので、私たちは信頼感をもってよしとする。検証プログラムが成功すれば信頼感が高まる」と明言し、Chaos Monkey・Chaos Kong のような継続的な経験的検証を、確率の解析的証明でなく反証されなかった試行の蓄積による信頼構築として位置づける。これは本 concept の「カバレッジ」節が前提とするマルコフモデルによる確率計算という発想そのものを実務上放棄する理由を、実践者本人が明示的に述べた一次資料であり、DDIA の記述(第三者の解釈)を裏付ける。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "Coverage", [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.6) - **McAllister & Vouk 1996 は、本 concept の6アクション(検知・診断・封じ込め・マスキング・補償・修復)のうち「マスキング」と「補償」がソフトウェア多版方式でどう実装されるかを具体化する**: Heimerdinger+Weinstock 1992 の障害マスキング(masking)は「障害コンポーネントにもかかわらず正しい値を保証する」と抽象的に定義されるが、[[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] のNバージョンプログラミング(投票器による多数決)はこのマスキングの具体的な実装であり、リカバリブロック(受け入れテストによる検知+ロールバックという補償)は同じ6アクションのうち検知+補償の組み合わせに対応する。ただし本 concept が既に指摘するとおり、ソフトウェアの冗長化はハードウェアと異なり「同じ入力に同じ誤りで応答する」という制約(前節参照)を負うため、マスキングが機能する前提条件(版が独立に故障すること)自体がハードウェアより脆い。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "フォールトトレランスの6アクション", [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.3.2, §14.4) - **Saltzer & Kaashoek(2009)の fault→error→failure 連鎖モデルは、Heimerdinger+Weinstock(1992)ではなく Avizienis(2004)の3段モデルと同型である**: 既出の横断的知見が指摘するとおり、Heimerdinger+Weinstock 1992 は fault/failure の2項を明確化するために error を fault に吸収した(「一人の障害は別の人の失敗」)のに対し、Avizienis 2004 は fault→error→failure の3段連鎖を保持した。Saltzer & Kaashoek(2009)はこの3段モデルを踏襲し、しかも「障害は潜在(latent)/活性(active)の2状態を持ち、活性化して初めて誤りを生む」という Avizienis 側にも Heimerdinger+Weinstock 側にも明示されていない状態遷移の細部(潜在/活性の区別)を独自に導入している。教科書としての PCSD が、CMU SEI の技術報告書(1992)より IEEE の学術論文(2004)に近い定義体系を採用している点は、fault/error/failure の3語区別が2000年代以降の標準的な語彙として定着したことを示唆する。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]], [[@2009__MITOCW__Principles of Computer System Design - Chapter 8 Fault Tolerance - Reliable Systems from Unreliable Components]] §8.1.1) - **Saltzer & Kaashoek の「安全余裕の原則」は、Heimerdinger+Weinstock の「カバレッジ(coverage)」概念のうち、マルコフモデルによる事前の定量化ではなく運用時の実測による事後監視という半分だけを取り出したものである**: 本 concept の「カバレッジ」節が示すマルコフモデルは、障害発生時にシステム失敗が起きない確率を設計時に解析的に見積もる手法である。これに対し PCSD §8.2.3・§8.1.2 が説く安全余裕の原則は、「残余の耐障害性(remaining failure tolerance)」——現在どれだけの誤りをすでにマスクし、あと何回分の耐障害性が残っているか——を運用中に常時ログで追跡し、気づかれないまま許容量を使い果たすことを防ぐ、という事後監視の実践に焦点を絞る。PCSD 自身が MAXC の戦訓(§8.8.1、訂正された誤りをログしていなかったために誤り率の上昇に長く気づかなかった)を安全余裕の原則の違反例として挙げており、「設計時にカバレッジを計算する」ことと「運用時に実際のマスク回数を追跡する」ことは、同じ耐障害性の定量化という目的に対する異なる時間軸のアプローチである。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "Coverage", [[@2009__MITOCW__Principles of Computer System Design - Chapter 8 Fault Tolerance - Reliable Systems from Unreliable Components]] §8.1.2, §8.2.3, §8.8.1) - **PCSD の図8.3(誤り分類木: 検知可能/不能→検知済み/未検知→マスク可能/不能→マスク済み/未マスク→許容/未許容)は、Heimerdinger+Weinstock の6アクション(検知・診断・封じ込め・マスキング・補償・修復)のうち検知とマスキングの2つだけを、時系列の意思決定木として精緻化したものである**: 本 concept の6アクションは並列な分類として提示されるが、診断(Diagnosis)・封じ込め(Containment)・補償(Compensation)・修復(Repair)に相当する軸は図8.3には現れない。逆に図8.3が持つ「検知可能だが検知手続きが実装されていないために未検知にとどまる」「マスク可能だが設計者がマスクしないと決めた」という、実装判断による分岐(検知手続き・マスク手続きの有無)は、6アクションの並列列挙には存在しない時系列の意思決定構造である。両者は同じ問題(障害への対応の体系化)を、6アクションという「何をするか」の列挙と、図8.3という「ある誤りが最終的にどう扱われるか」の意思決定木という、異なる形式で捉えている。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] "フォールトトレランスの6アクション", [[@2009__MITOCW__Principles of Computer System Design - Chapter 8 Fault Tolerance - Reliable Systems from Unreliable Components]] §8.3.1) ## 未解決の問い - fault evasion(障害回避的措置)と AIOps の prevention・online prediction カテゴリの間の概念的一致は 1992 年から認識されていたか。両者の「正常挙動からの逸脱の定義」はどう異なるか。 - カバレッジ(coverage)をマルコフモデルで定量化する手法は、数千コンポーネントを持つ現代の大規模クラウドシステム・LLM 訓練クラスタに適用できるか。状態爆発問題にどのように対処しているか。 - 設計多様性(design diversity)のコスト——「別チームの物理的分離」——は LLM エージェントを複数独立実装することで低減できるか。[[agentic SRE]] における設計多様性の現代的形態は何か。 - 障害封じ込め領域(FCR)の境界設計はどう決定すべきか。現代のマイクロサービスアーキテクチャやコンテナオーケストレーションにおける FCR の等価物は何か([[マイクロサービスアーキテクチャ]]との接続)。 - DDIA が単一障害点(SPOF)と呼ぶ概念は、Heimerdinger+Weinstock の6アクション(検知・診断・封じ込め・マスキング・補償・修復)のどれとも直接対応しない——SPOF は「冗長性が存在しないためこれらのアクションのいずれも実行できない部分」を指す事後的な診断ラベルである。SPOF の有無を設計時に体系的に検出する手法(FCR 分析との関係を含む)は何か。 - クォーラムによる意思決定の集約は、1992 年の「障害診断(Diagnosis)」アクション——障害の原因・サブシステムを特定する——をどう変質させるか。単一の中央診断器でなく分散合意で診断を行う場合、診断の正確性・速度はどうトレードオフされるか([[分散コンセンサス]] も参照)。 - [[@2013__CACM__The Tail at Scale]] は tail-tolerant 技術を「フォールトトレランスと同様のアプローチ」と位置づけるが、6アクション(検知・診断・封じ込め・マスキング・補償・修復)のうち「診断(Diagnosis)」に相当する部分は明確でない——レイテンシ起因の保護観察(latency-induced probation)は遅いマシンを検知して除外するが、これは障害の「原因」を特定する診断というより症状ベースの対症療法に近い。レイテンシ領域における「診断」アクションの明確な定義は何か。 - PCSD の耐障害設計プロセス(§8.1.2)は「未許容の障害確率が低くなるまで反復する」という主観的判断を明示的に許容する(個人用PC・中小企業・宇宙飛行誘導系で異なる耐障害性の水準を選ぶ、という例が挙げられる)。この主観性は、本 concept の6アクションやカバレッジのマルコフモデルのような、より形式化された枠組みではどう扱われるか。「どこまで耐障害性を作り込むか」の意思決定を形式的に支援する手法は存在するか。 ## 関連 - 概念: [[ディペンダビリティ]] / [[ソフトウェア耐障害性]] / [[プロセスペア]] / [[チェックポイント]] / [[Heisenbug]] / [[障害予測]] / [[プロアクティブ障害管理]] / [[AIOps]] / [[agentic SRE]] / [[部分故障]] / [[分散コンセンサス]] / [[テールレイテンシ耐性技術]] / [[カオスエンジニアリング]] / [[信頼性工学]] / [[システム信頼性モデル]] - ソース: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] / [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]] / [[A Survey of Online Failure Prediction Methods]] / [[A Survey of AIOps Methods for Failure Management]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] / [[@2013__CACM__The Tail at Scale]] / [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] / [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] / [[@2009__MITOCW__Principles of Computer System Design - Chapter 8 Fault Tolerance - Reliable Systems from Unreliable Components]] - 参照 MOC: [[structures/SRE - MOC]] ## 出典 - [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]](全文: §2〜§5) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] "Reliability and Fault Tolerance", "Fault Tolerance", "Hardware and Software Faults" - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "The Majority Rules", "Fencing off zombies and delayed requests" - [[@2013__CACM__The Tail at Scale]] 本文 pp.74, 76, 80 - [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] — Casey Rosenthal, 「初めにカオスありき」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 14章（§14.6） - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.3.2, §14.4 - Jerome H. Saltzer and M. Frans Kaashoek, *Principles of Computer System Design: An Introduction*, Version 5.0, 2009, Chapter 8, §8.1.1, §8.1.2, §8.2.3, §8.3.1, §8.3.2. MIT OpenCourseWare, CC BY-NC-SA 3.0 US.