# ビジネスモニタリング ## 定義 ビジネスモニタリング(Business Monitoring)は、インフラストラクチャやシステムの内部メトリクス（CPU、JVM、ネットワーク帯域等）ではなく、ビジネス KPI（トランザクション数、成功率、応答時間、障害数等）を一次的なモニタリングシグナルとして扱い、障害の顧客影響を定量的に把握する手法。Alibaba の GOC は 4 層モニタリング構造（インフラストラクチャ → システム/アプリケーション → ビジネス → 顧客フィードバック）のなかでビジネス層を最重要と位置づけ、「顧客に最も近く、影響度を明確な数値で表現できる」ことを根拠とする([[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 ビジネスモニタリングでは、各ビジネス機能を **5 つのゴールデンエレメント**——総数(total count)、成功数(success count)、成功率(success rate)、応答時間(response time)、失敗数(failure count)——で統合的に表現する。この 5 要素の組み合わせにより、モニタリング担当者は「顧客側で何が起きているか」をシステム内部の状態を介さずに把握できる。CMDB [[Hammurabi]] がビジネス機能と KPI の対応関係と優先度定義（P1〜P4）を管理し、アラーム発生時に自動的にビジネス影響と担当者を特定する。 ## 横断的知見 - （1 ソース目のため、横断的知見は次の関連ソース追加時に育てる。） ## 未解決の問い - Alibaba の「5 ゴールデンエレメント」は Google SRE の Four Golden Signals（レイテンシ、トラフィック、エラー、サチュレーション）とどう対応し、どう異なるか。Alibaba のフレームワークはビジネストランザクション単位の「成功数/失敗数」を明示する点で、Four Golden Signals のシステムレベルの抽象化よりも顧客影響の直接表現に寄っている可能性がある。 - ビジネス層のモニタリングが「最重要」であるという Alibaba の位置づけは、[[オブザーバビリティ]] の文脈でどう評価されるか。オブザーバビリティはログ・メトリクス・トレースの統合を志向するが、ビジネスモニタリングは「ビジネス層のメトリクスだけで障害影響を十分に把握できる」と主張する。これは層の優先度の問題か、それとも多層統合の不要性の主張か。 - [[Hammurabi]] のような CMDB ベースのビジネス機能登録は、マイクロサービスの動的トポロジ変化に追従できるか。2018 年時点のモノリシック寄りなアーキテクチャでの知見が、2020 年代のクラウドネイティブ環境にそのまま適用できるかは未検証。 ## 関連 - ソース: [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]] - エンティティ: [[Hammurabi]]、[[Alibaba Group]] - 関連概念: [[アラート管理]]、[[オブザーバビリティ]]、[[サービスレベル目標]]、[[異常検知]] - 関連 MOC: [[structures/000 Index.md|000 Index]] ## 出典 - [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]]（4 層モニタリング構造、5 ゴールデンエレメント、Hammurabi、P1〜P4 優先度定義、次元分析、変更連携——transcript 全体 + frame-003/006/010/012）