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