2026年7月10日，SRE NEXT 2026 @TOC有明 OSINT for SRE: 学術論文とポストモーテムから探る システム障害の共通パターン 株式会社メルカリ，東京工科大学大学院 小山 智之 1 bit.ly/srenext26 

こやま ともゆき 小山 智之 (28) • 　 SRE NEXT 初参加 　 分散システム • 株式会社メルカリ DBREチーム • 40TB+のDBの運用(MySQL / TiDB) • マネージャとメンバーを募集中 • 東京工科大学大学院 博士後期課程 • 社会人学生 • ITシステムでの障害の原因分析 (Fault Localization, Root Cause Analysis) 2 #sre-paper にポストしています SNS/Webサイト: 　　www.koyama.me 　　koyama.bsky.social 　　x.com/tmyk_kym 

はじめに •大学院での研究活動 • 論文を執筆する際には，関連する分野の文献調査をする． • 最先端の到達点と未達点を明らかにする． •文献調査 • 50~100+件程度の関連する論文に目を通す． • 大規模な分散システムの運用に関する論文に気づく． • Microsoft [Chen,2020], Uber Technologies [Lee,2024] • 論文の内容を実システムの運用に役立てられないか？ 3 学術論文の例 [Koyama, 2026] 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. 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. 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. 

本セッションの位置づけ 4 論文 論文 公開された ポストモーテム 体系的な分析結果 OSINT* for SRE 主要な4種類の 障害原因を紹介 システム障害の対策において対象や優先度の決定 Google Scholar ChatGPT / Claude Deep Research Google Alert *Open Source Intelligence 公開情報の論文やポスト モーテムの解析を通じた 障害原因の解析 SRE Q. いくつのマイクロ サービスに連鎖する ケースが最も多いか Q. どんな種類のシス テムから連鎖障害が 発生しやすいか ゴール 本セッション 

何が障害の原因か？ • どんな「障害の原因」の種類が多いかを知りたい • 障害･･･システムが正常な状態から逸脱しているとき • Google Scholarから「root cause analysis」でキーワード検索する • 生成AIへ以下のプロンプトを渡してDeep Researchで論文を探す • 5本の論文から障害の原因の種類を集計 5 • ITシステムでの障害の原因の割合を分析した論文を探してください． • 探す論文は，IEEE, ACM, Springer, ScienceDirectを含むScopusに 登録されている中から探してください． • 出版年が10年以内だと望ましいです． • プレプリントは除外してください． 

企業でのシステム障害の原因の内訳 • 5本の論文から障害の原因を集計し，上位5件を抽出 • 主な原因はコードのバグ，連鎖障害，インフラ，コンフィグミス 6 論文で紹介されている障害の内訳の上位5件 広発銀行 (中国) [Zhao, 2021] Microsoft [Ghosh, 2022] サーベイ [Li, 2022] DeepFlow [Shen, 2023] eBay [Xie, 2024] 1位 コードの欠陥 コードのバグ コンフィグミス インフラ (ネットワーク) 連鎖障害 (サードパーティ) 2位 コンフィグエラー 依存関係 その他 インフラ (コンピューティング) 連鎖障害 (内部のサービス) 3位 互換性のないソフト ウェアバージョン インフラ インフラ (ハードウェア) コードのバグ ソフトウェア の変更 4位 リソース競合 デプロイメント エラー ソフトウェア の変更 その他 インフラ (データベース) 5位 その他 コンフィグバグ リソース枯渇 ー ー 類似した原因に 同じ色をつけて分類 

企業でのシステム障害の原因の内訳 •インフラ • インフラストラクチャ(ネットワーク，データセンタ，サーバ)に起因して障害が発生 7 コードの バグ 連鎖障害 コンフィグ ミス ミドルウェア アプリケーション OS ハードウェア ミドルウェア アプリケーション OS ハードウェア ネットワーク ソフトウェア インフラ マシン1 マシン2 

