SRE NEXT 2026 CFP

OSINT for SRE: 学術論文とポストモーテムから探るシステム障害の共通パターンの解析

発表の概要 / Abstract

私はソフトウェアエンジニア(DBRE)として実務におけるシステム運用に関わりながら、博士後期課程でシステム障害原因の分析を研究しています。研究活動で学術論文やポストモーテムの記事を読むうちに、システム障害の事例や分析結果が十分に運用で活用されていないことに気づきました。こうしたシステム障害の知見が活用しきれていない要因の一つは、システム障害の事例を包括的に分析した日本語の資料の不足にあると考えます。本セッションではインターネットに公開されている20以上の英語で書かれた論文やポストモーテムを使い障害原因の傾向の分析(OSINT for SRE)を行います。セッションでは、まずMicrosoftやeBayのエンジニアによるものを含む5件の論文を分析し、その中から主要な4種類の共通した障害原因を紹介します。さらに、それら4種類の主要な障害原因をポストモーテムや論文、具体的な事例とともに詳細に分析します。4種類の主要な障害原因の1つには連鎖障害があります。マイクロサービスアーキテクチャで設計されたシステムでの連鎖障害は、あるマイクロサービスで起きた障害が別のマイクロサービスへ連鎖して障害が発生することです。システムの運用で連鎖障害を知っていても、いくつのマイクロサービスに連鎖するケースが最も多いか、どんな種類のシステムから連鎖障害が発生しやすいかを把握しきれていない状況にあると考えています。本セッションでは運用経験にもとづく感覚的な認識ではなく、データを使った定量的な分析を行います。本セッションを通じてシステム障害の原因の傾向を具体的なデータをもとに定量的に把握できます。またデータを把握することにより、自社でのシステム障害の対策において対象や優先度の決定を正確に行えます。

聞いた人が得られるもの / Audience Takeaways

学術論文やポストモーテムを読む機会がない参加者でも、このセッションを通じてシステム障害の原因のうち典型的なパターンがコードのバグ、連鎖障害、インフラ、コンフィグミスであることが把握できます。また、それぞれで何が主要な原因になっているかを具体的な事例をもとに理解できます。参加者が自社でのシステム障害の再発防止や未然防止を考える際に、優先して対応すべき障害を明確に設定できます。

発表の詳細 / Session Details

はじめに（3分）

参加者にとって博士課程は身近ではないため、はじめに博士課程での研究活動での調査について簡単に述べます。こうした文献調査の過程では50~100件を超える論文に目を通しており、そうした論文のデータを現場のエンジニアが把握していない状況にあることを説明します。論文の探し方や読み方、専門用語や英語、データの分析をはじめとしたスキルが必要であり、日常的に研究活動に取り組む経験がないとそれらを読み解くには苦労することを述べます。こうしたデータには障害の解析や再発防止に役立つものの、日本国内には包括的にまとめた資料が存在せず、現場での運用に役立てられていない状況を説明します。

企業でのシステム障害の原因の内訳（2分）

論文をもとに独自に整理した中国広発銀行、Microsoft、サーベイ、DeepFlow、eBayでの障害の分類のうち上位5件をまとめた表を提示し、どのような障害が多いのかをまず参加者に提示します。その上で色分けした結果から主に4種類が特に主要なパターン(コードのバグ、連鎖障害、インフラ、コンフィグミス)であることを説明します。以降では4種類について詳細に紹介していくことを述べます。

コードのバグ（5分）

コードのバグの事例として2025年8月に発生したPagerDutyでのKafkaブローカでJVMのヒープメモリの使用量が増加した障害をあげます。また、Microsoft Azureの本番環境で6ヶ月間に発生した112件のインシデントをコードのバグに関して分類した論文のデータを示します。コンポーネントでの障害の検知や対処が不正確または欠落していた障害が最多の31%であり、次いでシステム間でのデータ形式の不一致が21%であることを述べます。コードのバグを開発時に防ぐための有効な代表的な方法(主にソフトウェアテストやツール)を紹介します。

連鎖障害（5分）

