# LiveOps: Systems Management as a Service > [!abstract] 概要(abstract の日本語訳) > 既存の管理システムは、システム管理者が直面する最も時間を要し技術的に困難な異常を検知できない。Oppenheimer[25]は、障害の33%が人的過誤に起因し、障害解決に要した時間の76%が人間によってどのような変更が必要かを特定する作業に費やされたことを明らかにした。異常検知ルールを定義することは困難であり、しばしば組織間で共有できない。それには、ソフトウェア・ワークロード・システム構成、およびワークロードと分散アプリケーショントポロジ全体に固有のチューニングパラメータについての深い複合的知識が必要となる。 > 我々は、アプリケーションとそれが用いる永続状態との相互作用を監査することに基づく、スケーラブルなシステム・セキュリティ管理サービスであるLiveOpsを提示する[33]。このアプローチは、セキュリティ脆弱性の識別を単純化し、コンプライアンス監査を実施し、フォレンジック調査を可能にし、パッチ適用問題を検知し、トラブルシューティングを最適化し、マルウェア/侵入を検知する。このサービスは組織間・管理境界を越えた知識共有を可能にし、これを基盤とする異なる管理製品間の分析結果のシームレスな統合を可能にする。我々の設定不要のエージェントは、レジストリエントリ・ファイル・バイナリ・プロセス生成に対するすべての読み取り・書き込みアクセスを収集する。エージェントのストリーミングの可逆圧縮により、ログファイルは1日あたりわずか20MB(平均4500万イベントを含む)しか生成されない。スケーラブルなLiveOpsバックエンドサービスは、1000マシン日分のログを30分で解析できる。LiveOpsエージェントは、ホームシステムから企業デスクトップまで1149台のマシンに展開され、そのうち11拠点にまたがる381台のMSN本番サーバを含む。 ## 論文情報 - タイトル: LiveOps: Systems Management as a Service - 著者: Chad Verbowski([[Microsoft Research]])、Juhan Lee・Xiaogang Liu([[Microsoft MSN]])、Roussi Roussev([[wiki/entities/Florida Institute of Technology|Florida Institute of Technology]])、Yi-Min Wang([[Microsoft Research]]) - 媒体: 20th Large Installation System Administration Conference(LISA '06)、USENIX Association、Washington, DC、2006-12-03〜12-08(掲載ページ 187–203) - URL: https://www.usenix.org/legacy/events/lisa06/tech/full_papers/verbowski/verbowski.pdf - 関連する著者自身の先行研究: [33] Verbowski, C., et al., "Flight Data Recorder: Monitoring Persistent-State Interactions to Improve Systems Management," OSDI, Seattle, WA, 2006(本論文はこの技術基盤の上に構築されたサービス化・運用報告である)。[32] Verbowski, C., et al., "Analyzing Persistent State Interactions to Improve State Management," SIGMETRICS, Saint Malo, France, 2006。 ## 概要 Microsoft Research と MSN の著者らが、アプリケーションと永続状態(persistent state, PS: レジストリ・ファイル・バイナリ・プロセス生成)の相互作用を監査するサービス LiveOps を提案し、MSN本番環境への実配備から得られた分析結果を報告する論文である。LiveOpsはエージェントが全PS変更を非参加型(アプリケーション側の協力を要しない)に記録し、バックエンドサービスが変更管理・異常挙動対応・ベストプラクティス遵守という3つの管理シナリオ向けにレポートを生成する。 ## 問題設定 - **前提**: 既存の管理システムは、性能・スケーラビリティ上の理由から全ての変更やアプリケーション・ユーザー・PS間の相互作用を追跡していない。管理者は自身の経験とアプリケーション知識を頼りに、これらのシステムが記録するPS変更の部分集合を手動でフィルタしてアプリケーションへの影響を特定しなければならない。 - **動機となる具体例**: (1) ある大規模MSNサイトで、トラブルシューティング中に重要な設定ファイルが誤って削除され、問題は一旦解消したように見えたが18時間後に部分的な障害が発覚し、根本原因の特定に27時間を要した。(2) 大規模MSNサイトへのパッチ配布後、一部サーバのみが部分的な設定しか受け取らなかったことが原因の性能劣化を特定するのに、2つのエンジニアリングチームが約72時間を要した。いずれも「何がいつ変更されたか」の記録があれば迅速に特定できた事例として提示される。 - **入力**: 管理対象マシン上のレジストリ・ファイル・バイナリロード・プロセス生成へのすべての読み取り・書き込みアクセス。 - **出力**: 変更管理・異常挙動対応・ベストプラクティス遵守の3シナリオに対応するWebレポート、アラート(Instant Messenger・メール・RSS)、他の管理製品との統合用API。 - **規模感**: MSN本番環境で1149台(うち381台が11拠点のMSN本番サーバ)にエージェントを展開。 **Figure 1: Typical Change Management Process** ![[_attachments/verbowski/fig01-change-management-loop.png]] (Figure 1. 一般的な変更管理プロセス(変更要求→変更ツール→変更の承認判定→OS+アプリケーション基盤への適用→自動化/担当者への通知→変更検知→変更要求へ戻るループ)を示す。LiveOpsは「変更検知」と「未知の変更へのアラート」を担い、このループを閉じる欠けていた構成要素として位置づけられる。) 多くのIT組織が従う典型的な変更管理プロセスは、(1) 変更対象の特定と作業指示書(work order)の作成、(2) テスト環境での正しさの検証、(3) サブセットのサーバへの展開と実運用ワークロードでの問題監視、(4) 全体展開と作業指示書のクローズ、の4段階からなる。このプロセスの3つの主要課題は、変更内容の正確な定義、変更が実際に適用されたことの監査、変更が影響するアプリケーションの特定である。既存手法(サンプリング調査、管理者のメモ、不完全なログの参照)はいずれも信頼性に欠ける。 ## 提案手法 - **設計思想**: LiveOpsはCFEngine[5]のようにシステム全体に対する正しさの制約を課すのではなく、OSレベルの相互作用の観点から構成を管理する。これにより、各アプリケーションが実際に使用するPSの部分集合だけに考慮を絞れる(非一時的なレジストリ・ファイルのうち日常的に使われるのは15%未満[32])。 - **既存アプローチに対する優位性(著者の主張)**: (1) 非参加型モデルであり、アプリケーションが使うAPIやログ出力の有無に関わらず全ての変更を追跡できる、(2) 単一のイベントソースから少数の明確に定義されたイベント型だけで全アプリケーションを監視できる、(3) 根本原因が自明でない場合でも候補を絞り込める、(4) 根本原因が判明すれば「誰が・いつ・どのプロセスで」変更したかが分かるため再発を防止できる。 **Figure 2: LiveOps System Architecture and data flow** ![[_attachments/verbowski/fig02-architecture-dataflow.png]] (Figure 2. アーキテクチャ全体を示す。低レベルのサーバ/デスクトップエージェントがレジストリ・ファイル・バイナリロード・プロセス生成の相互作用をログし、ストリーミング圧縮してアップロードする(左)。バックエンドサービスがログを処理・アーカイブする(中央、Archive)。拡張可能なWebインターフェースがレポート取得・プログラムからのデータアクセス・既存の通知機構との統合を提供する(右、Alerts/Compliance/Forensics/Web Reports)。) - **バックエンド処理フロー**: 新しくアップロードされたログを解析するデーモンは、標準のC/C++/C#で書かれ動的ロード可能なQuery Module(QM)としてコンパイルされたルールを適用する。QMは変更管理データベース(CMDB)や変更ポリシー定義といった外部ITデータソースと統合でき、ログ活動をパターン識別・CMDB作業項目との相関・ポリシー違反判定によって異常検知する。全QMはAlert Databaseへ共通APIでアラートを書き込み、Alert Notification daemonがInstant Messenger・メール・RSSフィードで通知する。QMは内部データベース(ベースラインQMが持つ、アプリケーションとPSの相互作用履歴のベースラインDB等)を保持できる。処理済みログは中央アーカイブへ移され、管理者はLiveOpsクエリAPIを介してアドホッククエリを実行できる。 **Figure 3: LiveOps analysis framework** ![[_attachments/verbowski/fig03-analysis-framework.png]] (Figure 3. バックエンドサーバの解析フロー(ログの受信→Automatic Grouping/Labeling/Correlation の STAGE-1 → State-to-Friendly Name Mapping の STAGE-2 → Expert Annotations の STAGE-3 → Forensics/Reporting/Alerting)を示す。CMDB・Change Policy・Planned Change・Known Problem・Baseline・Archive の各コンポーネントが Extensible Processing の Query Modules として統合される。) - **注釈(annotation)の3段階**: LiveOpsは各アラート・個々のファイル/設定に、(1) 自動的な統計情報(他に何台がこのアプリケーションをインストールしているか、最も一般的なバージョン・値)、(2) 事前定義されたコンテキストマッピング(インストールされたファイルのバイナリハッシュを、会社名・アプリ名・バージョン情報を索引するデータベースと突き合わせる)、(3) エキスパート注釈(他ユーザーが提供したコメントや評価。スパイウェア/マルウェアであれば対処法の記事も含む)、の3段階の注釈を付与する。 **Figure 4: LiveOps annotation of information** ![[_attachments/verbowski/fig04-annotation-stages.png]] (Figure 4. アラートへの注釈付与の3段階(Automatic/Pre-defined context mapping/Expert)を示す。) ## 新規性 - 既存のシステム管理製品[21]はアプリケーション側のログ出力に依存するため、開発者が想定しなかった問題(他アプリケーションとの統合、OSとの相互作用、分散システム構成要素との相互作用)を検知できない。LiveOpsはアプリケーションが何をログするかに関わらず、OSレベルでPSへの全アクセスを非参加型に記録する点で新規性がある。 - 「アプリケーションは失敗するものとして設計する」というRecovery-Oriented Computing[4]的アプローチとは異なり、LiveOpsは根本原因の特定・再発防止という、失敗前提のアプローチが放棄していた課題に取り組む。 - TripWire[16]のようなレジストリ/ファイル完全性チェッカーとは異なり、LiveOpsは各管理対象システム上でスキャンを実行する必要がなく、中央にアップロードされたログをスキャンする。これにより、実際にアプリケーションが使用している値のみを対象にでき、未使用のエントリに起因する偽陽性を減らせる。 - サービスとして複数組織・管理境界を横断して運用することで、新しいルールが開発されるたびに全加入者が即座に恩恵を受けられる点、既知の良い値・悪い値を大規模なホスト間相関から特定できる点が、個別インストール型の管理システムに対する優位点として挙げられている。 ## 実験設定 本論文は新規アルゴリズムのベンチマーク評価ではなく、実運用中のMSNデータセンター(サーバ・デスクトップ・ホームマシン)から収集したLiveOpsのログ・レポートに基づく事例分析・実測である。主な分析対象データセットは次のとおり。 - 34台の本番サーバの1か月分(28日間)のPS変更トレース(Report: Critical Changesの分析基盤)。 - 5つのプロパティ・9つのlockdown期間・7か月間のlockdownレポート。 - 126台の本番サーバの1か月分の未承認プロセスレポート。 - 34台の本番サーバの1か月分の変更影響分析(Table 2)。 - 383マシン日・35台のデータセンターサーバ/企業デスクトップの機密データレポート。 - 8台のデスクトップ・20台のサーバ・42台のラボマシンを対象とした静的マニフェストとの突き合わせ(orphaned PSの測定)。 - Doom3・Microsoft Office・Microsoft SQL Server Yukon edition の3アプリケーションのインストール/アンインストール前後差分測定(ケーススタディ)。 - 350台のデスクトップ・ホーム・サーバマシンの1か月分のknown problemレポート。 - 39日間の全監視対象システムにおける新規プロセス/バイナリ/ファイル/レジストリエントリの出現率(Feasibility of Labeling All Changes)。 ## 実験結果 ### Report: Critical Changes LiveOpsは変更を9段階の優先分類(Problem・Install・Setting・Content・Management Change・Unauthorized・User Activity・Noise・Unknown)でラベル付けする。分類ルールはPS名に対する部分文字列一致で行われ、優先度の高い分類が優先される。 **Table 1: Critical changes for one month of production server logs across 34 machines showing individual changes and changes grouped by process.** | State Classification | All | Distinct | Daily Instances | Daily Distinct | Monthly Distinct | Average Per Machine Daily Distinct | |---|---:|---:|---:|---:|---:|---:| | Problem | 0 | 0 | 0 | 0 | 0 | 0 | | Install | 104,149 | 16,947 | 810 | 155 | 69 | 4 | | Configuration | 176,300 | 3,340 | 399 | 86 | 22 | 3 | | Content | 16,261,721 | 1,593,100 | 9,513 | 50 | 1 | 3 | | Management Change | 57,145 | 864 | 234 | 79 | 11 | 2 | | Unauthorized | 4,206 | 634 | 14 | 9 | 3 | 2 | | User Activity | 1,221 | 189 | 96 | 33 | 4 | 3 | | Noise | 104,109 | 1,727 | 909 | 66 | 14 | 2 | | Unknown | 39,715 | 2,613 | 534 | 60 | 13 | 3 | | TOTAL | 16,748,566 | 1,619,414 | 12,509 | 538 | 137 | 22 | (Table 1, p.192) 初期の分類ルール(分類あたり1〜20個の部分文字列ルール、28日間・34システムのトレースから設計)は、観測されたPSの99.8%(39k/16.7M以外)をカバーする。1か月間で1660万件の個別変更が160万件の distinct PS エントリに対して行われており(1エントリあたり平均10回変更)、マシンあたり平均30万件のPSエントリのうち変更されたのは16%(160万 / (30万 × 34台))にとどまる。プロセスインスタンス単位に集約するとO(10^2)、日次distinctプロセス単位ではさらにO(10^1)、確認すべき項目数を削減できる。ただし月次distinctと日次distinctを比較すると、削減効果は半分程度にとどまる。 **Figure 5: A marker for each property with at least one violation during a Lockdown period** ![[_attachments/verbowski/fig05-lockdown-violations.png]] (Figure 5. 5つのプロパティ×9つのlockdown期間のマトリクスで、各プロパティに少なくとも1件の違反があった期間をマーカーで示す。全プロパティが少なくとも1期間で違反を起こし、2プロパティは9期間中8期間で違反していた。) lockdown(変更禁止)期間中の変更を検出するレポートは、5プロパティ・9lockdown期間・7か月分を分析し、軽微な診断実行から Service Pack やアプリケーションの新規インストールといった重大な変更まで違反の幅があったことを示す。 ### Report: Unauthorized Applications 126台の本番サーバの1か月間の分析では、37システム(29%)が合計18種類の未承認プロセスを実行していた(3件は自動更新に関連するランタイム、7件はデスクトップアプリ/データ操作ツール、8件は管理者・セキュリティ専門家でも識別できなかった)。76システム(60%)は診断・設定変更に使われうる17種類のプロセスを実行しており、承認が必要と判定された。 ### Report: Change Impact Analysis **Figure 6: LiveOps detecting a web browser (iexplorer.exe) downloading and installing two new applications** ![[_attachments/verbowski/fig06-iexplorer-install-alerts.png]] (Figure 6. iexplorer.exe(Webブラウザ)が2回、msnsearchtoolbarsetup_en-us.exe(MSN Search Toolbar)とwinamp52_full_emusic-7plus.exe(Winamp Media Player)をダウンロード・インストールした日次アラートを示す。Winampはさらにemusic-7plus.exe(EMusic)を含む複数のバイナリを作成し、それが後続のインストールを引き起こした。) **Figure 7: Drill in of the process tree at the time of the installation** ![[_attachments/verbowski/fig07-process-tree-drillin.png]] (Figure 7. Figure 6のアラートを「drill in」した、インストール時点のプロセスツリーを示す。Webブラウザ起動→Winampインストーラ起動→EMusicインストーラ起動、という依存関係が可視化されている。) LiveOpsは、RPM・MSI・PackageAddといった参加型のインストール記録機構の有無に関わらず、新規バイナリの使用を検知できる。各プロセスが読み書きしたPSの一覧(manifest)を追跡し、パッチ・アプリケーションの内容と交差(intersect)することで影響を受けるプロセスを予測できる(Application Compatibility Toolkit 5.0のUpdate Impact Analyzerはこの技術の一部を利用する)。 **Table 2: Impact analysis showing the average daily global and per machine changes impacting each of the six categories of processes observed running across the 34 production servers during a one month period.** | Average Daily PS Change Type | Desktop | Developer | LOB | Management | OS | |---|---:|---:|---:|---:|---:| | Install(全マシン合計) | 2 | 182 | 56 | 168 | 25 | | Install(マシンあたり) | 2 | 124 | 23 | 95 | 5 | | Configuration(全マシン合計) | 0 | 2 | 4 | 27 | 9 | | Configuration(マシンあたり) | 0 | 2 | 2 | 10 | 1 | | Content(全マシン合計) | 0 | 8 | 37,063 | 46 | 9 | | Content(マシンあたり) | 0 | 8 | 18,112 | 22 | 6 | | Management(全マシン合計) | 0 | 0 | 1 | 59 | 5 | | Management(マシンあたり) | 0 | 0 | 1 | 59 | 6 | (Table 2, p.195) 各マシンは平均でOSアプリケーションに影響するグローバルなインストール変更163件のうち約半分(90件)しか受け取っておらず、34台が同一の変更セットを一様には受け取っていないことを示す。一方デスクトップカテゴリの2件のインストール変更は全システムに一様に適用されていた。LOB・管理アプリケーション設定・OS設定の変更のうち一様に適用されているのは半分未満である。 ### Report: Sensitive Data CSI/FBIレポート[11]は企業のセキュリティ侵害の59%が従業員に起因すると主張し、著者らが調査した匿名のセキュリティ専門家はこの割合を80〜90%に近いと見積もった。35台のデータセンターサーバ/企業デスクトップの383マシン日のログから、36件の内部文書、6件のソースコード、3件のアプリケーションがネットワーク/リムーバブルデバイスへコピーされた事例が検出された。加えて、数百件の企業ITツールによるログ持ち出しが確認された。 ### Case Study: Tracking Software Ownership **Table 3: Distribution of installations by program type for all observed installations.** | 環境 | User Setup | Script | Auto Update | Self Update | Developer | |---|---:|---:|---:|---:|---:| | Home | 7% | 7% | 51% | 35% | 0% | | Desktop | 5% | 8% | 58% | 22% | 7% | | Lab | 2% | 5% | 61% | 32% | 0% | | Server | 1% | 17% | 38% | 44% | 0% | (Table 3, p.196) 平均でマシン日の20%に少なくとも1件のインストールがあった(Home/Labは15%、Desktopは30%、Serverは変更管理ポリシーの違いにより7%〜80%と大きくばらついた)。Self Update(主にアンチウイルスの自己更新)とWindows Auto Updateが大半のインストールを占め、集中管理された企業デスクトップでも更新が同期して発生する傾向は見られなかった。 **Table 4: Average file and registry entries that are specified in manifests, implicitly in manifests, user data, or temp entries.** | 種別 | 環境 | Manifest | Implicit | Data | Temp | Unknown | |---|---|---:|---:|---:|---:|---:| | File | Desktop | 18.5% | 21.0% | 20.6% | 8.3% | 31.6% | | File | Server | 4.7% | 52.6% | 2.4% | 3.4% | 36.9% | | File | Lab | 13.2% | 5.8% | 9.5% | 1.4% | 70.1% | | Registry | Desktop | 28.2% | 32.2% | N/A | N/A | 39.6% | | Registry | Server | 10.5% | 36.4% | N/A | N/A | 53.1% | | Registry | Lab | 30.3% | 31.7% | N/A | N/A | 38.0% | (Table 4, p.197) 自作ツールでOSインストール構成ファイル・Add/Removeプログラム・Windows Installerデータベース(WI)・拡張子起動設定・パッチマニフェストからownership manifestを再構成し、実際のファイル/レジストリエントリと突き合わせた。8台のデスクトップ・20台のサーバ・42台のラボマシンで、ファイルの31〜70%・レジストリエントリの38〜53%がいずれのマニフェストにも属さない「orphan」状態だった。個別のポイント実験では、Doom3が9ファイル・418レジストリエントリ、Microsoft Officeが0ファイル・1490レジストリエントリ(加えてログインユーザーごとに129レジストリエントリ)、Microsoft SQL Server Yukon editionが57ファイル・6レジストリエントリを、アンインストール後も残した。 ### Report: Stale Processes **Figure 8: LiveOps detected that the updated tcpip.sys binary was not reloaded on the bottom two machines, therefore they are still vulnerable** ![[_attachments/verbowski/fig08-stale-tcpip-sys.png]] (Figure 8. 2006年2月28日にWindows Update(update.exe)が3台の本番サーバでtcpip.sysドライバを4:35am〜5:05amの間に更新した際、1台目のみ6時間後の10:49amにドライバを再読み込みし、残る2台はレポート閲覧時点(パッチ適用から24時間以上経過)でも古い脆弱なバイナリをメモリ上で使い続けていたことを示す。) LiveOpsは、プロセスが読み込んだPSと実際に書き込まれたPSを相関させることで、5分以内に更新されたPSを再読み込みしていないプロセスを stale process として検知する。34台の1か月間の観測では、OS・Management・LOBの各プロセスがソフトウェアバイナリ更新や管理設定変更から20時間以上staleな状態にあった例が複数見つかった。 ### Query Interface: Forensics and Troubleshooting LiveOpsは、アプリケーションが1秒あたり240回もレジストリエントリ(`\HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Strong Cryptographic Provider`)を読み続けていた性能問題や、ある商用管理製品エージェントが`\HKLM\System\CurrentControlSet\Services\`配下の全レジストリエントリを継続的にポーリングしていた事例を発見した。両ケースともRegNotifyChangeKeyValue関数によるイベント駆動の変更通知への切り替えを開発者に提案した。 ### Report: Detecting Known Problems 約100件のアサーション(Strider[36]、PC fragility研究[9]、MSN管理者が特定した重要なレジストリエントリに由来)からなるknown problemルールセットを、350台のデスクトップ・ホーム・サーバマシンの1か月分のレポートに適用した。ページファイル設定がnullに構成され物理メモリ枯渇時にクラッシュしていた35台のサーバ、GSM audio codec設定の欠落によりWAVファイル再生ができなかったノートPCなど、複数の実問題が発見された。 ### Scenario: Enforcing Best Practices 34台の本番システムの1か月分のログイン報告では、9システムがscrnsave.srcプロセスの検出により合計28回のスクリーンセーバー稼働(=長時間のログイン放置)を示し、1システムは11回のログインを記録した。非システムデーモン報告では、34システム全てが少なくとも1つのデーモンをマシンアカウント以外の権限で実行しており、6種類の異なるプロセス(うち5つは管理製品エージェント、1つはLOBプロセス)が特定された。 ### Feasibility of Labeling All Changes **Figure 9: Growth of new processes since the start of LiveOps data collection** ![[_attachments/verbowski/fig09-growth-new-processes.png]] (Figure 9. 学習期間は1日で、この時点で1000種類のプロセスが観測される。定常状態での新規プロセス出現率はソフトウェア更新/インストールが無い限りほぼ0である。) **Figure 10: Growth of new binaries since the start of LiveOps data collection** ![[_attachments/verbowski/fig10-growth-new-binaries.png]] (Figure 10. 学習期間は1日で、この時点で1400種類のバイナリが観測される。以降は新規インストール/パッチがある場合のみ新規バイナリが出現する定常状態に至る。) **Figure 11: Growth of new files since the start of LiveOps data collection, filtering temp entries** ![[_attachments/verbowski/fig11-growth-new-files.png]] (Figure 11. 一時ファイルを除外したうえでの新規ファイル出現率の対数グラフ。定常状態はO(10^1)。) **Figure 12: Growth of new registry entries since the start of LiveOps data collection, filtering temp entries** ![[_attachments/verbowski/fig12-growth-new-registry.png]] (Figure 12. 一時レジストリエントリを除外したうえでの新規レジストリエントリ出現率の対数グラフ。定常状態はO(10^1)で、14日目・23日目のような新規インストール/設定変更の日にスパイクする。) 39日間の全監視システムを対象とした観測では、新規プロセスの学習期間は1日(1000種類観測)、新規バイナリの学習期間も1日(1400種類観測)であり、定常状態での新規出現率は新規インストール/パッチがない限りほぼ0である。ファイル・レジストリエントリについても、一時的な乱数名のファイルを部分文字列ルールで除外すると、定常状態の新規出現率はO(10^1)にとどまり、人間が日次で妥当に評価できる規模だと結論づけている。 ## 考察 - LiveOpsの中核的な貢献は、(1) スケーラブルかつ網羅的な構成監視、(2) 組織内・全体を横断したクロスマシン/クロスタイムのベースライン分析による包括的な異常検知とルールの自己チューニング、(3) 単一バックエンドサーバで4000台超のマシンを管理できるスケーラビリティによるサービス化、の3点である。 - サービスとして運用することで、新ルールの即時展開・組織横断の知識共有・元開発者へのフィードバックという、個別インストール型の管理製品にはない利点が得られると論じる。 - 一方で、静的マニフェストの不完全性(orphaned PSが3〜7割)やstale process問題は、既存の管理・パッチ適用プロセスそのものの構造的な弱さを示す実測結果として提示されており、LiveOpsの検知能力がこうした問題を「初めて可視化した」ことの意義が強調されている。 ## 強み / 弱点・課題 - **Strengths**: アプリケーション側のログ出力・API利用に依存しない非参加型モデルにより、開発者が想定しなかった問題まで捕捉できる。MSN本番環境1149台・381台の本番サーバという大規模な実運用データに基づく複数レポート(Critical Changes・Unauthorized Applications・Change Impact Analysis・Sensitive Data・Stale Processes・Known Problems・Best Practices)を提示し、定量的な効果(ログサイズ20MB/日、1000マシン日を30分で解析、定常状態の新規出現率O(10^1))を具体的に示している。 - **Weaknesses/Limitations**: 分類ルール・known problemアサーションは人手で作成した部分文字列マッチングに依存し、未知のPS名パターンやルール保守コストについての体系的な評価は行われていない。評価はほぼ全てMSN内部の本番環境に限られ、他組織への一般化可能性は論じられているが実証はされていない。バイナリのハッシュベース識別やannotationデータベースの整備コスト(コミュニティによる継続的な貢献が前提)についての定量評価もない。 ## 関連 - 概念: [[永続状態相互作用監査]]