インフラの障害 • オンプレミスからパブリッククラウドへの移行で， DCのネットワーク機器や物理サーバの故障への対処は減っている印象 • クラウド事業者 / オンプレミスの視点での障害の分析が大半 • クラウドのユーザ側の視点で書かれている資料が少ない • データセンタのハードウェアとネットワークを紹介 • ハードウェア系 … CPU, メモリ, SSD • ネットワーク系 … 機器(ルータ, スイッチ), 輻輳, 経路広告 • ソフトウェア系 → 以降で重複するため割愛 8 

ハードウェア故障 • 壊れやすい物理マシンのハードウェアを調査 • Microsoftでデータセンタのハードウェア故障 を分析 [Sankar, 2013] • HDDの故障は71.1%で最多 • Baiduでの過去4年分のハードウェア故障の 作業チケットを分析 [Wang, 2017] • HDDの故障は81.84%で最多 • SSDの故障は0.31% • HDDのプラッタ(皿)は物理的に回転している ため，摩耗故障が起こりうる (cf. バスタブ曲線) 9 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. 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. データセンタでのハードウェア故障の上位5件 Baidu [Wang, 2017] Microsoft [Sankar, 2013] 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% > 

ハードウェア故障の影響 • ハードウェアの故障がサービスレベルに影響のある障害の主な原因ではない [Barroso,2019] • 一般的なソフトウェアのバグやオペレータのミスに対する耐性を高めるよりも， 既知のハードウェア障害を許容するサービスを設計する方が容易 •ディスク故障はストレージシステムの障害の主要な原因ではない • 39,000+のストレージシステムのデータ分析 [Jiang,2008] →NetApp • 分散ストレージシステムの可用性の分析 [Ford,2010] → Google 10 Barroso, L. A., et al. “The datacenter as a computer: Designing warehouse-scale machines.” Springer Nature. 2019. 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. Ford, Daniel, et al. "Availability in globally distributed storage systems." 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI 10). 2010. 

DCのネットワーク障害 • データセンタのネットワーク障害の原因 を調査した論文 • Meta社 [Meza,2018] • Alibaba社 [Yang,2025] • 共通で存在する原因: • ハードウェア…いずれもTop2 • (ソフトウェア)バグ…ともに4位 • 設定(ミス)…Alibaba << Meta • (課題) 原因の分類が統一されていない • ハードウェアの割合が特に多いことは共通 11 Meza, Justin, et al. "A large scale study of data center network reliability." Proceedings of the Internet Measurement Conference 2018. 2018. Yang, Bo, et al. "SkyNet: Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures." Proceedings of the ACM SIGCOMM 2025 Conference. 2025. DC内のネットワーク障害の原因の内訳 Meta [Meza,2018] Alibaba [Yang,2025] 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% 類似した原因に同じ色をつけて分類 

インフラの障害のまとめ • ハードウェアの故障: HDDがMicrosoft, Baiduともに 70-80%で最も多い • ディスク故障は，システム障害の全体のうちの主因ではない (重大でない) • DCネットワーク: ネットワーク機器のハードウェアがAlibaba, Metaともに Top2 • DCネットワークではハードウェアの故障が代表的 • (課題) クラウドベンダ側の障害事例の分析のデータは十分だが， ユーザ側での構成に起因する障害を分析したデータが不足している • クラウド時代のインフラは，設定ファイルの記述+API呼び出し → コンフィグミスやバグの割合が増えているのでは? 12 

企業でのシステム障害の原因の内訳 •連鎖障害 • あるシステムで障害が発生すると，その影響で別のシステムに障害が発生 13 コードの バグ 連鎖障害 コンフィグ ミス ミドルウェア アプリケーション OS ハードウェア ミドルウェア アプリケーション OS ハードウェア ネットワーク ソフトウェア インフラ マシン1 マシン2 

