このガイドでは、アラートの品質を改善および最適化する方法について説明します。これは、オブザーバビリティの成熟度に関するシリーズの一部です。変更されたアラート アーキテクチャを反映し、ストックNrAiIncidentおよびNrAiIssueイベント タイプを使用するように更新されました。
概要
チームは、大量のアラートや、ビジネスへの影響に対応していないアラートを経験すると、アラート疲労に悩まされます。アラートの量が多いと、インシデント レスポンダーは、アラートが誤りであり、ビジネスに影響がないと想定するように訓練されます。その結果、他のアラートよりも解決しやすいアラートを優先するようになり、未解決のインシデントをクローズして、SLA ターゲット内にとどまることができるようになります。これにより、実際にビジネスに影響を与える問題が発生した場合、インシデントへの対応が遅くなり、範囲と重大度が増加します。
アラート品質管理(AQM) は、厄介なインシデントの数を減らすことに重点を置いているため、ビジネスに真の影響を与えるアラートのみに集中できます。これにより、アラート疲れが軽減され、チームは適切なタイミングで適切な場所に注意を向けることができます。
次の場合、あなたはAQMの有力候補です。
- アラートの数が多すぎます。
- 長時間開いたままのアラートがある。
- あなたのアラートは関係ありません。
- モニタリングツールが発見する前に、お客様が問題を発見する。
- オブザーバビリティツールの価値がわからない。
望ましい結果
ビジネスへの影響の測定に基づくアラート戦略を使用することで、応答時間を短縮し、重要なイベントに対する認識を高めることができます。アラートの信号対雑音比を改善すると、混乱が減り、問題の根本原因を迅速に特定して分離できるようになります。
アラート品質管理の全体的な目標は、作成されるインシデントの数を減らし、より価値のあるものにすることです。これにより、次のようになります。
- アップタイムと可用性の向上
- 平均解決時間 (MTTR) の短縮
- 警報音量の低下
- 価値のないアラートを簡単に識別できるので、価値のあるものにするか、削除することができます。
このガイドでは、これらの目標に向けた進捗状況を測定するために使用する主要業績評価指標を生成するプロセスについて順を追って説明します。KPI はリアルタイムで測定され、ダッシュボードに公開され、迷惑アラートを特定して削減し、インシデント調査への関与を高めるために使用する継続的な改善プロセスを推進するために使用されます。
アラートの品質管理の実践には、未知または予期しない障害モードを検出するように設計された異常検出または AIOps は含まれません。2 つのプラクティス (AQM と ML/AI) は連携して機能し、相互に排他的ではありません。
主要業績評価指標
注: この実装ガイドの以前のリリースでは、必要な KPI を収集するために Webhook によって生成されたカスタム イベント ( NrAQMIncident ) に依存していました。その依存関係が変わりました。AQM は、代わりにデフォルトのNrAiIncidentおよびNrAiIssueイベント タイプを使用するようになりました。詳細については、 AQM 移行ガイドのセクションを参照してください。
AQM プロセスを使用して、インシデントの量とエンゲージメントの KPI を収集して測定します。
インシデントボリューム。これには次のものが含まれます。
- インシデント数
- 累積インシデント時間
- 平均終了時間（MTTC）
- 5分未満の割合
インシデント エンゲージメントには次のものが含まれます。
- 調査する平均時間（MTTI）
- 調査したインシデントの割合
これらの KPI は、最もノイズが多く、価値の低いアラートを見つけるのに役立ち、その価値を向上させたり、それらを排除したりできます。次に、長期的な指標の傾向を使用して、経営陣と利害関係者に対する実際のビジネス インパクトを示します。
これらの指標に関する詳細情報は次のとおりです。
インシデント量
インシデント (アラートの有無にかかわらず) は、タスクのキューのように扱う必要があります。キューと同様に、アラートの数はゼロに近い時間を費やす必要があります。各インシデントは、状態を解決するための調査または是正措置のトリガーとなる必要があります。アラートによってなんらかのアクションが発生しない場合は、アラート条件の値を疑問視する必要があります。
特に、「常にオン」になっている特定のインシデントが見られる場合は、その理由を疑問視する必要があります。常にビジネスに影響を与えている状態ですか、それとも単にノイズが多いだけですか?アラート ボリューム KPI は、これらの質問に答え、高品質のアラートの健全な状態に向けた進捗状況を測定するのに役立ちます。
ユーザーエンゲージメント
インシデントの価値は、それが受ける注目の量によって測定する必要があります。ここでは、インシデントが認識されたかどうかによってエンゲージメントを測定します。
個々のアラートが受け取るエンゲージメントの量は、その値の直接的な測定値です。より多くの関与は、貴重な警告を意味します。エンゲージメントが少ない（またはゼロ）ということは、変更または無効にする必要のある迷惑アラートを意味します。
インシデント認識の瞬間を測定することと、解決活動が開始された瞬間を認識することの間には大きな違いがあります。New Relic アラートとの統合を使用している場合は、New Relic に送信される「承認」イベントが、インシデントが外部のインシデント管理ツールに送信されたときではなく、解決アクティビティが開始されたときにトリガーされることを確認してください。
標準的なインシデント管理プロセスの詳細については、「インシデント管理プロセス: 効果的な解決への 5 つのステップ、OnPage Corporation によって 2020 年 8 月 31 日に投稿されました。ITIL4を参照して」を参照してください。
前提条件
始める前に、同等の経験がない場合は、 New Relic University（NRU）の概要コースを完了してください。
また、少なくとも次の基本的な知識が必要です。
NewRelicアラートポリシーと条件の構成
NRQL（クエリ言語）
アラートのベストプラクティス
ニューレリック
およびインフラストラクチャの監視
異常と正常な動作を判断するためにデータをベースライン化する方法
現在の状態を確立する
継続的な改善プロセスと同様に、AQM の最初のステップは、KPI の現在の状態を確立することです。これを行うには、次のタスクを実行します。
注: この実装ガイドの以前のリリースでは、必要な KPI を収集するために Webhook によって生成されたカスタム イベント ( nrAQMIncident ) に依存していました。その依存関係が変わりました。AQM は、代わりにデフォルトのNrAiIncidentおよびNrAiIssueイベント タイプを使用するようになりました。詳細については、 AQM 移行ガイドのセクションを参照してください。
AQMダッシュボードのインストール
AQM ダッシュボードは、AQM プロセスを推進する主要な資産です。次の手順に従って、クイックスタート ライブラリから AQM ダッシュボードをインストールする必要があります。
- Alert Quality Management のインスタント オブザーバビリティ ページに移動します。
- [今すぐインストール]ボタンをクリックします。
- プロンプトに従って、ダッシュボードをインストールするアカウントを選択します。
- ダッシュボードを表示します。
JSON ダッシュボードの定義は、GitHub のオブザーバビリティ成熟度リソース センターでも入手できます。 .このバージョンは、クイックスタートにあるものと同じです。GitHub バージョンを使用する場合は、次の手順を実行します。
- ダッシュボードをインポートするアカウントの ID を反映するようにaccountIdプロパティを更新します。そのプロパティには、0000000 から正しいアカウント ID に更新する必要がある 13 のインスタンスがあります。
- 定義をアカウントにインポートします。
ダッシュボードのインポートの詳細については、ダッシュボードの概要を参照してください。
イベント量の KPI を分析する
ダッシュボードをインストールしたら、すぐにそれを使用して 4 つのイベント ボリューム KPI を分析できます。
ダッシュボードの[ポリシーごとのアラート数]ペインを使用して、インシデント数が多い、累積インシデント期間が長い、MTT クローズが長い、または 5 分未満のオープン インシデントの割合が高いポリシーを見つけます。特に、ポリシーを特定する必要があります。
- 「常時」インシデントを生成する (つまり累積期間が数千分以上のインシデント)。
- インシデントの 30% 以上が 5 分未満で開かれている場合。
- MTT-close が 30 分を超えている。
- これにより、1 週間に 350 件以上のインシデントが発生します。
これらの基準の 1 つ以上に適合する上位 4 つのポリシーを特定し、ポリシーの条件を確認し、結果のインシデントの詳細を調べてパターンを判断する必要があります。次に、それらのポリシーを作成したチームと、それらのポリシーのインシデントに対応するチームが AQM 有効化プロセスに参加するようにする必要があります。
初期のAQMオリエンテーションとイネーブルメントの実施
このフェーズでは、インシデント管理チームと他の利害関係者は、AQM プロセスの目標、プロセスへの関与の範囲を学び、イベント ボリューム分析ステップで特定したポリシーの最初のレビューに参加します。
最初のセッション テンプレート プレゼンテーションを使用して、この資料を関係者に伝えることができます。
AQM ダッシュボードは、継続的な改善プロセスの開始点として使用する必要があるインシデント ボリューム KPI の初期ベースラインを提供します。さらに、上位 4 つの最も厄介なインシデント ポリシーをより価値のあるものに変更する方法について、適切なチームと話し合う必要があります。ノイズの多いポリシーを確認するときは、各ポリシーについて次の順序で質問する必要があります。
- アラートは、修正が必要なリソースについて何かを伝えていますか?その場合は、問題を修正し、アラートの音量が減少するかどうかを確認します。
- アラートは、実際に即時の対応が必要なことを示していますか?そうでない場合は、ポリシーを調整または無効にします。
- ポリシーのしきい値は適切に設定されていますか?そうでない場合は、しきい値の調整を検討してください。
このタスクの最も重要な部分の 1 つは、アラートの値が決定される方法であるため、インシデント アラートを確認することの重要性についてチームを教育することです。一般に、次のガイドラインに従うように指示します。
- アラートを見て、さらに調査を行うことを決めた場合は、アラートを確認してください。
- 通常、何もせずにアラートを閉じる場合は、アラートを確認しないでください。
- インシデントアラートが常にオンになっている場合は、それを閉じたり確認したりしないでください。詳細については、 2回目の有効化セッションを参照してください。
エンゲージメント データの蓄積
アラート エンゲージメントを測定するプロセスを進めるには、少なくとも 2 週間分のデータが必要です。この間、インシデント レスポンダーが最初の有効化セッションで概説されたアラート確認ガイドラインに従っているかどうかを定期的に確認する必要があります。
2回目のイネーブルメントセッションの実施
2 回目の有効化セッションは、最初のセッションの 2 週間後に実行する必要があります。このフェーズでは、インシデント管理チームやその他の利害関係者に、AQM 傾向データと継続的な継続的改善プロセスを紹介します。
このプロセスは4つのアクティビティで構成されています。
- AQMダッシュボードとKPIの傾向を確認する：ここでは、あなたと利害関係者がAQM KPIを確認し、週ごとの傾向を特定します。チームは、KPIが改善されていない領域を特定し、改善を推進するための戦略を策定する必要があります。
- 成果、課題、および機会を特定する：ここでは、アラートの品質の現在の状態をビジネスへの影響にマッピングし、改善によってビジネスの成果が向上した領域と、問題がビジネスの成果に影響を与えている領域を特定します。
- インシデントポリシーのレビュー：AQMダッシュボードを使用して、あなたと利害関係者は最もノイズの多いインシデントポリシーを特定します。識別されたら、これらのポリシーは、以下のステップ4で詳しく説明されているように評価する必要があります。
- アラートポリシーの推奨事項：このステップでは、あなたと利害関係者は、次の基準を使用して最もノイズの多いポリシーを確認します。
アラートはビジネスに影響を与えるか？
ポリシーは正しく設定されていますか？
- リソースの修正点を教えてくれているのでしょうか？
- そのポリシーは必要か？ビジネスに影響を与えるか？
- しきい値は適切に設定されているか？
技術的な推奨事項ここでは、あなたと関係者が、以下のような技術的提案を検討します。
- エンジニアリングが検討すべきアプリケーション/システムの問題はありますか？
- 修正しなければならない不十分な政策があるのか？
- インストルメントギャップはありますか？
2 番目のセッション テンプレート プレゼンテーションを使用して、AQM プロセスのこの部分を整理しておくことができます。
このフェーズでは、最初の有効化セッションで特定した 4 つの最も厄介なポリシーを確認し、それらの KPI がどのように改善されたかを強調することで、AQM の価値を示す機会を利用する必要もあります。
改善プロセス
これは継続的な改善プロセスの進行中のフェーズであり、蓄積された AQM データを定期的に確認し、必要に応じて調整を行ってポリシーを警告します。アラートの量が許容範囲内になるまで、この手順を毎週または隔週で実行する必要があります。その後、実行する頻度を減らすことができます。
この段階では、あなたは
- KPI を毎週上級管理職に報告して、利害関係者チームが適切に作業の優先順位を付け、約束されたビジネス成果に向けた進捗状況を示すようにします。
- 数ヶ月から数年にわたり、毎週のKPIを記録・保存し、基準値を設定し、改善率を表示します。
これは継続的な改善プロセスであることを覚えておいてください。AQM の目標を確実に達成するために、長期間にわたって KPI の収集と評価を続けます。
価値の実現
AQMプロセスが確立されると、信頼性と安定性が変わらない、または向上する一方で、アラートの量が大幅に減少することがわかります。さらに、アラートが明確かつ明確なビジネス・インパクトを持つようになります。AQMのKPIは、これらの改善を定量的に証明します。
このプロセスは、アラートの作成者が新しいアラート ポリシーが応答者に与える影響をよりよく理解し、アラートの作成者がより意味のあるアラート ポリシーを作成するのにも役立ちます。
AQMの目標を確実に達成するための道を進んだら、 サービスレベル管理や信頼性エンジニアリングなど、稼働時間、パフォーマンス、信頼性のバリューストリーム内の他のユースケースに移行することを検討してください。 カスタマーエクスペリエンスなど、他の可観測性成熟度バリューストリームに移動することもできます。
KPI参照
以下は、各KPIの説明と、NewRelicプラットフォームからそれらを抽出するサンプルNRQLクエリです。これらのKPIは、GitHubの可観測性成熟度リソースセンターからダウンロードできるAQMダッシュボードにも含まれています。
インシデント量
インシデント・エンゲージメント
追加リソース
お客様のアカウントに導入する前に、手を動かしてみませんか？ alert quality management labをご覧ください。
AQM 移行ガイド
AQM の最初のリリースでは、nrAQMIncident というカスタム イベントを利用してプロセスを推進していました。nrAQMIncident イベントは、アカウントの各アラート ポリシーに関連付けられた Webhook によって生成され、インシデント ボリュームとエンゲージメント KPI の両方を生成しました。
AQM の現在のバージョンでは、自動的に生成されるNrAiIncidentとNrAiIssueの 2 つのデフォルト イベントを使用します。
AQM のオリジナル リリースで使用されていた従来の Webhook メソッドは、2023 年 1 月に廃止される予定です。その前に、新しい方法論に移行する必要があります。組織が初めて AQM を採用する場合は、新しいNrAiIncidentベースの方法論を使用する必要があります。
移行するときは、次の点に注意する必要があります。
- 既存の AQM ダッシュボードは、NrAiIncident / NrAiIssue イベントを使用する新しい AQM ダッシュボードに置き換える必要があります。
- インシデント ボリューム KPI を生成するには NrAiIssue イベントが必要であり、インシデント エンゲージメント KPI を生成するには NrAiIncident イベントが必要です。
- nrAQMIncident から NrAiIncident に移行すると、KPI の数値が大幅に変化します。これは、NrAiIncident イベントがしきい値違反の発生回数を追跡するのに対し、nrAQMIncident イベントはアラート通知を追跡するためです。数値は変化していますが、KPI との基本的な関係およびそれらの間の相対値は変化していません。混乱のリスクを軽減するために、これについて AQM 参加者を教育する必要があります。
移行が完了したら、AQM Webhook と古いダッシュボードを無効化または削除できます。