このガイドでは、エラーを最適化して、エラー率、エラー検出、カスタマー エクスペリエンスを向上させる方法について説明します。これは、オブザーバビリティの成熟度に関するシリーズの一部です。
概要
エラー追跡は、アプリケーションのエラーとエラー率を把握することで、顧客のソフトウェア体験に影響を与える問題に対処できるようにします。
このガイドの目的は、New Relic の顧客またはチームが以下を行えるようにすることです。
- New Relic がエラーを理解する方法を調整して、エラー関連のメトリクスが意味のあるエラーのみを反映するようにします。
- 時間の経過とともにエラーの発生率を下げる
望ましい結果
アプリケーションのエラー率と平均解決時間を短縮することで、カスタマー エクスペリエンスと信頼性を向上させます。
主要業績評価指標
ビジネスKPI
顧客が経験するエラーを減らすことで、信頼性が向上します。信頼性を向上させた組織は、より高いコンバージョン率 (ユーザー ジャーニーの完了率) とより高いユーザー エンゲージメントを経験します。これにより、組織は収益目標 (商業) または社会的影響の目標 (非営利) の達成に近づきます。
上記のビジネス KPI は、フロントエンド アプリケーションを提供することでユーザーをサポートすることを前提としています。API を介して顧客をサポートする場合、上記の KPI をトランザクション エンティティ タイプに適合させることができる場合があります。API をサービスとして提供する一部の組織は、以下のような運用 KPI を使用して、提供するサービスの品質を高めています。
運用 KPI
前提条件
必要なインストールと構成
私たちの
、
、モバイル監視、サーバーレス監視、または OpenTelemetry ソリューションでエラーが発生しています。
Web アプリケーションの最新のソース マップ
モバイル アプリケーションの最新の記号化
現在の状態を確立する
アプリケーションのワークロードを作成する
エラーを最適化しようとしているアプリケーションとサービスのリストを定義します。エラー最適化プロセスを実施するチームは、これらのアプリとサービスに対して全責任を負い、管理する必要があります。決定したら、これらのエンティティのワークロードを設定します。
ワークロードは、特定のチームが担当するエンティティ (アプリケーション、インスタンスなど) のグループです。それらを使用すると、何かを実行できるエンティティのみのデータを確認できます。ここで設定したワークロードに基づいて、ほとんどの作業を進めることになります。
ワークロードのセットアップには数分しかかかりません。ワークロードの説明を参照してください。
すでにワークロードに精通しており、アプリケーションとサービスを複数のワークロードに分割したい場合は、そうすることができます。ワークロードごとに以下の手順に従ってください。
ワークロードのサービス レベルを作成する
サービス レベルを使用すると、特定のエンティティ グループのサービス レベル目標 (SLO)を簡単に構成および表示できます。サービス レベルを使用することは、エラー管理プロジェクトの成功を監視および伝達するための 1 つの方法です。
ワークロードから、[サービス レベル] タブに移動します。ワークロード内の各エンティティのエラー率を測定するサービス レベルを作成します。これは、サービス レベル UI のステップ 2 で構成されます。サービス レベルごとに、WHERE 句を使用して、考慮すべきではない適切な要求またはエラーを除外します。
サービス レベルを使用して、現在のエラー率に対する進捗状況を追跡します
上記のプロセスを使用して、現在のエラー率に基づいてサービス レベルを作成しました。
- SLO 列には、ベースラインを使用して選択した目標エラー率が表示されます。
- 運用ビュー モードでは、ターゲットに対する最近のパフォーマンスが表示されます。
- 期間表示モードでは、より長い期間にわたってターゲットに対するパフォーマンスが表示されます。
- 改善が行われると、エラー率の目標を更新できます。
改善プロセス
- 重要でないエラーを特定する
- エラー率から重要でないエラーを取り除く
- エラー率アラートを設定する
- エラーヒーロー名簿を確立する
- エラー インボックスを使用してエラーをトリアージする
- エラーを JIRA にリンクする
- エラーを Slack にリンクする
- CodeStream を使用する
重要でないエラーを特定する
最も快適な方法でエラーを調べてください。以下を使用してこれを行うことができます。
- APM、モバイル監視、JavaScript エラー、サーバーレス監視、および OpenTelemetry のすぐに使えるビュー
- ワークロード用にフィルター処理された受信トレイのエラー
TransactionError、JavaScriptError、MobileRequestError、AwsLambdaInvocationError、Span
エラー率から重要でないエラーを取り除く
重要でないエラーは、次の 2 つの方法のいずれかで削除できます。
- 構成(APM のみ) またはドロップ ルールを使用して、それらの取り込みを停止します。このアプローチは、キャプチャする必要がないことが確実なエラーに対してのみ機能します。このアプローチの追加の利点は、ノイズの多いエラーの取り込みが減少することです。
- NRQL を使用して、サービス レベルの計算からエラーを除外します。これを行うには、不適切な応答の WHERE 句フィルターに追加します。これによりエラー率が大幅に改善される場合は、必ずサービス レベルを再ベースしてください。そうすることで、エラー アラートの精度が向上します。
エラー率アラートを設定する
ワークロードのサービス レベルの作成で設定した各サービス レベルを確認し、エラー率が許容範囲を超えた場合にチームに通知するアラートを作成します。
エラーヒーロー名簿を確立する
アラートは、現在のレベルのエラー パフォーマンスを満たしているかどうかを知らせますが、改善には役立ちません。顧客の感情を改善するには、チームのメンバーが毎日エラーを確認するプロセスを作成します。エラー ヒーローは次のことを行う必要があります。
- 最初は、スクロールせずに見える範囲で発生するエラーに焦点を当てます。毎日のレビュー プロセスの場合、これは、過去 24 時間以内にのみ発生したエラーに焦点を当てることを意味します。
- エラー インボックスを使用してエラーをトリアージする
エラー インボックスを使用してエラーをトリアージする
エラー インボックスは、すべてのエラーが顧客に影響を与える前に、プロアクティブに検出、トリアージ、アクションを実行するための単一の場所です。同様のエラーはグループ化され、作業の重複を回避し、発生回数によってエラーに優先順位を付けることができます。
エラー インボックスにアクセスするときは、チームに関連するエラーのみが表示されるように、必ずワークロードを選択してください。
チームとしてエラー インボックスを確認する時間を定期的に取っておきます。多数のエラー グループを処理する必要があるため、まず、毎日または週に数回が理にかなっています。その後、毎週または隔週がより適切な場合があります。
トレースやログなどの詳細情報を取得する必要がある場合は、エラーの詳細画面をクリックして、エラーを 1 つずつ確認します。これは、エラーの原因を指摘するか、さらなる調査の開始点を提供します。
簡単な議論の後、エラーグループを次のいずれかとしてマークする立場になるかもしれません:
- 無視: エラーが問題にならない場合に使用します。これにより、その時点から受信トレイ ビューからエラー グループが非表示になります。
- 解決済み: エラーが既知の問題の結果であり、現在は修正されている場合に使用します。これにより、再発しない限り、リストからエラー グループが削除されます。再発する場合は、以前に実装した修正を再考する必要があります。
注: エラー インボックスを介してエラーを無視または解決しても、エラー率メトリックへのカウントは停止しません。
上記のステータスのいずれも適切でない場合は、エラーを適切なチーム メンバーに割り当てて、さらなる調査と解決を依頼してください。そのチーム メンバーは、自分の時間にさらに調査を実施し、エラー グループのメモを進捗状況で更新したり、メモ セクションを介して他のチーム メンバーに助けを求めたりすることができます。
次のトリアージ ミーティングで、これらのエラー グループに再度アクセスして、解決済みとしてマークできるかどうかを確認できます。時間が経つにつれて、新しいエラー グループの数が減り、KPI にプラスの動きが見られるようになるはずです。
エラーを JIRA にリンクする
特殊なケースや複雑なエラーが発生すると、他のチームに助けを求める必要があることに気付くかもしれません。エラー インボックスを Jira にリンクすると、これに役立つ場合があります。エラー受信トレイを Jiraに接続して、エラー グループに接続されたチケットを簡単に作成できるようにします。Jira テンプレートを介して Jira に送信される情報を制御できます。
エラーを Slack にリンクする
エラー インボックスに届くエラーの速度が低下するにつれて、定期的なチーム セッションはもはや有効な時間の使い方ではない可能性があります。別の方法として、エラー インボックスを Slack にリンクし、a) チャネルを監視し、発生したエラー グループを解決/無視/割り当てする担当者をローテーションで指名するか、b) チームがエラー グループに積極的に対応できるようにする、のいずれかを行います。
CodeStream を使用する
エラー グループの多くは、解決するためにコードの変更が必要になります。CodeStream を New Relic アカウントに接続して、問題のあるコードを IDE で直接開き、コードを直接調査します。開発者がレビューできるように、コードの特定の行にメモやコメントを残すこともできます。
CodeStream を使用した New Relic は、バージョン番号の確認や SHA のコミットなど、エラー グループに関するより多くのコンテキストを提供します。さらに、コードの問題を特定、議論、および修正するための一元化された場所としてエラー インボックスを使用すると、コードの問題に効率的に対応し、作業の重複を避けることができます。
価値の実現
練習を進めながら、エラー率を毎週確認してください。エラー率が低下するにつれて、解決までの平均時間が短縮され、顧客満足度が向上するはずです。