連鎖障害の事例として2020年6月に発生したIBM Cloudでのサードパーティのネットワークプロバイダによる誤った経路の広告による障害をあげます。また、Microsoftでの主要な5サービスを対象にした障害の調査結果から約67%の障害で別サービスに障害が連鎖していたことを説明します。インターネット上に公開されたポストモーテムを解析した論文をもとに、連鎖障害が何カ所に連鎖しているかを紹介します。最も多いパターンは1カ所への連鎖が52.6%であることを説明します。この結果から連鎖障害の調査では、あるエラーの起きたシステムに関連しているサービスを重点的に調査するとよいことを述べます。

さらに連鎖障害のパターンを二部グラフを使って可視化し、システムを構成するコンポーネント(アプリ、ネットワーク、ストレージ)の間で障害が連鎖しやすいケースを説明します。特にインフラ(ストレージ、ネットワーク、ミドルウェア)からアプリへ連鎖するケースが多いことを説明します。この結果からアプリケーションの可用性を高めるためには、インフラの可用性を上げることが重要であることを説明し、インフラの可用性をあげるための基本的な方法(冗長化、Fault Injection)を紹介します。

インフラ（6分）

インフラを構成する要素をハードウェア系、ソフトウェア系、ネットワーク系に分類します。ハードウェア系ではデータセンタでのハードウェアを中心に説明をします。BaiduとMicrosoftのデータセンタでのハードウェア故障に関する論文をもとに、データセンタで故障しやすいハードウェアを紹介します。最も故障しやすいハードウェアがHDDであることを説明します。一方でHDDの故障は典型的な故障であるため復旧時間がほかの障害に比べて短く、復旧時間の長い障害は自然災害や電源喪失、ヒューマンエラーであることを述べます。ソフトウェア系では、分散ストレージやOSでの障害を対象とした論文を紹介する予定です。ネットワーク系ではCloudflareで2025年8月に起きた障害を紹介します。ネットワーク系の障害を扱ったMetaとAlibabaの論文をもとにネットワーク関連の障害の原因を紹介します。典型的な故障パターンにはメンテナンス(17%)やハードウェア(13%)、コンフィグミス(13%)やソフトウェアのバグ(12%)があることを説明します。オペレーションを行うエンジニア側で防止に役立つのは、メンテナンス作業ではプロセスの改善や自動化であり、コンフィグミスでは設定ファイルのバリデーションであることを述べます。代表的なツールや方法について簡単に紹介をします。

コンフィグミス（5分）

Metaで2021年10月におきたバックボーンルータのメンテナンスのミスによる障害とSkyScannerでのコンフィグミスの事例をあげます。NetAppの本番システムとOSSのフォーラムでのコンフィグミスを収集し、種類別(パラメータ、互換性、コンポーネント)に集計した論文を紹介します。70〜85%の原因が設定パラメータ、コンソールのコマンドミスであることを説明します。コンフィグミスの具体例を紹介し、コンフィグミスを防止するために有効なツールや最新の研究を紹介します。

まとめ（5分）

障害の典型パターンの4つは、コードのバグ、連鎖障害、インフラ、コンフィグミスであることを説明します。コードのバグでは31%の障害の原因は、ソフトウェアコンポーネントでのタスク/ジョブの失敗やハングであることを述べます。連鎖障害は88.8%が他の箇所に連鎖しており、最も多い連鎖する数は1であることを説明します。インフラの障害ではハードウェア系でHDDが70-80%であり最多であること、ネットワーク系では典型的な4パターン(メンテナンス、ハードウェア、コンフィグミス、バグ)があること、を説明します。コンフィグミスでは70~85%の原因が設定パラメータやコンソールコマンドのミスにあることを説明します。一連の障害原因はシステム規模にかかわらず発生しており、割合はシステムや企業によって異なるものの、1つは当てはまる事例があると考えます。典型的な障害を防ぐことがシステムの可用性を高めるうえでは効果的だといえます。個別の障害の対処はもちろん重要ですが、障害の発生を網羅的に防ぐには、個別の障害に着目するのではなく俯瞰的な傾向の分析が効果的です。セッションを通じて典型な障害とその検出や防止の方法を紹介し、参加者はそれらを導入することで運用するシステムの可用性を向上できます。