• ログイン今すぐ開始

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

アラート品質管理:アラートを最適化し、アラートの疲労を軽減します

このガイドでは、アラートの品質を改善および最適化する方法について説明します。これは、オブザーバビリティの成熟度に関するシリーズの一部です。変更されたアラート アーキテクチャを反映し、ストック NrAiIncident イベント タイプを使用するように更新されました。

概要

チームは、大量のアラートや、ビジネスへの影響に対応していないアラートを経験すると、アラート疲労に悩まされます。アラートの量が多いと、インシデント レスポンダーは、アラートが誤りであり、ビジネスに影響がないと想定するように訓練されます。その結果、他のアラートよりも解決しやすいアラートを優先するようになり、未解決のインシデントをクローズして、SLA ターゲット内にとどまることができるようになります。これにより、実際にビジネスに影響を与える問題が発生した場合、インシデントへの対応が遅くなり、範囲と重大度が増加します。

アラート品質管理(AQM) は、厄介なインシデントの数を減らすことに重点を置いているため、ビジネスに真の影響を与えるアラートのみに集中できます。これにより、アラート疲れが軽減され、チームは適切なタイミングで適切な場所に注意を向けることができます。

次の場合、あなたはAQMの有力候補です。

  • アラートの数が多すぎます。
  • 長時間開いたままのアラートがある。
  • あなたのアラートは関係ありません。
  • モニタリングツールが発見する前に、お客様が問題を発見する。
  • オブザーバビリティツールの価値がわからない。

これは、アラート品質管理の概念の概要を示す短いビデオ(3:34)です。

望ましい結果

ビジネスへの影響の測定に基づくアラート戦略を使用することで、応答時間を短縮し、重要なイベントに対する認識を高めることができます。アラートの信号対雑音比を改善すると、混乱が減り、問題の根本原因を迅速に特定して分離できるようになります。

アラート品質管理の全体的な目標は、作成されるインシデントの数を減らし、より価値のあるものにすることです。これにより、次のようになります。

  • アップタイムと可用性の向上
  • MTTRの短縮
  • 警報音量の低下
  • 価値のないアラートを簡単に識別できるので、価値のあるものにするか、削除することができます。

このガイドでは、これらの目標に向けた進捗状況を測定するために使用する主要業績評価指標を生成するプロセスについて順を追って説明します。KPI はリアルタイムで測定され、ダッシュボードに公開され、迷惑アラートを特定して削減し、インシデント調査への関与を高めるために使用する継続的な改善プロセスを推進するために使用されます。

アラートの品質管理の実践には、未知または予期しない障害モードを検出するように設計された異常検出または AIOps は含まれません。2 つのプラクティス (AQM と ML/AI) は連携して機能し、相互に排他的ではありません。

主要業績評価指標

注: この実装ガイドの以前のリリースは、必要な KPI を収集するために Webhook によって生成されたカスタム イベント ( nrAQMIncident ) に依存していました。その依存関係が変わりました。AQM は、代わりにデフォルトのNrAiIncidentイベント タイプを使用するようになりました。NrAiIncidentはまだインシデント エンゲージメント KPI を公開していないため、インシデント エンゲージメントへのすべての参照が AQM から削除されました。詳細については、 AQM 移行ガイドのセクションを参照してください。

AQM プロセスを使用して、インシデント ボリューム KPI を収集および測定します。これらの KPI は、最もノイズが多く、価値の低いアラートを見つけるのに役立ち、その価値を向上させたり、それらを排除したりできます。次に、長期的な指標の傾向を使用して、経営陣と利害関係者に対する実際のビジネス インパクトを示します。

インシデント (アラートの有無にかかわらず) は、タスクのキューのように扱う必要があります。キューと同様に、アラートの数はゼロに近い時間を費やす必要があります。各インシデントは、状態を解決するための調査または是正措置のトリガーとなる必要があります。アラートによってなんらかのアクションが発生しない場合は、アラート条件の値を疑問視する必要があります。

特に、「常にオン」になっている特定のインシデントが見られる場合は、その理由を疑問視する必要があります。常にビジネスに影響を与えている状態ですか、それとも単にノイズが多いだけですか?アラート ボリューム KPI は、これらの質問に答え、高品質のアラートの健全な状態に向けた進捗状況を測定するのに役立ちます。

これらの指標に関する詳細情報は次のとおりです。

前提条件

始める前に、同等の経験がない場合は、 New Relic University(NRU)の概要コースを完了してください。

また、少なくとも次の基本的な知識が必要です。

  • NewRelicアラートポリシーと条件の構成
  • NRQL(クエリ言語)
  • アラートのベストプラクティス
  • NewRelicAPMとインフラストラクチャの監視
  • 異常と正常な動作を判断するためにデータをベースライン化する方法

現在の状態を確立する

継続的な改善プロセスと同様に、AQM の最初のステップは、KPI の現在の状態を確立することです。これを行うには、次のタスクを実行します。

注: この実装ガイドの以前のリリースは、必要な KPI を収集するために Webhook によって生成されたカスタム イベント ( nrAQMIncident ) に依存していました。その依存関係が変わりました。AQM は、代わりにデフォルトのNrAiIncidentイベント タイプを使用するようになりました。詳細については、 AQM 移行ガイドのセクションを参照してください。

AQMダッシュボードのインストール

AQM ダッシュボードは、AQM プロセスを推進する主要な資産です。次の手順を実行して、AQM ダッシュボードをインストールする必要があります。

  1. GitHubの可観測性成熟度リソースセンターからダッシュボード定義JSONファイルをダウンロードします。
  2. ダッシュボードをインポートするアカウントの ID を反映するようにaccountIdプロパティを更新します。そのプロパティには、0000000 から正しいアカウント ID に更新する必要がある 13 のインスタンスがあります。
  3. 定義をアカウントにインポートします。