連鎖障害 (カスケード障害) • 例) マシンの内部であるプロセスがメモリ(共有資源)を過剰に消費 • SRE Bookでは「カスケード障害」として定義 •(事例) 2025年10月のAWS 米国東部リージョンでの障害* • DynamoDBのDNS管理システムで競合状態 → EC2, NLB, …の障害に • Microsoftではあるサービスの障害の約67%が別サービスに連鎖 [Li,2021] • 1年間に主要な5サービスで起きた数百件の障害を調査 • 連鎖障害に警戒したいケース • 1つのシステムを複数のシステム(プロセス)で共有 • 元々1つのシステムを複数のシステム(プロセス)に分割 14 ドミノ効果 * 米国東部（バージニア北部、US-EAST-1）リージョンにおける Amazon DynamoDB サービス 中断の概要 https://aws.amazon.com/jp/message/101925/ Li, Liqun, et al. "Fighting the fog of war: Automated incident detection for cloud systems." 2021 USENIX Annual Technical Conference (USENIX ATC 21). 2021. 元々 依存 分離 共有DB App1 App2 信頼性工学では 共通原因故障 (CCF)とよぶ 

障害の連鎖する深さ(爆発半径 / Blast Radius) • 354件の公開されたポストモーテムから障害の 連鎖する深さ(propagation length)を解析 [Li,2022] • 1カ所に連鎖(深さ=2)する場合が最多 • 全体の88.8%が他の箇所に連鎖 • Uber Technologies社でマイクロサービス間の RPCのエラーを解析 [Lee,2024] • 80%以上のエラーが3カ所以下に連鎖 • 最も深いケース: 深さ=26 • 連鎖障害のほとんどは連鎖数が3以下 15 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. 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. MS MS MS 1 2 深さ=3の例 最初のエラー 3 深さ サーベイ [Li,2022] Uber [Lee,2024] 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% 

障害の連鎖するパターン • 公開されているポストモーテムから連鎖障害の伝搬を 調査 [Li,2022] • 連鎖障害の伝搬を二部グラフで可視化 • インシデントの件数が多いほど線が太くなる • ストレージやネットワークの障害がアプリケーション に伝搬している • 典型的なパターン: 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. 16 From To 論文[Li,2022]のTable 4をもとに作成 右図の上位5件 From To 1位 ストレージ アプリケーション 2位 ネットワーク アプリケーション 3位 ミドルウェア アプリケーション 4位 バックエンド アプリケーション 5位 アプリケーション アプリケーション 下位層(インフラ) 上位層(アプリ) 

障害の最小化 障害の隔離 連鎖障害の対策 17 •サーキットブレーカ/スロットリング • 過負荷時にリクエストを拒否/制限 • (SDK) Resilience4j[1], Polly[2] (Service Mesh) Istio, Linkerd • セルベースアーキテクチャ[3,4] • リージョン/ゾーンごとにシステムを 論理単位の”セル”に分割 • セルごとにLBやアプリを分離 [1] Resilience4j https://github.com/resilience4j/resilience4j [2] Polly https://www.pollydocs.org/ [3] AWS re:Invent 2024 - Learn to create a robust, easy-to-scale architecture with cells (ARC335) https://www.youtube.com/watch?v=OkT12t-fvRE [4] バルクヘッド パターン - Azure Architecture Center | Microsoft Learn https:// learn.microsoft.com/ja-jp/azure/architecture/patterns/bulkhead [5] 乃村 翼, “Azure の裏側を支える SRE の世界”, https://speakerdeck.com/tsubasaxzzz/ azure-noli-ce-wozhi-eru-sre-noshi-jie-487afc55-4d81-45bf-98f6-87757dda5fad?slide=18 • リリースの分割 [5] • リージョン/ゾーン単位でリリース • マルチクラスタ/リージョン向け • カナリアリリース [5] • 割合ベースで段階的にリリース • 1% → 5% → 10% → … • (トラフィック) DNS RR, LB (アプリケーション) Feature Flag APP DB LB AZ1 セル セル AZ2 セル セル 

