# 運用プロファイル ## 定義 運用プロファイル(operational profile)とは、システムが実運用でどう使われるかを、互いに排他的な使用パターン(操作、operation)の集合とその生起確率の組として定量化したものである。テスト資源を実際の使用頻度に比例して配分することで、限られたテスト時間でも実務上到達可能な最大の信頼性を得る、あるいはテストが途中で打ち切られても最も使用頻度の高い操作が最も手厚くテストされている状態を保証する、という考え方に基づく。AT&T の [[John Musa]] が確立した概念であり、1993年の IEEE Software 誌で包括的に発表された(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]] §5.1)。 ### 基本語彙 - **run / run type**: run は外部からの介入(人間またはシステム)によって開始できる最小の作業単位。同一の入力状態を持つ run は同じ run type に属する(ch.5 §5.2)。 - **function / operation**: function は要求仕様段階での run type のグルーピング(ユーザー視点)、operation は実装されたシステムでの run type のグルーピング(実装視点)。両者は必ずしも一対一に対応しない(ch.5 §5.2, §5.3.5)。 - **explicit / implicit プロファイル**: explicit プロファイルはキー入力変数の値の組を直接列挙する。implicit プロファイルは有向グラフや木(call tree など)で条件付き確率の系列として表現し、要素数を「レベル数の積」ではなく「レベル数の和」程度に圧縮できる(ch.5 §5.3.4.2)。 ## 作成手続き(5段階) 運用プロファイルは、システムの使用実態を段階的に絞り込む最大5段階の手続きで作成する。各段階は前段の出力を入力として、より詳細な中間プロファイルを生成する(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]] §5.3)。 1. **顧客型リスト(customer type list)**: システムを購入する顧客(個人・組織)を、使用パターンが類似する型に分類する。単一顧客のみ、または全顧客が同じ使い方をする場合は省略できる。 2. **ユーザー型リスト(user type list)**: 顧客型ごとに、システムを実際に使用するユーザー(職務ロールなど)を洗い出す。顧客(購入者)とユーザー(使用者)は必ずしも一致しない。顧客型をまたいで類似のユーザー型があれば統合する。 3. **システムモードリスト(system mode list)**: 分析の便宜のためにグルーピングした function/operation の集合。重要度(criticality)・環境条件(平常時/過負荷時など)・アーキテクチャ構造などを基準に定義し、システムモードごとに独立した運用プロファイルを持つ。 4. **機能プロファイル(functional profile)**: 要求仕様段階の視点(function)で、各要素の生起確率を求める。設計着手前の開発資源優先順位付けに使えるため、実装が固まる前でも作成できる。 5. **運用プロファイル(operational profile)**: 機能プロファイルを実装後の operation に写像し直し、生起確率を割り当てる。テスト選択に直接使うのはこの最終段階の出力である。 すべての段階が常に必要なわけではない。要求が十分に詳細で function と operation がほぼ一致する場合、機能プロファイルの段階は省略できる。逆に実装が完了するまで運用プロファイルに必要な情報が得られない場合は、機能プロファイルのみで開発資源配分の指針とすることもある(ch.5 §5.3)。 ## テスト選択への適用 運用プロファイルから実際にテストを選ぶ際は、operation の粗粒度選択(coarse grain、使用頻度・重要度に基づく)と run type の細粒度選択(fine grain、単純な乱択)を分離する。選択は置換ありで行う(重複実行を許容する)。中間単位として run category(おおよそ均一な run type の集合)を導入すると、詳細情報がなくても近似的に均一な選択ができる。回帰テストも新規テストと同様に運用プロファイルに従って操作を選ぶべきであり、変更の影響が特定操作に限定されると確信できない限り全操作を対象に含める(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]] §5.4)。テスト技法・テスト戦略一般の議論は本ページのスコープ外とし、運用プロファイル由来の選択方針にとどめる。 ## 限界と特殊事情 - **間接入力変数(indirect input variable)**: プログラムが直接参照しないが処理に影響すると考えられる変数。トラフィック負荷や、実行時間経過に伴うデータ劣化の蓄積を表す soak time がその例。直接観測・制御が難しい入力状態を、間接的な変数で代理して制御する(ch.5 §5.5.1)。 - **更新**: 新版がリリースされるたびに運用プロファイルの更新が必要になる。実測データに基づく定常的な測定プログラムを組み込むのが望ましい。機能プロファイルは優先順位付けが主目的のため、運用プロファイルほど頻繁な精緻化は要しない(ch.5 §5.5.2)。 - **分散システム**: 分散・ネットワーク化システムにも適用できるが、環境変数(トラフィック負荷やソークタイムなど)を機器ごとに扱う必要が生じ複雑化しやすい。設計・運用手順を対称化する(各機器のトラフィック負荷比率を揃える、再初期化タイミングを同期させるなど)ことで環境変数の増殖を抑えられる(ch.5 §5.5.3)。 ## 適用事例 Musa らは AT&T 内の性質の異なる3システムへの適用を報告している(詳細は [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]] を参照)。 - **DEFINITY(PBX交換機)**: 業種ごとに独立した運用プロファイルを構築し、implicit プロファイルである call tree でユーザーの通話行動を表現した。顧客報告問題・保守コストを10分の1、システムテスト期間を2分の1、製品導入期間を30%短縮した。 - **FASTAR(光ファイバケーブル切断からの高速自動復旧システム)**: 運用スコープが異なる2つのサブシステム(拠点ごとの Restoration Node Controller、網全体を統括する Central Restoration System)にそれぞれ独立した運用プロファイルを構築し、シミュレータ環境上で加速テスト(負荷を最大50倍に加速)を実施した。DS3経路の正しい報告・再ルーティング率が90%から99%超に改善した。 - **PQRS(電源品質管理システム)**: データフロー図由来の機能プロファイルを56トランザクション・12操作の運用プロファイルへ精緻化し、意図的に発生確率を平均から外して変動させることで、通常の機能テストでは検出できない故障を検出した。 ## 横断的知見 - (現時点では単一ソース([[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]])のみに基づく。2ソース目の ingest 時に、他ソースとの突き合わせで見える観察をここに追記する。) - **構造的カバレッジとの対比**: 運用プロファイルに基づくテスト配分(使用頻度に比例した配分)と、[[wiki/concepts/テストカバレッジ]] が扱う文・分岐・データフローカバレッジに基づく配分(構造網羅を目指す配分)は独立した原理である。第13章はこの対比を明示的に論じ、運用プロファイルどおりにテストしても構造的カバレッジが低い(=未検証のコードが残る)ことがありうるとし、運用プロファイルの推定誤差(本ページの「限界と特殊事情」参照)がそのまま構造的な検証漏れに直結すると指摘する。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]], [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 13 Software Testing and Reliability]]) - **SREプロセス全体における位置づけ**: 第6章「Best Current Practice of SRE」は運用プロファイル(および機能プロファイル)の決定を、開発ライフサイクル4フェーズのうち「実現可能性・要求」フェーズ(機能プロファイル決定)と「システムテスト・フィールドトライアル」フェーズ(運用プロファイル決定・信頼性成長テストの駆動)の2箇所に明示的に位置づける(図6.1)。さらに段階的導入順序(表6.1)では、機能・運用プロファイルの決定が信頼性成長テストの実施に次ぐ2番目の導入ステップとされ、SRE導入の最も基礎的な部分の一つとして扱われる。第5章が単体で作成手続き・適用事例を詳述するのに対し、第6章はそれをいつ・誰が・どの活動と組み合わせて実行するかという組織プロセス上の座標を与える(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 6 Best Current Practice of SRE]] §6.2.4, §6.2.5)。 ## 未解決の問い - 運用プロファイルの精度に対する信頼性測定の頑健性は高いとされる(ch.5 §5.1, [Musa94] 参照、本書内では引用のみで詳細な導出は示されない)が、この頑健性は具体的にどのような統計的性質から導かれるのか。 - ユーザー行動が多様かつ急速に変化する現代のクラウドサービスに、運用プロファイルの5段階手続き(顧客型→ユーザー型→システムモード→機能→運用)はそのまま適用できるか。SLO駆動の運用フェーズ信頼性制御は運用プロファイルの後継概念と言えるか([[ソフトウェア信頼性工学]] の横断的知見も参照)。 - 分散システムでの環境変数増殖という限界(ch.5 §5.5.3)は、マイクロサービスのような現代の高度に分散した系ではどのような形で現れ、どう対処されているか。 ## 関連 - ソース: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]] / [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 6 Best Current Practice of SRE]] - 概念: [[ソフトウェア信頼性工学]] - 実体: [[John Musa]] / [[DEFINITY]] / [[FASTAR]] / [[PQRS]] ## 出典 - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 5 The Operational Profile]] - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 6 Best Current Practice of SRE]]