# OSINT for SRE: 学術論文とポストモーテムから探るシステム障害の共通パターン > [!info] Talk metadata > - **会議:** [[SRE NEXT 2026 参加録]]（2026年7月10日（金）16:10-16:40、TOC有明 Track A） > - **登壇者:** 小山智之（株式会社メルカリ DBREチーム。40TB超のMySQL／TiDB運用を担当。東京工科大学大学院 博士後期課程の社会人学生で、研究テーマは障害の根本原因分析と故障の箇所特定） > - **URL:** https://sre-next.dev/2026/schedule/#slot071 > - **スライド:** https://speakerdeck.com/tomoyk/sre-next-2026（全38ページ） > - **出典:** [[OSINT for SRE - transcript|一次ソース（公式アブストラクト、登壇者略歴、逐語文字起こし）]] > - **出典（スライド原本）:** [[OSINT for SRE - slides.pdf|スライドPDF原本（38ページ）]] > [!abstract] 概要（SRE NEXT 2026 公式ページ） > 私はソフトウェアエンジニア(DBRE)として実務でのシステム運用に携わりながら、博士後期課程でシステム障害原因の分析を研究している。 > 研究活動で学術論文やポストモーテムの記事を読むうちに、システム障害の事例や分析結果が運用で十分に活用されていないことに気づいた。 > こうしたシステム障害の知見を活用しきれていない要因の一つは、システム障害の事例を包括的に分析した日本語資料の不足にあると考える。 > 本セッションでは、インターネットに公開されている20以上の英語論文やポストモーテムを用いて障害原因の傾向を分析する（OSINT for SRE）。 > まずMicrosoftやeBayのエンジニアによるものを含む5件の論文を分析し、そこから主要な4種類の共通した障害原因を紹介する。 > さらに、それら4種類の主要な障害原因をポストモーテムや論文、具体的な事例とともに詳細に分析する。 > 4種類の主要な障害原因の1つに連鎖障害がある。 > マイクロサービスアーキテクチャで設計されたシステムでの連鎖障害とは、あるマイクロサービスで起きた障害が別のマイクロサービスへ連鎖して発生する障害である。 > システムの運用で連鎖障害を知っていても、いくつのマイクロサービスに連鎖するケースが最も多いか、どんな種類のシステムから連鎖障害が発生しやすいかは把握しきれていない状況にあると考えている。 > 本セッションでは運用経験にもとづく感覚的な認識ではなく、データを使った定量的な分析を行う。 > これによりシステム障害の原因の傾向を具体的なデータをもとに定量的に把握でき、自社でのシステム障害対策における対象や優先度の決定を正確に行えるようになる。 ## 障害分析の学術知見を運用に活かすという動機 大学院での研究活動の中心は論文の執筆であり、そのために関連分野の文献調査を行う。 文献調査では、その分野で人類がどこまで到達し何が未到達かを明確にする必要があり、そのために50件から100件以上の論文に目を通す。 この過程でMicrosoft[^chen2020]やUber Technologies[^lee2024]といったビッグテックによる大規模分散システムの運用に関する論文に気づいた。 こうした論文には運用改善に使えそうな具体的なデータが含まれており、これを実システムの運用にもっと活用できないかという問いが本セッションの動機になっている（例として、登壇者自身がKubernetesリソースイベントによるミドルウェア障害の根本原因分析を扱った論文[^koyama2026]も学術論文の一例として紹介された）。 ## OSINT for SRE：公開論文とポストモーテムの体系的分析 **OSINT**（Open Source Intelligence、公開情報インテリジェンス）は、本来セキュリティや軍事の分野でよく使われる語である。 小山はこの考え方を転用し、公開されている論文やポストモーテムを解析して障害原因のパターンや共通点を見つけ出す取り組みを「OSINT for SRE」と呼んでいる。 収集経路は3つある。 - Google Alertで公開されたポストモーテムを収集する。 - Google Scholarで論文を検索する。 - ChatGPTやClaudeのDeep Research機能に、IEEE、ACM、Springer、ScienceDirectを含むScopus登録誌から出版10年以内かつプレプリントを除いた論文を探させるプロンプトを渡す。 こうして集めた論文やポストモーテムを人間が体系的に分析し、傾向やパターンを明らかにする。 障害は「システムが正常な状態から逸脱している状態」と定義し、まずGoogle Scholarで「root cause analysis」を検索語に論文を探した。 この分析のゴールは、運用経験にもとづく感覚的な認識ではなく、データにもとづいて自社のシステム障害対策の対象や優先度を正確に決定できるようにすることである。 ## 上位5論文が示す4つの共通した障害原因 障害原因の傾向を知るため、Deep Researchで見つけた論文から5本を選びサマリーし、各論文が挙げる障害原因の上位5件を抽出して比較した。 | 順位 | 広発銀行（中国）[^zhao2021] | Microsoft[^ghosh2022] | サーベイ[^lixiaoyun2022] | DeepFlow[^shen2023] | eBay[^xie2024] | |---|---|---|---|---|---| | 1位 | コードの欠陥 | コードのバグ | コンフィグミス | インフラ（ネットワーク） | 連鎖障害（サードパーティ） | | 2位 | コンフィグエラー | 依存関係 | その他 | インフラ（コンピューティング） | 連鎖障害（内部のサービス） | | 3位 | 互換性のないソフトウェアバージョン | インフラ | インフラ（ハードウェア） | コードのバグ | ソフトウェアの変更 | | 4位 | リソース競合 | デプロイメントエラー | ソフトウェアの変更 | その他 | インフラ（データベース） | | 5位 | その他 | コンフィグバグ | リソース枯渇 | - | - | DeepFlowはクラウドネイティブコンピューティングファンデーション（CNCF）傘下のeBPFベースオブザーバビリティプロジェクトであり、この論文はその開発チームによる。 なお1位の論文について、文字起こしは「中国の交通銀行」としているが、スライドの表記は「広発銀行（中国）」であり、本ノートはスライドに従って訂正した。 5論文の障害原因を似た内容ごとに色分けして整理した結果、共通して現れる原因は**コードのバグ**、**コンフィグミス**、**連鎖障害**、**インフラ**の4種類であり、以降の節ではこの4種類を1つずつ取り上げる。 文字起こしでは色分けを「コード、コンフィグ、ネットワーク、インフラ」の4色と説明しているが、表中の該当セルの内容は依存関係や連鎖障害であって「ネットワーク障害」という分類は明示されていない。 まとめのスライドでも4分類は一貫して「インフラ、連鎖障害、バグ、コンフィグミス」とされているため、本ノートはこちらの分類に従う。 ## HDD故障が支配するインフラ障害とクラウドユーザー側データの欠如 インフラはミドルウェア、OS、ハードウェア、データセンターにまたがる広い領域であるため、要点のみをまとめる。 オンプレミスからパブリッククラウドへの移行にともない、データセンターのネットワーク機器や物理サーバーの故障に対処する機会は減っている。 調査の結果、インフラ障害の分析はクラウド事業者側やオンプレミス環境の視点によるものが大半で、クラウドユーザー側の視点で書かれた資料は少ないことがわかった。 ### ハードウェア故障はHDDが圧倒的に多いが、サービス障害の主因ではない 壊れやすい物理マシンのハードウェアを分析した論文2本を比較すると、いずれもHDDの故障が最多である。 | 順位 | Baidu（過去4年間の作業チケット）[^wang2017] | Microsoft（データセンター）[^sankar2013] | |---|---|---| | 1位 | HDD 81.84% | HDD 71.1% | | 2位 | その他 10.20% | その他 7.7% | | 3位 | メモリ 3.06% | 置き換えたマシン 5.6% | | 4位 | 電源 1.74% | メモリ 5.2% | | 5位 | RAIDカード 1.23% | 電源 4.0% | HDDのプラッター（円盤）は物理的に回転しているため摩耗による故障が起こりやすく、これがバスタブ曲線としてよく知られる故障パターンにつながっているとみられる。 なおBaiduのデータではSSDの故障率は0.31%にとどまり、HDDとの差は大きい。 一方で、ハードウェアの故障がサービスレベルに影響する障害の主な原因ではないことも知られている[^barroso2019]。 一般的なソフトウェアのバグやオペレーターのミスへの耐性を高めるよりも、既知のハードウェア障害を許容できるようにサービスを設計するほうが容易だとされる。 ディスク故障についても、39,000台超のストレージシステムを分析したNetAppのデータ[^jiang2008]や、Googleの分散ストレージシステムの可用性分析[^ford2010]から、ストレージシステム障害の主要な原因ではないことが確認されている。 ### データセンターネットワーク障害でもハードウェアが上位を占める データセンターのネットワーク障害の原因をMeta[^meza2018]とAlibaba[^yang2025]がそれぞれ分析している。 | 順位 | Meta[^meza2018] | Alibaba[^yang2025] | |---|---|---| | 1位 | メンテナンス 17% | 機器のハードウェア 42.6% | | 2位 | ハードウェア 13% | リンク 18.5% | | 3位 | 設定ミス 13% | ネットワークの変更 16.7% | | 4位 | バグ 12% | 機器のソフトウェア 9.3% | | 5位 | アクシデント 11% | インフラ 9.3% | | 6位 | キャパシティ 5% | セキュリティ 1.9% | | 7位 | - | 設定 1.9% | | 8位 | - | 経路 1.9% | 両社に共通するのは、ハードウェアの故障がいずれも上位2位以内に入っている点と、（ソフトウェアの）バグがともに4位である点である。 一方で設定ミスの割合はMetaが13%（3位）であるのに対しAlibabaは1.9%（7位）にとどまり、両社で大きく異なる。 両社は原因の分類基準が統一されていないため単純な比較には注意が必要だが、ハードウェアの割合が特に多いことは共通の傾向として読み取れる。 ### まとめと未解決の課題 HDDのハードウェア故障はMicrosoftとBaiduのいずれも70から80%台で最も多いが、ディスク故障自体はシステム障害全体の中では主因ではない。 データセンターネットワークでは機器のハードウェア故障がAlibabaとMetaのいずれも上位2位以内に入る代表的な原因である。 クラウドベンダー側の障害事例を分析したデータは豊富にある一方、クラウドユーザー側の構成に起因する障害を分析したデータは不足している。 クラウド時代のインフラは設定ファイルの記述とAPI呼び出しが中心になるため、今後はコンフィグミスやバグの割合が相対的に増えているのではないかというのが登壇者自身の考察である。 ## 下位層からアプリケーションへ伝搬する連鎖障害 **連鎖障害**（カスケード障害）とは、あるシステムで発生した障害の影響が別のシステムに波及する現象を指し、SRE本でも「カスケード障害」として定義されている。 マシン内部で1つのプロセスが共有資源であるメモリを過剰に消費し他のプロセスに影響するケースや、あるマイクロサービスの障害が別のマイクロサービスへ伝搬するケースがこれにあたる。 2025年10月に発生した米国東部（バージニア北部、US-EAST-1）リージョンでのAmazon DynamoDBのサービス障害では、DynamoDBのDNS管理システムの競合状態が発端となり、EC2やNLBなど他のサービスへ障害が連鎖した[^aws2025]。 Microsoftの分析では、あるサービスの障害の約67%が別サービスに連鎖しており、これは主要な5サービスで1年間に発生した数百件の障害を調査した結果である[^liliqun2021]。 連鎖障害が起きやすい典型的な構造として、登壇者は次の2つを挙げている。 - 複数のシステムが1つのDBなどを共有している場合。ノイジーネイバーが発生すると他のシステムも巻き込まれる。信頼性工学ではこれを**共通原因故障**（CCF、Common Cause Failure）と呼ぶ。 - 元は1つだったシステムをモノリスからマイクロサービスへ分割した場合。分割によってシステム間に疎な依存関係が生まれ、一方の障害が依存先を巻き込む。 ### 連鎖する深さはほとんどが3以下 障害がどこまで連鎖するかという**ブラストラディウス**（爆発半径）を、354件の公開ポストモーテムを解析したサーベイ論文[^lixiaoyun2022]と、Uber Technologiesのマイクロサービス間RPCエラーを解析した論文[^lee2024]の2つのデータで比較する。 深さ1は障害元のシステムのみで連鎖していない状態を指し、深さ2で初めて別のシステムへ連鎖したことになる。 | 深さ | サーベイ（354件のポストモーテム）[^lixiaoyun2022] | Uber Technologies[^lee2024] | |---|---|---| | 1 | 11.9% | 33.49% | | 2 | 52.6% | 37.48% | | 3 | 27.1% | 11.24% | | 4 | 8.2% | 4.41% | | 5 | 0.3% | 8.43% | | 6以上 | 0% | 4.94% | 両データセットとも深さ2が最も多く、サーベイ論文では全体の88.8%が他の箇所に連鎖している。 Uberのデータでは80%以上のエラーが深さ3以下に収まっており、最も深い例でも深さ26にとどまる、まれなケースである。 以上から、連鎖障害の大半は連鎖数が3以下、つまり元のシステムを含めて高々3つのシステムに収まることがわかる。 ### 下位のインフラ層から上位のアプリケーション層への伝搬が典型 公開ポストモーテムから連鎖障害の伝搬パターンを二部グラフで可視化した分析[^lixiaoyun2022]では、ストレージ、ネットワーク、ミドルウェア、バックエンドといった下位層からアプリケーション層へ伝搬する件数が特に多い。 伝搬件数の上位は、ストレージからアプリケーション、ネットワークからアプリケーション、ミドルウェアからアプリケーション、バックエンドからアプリケーション、そしてアプリケーションからアプリケーションの順である。 ### 隔離と最小化による緩和 連鎖障害への対策は、障害の**隔離**と障害の**最小化**の2つに整理できる。 隔離の手段としては、過負荷時にリクエストを拒否したり制限したりするサーキットブレーカーやスロットリング（SDKのResilience4jやPolly、サービスメッシュのIstioやLinkerdなど）がある。 もう1つの隔離手段が**セルベースドアーキテクチャ**である。 これはリージョンやアベイラビリティゾーンごとにシステムを論理的な単位である「セル」に分割し、セルごとにロードバランサーやアプリケーション、DBを配置する方式で、あるセルで障害が起きても他のセルに影響が及ばないよう閉じ込めることができる（AWSが提唱し、2024年のAWS re:InventでSlackも自社の採用事例を発表している）。 このセルベースドアーキテクチャは**バルクヘッドパターン**とも呼ばれ、船の水密隔壁が浸水を一区画にとどめ沈没を防ぐ発想に由来する（日本国内でも2022年の知床遊覧船事故を機に、遊漁船等の水密区画に関する安全基準が見直された）。 最小化の手段としては、マルチリージョンやマルチゾーン構成で一部のリージョンやゾーンにのみリリースするリリースの分割と、トラフィックシフトやフィーチャーフラグを使って段階的にリリース範囲を広げるカナリアリリースがある。 ## コンポーネント故障とデータ形式の衝突が生むソースコードのバグ 「バグ」という語は機械式コンピュータに実際の虫（蛾）が挟まった逸話に由来し、これを取り除く作業が「デバッグ」と呼ばれるようになった[^hopper1947]。 2025年8月にPagerDutyで発生した障害は、新機能のバグにより単一のKafkaプロデューサーを使い回さずAPIリクエストごとにKafkaプロデューサーを作成してしまい、Kafkaブローカー側でJVMのヒープメモリ使用量が増加し最終的に枯渇したというものである[^pagerduty2025]。 Microsoft Azureの本番環境で6か月間に発生した112件のインシデントをソフトウェアバグの種類で分類した分析[^liu2019]では、コンポーネントの故障が31%、データ形式のバグが21%、タイミングのバグが13%、定数のバグが7%、その他が28%を占める。 以下ではこのうち上位2つを詳しく見る。 ### コンポーネントの故障（31%）：検知や対処が不正確または欠落すること コンポーネントの故障とは、ソフトウェアコンポーネントでの障害の検知や対処が不正確、または欠落していることを指し、次の3種類に分けられる[^liu2019]。 - **コンポーネントでのエラー応答による故障**（43%）：呼び出したコンポーネントが処理不能なエラーを返し（例：503 Service Unavailable）、特定のタスクやジョブが失敗する。 - **応答不能なコンポーネントによる故障**（29%）：ハングしたジョブや無効化されたノードが対処されず、ロードバランサーの切り離しにも失敗し、呼び出し元がエラーを受け取れないままタイムアウトする。 - **サイレント故障**（17%）：永続データやキャッシュされた永続データがエラーコードなしに破損したり不整合を起こしたりし、ユーザーに誤った結果が返る。 このうち最多である「コンポーネントでのエラー応答による故障」は、あるコンポーネントの障害が呼び出し元に伝わって新たな障害を起こすという構図そのものであり、前節で扱った連鎖障害の一形態でもある。 故障を検知できない理由も2種類に整理されている[^liu2019]。 - コンポーネントGがコンポーネントFの故障可能性に対する検知ロジックをそもそも持っていない。 - 検知ロジックは存在するが、故障そのものによってエラーのシグナルやログが失われる、あるいはネットワークの輻輳などで伝送経路上でシグナルやログが失われる。 対策としては、各ソフトウェアコンポーネントが故障検知のロジックを持つこと、そしてログやシグナルが残らないまま故障するケースを設計段階で想定しておくことが挙げられている。 ### データ形式のバグ（21%）：コンポーネント間でのデータ形式の衝突 データ形式のバグは、異なるソフトウェアコンポーネント間でデータ形式が衝突することを指す（Cross System Interaction Failureとも呼ばれる）。 大半のケースはソフトウェア更新時にデータ形式への考慮が不足していたことに起因し、内訳は次の2種類に分かれる[^liu2019]。 - **ローカルとグローバルファイルの不整合**（40%）：ソフトウェアコンポーネント間でDBテーブルやファイル形式の前提が食い違う。たとえば`ALTER TABLE item DROP COLUMN color;`でカラムを削除した後も、別コンポーネントが`SELECT color FROM item;`のように削除済みカラムを参照し続けエラーになる。 - **メッセージインターフェースの不整合**（60%）：RESTful APIなど外部インターフェースの変更により、他のプロセスやノードが想定外の応答を受け取る。 データ形式が変わっても一貫性を保てる仕組み（マスタデータ）と、変更を事前に伝える仕組みの両方が必要だというのが登壇者の結論である。 ## パラメータとコンソールコマンドのミスが多数を占めるコンフィグミス コンフィグミスはGoogleにおいてサービスレベルに影響する障害原因の2位であり[^barroso2019]、あるストレージ企業の技術サポートへの問い合わせのうち27%がコンフィグ関連である[^yin2011]。 2021年8月25日にSkyscannerで発生した障害は、ArgoCDでクラスター構成を変更した際に必要な括弧`{{ }}`が抜けていたことに起因する。 ``` - cell: {{ default $cluster.name $cluster.unique_name }} + cell: $cluster.name ``` この結果、新しい構成に有効なnamespaceが存在しなくなり、世界中のすべてのAZとリージョンのnamespaceにある478のサービスが一括削除される事態に至った[^skyscanner2021]。 文字起こしでは「世界中のアジュールのリージョン」としているが、スライドの表記は「世界中のAZとリージョン」であり、削除されたサービス数478件も文字起こしには現れない。 ### コンフィグミスの内訳は7から8割がパラメータ関連 実際に発生した546件のコンフィグミス障害を種類別に集計した分析[^yin2011]では、NetAppの本番システム（COMP-A）を含む5システムいずれでもパラメータ関連のミスが最多である。 | システム | パラメータ | 互換性 | コンポーネント | 合計 | |---|---|---|---|---| | COMP-A（NetApp本番システム） | 246 | 31 | 32 | 309 | | CentOS | 42 | 11 | 7 | 60 | | MySQL | 47 | 0 | 8 | 55 | | Apache | 50 | 5 | 5 | 60 | | OpenLDAP | 49 | 7 | 6 | 62 | 分類の内訳は、設定パラメータやコンソールコマンドのミスである「パラメータ」、ソフトウェアの互換性に関連する「互換性」、その他のソフトウェアに残る「コンポーネント」（モジュール不足など）の3種類であり、約70から85%の原因はパラメータにある[^yin2011]。 具体例として、Apache HTTP ServerとPHPの組み合わせで`extensions=recode.so`より先に`extensions=mysql.so`を読み込んでしまいセグメンテーションフォールトが発生するケースが紹介された（`mysql.so`は`recode.so`に依存するため、`recode.so`を先に読み込む必要がある）。 なお文字起こしはこのモジュール名を「mod_record.so」としているが、スライドの表記は「recode.so」であり、本ノートはスライドに従って訂正した。 もう1つの例として、MySQLで`log_output="Table"`と`log=query.log`が同時に設定され、ログの出力先をファイルにしたいのかDBテーブルにしたいのか設定だけからは意図が読み取れないケースも紹介された[^yin2011]。 ### コンフィグミスを誘発するソフトウェア設計 コンフィグミスを「利用者の誤りだから仕方ない」と片付けるのではなく、主要なミドルウェアにコンフィグミスを注入して挙動を収集した研究[^xu2013]は、コンフィグミスを誘発するソフトウェア設計そのものに問題があることを示した。 - **パラメータの単位の不整合**：同じソフトウェアの中でも、あるパラメータは秒、別のパラメータはミリ秒というように時間の単位が混在しており、利用者が単位を取り違えるバグを誘発する。 - **安全でない関数の使用**：`atoi`や`sscanf`、`sprintf`のような関数は、想定外の入力を静かに誤変換する。たとえば`atoi("1O0")`（数字のゼロの代わりにアルファベットのOが混入した文字列）はエラーにならず1を返してしまう。 ### 対策 ソフトウェア開発側では、パラメータ名に単位を含める（例：`timeout.sec = 10`）、単位のサフィックスを必須にする（例：`10MiB`）、JPCERTのコーディングスタンダードに沿って安全でない関数を避ける、といった対策が挙げられる。 利用側では、Linter（kube-linterなど）やdry-runによる構文ミスの検出が有効だが、利用者の意図と実際のソフトウェアの挙動を比較する値の不整合の検出は確立された方法がなく、ソースコード解析やLLMとLSTMを組み合わせた手法が研究段階にある。 コンフィグミスを起こすのは結局のところ人間であるため、なぜ見間違えるのかという人間の認知特性の分析も今後必要だというのが登壇者の見解である。 ## 障害データの公開が今後の課題 本セッションの動機は、論文の内容を実システムの運用に役立てられないかという問いだった。 企業ごとに障害原因の割合は異なるものの、インフラ（HDDやネットワーク機器のハードウェア故障）、連鎖障害（連鎖数はほとんど3以下でストレージやネットワークからアプリケーションへ伝搬）、バグ（コンポーネントの故障とデータ形式のバグを合わせて52%）、コンフィグミス（パラメータやコンソールコマンドのミスが70から85%）という主要な共通原因が確認できた。 残された課題として、登壇者はクラウド時代特有の障害データの不足を挙げている。 Terraformのコンフィグミスの内訳を分析したデータは見当たらず、引用した論文の中には2017年前後の障害データを使っているものもあるなど、公開されている障害データそのものが少ない。 障害データ、たとえばポストモーテムを各社が公開することが、こうした分析や業界全体のインテリジェンスの向上に役立つとして、登壇者は聴衆に公開を呼びかけて講演を締めくくった。 --- [^chen2020]: Chen, Junjie, et al. "How incidental are the incidents? characterizing and prioritizing incidents for large-scale online service systems." Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering. 2020. [^lee2024]: Lee, I-Ting Angelina, et al. "The tale of errors in microservices." Proceedings of the ACM on Measurement and Analysis of Computing Systems 8.3 (2024): 1-36. [^koyama2026]: Koyama, Tomoyuki, Takayuki Kushida, and Soichiro Ikuno. "Root Cause Analysis for Middleware Issues by Kubernetes Resource Events." 2026 18th International Conference on Knowledge and Smart Technology (KST). IEEE, 2026. [^zhao2021]: Zhao, Nengwen, et al. "Identifying bad software changes via multimodal anomaly detection for online service systems." Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 2021. [^ghosh2022]: Ghosh, Supriyo, et al. "How to fight production incidents? an empirical study on a large-scale cloud service." Proceedings of the 13th Symposium on Cloud Computing. 2022. [^lixiaoyun2022]: Li, Xiaoyun, et al. "Going through the life cycle of faults in clouds: Guidelines on fault handling." 2022 IEEE 33rd International Symposium on Software Reliability Engineering (ISSRE). 2022. [^shen2023]: Shen, Junxian, et al. "Network-centric distributed tracing with deepflow: Troubleshooting your microservices in zero code." Proceedings of the ACM SIGCOMM 2023 Conference. 2023. [^xie2024]: Xie, Zhe, et al. "Microservice root cause analysis with limited observability through intervention recognition in the latent space." Proceedings of the 30th ACM SIGKDD conference on knowledge discovery and data mining. 2024. [^sankar2013]: Sankar, Sriram, et al. "Datacenter scale evaluation of the impact of temperature on hard disk drive failures." ACM Transactions on Storage (TOS) 9.2 (2013): 1-24. [^wang2017]: Wang, Guosai, Lifei Zhang, and Wei Xu. "What can we learn from four years of data center hardware failures?" 2017 47th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2017. [^barroso2019]: Barroso, L. A., et al. "The datacenter as a computer: Designing warehouse-scale machines." Springer Nature. 2019. [^jiang2008]: Jiang, Weihang, et al. "Are disks the dominant contributor for storage failures? A comprehensive study of storage subsystem failure characteristics." ACM Transactions on Storage (TOS) 4.3 (2008): 1-25. [^ford2010]: Ford, Daniel, et al. "Availability in globally distributed storage systems." 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI 10). 2010. [^meza2018]: Meza, Justin, et al. "A large scale study of data center network reliability." Proceedings of the Internet Measurement Conference 2018. 2018. [^yang2025]: Yang, Bo, et al. "SkyNet: Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures." Proceedings of the ACM SIGCOMM 2025 Conference. 2025. [^liliqun2021]: Li, Liqun, et al. "Fighting the fog of war: Automated incident detection for cloud systems." 2021 USENIX Annual Technical Conference (USENIX ATC 21). 2021. [^aws2025]: 米国東部（バージニア北部、US-EAST-1）リージョンにおける Amazon DynamoDB サービス中断の概要. https://aws.amazon.com/jp/message/101925/ [^liu2019]: Liu, Haopeng, et al. "What bugs cause production cloud incidents?" Proceedings of the Workshop on Hot Topics in Operating Systems. 2019. [^pagerduty2025]: "In Incident Response, It's the People Who Make all the Difference." PagerDuty Engineering Blog. https://www.pagerduty.com/eng/in-incident-response-its-the-people-who-make-all-the-difference/ [^hopper1947]: Hopper, Grace. "Log Book With Computer Bug." National Museum of American History. 1947. [^yin2011]: Yin, Zuoning, et al. "An empirical study on configuration errors in commercial and open source systems." Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. 2011. [^skyscanner2021]: "How a couple of characters brought down our site." Skyscanner Engineering (Medium). https://medium.com/@SkyscannerEng/how-a-couple-of-characters-brought-down-our-site-356ccaf1fbc3 [^xu2013]: Xu, Tianyin, et al. "Do not blame users for misconfigurations." Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 2013.