# What Bugs Cause Production Cloud Incidents? **論文**: What Bugs Cause Production Cloud Incidents? **媒体**: HotOS 2019 **対象**: Microsoft Azure の高重大度本番インシデント **URL**: https://people.cs.uchicago.edu/~shanlu/paper/hotos19_azure.pdf > [!abstract] 概要 > 本論文は、Microsoft Azure の高重大度本番インシデントを調査し、クラウド停止に寄与するソフトウェアバグの性質を分類する。6 か月間のインシデントでは、ソフトウェアバグが大きな割合を占め、詳細分析された 112 件のバグ事例では、障害検知・処理、データ形式、タイミング、定数値に関する問題が主要カテゴリとなる。クラウド障害の多くは「コードが壊れている」だけでなく、失敗時の処理経路やデータ進化、運用上の緩和策と密接に関係する。 ## 論文情報 | 項目 | 内容 | |---|---| | 著者 | Haopeng Liu, Shan Lu, Madan Musuvathi, Suman Nath | | 発表 | HotOS 2019 | | 対象 | Microsoft Azure の高重大度本番インシデント | | 期間 | 2018-03-05 から 2018-09-05 までの 6 か月 | | 詳細分析 | ソフトウェアバグに起因する 112 件のインシデント | ## 概要 クラウドの本番障害は、ハードウェア、ネットワーク、運用、設定、ソフトウェアが絡み合って発生する。 本論文は、その中でもソフトウェアバグに焦点を当てる。 Azure の高重大度インシデントを対象に、どのような種類のバグが本番障害になるのかを分類する。 主要なメッセージは、クラウド本番障害のソフトウェアバグは、通常の機能バグとは性質が異なるという点である。 障害検知・処理、データ形式、タイミング、定数値のように、分散環境、運用環境、進化するデータと関係するバグが多い。 **Table 1: クラウドインシデントと単一マシン障害の違い** ![[_attachments/hotos2019-azure-software-failures/table01-cloud-vs-single-machine.png]] (Table 1. クラウドインシデントは、ハードウェアやメモリ問題が少なく、障害検知・処理、データ形式、永続データが相対的に重要になる。) ## 問題設定 クラウドサービスでは、テスト、コードレビュー、監視、段階的デプロイが行われている。 それでも高重大度インシデントは発生する。 本論文は次を問う。 - 本番クラウドインシデントの中で、ソフトウェアバグはどの程度重要か。 - どのカテゴリのバグが本番障害になりやすいか。 - 障害発生後、修正と緩和はどのように行われるか。 - 既存のテスト・検証で見落とされやすいバグは何か。 ## データセット 対象は Azure の高重大度本番インシデントである。 2018 年 3 月 5 日から 9 月 5 日までの 6 か月間の全高重大度インシデントを調べ、その中でソフトウェアバグに起因する 112 件を詳細分析している。 論文では、ソフトウェアバグがインシデント全体の約 40% に近い割合を占めると報告される。 一方、ハードウェア故障は 5% 未満である。 これは、クラウド障害の主要リスクが物理故障からソフトウェアと運用の複合問題へ移っていることを示す。 ## 分析軸 バグ原因は次のように分類される。 | 分類 | 割合 | 典型例 | |---|---:|---| | Fault detection / handling | 31% | 障害を検知できない、復旧処理が誤る | | Data-format | 21% | データ形式変更、互換性、パース失敗 | | Timing | 13% | レース、順序、遅延、タイムアウト | | Constant values | 7% | 閾値、上限、固定値の誤り | | その他 | 残り | リソースリークなど | また、インシデント解消は恒久修正と緩和策に分けられる。 論文では、44% が fix、56% が mitigation とされる。 **Figure 1/2: インシデント解決戦略** ![[_attachments/hotos2019-azure-software-failures/fig01-02-resolve-strategy.png]] (Figure 1/2. 全体では緩和策が修正より多く、根本原因ごとに修正・緩和・エスカレーションの比率が異なる。) ## 主な結果 ### ソフトウェアバグは高重大度インシデントの主要因である クラウド障害というとハードウェア故障やネットワーク障害が想起されやすい。 しかし、対象期間の Azure 高重大度インシデントでは、ソフトウェアバグが大きな割合を占める。 これは、クラウドサービスの信頼性がソフトウェア品質に強く依存することを示す。 ### 障害検知・処理バグが最多である Fault detection / handling が 31% と最大カテゴリである。 クラウドシステムは障害を前提に設計されるが、障害を検知するコードや、障害時に走る回復処理自体にバグが存在する。 通常経路ではなく、例外経路・復旧経路のテストが不足しやすいことを示す。 ### データ形式バグはサービス進化と結びつく Data-format バグは 21% と大きい。 クラウドサービスではコンポーネントが独立に更新され、古いデータと新しいコード、古いコードと新しいデータが混在する。 このため、データ形式変更や互換性処理が本番障害の原因になる。 ### 解決は修正より緩和が多い 詳細分析では、解決手段の 56% が mitigation であり、恒久的な code fix は 44% である。 緩和策には、コード変更だけでなく、データ修正、環境変更、設定変更、ロールバックなどが含まれる。 本番障害対応では、正しい修正より先に影響を止めることが優先される。 **Figure 3: バグ種別ごとの解決時間** ![[_attachments/hotos2019-azure-software-failures/fig03-resolving-time.png]] (Figure 3. データ形式、障害関連、タイミング、定数値などのバグ種別ごとに、インシデント解決時間の分布が異なる。) ## 新規性 この論文は、クラウド本番インシデントのうち、ソフトウェアバグに焦点を当てて原因分類した点に価値がある。 従来のバグ研究が開発時の欠陥やクラッシュを扱うのに対し、本研究は高重大度の本番影響を生んだバグだけを見る。 そのため、クラウドで重要なバグカテゴリが、一般的なテストベンチとは異なることが分かる。 特に障害処理・データ形式・タイミングは、分散クラウドの運用条件と密接に関係する。 ## 考察 この論文は、[[クラウドインシデント]] を「バグが原因だった」で止めずに読むための分類軸を与える。 本番障害を減らすには、正常系の機能テストだけでは不十分である。 重点的に検証すべきなのは次である。 - 障害検知と復旧処理。 - 古いバージョンと新しいバージョンのデータ互換性。 - タイミング、順序、タイムアウトの境界条件。 - 固定値・閾値・容量制限の本番スケールでの妥当性。 ## 強み / 弱点・課題 ### 強み - Azure の高重大度本番インシデントを対象にしている。 - ソフトウェアバグをクラウド運用文脈で分類している。 - 修正と緩和を分け、実運用の対応を捉えている。 - 障害処理コードの重要性を定量的に示している。 ### 弱点・課題 - 6 か月間の単一クラウド事業者のデータである。 - 公開データではなく内部データに基づくため、再現性や詳細確認には制約がある。 - 高重大度インシデントに限定され、軽微なバグや未報告事象は含まれない。 - バグ分類には研究者の解釈が入る。 ## 関連 - [[クラウドインシデント]] - [[@2016__SoCC__Why Does the Cloud Stop Computing - Lessons from Hundreds of Service Outages]] - [[@2011__SOSP__An Empirical Study on Configuration Errors in Commercial and Open Source Systems]] - [[@2016__ASPLOS__TaxDC - A Taxonomy of Non-Deterministic Concurrency Bugs in Datacenter Distributed Systems]] ## 出典 - [[.raw/papers/hotos2019-azure-software-failures.pdf]] - [[.raw/papers/hotos2019-azure-software-failures.txt]] - [[.raw/papers/hotos2019-azure-software-failures/images/images.json]]