連鎖障害のまとめ •共通パターン • 連鎖障害のほとんどは連鎖数が3以下 • ストレージやネットワークの障害が アプリケーションに伝搬している • 下位層から上位層への連鎖 •緩和する方法 • 障害の隔離: サーキットブレーカ/スロットリング， セルベースアーキテクチャ • 障害の最小化: リリースの分割，カナリアリリース 18 カナリア バルクヘッド(水密隔壁) (国土交通省Webサイトより[1]) [1] 遊漁船等に対する安全設備等の義務化について (国土交通省) https://www.mlit.go.jp/maritime/content/001901314.pdf 浸水を防ぐための壁 (2022年の知床での遊 覧船事故をきっかけに 基準が見直された) 

企業でのシステム障害の原因の内訳 •コードのバグ • ソフトウェアのソースコードにバグが含まれる 19 コードの バグ 連鎖障害 コンフィグ ミス ミドルウェア アプリケーション OS ハードウェア ミドルウェア アプリケーション OS ハードウェア ネットワーク ソフトウェア インフラ マシン1 マシン2 バグの由来[Hopper,’47] Hopper, Grace. "Log Book With Computer Bug." National Museum of American History (1947). 

ソースコードのバグ •(事例) 2025年8月のPagerDutyでの障害* • 新たな機能のバグにより単一のKafkaプロデューサを使い回さずに， APIリクエストごとにKafkaプロデューサが作成された • KafkaブローカでJVMのヒープメモリの使用量が増加し，最終的に枯渇 20 Liu, Haopeng, et al. "What bugs cause production cloud incidents?." Proceedings of the Workshop on Hot Topics in Operating Systems. 2019. * In Incident Response, It’s the People Who Make all the Difference | PagerDuty https:// www.pagerduty.com/eng/in-incident-response-its-the-people-who-make-all-the-difference/ Microsoft Azureの本番環境で6ヶ月間に発生した112件のインシデントを ソフトウェアのバグに関して分類 [Liu,2019] コンポーネントの故障 コンポーネントでの障害の検知や対処が不正確または欠落 31% データ形式のバグ 異なるソフトウェアコンポーネント間でデータ形式が衝突 21% タイミングのバグ 永続データやキャッシュデータがエラーなく破損や不整合 13% 定数のバグ ハードコードされた定数の誤った設定(例: タイポ) 7% その他 リソースリーク，セマンティクスのバグ 28% 

ソースコードのバグ ▶ コンポーネントの故障 (31%) • ソフトウェアコンポーネントでの障害の検知や対処が不正確または欠落であること •どのようにコンポーネントは 壊れたか？ [Liu,2019] 21 サイレント故障(17%) (1) (2) キャッシュされた 永続データ ユーザ • 永続データやキャッシュされた永続 データがエラーコードなしに破損や 不整合になる • ユーザーに誤った結果を返答 (3) (4) コンポーネントでのエラー応答による故障(43%) Error (1) (2) •特定のタスクやジョブが失敗 •処理不能のエラーが返される •503 Service Unavailable 応答不能なコンポーネントによる故障(29%) … Wait (1) (2) (3) • ハングしたジョブや無効にされた ノードが対処されず • ロードバランサの切り離し失敗 • エラーが返されず呼び出し元でタ イムアウト Liu, Haopeng, et al. "What bugs cause production cloud incidents?." Proceedings of the Workshop on Hot Topics in Operating Systems. 2019. 

故障検知のロジックは存在するがデータ消失 エラーのシグナルやログが伝送経路で消失 ソースコードのバグ ▶ コンポーネントの故障 (31%) •故障検知に失敗した理由 [Liu,2019] • ｿﾌﾄｳｪｱｺﾝﾎﾟｰﾈﾝﾄF: 故障箇所 • ｿﾌﾄｳｪｱｺﾝﾎﾟｰﾈﾝﾄGでFの故障を 検知 22 故障検知のロジックの不足 GがFの故障の可能性に関して 故障検知のロジックをもって いない． G F エラーのシグナルやログが故障で消失 Fの故障でシグナルやログ 自体が消失する可能性に 気づいていない． FからGへの伝送経路で シグナルやログが消失する 可能性に気づいていない． 監視 ログファイル G F Wait G F Liu, Haopeng, et al. "What bugs cause production cloud incidents?." Proceedings of the Workshop on Hot Topics in Operating Systems. 2019. 

