# フィールドデータ解析 ## 定義 フィールドデータ解析(field data analysis)は、実運用サイトで意図された利用者が実際に使用している最中に収集されるソフトウェアの故障・修正・稼働に関するデータ(フィールドデータ)を用いて、ソフトウェアの信頼性・可用性を評価・モデル化・予測する取り組みである。制御された system test や実験で得られる「テストデータ」の解析とは明示的に区別される。データの単位は個々の故障事象(failure)であり、根本原因分析によって特定される欠陥(fault)は事後に紐づけられる。目的は (1) 実運用環境での品質の評価、(2) 故障挙動と運用プロファイル・開発プロセスとの関係づけ、(3) 開発・保守プロセスの制御を通じたフィールド品質の予測・改善、の3段階に整理される。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]] §11.1-11.2.1) ## エクスポージャー指標の選択 フィールドデータ解析は、故障の分子(件数)だけでなく分母となる稼働エクスポージャー(usage time: CPU実行時間・実行時間・暦時間・in-service時間・論理時間・構造カバレッジ等)の把握が困難である点に固有の難しさを持つ。広域配布ソフトウェア(shrink-wrapped製品・フリーウェア等)では稼働の直接モニタリングが実務上困難なため、カレンダー時間ベースの解析に頼らざるを得ない。一方、電気通信・航空宇宙・医療機器のような稼働の直接モニタリングが可能な限定市場向けソフトウェアでは、稼働時間(usage-time)ベースの解析が可能になる。同一のフィールドデータであっても、カレンダー時間で見るか稼働時間で見るかによって信頼性の描像が正反対になりうる——新リリースの導入台数が暦時間に対してS字型に増減する「ローディング/ランピング効果」を無視すると、稼働時間あたりでは一貫して改善しているシステムが、暦時間あたりでは劣化しているように見える。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]] §11.2.3-11.2.4, §11.4) ## データ品質の固有の困難 フィールドデータは本質的に「きれいでない」というのが解析の出発点になる。収集への統制が乏しく、既存の履歴データに頼らざるを得ず、分析のためにシステムの使用を止めることはできない。データ粒度(granularity)の粗さにより、短期の「次の故障発生時刻」予測は実務上ほぼ無意味であり、長期予測・推定に焦点を当てるべきとされる。さらに、新リリースの出荷が旧リリースに潜在していた欠陥の発見を刺激する「次リリース効果(next-release effect)」により、複数リリースが並行稼働する期間の故障報告の帰属が複雑化する。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]] §11.1, §11.2.5-11.2.6, §11.5.1) ## 横断的知見 - **フィールドの信頼性研究には「オンライン計装ログ+ダンプ解析つき技術報告」を主データとする計測ベース解析と、「顧客・フィールド支援要員経由で人手集約される問題報告」を主データとするフィールドデータ解析という、データの出どころが異なる2つの系譜が1990年代から並存する**: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]](Iyer & Lee)は、GUARDIANのイベントログ・MVSのSYS1.LOGREC・VAX/VMSのbugcheckレポートといったシステム内部の機械計装と、分析者がダンプ解析まで行って作成するTPR(Tandem Product Report)を主データとし、データ合体(coalescing)という機械生成ログ特有の前処理課題を持つ。これに対し本章(Jones & Vouk)は、顧客・フィールド支援要員・問題スクリーナ・設計者・保守要員など多様な人間の発生源から集約される問題報告(Table 11.1のような多数のフィールドを持つレコード)を主データとし、サイトコードの一貫性・パッチ適用状況・重大度分類のような**人手入力に起因するデータ品質課題**(コード体系の不一致、履歴データの誤破棄、リリースへの故障の誤帰属)を主要な出発点に据える。両者はともに「稼働後ソフトウェアの信頼性」という同じ対象を扱いながら、機械生成ログの重複除去問題(第8章)と人手集約データの一貫性・完全性問題(第11章)という、性質の異なるデータ品質課題に直面する。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]], [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]]) - **「稼働エクスポージャーの分母をどう測るか」という問題は、計測ベース解析ではワークロード変数(CPU利用率・SIO・PAGEIN等)として、フィールドデータ解析ではカレンダー時間/稼働時間の選択問題として、異なる形で現れる**: 第8章はワークロードとソフトウェア故障の関係をload hazard modelで定量化し、OVERHEAD(R²=0.95)等のワークロード指標が故障リスクの対数線形な予測子になることを示した。第11章は同じ「稼働の強さをどう測るか」という問題を、リリース導入台数のランピング効果による暦時間ベース指標の歪みという、より粗い粒度(システム単位の導入台数)で扱う。第8章のワークロード変数はシステム内部の計装から得られる高頻度・高精度な指標であるのに対し、第11章のカレンダー時間/稼働時間の区別は、そもそも稼働の直接計測ができない広域配布ソフトウェアを前提にした、より粗い代替指標の選択問題である。データの入手可能性が測定の精緻さの上限を規定するという構造が、両章に共通して見られる。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]] §8.7, [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]] §11.4.3) ## 未解決の問い - 計測ベース解析(第8章)とフィールドデータ解析(第11章)を同一システムに対して並行適用した場合、両者が導く故障分布・信頼性推定はどの程度一致するか。本 wiki にはこの2系譜を直接突き合わせた実証研究は未収載である。 - カレンダー時間解析と稼働時間解析が正反対の信頼性描像を与えるという図11.8の教訓は、現代のクラウドサービス(継続的デプロイ・カナリアリリースにより「リリース」という単位そのものが曖昧になった環境)にどう再解釈されるか。 - 次リリース効果(旧リリースの欠陥が新リリースの出荷によって発見が刺激される現象)は、マイクロサービスや継続的デリバリー環境における「変更起因インシデント」の分析にどう対応づけられるか。 - フィールドデータの人手入力起因の品質課題(コード体系の不一致、履歴データの誤破棄)は、現代の障害追跡システム(Jira、PagerDuty等)や自動計装によってどの程度解消されているか。 ## 関連 - ソース: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]] - 概念: [[運用障害分析]](出荷後・稼働システムの障害の分類・分析という上位概念。本概念はそのうち「フィールドデータの収集・エクスポージャー測定」という工程に焦点を当てる) / [[運用プロファイル]](稼働の強さ・使われ方のモデル化) / [[可用性]](本章§11.8が扱う関連概念) ## 出典 - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]]