サービス配信を包括的にカバーすることで、顧客向けのアプリケーションとサービスに監視アラートが設定され、ユーザー体験やビジネス運営に影響を与える可能性のある問題を検出できるようになります。
このスコアカードルールについて
このサービス提供包括範囲ルールは、ビジネス稼働時間成熟度モデルのレベル 1 (リアクティブ) の一部です。 顧客に関連する問題が発生したときに通知するように、アプリケーションとサービスに基本的なアラートが構成されていることを確認します。
これが重要である理由:サービス提供の問題は、顧客体験とビジネス収益に直接影響します。適切なアプリケーションのアラートがないと、顧客が報告したときに初めて問題が発見され、サービス停止が長引いたり、顧客との関係が損なわれたりする可能性があります。
このルールの仕組み
このルールは、サービス配信エンティティを調べて、アラート条件が定義されているかどうかを確認します。具体的には、次のアラートを探します。
- APM - APPLICATIONエンティティ: APMエージェントによるバックエンド アプリケーションとサービスのモニター
- BROWSER-APPLICATION エンティティ:フロントエンド Web アプリケーション モニター by ブラウザ監視
- MOBILE-APPLICATIONエンティティ:モバイル監視によるモバイルアプリモニター
- SYNTH-MONITOR エンティティ: ユーザーのインタラクションをシミュレートする合成モニター
監視サービス配信エンティティに少なくとも 1 つのアラート条件が欠けている場合、ルールは失敗します。
スコアを理解する
- 合格（緑）：すべてのサービス提供エンティティに少なくとも1つのアラート条件が定義されている
- 失敗 (赤): 1 つ以上のサービス配信エンティティの包括的カバレッジが不足しています
- 目標:すべての顧客向けアプリケーションとサービスを 100% 一括カバー
これが意味するもの:
- 合格点:顧客に影響を与える問題を検出するためのアプリケーション監視基盤が整備されている
- 不合格スコア:一部のアプリケーションまたはサービスは、チームに警告することなく障害が発生する可能性があり、顧客に影響を与える可能性があります。
サービス提供を改善する方法 包括範囲
スコアにサービス提供アラートの欠落が表示されている場合は、包括的なカバレッジを確立するために次の手順に従ってください。
1. カバーされていないサービスを特定する
- 失敗したエンティティを確認します。包括的な対象範囲が不足している特定のアプリケーションまたはサービスを特定します。
- 顧客への影響による優先順位付け:顧客対応アプリケーションと収益に重要なサービスに最初に重点を置く
- サービスの重要度を評価する:即時アラートと遅延アラートが必要なサービスを決定する
2. 重要なサービス提供アラートを設定する
エンティティ タイプに基づいて、これらの重要なメトリクスのアラートを構成します。
APM アプリケーションアラート:
- エラー率:エラー率が5分間で5%を超えた場合の集計
- 応答タイム:平均応答時間が許容許容値を超えた場合 (例: >2 秒)
- スループット:リクエスト量が大幅に減少し、停止の可能性を示す場合に集中
- Apdex スコア:ユーザー満足度スコアが許容レベルを下回った場合の集計 (例: 0.8 未満)
Browser :
- JavaScript エラー:フロントエンドのエラー率が急上昇した場合の集計
- ページロードタイム: ページロードタイムがユーザー体験閾値を超えたときの累計
- Core Web Vitals : Largest Contentful Paint や Cumulative Layout Shift などのメトリクスが劣化したときの集計
- ユーザー セッション:アクティブ ユーザー セッションが予期せずドロップした場合の集計
モバイルアプリケーションのアラート:
- クラッシュ率:アプリのクラッシュ率が 1 ～ 2% を超えた場合の分割
- ネットワークエラー:ネットワークリクエストの失敗が急増したときの集計
- アプリのリリース時間:アプリの起動時間が許容できなくなったときの集計
- ユーザーインタラクション:ユーザーの主要なアクション (ログイン、購入) が頻繁に失敗する場合の集計
合成モニターのアラート:
- 監視失敗:合成チェックが失敗した場合に即座に集計
- パフォーマンスの低下:合成パフォーマンスタイムが大幅に増加した場合の分割
- 可用性:稼働時間がSLA要件を下回った場合 (例: 99.9% 未満)
- 複数の場所での障害:複数の場所で同じ問題が発生した場合
3. アラートを効果的に設定
適切な閾値を設定します。
- 過去のパフォーマンスデータとビジネス要件に基づく閾値
- 環境に応じて異なる閾値を使用する（生産環境はより敏感であるべき）
- 応答時間とエラー率の値を設定するときは、ユーザー エクスペリエンスへの影響を考慮してください。
適切な評価ウィンドウを選択します。
- ユーザーが直面する重大な問題には、より短い時間枠（2～5 分）を使用します。
- パフォーマンスの傾向が確立されるまでに時間を要する場合は、より長いウィンドウ（10～15分）を使用します。
- 一時的な変動でトリガーされるような短いウィンドウは避ける
4. インシデント対応手順を確立する
- 通知チャネルの定義: Slack、 PagerDuty 、または電子メールとの統合をセットアップする
- 責任チームの割り当て:問題を診断して修正できるチームにアラートが確実に届くようにします。
- エスカレーション パスの作成: SLA の期間内にアラートが確認されない場合に何が起こるかを定義します。
- 対応手順のテスト:チームがアラートの問題に実際に対応して解決できることを確認します。
改善の測定
これらのメトリクスを追跡して、サービス提供範囲の改善を検証します。
- カバレッジ率: AI モニタリングによる本番アプリケーションとサービスの 100% 包括カバレッジ
- 平均検出時間（MTTD）：アラートが顧客に影響を与える問題をどれだけ早く特定するかを測定する
- 総合精度:アクションが必要な真の問題を表すアラートの割合を監視します
- 顧客への影響の軽減:より迅速な検出が顧客に直面する停止の短縮につながるかどうかを追跡します。
一般的なシナリオと解決策
レガシーまたは未使用のアプリケーション:
- 問題:古いアプリケーションは監視対象として表示されますが、顧客にサービスを提供しなくなりました
- 解決策:使用されていないアプリケーションを監視から削除するか、非推奨としてタグ付けしてカバレッジ要件から除外します。
開発およびテスト環境:
- 問題:非実稼働アプリケーションの乱雑さ 集約カバレッジ メトリクス
- 解決策:タグまたは命名規則を使用して環境を分離し、カバレッジルールを本番サービスに集中させる
マイクロサービスアーキテクチャー:
- 問題:小規模なサービスが多く、100% のカバレッジを達成し維持することが困難です。
- 解決策:顧客向けサービスと重要な依存関係を優先し、サービスマップを使用して主要コンポーネントを特定します。
サードパーティの依存関係:
- 問題:外部サービスは制御できないが、アプリケーションに影響を与える
- 解決策:合成モニターを作成して重要なサードパーティ統合と API をテストする
高度な考慮事項
カバレッジルールのカスタマイズ
次の場合には、スコアカード ルールを調整する必要があります。
- さまざまなサービス タイプ:アーキテクチャーには他のエンティティ タイプ ( Lambda関数、データベース、メッセージキュー) が含まれています
- ビジネス重要度レベル:一部のサービスは他のサービスよりも重要度が高く、異なる集計戦略が必要です。
- デプロイメント パターン: Canary デプロイメントまたは青緑色のデプロイメントは、カバレッジに一時的に影響を与える可能性があります
一括調整と依存関係
複雑なサービスのアーキテクチャー:
- サービスの依存関係:上流のサービス障害を考慮してアラートを設定する
- まとめ相関関係:インシデント中の通知嵐を避けるためのグループ関連アラート
- インテリジェントアラート:機械学習機能を使用して誤検知を減らし、信号品質を向上させます
重要な考慮事項
- 顧客への影響に焦点を当てる:顧客エクスペリエンスに直接影響する問題についてアラートを優先します。
- カバー範囲と品質のバランス:包括的なカバー範囲によってアラート疲れが生じないようにする
- 定期的なメンテナンス:アプリケーションの進化に合わせてアラート条件を確認し更新します
- チーム間の調整:開発チームと運用チームが集計戦略に関して確実に連携できるようにする
次のステップ
- 即時の対応:現在カバーされていないサービスについて、基本的なアラートを設定する
- 継続的な監視:サービスの変更に応じてカバレッジを維持するために、このスコアカードのルールを毎週確認してください。
- 品質の向上:全体の有効性と誤検知の削減に焦点を当てる
- レベル2に進む:サービス提供のアラートが確立されたら、 プロアクティブな監視の実践に焦点を当てます。
アプリケーション監視のセットアップに関する詳細なガイダンスについては、 APM 、ブラウザ監視、モバイル監視、および 外形監視のドキュメントを参照してください。