ソースコードのバグ ▶ データ形式のバグ (21%) • 異なるソフトウェアコンポーネント間でデータ形式が衝突すること • 大半のケースは，ソフトウェアの更新でデータ形式の考慮の不足 • どのようにコンポーネント は壊れたか？ [Liu,2019] 23 ローカルとグローバルファイル(40%) ソフトウェアコンポーネント同士でDBテー ブルやファイルの形式の前提が異なる． メッセージインターフェース(60%) • ソフトウェアコンポーネントの外部インター フェース(例: RESTful API)を変更 • 他のプロセスやノードが想定外の結果を受け 取る DB App ALTER TABLE item 
 DROP COLUMN color; SELECT color FROM item; (1)color列を削除 エンジニア Error (2)color列の参照が存在 (3) Error { "id": 123, "color": "XXX", } { "id": 123 } (2) (3) エンジニア (1)変更 想定した応答 実際の応答 cf. Cross System Interaction Failure Liu, Haopeng, et al. "What bugs cause production cloud incidents?." Proceedings of the Workshop on Hot Topics in Operating Systems. 2019. 

「ソースコードのバグ」の対策・まとめ • コンポーネントの故障(31%) … 障害の検知や対処が不正確/欠落 • 「コンポーネントでのエラー応答による故障」が最多 → 連鎖障害 • ソフトウェアの設計: • 各ソフトウェアコンポーネントが故障検知のロジックをもつ • 故障をあらわすログやシグナルがないまま故障するケースを想定する • データ形式のバグ(21%) … コンポーネント間でデータ形式が衝突 • 「メッセージインターフェース」が最多 • データ形式が変わっても，データ形式の一貫性を保つ仕組み(マスタデータ) • データ形式が変わることを伝える仕組み (起きる前に気がつく) 24 

企業でのシステム障害の原因の内訳 •コンフィグミス • 設定ファイルの記述やコマンドのオプションのミスにより障害が発生 25 コードの バグ 連鎖障害 コンフィグ ミス ミドルウェア アプリケーション OS ハードウェア ミドルウェア アプリケーション OS ハードウェア ネットワーク ソフトウェア インフラ マシン1 マシン2 

コンフィグミス • Googleではサービスレベルに影響する障害原因の2位 [Barroso,2019] • ストレージ企業の技術サポートの問い合わせの27%はコンフィグ関連 [Yin,2011] •(事例) 2021年8月25日にSkyscannerで発生した障害 • ArgoCDでクラスターの構成を変更 • 必要な括弧 {{ }} が欠けていた • 新しい構成に有効なnamespaceがないため，世界中のAZとリージョンのすべて のnamespaceにある478のサービスの一括削除が開始された 26 - cell: {{ default $cluster.name $cluster.unique_name }} + cell: $cluster.name Barroso, L. A., et al. “The datacenter as a computer: Designing warehouse-scale machines.” Springer Nature. 2019. 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. How a couple of characters brought down our site | by Skyscanner Engineering | Medium https://medium.com/@SkyscannerEng/how-a-couple-of-characters-brought-down-our- site-356ccaf1fbc3 

コンフィグミスの分類 • 実際におきた546件のコンフィグミスの障害を種類別で集計 [Yin,2011] 約70-85%の原因は設定パラメータ，コンソールコマンドのミスにある 27 論文内のTable. 3より抜粋 [Yin,2011] システム パラメータ 互換性 コンポーネント 合計 COMP-A 246 31 32 309 CentOS 42 11 7 60 MySQL 47 0 8 55 Apache 50 5 5 60 OpenLDAP 49 7 6 62 • パラメータ: 設定パラメータのミス，コンソールコマンドのミス • 互換性: ソフトウェアの互換性に関連するコンフィグミス • コンポーネント: その他のソフトウェアに残るコンフィグミス(モジュール不足) COMP-A NetAppの本番システム その他 公式ユーザサポート， メーリングリスト， ServerFault.com 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. 

