# グレイ障害 クラウドや分散システムにおいて、コンポーネントが**完全には停止しないが徐々に性能が劣化する**故障様式の総称。[[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]](Huang+、HotOS 2017、[[Lidong Zhou]] 共著)が正式に定義し、Arpaci-Dusseau+(2001)の「fail-stutter」、Gunawi+(TOS 2018)の「fail-slow at scale」、Do+(SoCC 2013)の「limpware / limplock」、Lou+(NSDI 2020)の「partial failure」など、類似概念が多分野で並立する。**特徴は observability の非対称性**——システム内部の監視が「OK」を返す一方で、利用側のアプリは明確に劣化を観測する。 ## 公式定義(Huang+ 2017) Huang+ 2017 は Observer/App モデルを用いて以下のように定義する: - **System**: サービスを提供するエンティティ。Observer(ヘルス情報収集)と Reactor(復旧アクション)を内包する - **App**: System を利用するエンティティ。端点間メトリクス(クエリレイテンシ・リモート I/O 状態等)から独自のヘルス観測を行う - **グレイ障害**: 少なくとも 1 つの App が System を不健全と観測しているが、Observer は System を健全と観測している状態 | | $A_i^{\text{good}}$ | $A_i^{\text{bad}}$ | |---|---|---| | $S^{\text{good}}$ | ➊ 正常 | ➋ **グレイ障害** | | $S^{\text{bad}}$ | ➌ 良い方向の差分 | ➍ fail-stop 障害 | ケース ➋ が核心: ユーザーが苦しんでいるが Reactor が呼ばれず回復しない。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3) **時間的進展**: 潜在障害(➊)→グレイ障害(➋)→完全障害(➍)。断続的誤動作ではこの遷移を繰り返す。メモリリークが典型例。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3.3) **グレイ障害の具体例** (Azure 本番、Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §2): - 深刻な性能劣化・ランダムパケットロス・不安定な I/O・メモリスラッシング・容量プレッシャー・非致命的な例外 - Clos ネットワークのコアスイッチがランダムパケットロス → ルーティングプロトコルが再ルーティングしない → 高冗長性が逆に可用性を下げる逆説 - VM が内部でネットワーク接続障害を経験しているが、ハートビートのみ監視する外部検知器には見えない - 容量制約を報告できないデータサーバへの書き込み継続 → クラッシュ→リブートのループ → 連鎖障害 ## AI 時代のグレイ障害 [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] は、AI クラウドで顕在化する 3 つの新しい増悪要因を整理した: 1. **ハードウェア冗長が劣化を覆い隠す**: GPU CUDA コアや HBM 行リマッピング(Row Remap)、InfiniBand の過剰プロビジョン uplink など、信頼性のための冗長機構が「半壊」を許容するため、平均値ベースのモニタリングでは検出されない。Azure A100 では HBM の correctable error が 10 件を超えるとエンドツーエンド回帰確率が 5.6%→83.3% に跳ね上がる(Table 1)。 2. **長時間・同期ワークロードが劣化を増幅する**: AI 学習は週〜月単位で同期的に動くため、単一ノードの劣化が gang-scheduled 全体を停止させる。Azure A100 クラスタの MTBI は 17.5 時間、38.1% のインシデントが復旧に 1 日超を要する(Figure 1-2)。 3. **部分修復(partial repair)が信頼性を漸減させる**: ToR の冗長 uplink が複数本切れたとき、運用は「動く最小本数だけ復旧」して問題を閉じることが多い。これにより同じノードの 1 回目→20 回目のインシデント間隔は 719.4→151.7 時間まで縮む(Figure 4)。 ## 横断的知見 - **グレイ障害の根本は「Observer が見ているものとアプリが経験しているものの乖離」**: Huang+ 2017 は差分可観測性(differential observability)としてこれを定式化した。ハートビートが「正常」を返しても VM が内部で接続不能なケース(§2.2)・平均パケットロス率が閾値未満でも特定フローが影響を受けるケース(§2.1)・容量制約を報告できないデータサーバへの書き込み継続(§2.3)はいずれも同一の構造的パターンを示す。GrayScope([[@2024__FSE__Illuminating the Gray Zone - Non-Intrusive Gray Failure Localization in Server Operating Systems]])の非侵入的メトリクス箇所特定・Harp の物理パス単位監視・SuperBench のプロアクティブ検証はすべて「Observer の観測ギャップを埋める」という同一の方向性を取る。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3.2, [[@2024__FSE__Illuminating the Gray Zone - Non-Intrusive Gray Failure Localization in Server Operating Systems]], [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) - **高冗長性はグレイ障害に対して両刃の剣**: Huang+ 2017 はコアスイッチ数が増えるほど少なくとも 1 台がグレイ障害を起こす確率も上がるという逆説を示した($1-(n-1)^m/n^m$ → 1)。SuperBench も ToR の冗長アップリンクが複数本劣化したとき「動く最小本数だけ復旧」することで同一ノードのインシデント間隔が短縮する「部分修復の罠」を報告している。冗長化設計が fail-stop 障害を想定している限り、グレイ障害では効果が薄いか逆効果になりうる。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §2.1, [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §2.2) - **集約パケットロス率ではグレイ障害を検知できない**: Pingmesh 系の監視はネットワーク全体の平均的なパケットロス率を見るため、特定フローへの選択的ドロップ(リーフスイッチのシステムソフトウェアバグによる特定フローへのドロップ)や低比率のリンク輻輳では閾値未達で通知されない。Harp([[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] §6.1・Figure 11(c)(d))は UDP ソースポートで特定した物理パス単位で健全性を追跡するため、集約率が低くても検知・迂回が可能。SuperBench([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]])が「モニタリングだけでは漸減する冗長が見えない」と指摘する構造的問題の別事例。(Source: [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] Figure 11, [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §1) - **AI ワークロードはグレイ障害の倍率器**: gang-scheduled で同期通信が必須なため、単一ノードの劣化が全ノードのアイドル時間に直結する([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §1)。同じ観察は [[耐障害LLM訓練]] や [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] でも繰り返されており、AI 専用の検証/回復メカニズムが必要だという結論を共有している。 - **モニタリングだけでは見えない**: 既存ワークロードのモニタは平均値ベースで冗長の漸減を捕えない。SuperBench は「standalone でハードウェアを stress する独立テスト」が必要だと主張する(§1-2.3)。**この点は [[障害注入]] と相補的**——障害注入は能動的に壊して観察するが、プロアクティブ検証は「正常そうに見えるノードを stress テストして潜在劣化を捕える」。 - **「沈黙ノード」はグレイ障害の AIOps 入力表現版である**: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems|GRLIA]] は、障害伝播中の中間サービスがフォールトトレランスやモニタ閾値によりインシデントを出さない現象を、障害影響グラフが分断される主要因として扱う。Huang+ 2017 のグレイ障害が「内部監視では健康に見えるが外部利用では劣化する」非対称性なら、GRLIA の沈黙ノードは「障害の影響を受けているが incident stream には現れない」非対称性である。どちらも平均的・閾値的なモニタリングでは伝播範囲が欠けるため、GRLIA は KPI トレンド類似度で補完し、SuperBench/Harp は能動検証やパス単位監視で補完する。(Source: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]], [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]], [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]]) - **失敗モードがワークロード依存**: 同じ Azure A100 クラスタで影響を受けた 4.7% のノードのうち、21.5% は 6 つの代表ベンチを走らせても 1 つでしか劣化を再現できない([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §2.3)。「あるベンチで OK だから健全」とは言えず、ベンチマーク群の被覆性こそが鍵。 - **冗長は IB / メモリ / 電源温度の三層で同時に効く**: 熱帯地域のデータセンタでは IB リンクの BER > 10⁻¹² の不良が高緯度比 35×。GPU の thermal throttling もラック位置依存で起きる(§2.1)。同じラックの中でも環境が均一ではないため、「均一なハードウェアに均一な冷却」という前提が信頼性を蝕む。 - **トラブルシューティングと検証は別物**: トラブルシュートは事後的・ワークロード固有・部分修復で打ち切られる。検証はインシデント前に冗長を**全部**修復することを目的とする([[プロアクティブ検証]])。 - **DDIA 2E(2026)はグレイ障害を実証研究のカテゴリでなく分散システムの形式的な「システムモデル」の一部として一般教科書に定着させた**: Huang+ 2017 の Observer/App 非対称性の定式化や SuperBench・GRLIA・Harp の検知・緩和研究は本番システムの実証分析から出発するが、DDIA 第9章は「クラッシュ停止・クラッシュ回復・**劣化性能(=limping node・gray failure・fail-slow)**・ビザンチン」という 4 つのノード故障モデルの 1 つとして gray failure を位置づけ、Gigabit NIC がドライババグで 1Kb/s に落ちる例・メモリ圧迫下の GC 時間占有・摩耗した SSD の不安定な性能・バックグラウンドスレッドのクラッシュ/デッドロックによる部分機能停止を具体例に挙げる。実証研究群が「本番でどう観測されるか」を扱うのに対し、教科書は「アルゴリズムの前提としてどう形式化するか」を扱っており、両者は経験的知見と理論的定式化という異なる層で補完する。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "System Model and Reality") - **Microsoft 2 年超の実証研究がグレイ障害を「アラームフラッド回避と微細障害検知のトレードオフ」として操作的に定義した**: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It|Chen+ ESEC/FSE 2020]] は Microsoft 6 コアサービスの実証研究から、グレイ障害の産業規模での現れを「アラームフラッドを避けるために設定した鈍感なアラーム閾値が重大問題を見逃す」という構造として記述する(§4.2、Lesson 4)。フォールトトレランス設計が 1 つの障害を複数レイヤのリソース障害に連鎖させ、モニタが閾値ベースの大量アラームを発生させる(アラームフラッド)。これを抑制するため閾値を鈍感にした結果、微妙な性能劣化(グレイ障害)が通知されなくなる。Huang+ 2017 の「Observer/App 非対称性」という理論的定義に対し、本論文は「フォールトトレランス設計 → アラームフラッド → 閾値鈍感化 → グレイ障害の見逃し」という操作的な産業メカニズムを補完する。また本論文は重要度アップグレード(ユーザから重要度が上げられたインシデント)をグレイ障害の近似指標として扱う——直接定量化できない本番環境での代替評価アプローチ。(Source: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It]] §4.2) - **グレイ障害の「原因側」を辿ると、ハードウェア劣化がソフトウェアの同期・タイムアウト機構を突き崩す構造に行き着く**: 本 concept のこれまでのソースは Observer とアプリの観測非対称性という**現象の記述**と、その検知・緩和(Panorama・SuperBench・Harp・GrayScope)を扱ってきた。[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] は逆に原因側から入り、ZooKeeper・HDFS・HBase・MapReduce・Cassandra の実障害 48 件を分析して「フェイルスローハードウェアが引き起こすバグは 100% が同期機構とタイムアウト機構の脆弱性に起因する」ことを示した。決定的なのは細粒度性である——フェイルスロー NIC が `serializeNode` だけを遅くし heartbeat を遅くしないため leader は健全と報告され続けるが、粗粒度のフェイルストップ NIC なら heartbeat も止まりリーダー選出が走ってクラスタは回復する。すなわち Huang+ 2017 の差分可観測性は、細粒度障害が内部チェッカの観測経路をすり抜けるという**因果的な機序**を持つ。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §1・§3.1, [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]]) - **本番監視・プロアクティブ検証・リリース前テストは、グレイ障害検知の時間軸上で三分される**: Panorama・IASO・OmegaGen・PERSEUS は本番監視で検知するが、検知時点で既に被害が出ており、IASO は 1.5 年以上の運用を経てフェイルスロー障害を捕捉している。SuperBench は本番だが事前(プロアクティブ検証)に位置し、[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] は「リリース前に障害注入で見つける」という第三の位置を主張する。同論文は前者を「本番監視は検知に長時間を要し、リリース前テストには向かない」と明示的に切り分けており、三者は競合ではなく時間軸上の補完関係にある。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §8, [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) - **PERSEUS は「本番監視系のグレイ障害検知」の具体例であり、Observer/App 非対称性を統計モデルで運用可能にした事例である**: [[PERSEUS]]([[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]])は Alibaba のストレージデバイス(HDD/SSD)を対象に、ノード内のレイテンシ対スループット分布へ多項式回帰を適用してドライブごとの適応的しきい値を導出し、リスクスコアで劣化ドライブを格付けする。これは Huang+ 2017 が定式化した「Observer には健全に見えるが実際には劣化している」という差分可観測性の問題を、固定閾値(Observer が事前に決めた基準)ではなくノード内ピアとの統計的相対比較で埋めようとする具体策である。同記事が報告する「閾値フィルタリングは緩めると誤検知、厳しめると見逃す」というジレンマは、Huang+ 2017 のアラームフラッド回避と微細障害検知のトレードオフ([[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It|Chen+ ESEC/FSE 2020]])と同一の構造を、ストレージデバイス単体という最小スケールで再現している。(Source: [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]], [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3, [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It]] §4.2) - **「比較の粒度」がグレイ障害検知の精度を左右するという知見は、ネットワーク層(Harp)とストレージデバイス層(PERSEUS)で独立に確認された**: Harp([[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]])は集約パケットロス率では検知できない障害を物理パス単位の監視で捉える。PERSEUS は同じ問題をピア比較の粒度で発見した——サービス単位・クラスタ単位ではドライブのレイテンシ対スループット分布が大きく乖離し閾値が定まらないが、**同一ノード内のドライブ群だけ**は分布が均質になる(Figure 3)。両者は対象レイヤーが違うにもかかわらず「集約・広域での比較は平均化によってグレイ障害を隠し、最小の同質集団(同一ノード・同一物理パス)まで粒度を絞ってはじめて検知できる」という同一原理を独立に発見している。(Source: [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]] Figure 3, [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] Figure 11) - **[[障害検出器]]の Phi-Accrual 方式は「連続的な疑わしさの尺度」という点でグレイ障害の劣化状態表現と親和的だが、両者の理論的な接続は蓄積が浅い**: [[@2021__OReillyJapan__詳説 データベース - Chapter 9 障害検出]]が紹介する Phi-Accrual Failure Detector[HAYASHIBARA04] は、ノードの障害を二者択一(alive/dead)ではなく連続した確率的尺度 φ として扱う。これは Huang+ 2017 のグレイ障害モデルが「$S^{good}$/$S^{bad}$」の二値でシステム状態を表すのとは異なる粒度であり、φ という連続量は概念的にはグレイ障害のような「劣化の度合い」を表現できる余地を持つ。ただし Petrov の章は Phi-Accrual を障害検出アルゴリズムとして紹介するにとどまり、グレイ障害・差分可観測性という語彙とは接続していない。両者を明示的に結びつける議論は本 concept・[[障害検出器]] のいずれにもまだ存在せず、今後の突き合わせの余地として残る。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 9 障害検出]] §9.2, [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3) - **『ウェブオペレーション』17章の「劣化障害」は、Huang+ 2017 の差分可観測性(ソフトウェア層の Observer/App 非対称性)より1桁上の物理インフラ層で、同じ「完全停止でなく徐々に劣化する障害」という構造を先取りする実務報告である**: [[Mike Christian]]([[Yahoo!]])は、データセンタの HVAC(空調設備)故障を実例に挙げる——1台の HVAC が故障し温度上昇を検知した火災報知器が誤作動、消火システムが残りの HVAC まですべて停止させ、数分でサーバ全体が危険な温度に達したが、迅速な検知とレプリケーションデータのダンプによって危機を回避したという。著者は「データセンタが機能停止する原因の多くは停電・UPS・発電機の故障であり、障害はゆっくりと近づいてくる」と述べ、これを「劣化障害」と呼ぶ。Huang+ 2017 の差分可観測性が「Observer(内部監視)には健全に見えるがApp(利用側)には劣化として現れる」というソフトウェア・ネットワーク層の観測ギャップを定式化するのに対し、17章の劣化障害はハードウェア・設備(空調・電源)というより下位の物理層で同型の「完全停止に至る前の緩慢な劣化」を扱う。両者に共通するのは「早期検知が対応の猶予時間を作る」という処方箋だが、17章(2011)はこれをソフトウェアの可観測性設計としてではなく、運用者の経験則(異常の兆候が出たら原因究明を待たずただちにデータをダンプする)として記述しており、Huang+ 2017(2017)の形式的な Observer/App モデルより6年早く、かつ異なる抽象度で同じ問題に触れている。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.5, [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3) - **グレイ障害の「Observer/App 観測非対称性」は、対象をデータの正しさに置き換えると SRE Book のデータ完全性論と同型になる**: [[データ完全性]]([[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]])が説く out-of-band データ検証(バリデータ)は、ストレージAPIが「書き込み・読み出しは成功した」と報告していても、実際にはデータが破損・欠落している可能性があるため、アプリケーション自身が定期的に検証(trust but verify)しない限り「100%のデータが健全」とは言えないという構図を持つ。これは Huang+ 2017 の Observer(内部監視)が健全と報告する一方で App(利用側)が劣化を経験するという差分可観測性と構造的に同型だが、観測対象が**性能・可用性の劣化**(グレイ障害)ではなく**データの正しさ**(データ完全性)である点で異なる。Gmailのデータ検証器が日次で稼働し、本番投入から24時間以内にバグを検知できるという安心感がエンジニアの開発速度を上げたという報告は、[[プロアクティブ検証]]がエンジニアリング速度を支えるという本ページの既存知見と同じ構図を、データ層で再現している。(Source: [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]], [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3) ## 未解決の問い - **差分可観測性のギャップを自動的に測定する指標はどう設計するか**: Huang+ 2017 は「多次元ヘルス監視」を提唱するが、何をどれだけ監視すれば Observer とアプリの観測ギャップを定量化できるかは未解決。Observer の監視カバレッジと App の観測カバレッジの「差分」を測るメトリクスが必要ではないか。 - **グレイ障害の検知とその検知行為自体が引き起こすグレイ障害をどう両立するか**: Huang+ 2017 §4.2 では「過度なプロービングが劣化システムに追加負荷をかけ逆効果になる」と指摘する。SuperBench のプロアクティブ検証も本番ワークロードへの影響を最小化することが課題。検証密度と干渉のトレードオフの最適設計は？ - **パス単位の直接監視と集約監視の最適組み合わせ**: Harp のパス単位インバンド監視は特定フロー障害を捉えるが、ネットワーク全体のトレンド把握には集約監視が適している。両者を組み合わせてグレイ障害検知を高精度化する設計指針は？ - ground truth が無い状況で、**全ノードが系統的に劣化している場合**(新型 SKU の初期投入や firmware 一斉退化)に CDF 類似度ベースの基準学習は機能するのか。Day-0 デプロイでの基準ブートストラップ手法は何が良いか。 - 「漸減する冗長」を可視化する **operator 向けメトリクス**(redundancy budget のような指標)は設計可能か。現状はインシデント間隔の事後集計しかない。 - インシデントを出さないが KPI だけ異常な「沈黙ノード」を、グレイ障害候補として継続監視すべきか。GRLIA は障害中の集約補助として使うが、同じ信号を平時に蓄積すれば、閾値未満の劣化サービスやモニタ設定不備を先回りで見つけられるか。 - LLM 推論ワークロードや MoE のようなトラフィックパターンに対しても、SuperBench 系の検証は同じ被覆を持てるか。長文出力時の KV cache 帯域や、稀少エキスパートの活性化に依存する劣化は別ベンチを要求するか。 - グレイ障害を**リリース前に**露出させる細粒度障害注入は、ネットワーク・ストレージ以外のハードウェア(GPU の thermal throttling・HBM の行リマッピング・IB リンクの BER 劣化)にも適用できるか。[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] の対象はフェイルスローなストレージとネットワークに限られており、SuperBench が扱う AI ハードウェアの劣化は「同期・タイムアウト保護された I/O 操作」という枝刈り基準に収まらない可能性がある。 - 「フォールトトレランス機構が正常に働くからこそグレイ障害が隠れる」という逆説は、冗長設計の指針にどう反映すべきか。heartbeat のような活性検査を、実際のデータ経路と同じ I/O 経路を通す設計(いわゆるエンドツーエンドの健全性検査)に変えれば細粒度障害を捕捉できるか、それとも検査自体が本番トラフィックに干渉するか。([[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) - グレイ障害と [[障害予測]](survival analysis)を組み合わせたとき、**Cox-Time の covariates にどのテレメトリを追加すべきか**(ECC カウンタ・thermal・SMART・NCCL retry など)。 - Phi-Accrual Failure Detector の連続的な疑わしさの尺度 φ は、グレイ障害検知の指標として転用できるか。[[障害検出器]] の文脈(単一プロセスの生死判定)からグレイ障害の文脈(Observer/App の観測非対称性)へこの尺度を持ち込むには、何を測定対象にすべきか。 ## 関連 - ソース(定義): [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] - ソース(検知・緩和): [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] / [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] / [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]] / [[@2024__FSE__Illuminating the Gray Zone - Non-Intrusive Gray Failure Localization in Server Operating Systems]] - ソース(教科書での形式化): [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] - ソース(原因側の実証とリリース前テスト): [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] - ソース(本番監視によるストレージデバイス単位検知): [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]] - ソース(障害検出アルゴリズムの理論的基盤): [[@2021__OReillyJapan__詳説 データベース - Chapter 9 障害検出]] - ソース(物理・設備層での劣化障害の実務報告): [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] - ソース(データの正しさの観測非対称性): [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]] - 概念: [[差分可観測性]] / [[プロアクティブ検証]] / [[フォールトトレランス]] / [[Fault Localization]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[障害予測]] / [[障害注入]] / [[システムモデルと安全性・活性]] / [[フェイルスローハードウェア]] / [[障害検出器]] / [[事業継続計画（BCP）]] / [[データ完全性]] - 著者: [[Peng Huang]] / [[Lidong Zhou]] / [[Chuanxiong Guo]] - 製品: [[SuperBench]] / [[Sieve]] / [[PERSEUS]] - MOC: `[[structures/AIOps.MOC]]`(該当があれば一方向参照)