概要
チームは、大量のアラートやビジネスインパクトに合致しないアラートを経験すると、アラート疲れに陥ります。ほとんどのアラートが偽物であると考えるようになると、解決が容易なアラートを他のアラートよりも優先するようになります。また、SLAの目標を達成するために、未解決のインシデントをクローズすることもあります。
その結果、インシデント対応が遅くなり、問題の範囲が拡大し、ビジネスに影響を与える真の問題が発生したときに深刻度が増すことになります。
アラート・クオリティ・マネジメント（AQM）は、迷惑なインシデントの数を減らすことに重点を置き、真のビジネス・インパクトを持つアラートだけに集中することができます。これにより、アラートの疲労を軽減し、お客様とお客様のチームが適切なタイミングで適切な場所に注意を向けることができます。
次のような方は、AQMに向いています。
- アラートの数が多すぎます。
- 長時間開いたままのアラートがある。
- あなたのアラートは関係ありません。
- モニタリングツールが発見する前に、お客様が問題を発見する。
- オブザーバビリティツールの価値がわからない。
望ましい結果
ビジネスインパクトの測定に基づいたアラート戦略は、レスポンスタイムの短縮と重要なイベントに対するプロアクティブな認識をもたらします。アラートのS/N比が改善されると、混乱が緩和され、迅速な特定と問題の切り分けが可能になります。
AQMの全体的な目標は、より少ない、より価値のあるインシデントを確実に発生させることであり、その結果、以下のようになります。
- アップタイムと可用性の向上
- MTTRの短縮
- 警報音量の低下
- 価値のないアラートを簡単に識別できるので、価値のあるものにするか、削除することができます。
このガイドに記載されているAQMプロセスは、これらの目標に向けた進捗状況を測定するために使用する主要なパフォーマンス指標とメトリクスを生成します。メトリクスはリアルタイムで測定され、ダッシュボードで公開され、迷惑なアラートを特定して削減し、インシデント調査へのユーザーの関与を高める継続的な改善プロセスを推進するために使用されます。
AQMは、未知の、あるいは予期せぬ故障モードを検出するために設計された異常検知やAIOpsを包含していません。AQMとML/AIの2つの手法は、相互に連携して機能するものであり、相互に排他的なものではありません。
主要なパフォーマンス指標
AQMプロセスを使って、以下のKPIを収集・測定していただきます。
- インシデント数
- 累積インシデント時間
- 平均閉店までの時間（MTTC）
- 5分未満の割合
- MTTI（Mean Time to Investigate）について
- 調査されたインシデントの割合
これらのKPIは、最もノイズの多いアラートや価値の低いアラートを見つけるのに役立ち、その価値を向上させたり、排除したりすることができます。そして、長期的な指標のトレンドを利用して、経営陣やステークホルダーに実際のビジネスインパクトを示すことができます。各指標の詳細情報は以下の通りです。
インシデント量
インシデント（アラートの有無にかかわらず）は、タスクのキューのように扱うべきです。キューのように、アラートの数はゼロに近い状態で過ごすべきです。それぞれのインシデントは、その状態を解決するためのアクションのトリガーとなるべきです。アラートがアクションにつながらない場合は、アラート条件の価値を疑うべきです。
"インシデントの発生率が一定であったり、特定のインシデントが"常時発生していたりする場合は、その理由を疑ってみてください。ビジネスに影響を与える状態が続いているのか、それとも単に大量のノイズが発生しているのか。アラートボリュームKPIは、これらの疑問に答え、高品質なアラートの健全な状態への進捗を測定するのに役立ちます。
ユーザーエンゲージメント
インシデントの価値は、そのインシデントがどれだけ注目されているかで測るべきです。ここでいう「関与」とは、インシデントが認知されたかどうかで測ります。
個々のアラートが受け取るエンゲージメントの量は、その価値を直接測ることができます。エンゲージメントが多ければ、価値のあるアラートであることを意味し、エンゲージメントが少ない（またはゼロ）場合は、修正または無効にすべき迷惑なアラートであることを意味します。
インシデントを認識した瞬間を測定するのと、解決活動が始まった瞬間に確認するのとでは、大きな違いがあります。New Relic Alerting との統合を使用している場合は、New Relic に送信される"acknowledge" イベントが、外部のインシデント管理ツールにインシデントが送信されたときではなく、解決活動が開始されたときにトリガーされることを確認してください。標準的なインシデント管理プロセスの詳細については、" インシデント管理プロセスを参照してください。5 Steps to Effective Resolution Posted on August 31, 2020 by OnPage Corporation. -- ITIL4を参考に"
前提条件
始める前に、同等の経験がない場合は、 New Relic University (NRU) Overview Course を修了してください。また、以下について基本的に理解していることを確認してください。
- NR1 アラートポリシーと条件設定
- NR1インシデント通知チャネルのWebhook設定
- NR1 NRQL
- NR1アラーティングのベスト・プラクティス
- NR1 APM& インフラ
- 異常と通常の動作を判断するためのデータのベースラインの取り方。
現状の確立
他の継続的改善プロセスと同様に、AQMの最初のステップは、KPIの現状を把握することです。そのためには、次のような作業を行います。
- インシデントイベントWebhookのインストールと設定
- AQMダッシュボードのインストール
- 初期のAQMオリエンテーションとイネーブルメントの実施
- AQMデータの蓄積
- 2回目のイネーブルメントセッションの実施
インシデントイベントWebhookのインストールと設定
このWebhookは、各インシデントがそのライフサイクル（オープン、アクノレッジ、クローズ）を経るごとに、New Relicイベントを作成します。AQMプロセスが正確で価値のある調査結果を確実に生成するために、このWebhookをすべてのアラートポリシーに通知チャネルとして追加する必要があります。
AQMプロセスでは、違反データではなくインシデントデータが必要です。そのため、違反データのみを提供するデフォルトのNrAiIncidentイベントは使用しません。代わりに、このWebhookを使って必要なインシデントデータをNew Relicに送信します。
Webhookを使用するには、以下のようにします。
- プライマリープロダクションアカウントと、AQMプロセスで分析する予定の各アカウントを特定します。
- AQMプロセスに参加する各アカウントにインシデント・イベント・ウェブフックをインストールし、nrAQMIncidentイベントをプライマリ本番アカウントに報告するようにウェブフックを構成します。
- 各アカウントのすべてのアラートポリシーに、通知チャネルとしてWebhookを割り当てます。
この例では、複数のサブアカウントを持つNew Relicアカウントの各アラートポリシーにWebhook通知チャネルを割り当てています。
Webhook、AQMダッシュボード、および詳細なインストール手順は、GitHub上のNew Relic OMAリソースセンターで 。
AQMダッシュボードのインストール
AQM ダッシュボードは、AQM プロセスを駆動する主要な資産です。AQMダッシュボードを、以前実行した " Install and configure incident event webhook" のステップで特定したプライマリープロダクションアカウントに、以下のようにしてインストールする必要があります。
- ダッシュボード定義のJSONファイル をNew Relic OMAリソースセンターのGitHub repoからダウンロードします。
- 定義をプライマリプロダクションアカウントにインポートします。
ダッシュボードのインポートの詳細については、New Relic Introduction to dashboards のドキュメントをご覧ください。
初期のAQMオリエンテーションとイネーブルメントの実施
この段階では、インシデントマネジメントチームやその他の利害関係者が、AQMプロセスの目標とその関与の範囲を学びます。
このタスクで最も重要なのは、インシデントアラートを確認することの重要性をチームに教えることです。一般的には、以下のガイドラインに従うように指示してください。
- アラートを見て、さらに調査を行うことを決めた場合は、アラートを確認してください。
- 通常、何もせずにアラートを閉じる場合は、アラートを確認しないでください。
- インシデントアラートが常にオンになっている場合、それを閉じたり確認したりしないでください。詳細については、 第二回イネーブルメントセッション をご覧ください。
この資料を関係者に伝える際には、 第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の説明と、New RelicプラットフォームからKPIを抽出するNRQLクエリのサンプルを示します。これらのKPIはAQMダッシュボードにも含まれており、New Relic OMAリソースセンターのGitHub repoから ダウンロードできます。
インシデント量
インシデント・エンゲージメント
追加リソース
お客様のアカウントに導入する前に、手を動かしてみませんか？ alert quality management labをご覧ください。