パラメータのコンフィグミス • 実際におきた546件のコンフィグミスの障害を種類別で集計 [Yin,2011] 28 extensions=mysql.so
 extensions=recode.so Syntax (Apache HTTP Server + PHP) コンフィグミスあり log_output="Table"
 log=query.log コンフィグミスあり 値の不整合(MySQL) ログをファイルに書き出そうとするが ログの書き出し先はDBのテーブル ▶コンフィグだけでは何を意図しているか不明 モジュールが見つからずにSEGV →recode.soを先に読み込むべき 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. 

コンフィグミスはユーザが悪いのか？ • 主要なミドルウェアにコンフィグミスを注入しソフトウェアの挙動を収集 [Xu,2013] • コンフィグミスを誘発するソフトウェアの設計を明らかにした • 人の誤解やタイポを検知・回避できていない設計にも問題がある 29 Xu, Tianyin, et al. "Do not blame users for misconfigurations." Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 2013. パラメータ数 0 25 50 75 100 時間の単位 μs ms s m h Storage-A Apache MySQL PostgreSQL OpenLDAP VSFTP Squid 箇所 0 50 100 150 200 Storage-A Apache MySQL PostgreSQL OpenLDAP VSFTP Squid パラメータの単位の不整合 安全でない関数の使用 atoi, sscanf, sprintf 同じソフトウェアに単位の 異なるパラメータが混在 パラメータを「時間の単位」ごとに集計 (Table7より)[Xu,2013] 実際の入力値と内部での値が食い 違う [例] atoi(1O0) returns 1 安全でない関数を使用したパラメータ 受け取りの実装 (Table8より) [Xu,2013] 

ソフトウェアの使用(ユーザ) ソフトウェアの開発[1] コンフィグミスの対策・まとめ • パラメータ(設定ファイル, コマンド)が原因のコンフィグミスが最も多い • コンフィグミスには，ソフトウェアの設計が誘発するケースがある • 人がコンフィグミスをするので，人間の認知特性(例: なぜ見間違えたのか)の分析も必要 30 • パラメータの単位の明示 • パラメータ名に単位の付与 (例) timeout. sec = 10 • 単位のsuffixの必須化[2] (例) 10 MiB • 安全でない関数を使わない • JPCERTコーディングスタンダード[3] • ケアレスミス(Syntax)のチェック • Linter(例: kube-linter*)やdry-run • 値の不整合 • ユーザの意図と実際のソフトウェアの挙 動を比較する方法が確立されず • ソースコード解析[4], LLM+LSTM[5] [1] Xu, Tianyin, et al. "Do not blame users for misconfigurations." Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 2013. [2] Dustin Boswell, et al. “リーダブルコード”, O’Reilly Japan https://www.oreilly.co.jp/books/9784873115658/ [3] INT06-C. 文字列トークンを整数に変換するには strtol() 系の関数を使う https://www.jpcert.or.jp/sc-rules/c-int06-c.html [4] Automated Reasoning and Detection of Specious Configuration in Large Systems with Symbolic Execution | USENIX https://www.usenix.org/conference/osdi20/presentation/hu [5] Mandal, Shantanu, et al. "Large language models based automatic synthesis of software specifications." arXiv preprint arXiv:2304.09181 (2023). * stackrox/kube-linter https://github.com/stackrox/kube-linter 