ダッシュボードのインポートの詳細については、ダッシュボードの概要を参照してください。

イベント量の KPI を分析する

ダッシュボードをインストールしたら、すぐにそれを使用して 4 つのイベント ボリューム KPI を分析できます。

ダッシュボードの[ポリシーごとのアラート数]ペインを使用して、インシデント数が多い、累積インシデント期間が長い、MTT クローズが長い、または 5 分未満のオープン インシデントの割合が高いポリシーを見つけます。特に、ポリシーを特定する必要があります。

  • 「常時」インシデントを生成する (つまり累積期間が数千分以上のインシデント)。
  • インシデントの 30% 以上が 5 分未満で開かれている場合。
  • MTT-close が 30 分を超えている。
  • これにより、1 週間に 350 件以上のインシデントが発生します。

これらの基準の 1 つ以上に適合する上位 4 つのポリシーを特定し、ポリシーの条件を確認し、結果のインシデントの詳細を調べてパターンを判断する必要があります。次に、それらのポリシーを作成したチームと、それらのポリシーが作成したインシデントに対応するチームが AQM 有効化プロセスに参加するようにする必要があります。

初期のAQMオリエンテーションとイネーブルメントの実施

このフェーズでは、インシデント管理チームと他の利害関係者は、AQM プロセスの目標、プロセスへの関与の範囲を学び、イベント ボリューム分析ステップで特定したポリシーの最初のレビューに参加します。

最初のセッション テンプレート プレゼンテーションを使用して、この資料を関係者に伝えることができます。

AQM ダッシュボードは、継続的な改善プロセスの開始点として使用する必要があるインシデント ボリューム KPI の初期ベースラインを提供します。さらに、上位 4 つの最も厄介なインシデント ポリシーをより価値のあるものに変更する方法について、適切なチームと話し合う必要があります。ノイズの多いポリシーを確認するときは、各ポリシーについて次の順序で質問する必要があります。

  1. アラートは、修正が必要なリソースについて何かを伝えていますか?その場合は、問題を修正し、アラートの音量が減少するかどうかを確認します。
  2. アラートは、実際に即時の対応が必要なことを示していますか?そうでない場合は、ポリシーを調整または無効にします。
  3. ポリシーのしきい値は適切に設定されていますか?そうでない場合は、しきい値の調整を検討してください。

2回目のイネーブルメントセッションの実施

2 回目の有効化セッションは、最初のセッションの 2 週間後に実行する必要があります。このフェーズでは、インシデント管理チームやその他の利害関係者に、AQM 傾向データと継続的な継続的改善プロセスを紹介します。

このプロセスは4つのアクティビティで構成されています。

  1. AQMダッシュボードとKPIの傾向を確認する:ここでは、あなたと利害関係者がAQM KPIを確認し、週ごとの傾向を特定します。チームは、KPIが改善されていない領域を特定し、改善を推進するための戦略を策定する必要があります。
  2. 成果、課題、および機会を特定する:ここでは、アラートの品質の現在の状態をビジネスへの影響にマッピングし、改善によってビジネスの成果が向上した領域と、問題がビジネスの成果に影響を与えている領域を特定します。
  3. インシデントポリシーのレビュー:AQMダッシュボードを使用して、あなたと利害関係者は最もノイズの多いインシデントポリシーを特定します。識別されたら、これらのポリシーは、以下のステップ4で詳しく説明されているように評価する必要があります。
  4. アラートポリシーの推奨事項:このステップでは、あなたと利害関係者は、次の基準を使用して最もノイズの多いポリシーを確認します。
  • アラートはビジネスに影響を与えるか?

  • ポリシーは正しく設定されていますか?

    • リソースの修正点を教えてくれているのでしょうか?
    • そのポリシーは必要か?ビジネスに影響を与えるか?
    • しきい値は適切に設定されているか?
  1. 技術的な推奨事項ここでは、あなたと関係者が、以下のような技術的提案を検討します。

    • エンジニアリングが検討すべきアプリケーション/システムの問題はありますか?
    • 修正しなければならない不十分な政策があるのか?
    • インストルメントギャップはありますか?

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 と呼ばれるデフォルトのイベントを使用しますが、インシデント エンゲージメントは生成しません (つまり、MTT-Investigate および調査されたパーセント) KPI。

エンゲージメント KPI が重要な場合は、Webhook ベースの方法論を引き続き使用する必要があります。Webhook のメンテナンス タスクによって手間がかかりすぎる場合は、新しい (NrAiIncident) 方法に移行できます。組織が初めて AQM を採用する場合は、新しいNrAiIncidentベースの方法論を使用する必要があります。

移行を選択する場合は、次の点に注意する必要があります。

  • 既存の AQM ダッシュボードは、NrAiIncident イベントを使用する新しい AQM ダッシュボードに置き換える必要があります。
  • nrAQMIncident から NrAiIncident に移行すると、KPI の数値が大幅に変化します。これは、NrAiIncident イベントがしきい値違反の発生回数を追跡するのに対し、nrAQMIncident イベントはアラート通知を追跡するためです。数値は変化していますが、KPI との基本的な関係およびそれらの間の相対値は変化していません。混乱のリスクを軽減するために、これについて AQM 参加者を教育する必要があります。
  • インシデント エンゲージメント KPI は表示されなくなります。

移行が完了したら、AQM Webhook と古いダッシュボードを無効化または削除できます。

Copyright © 2022 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.