• (動機) 論文の内容を実システムの運用に役立てられないか？ • 企業ごとに障害原因の割合は異なるが，主要な共通した障害原因がある • 残された課題 • (クラウド時代の障害データの不足) Terraformのコンフィグミスの内訳 → ない • 障害データ(例: ポストモーテム)の分析と公開が障害を防ぐために役立つ まとめ 31 インフラ • HDDのハードウェア故障 • NW機器のハードウェア故障 連鎖障害 • 連鎖障害の大半は3箇所以下に連鎖 • ストレージやネットワークからアプリケーションに連鎖 バグ • コンポーネントの故障， データ形式のバグが52% コンフィグミス • 設定パラメータやコンソールコマンドのミスが70~85% • コンフィグミスを誘発する設計(パラメータの単位の不整合) 論文化! 

告知 (株)メルカリから合計4件の登壇があります．他のセッションもご覧ください． 32 日時 タイトル 発表者 7/10 (金) 13:00 - 13:30 AI-native時代の信頼性を育てる、 インシデント学習と改善ループの実践 foostan 7/10 (金) 16:10 - 16:40 OSINT for SRE: 学術論文とポストモーテムから探る システム障害の共通パターン 小山 智之 7/10 (金) 16:55 - 17:25 分散システム、なんですぐ死んでしまうん？ 耐障害性を高めたいあなたのためのレジリエンスパターン入門 渋谷 充宏 7/11(土) 15:35 - 16:05 月間400万ジョブを支えるGitHub Actions self-hosted runner の信頼性 azrsh 

参考文献(ランキングの5本の論文) • 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. • 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. • Li, Liqun, et al. "Fighting the fog of war: Automated incident detection for cloud systems." 2021 USENIX Annual Technical Conference (USENIX ATC 21). 2021. • Shen, Junxian, et al. "Network-centric distributed tracing with deepflow: Troubleshooting your microservices in zero code." Proceedings of the ACM SIGCOMM 2023 Conference. 2023. • 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. 33 

付録 34 

参考資料 • 真壁徹. "クラウドアプリケーション 10 の設計原則:「Azure アプリケーションア ーキテクチャガイド」 から学ぶ普遍的な原理原則." インプレス (2023). • 連鎖障害の対処で紹介した方法が詳しく紹介されている • Yamaguchi, Junya. "Azure の運用を支える AIOps #1【イントロ編】 “ https://zenn.dev/openjny/articles/78f91604a8c30f • Micorosoft社の運用改善の研究を紹介している • Koyama, Tomoyuki. "システム障害やRCAに関連した論文 | Coyama Wiki" https://wiki.koyama.me/%E7%A0%94%E7%A9%B6/favorite-papers/ • 運用/システム系の読んだ論文を紹介している (私のWiki) 35 

障害の連鎖する深さ(爆発半径)と致命的なエラー • Uber Technologies社での解析 [Lee, 2024] • NotPropToRoot (致命的でない): 最終的にリクエストがエラーにならず • PropToRoot (致命的): 最終的にリクエストがエラーになる • 致命的でないエラーは連鎖する深さが 深い • 致命的なエラーは連鎖する深さが 浅い • 大半の致命的なエラーは深さが浅い 36 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. エラーの連鎖する深さと致命的であるか の比較[Lee, 2024] エ ラ ー の 連 鎖 す る 深 さ ( 平 均 ) エンドポイントに番号を採番 

コンフィグミスの例 • 出典: Figure 2 [Yin,2011] 37 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. 

コンフィグミスの防止 •設定テスト (SRE本 17章より) [Beyer,2017] • Googleでは設定ファイルごとに個別の設定テストを行う． • 商用環境を調べて特定のバイナリが実際にどのように設定されるているかを確認 • テスト対象の設定ファイルにどのような差異があるのかをレポートする． 38 (2)比較 変更対象の 設定ファイル レポート (1)収集 (3)レポート化 サーバ サーバ サーバ Beyer, Betsy et al. (澤田, 武男 et al. 監訳) SRE サイトリライアビリティエンジニアリング―Google の信頼性を支えるエンジニアリングチーム. O'Reilly Japan, Inc., 2017.