サービス エラー率は、サーバー側エラー (5xx HTTP 応答) が発生した APM サービスの割合を測定します。サーバー側エラーが発生すると、ユーザーが購入、サインアップ、データ アクセスなどの重要なタスクを完了できなくなる可能性があります。このスコアカード ルールは、顧客エクスペリエンスに直接影響を与えるバックエンドの問題を特定し、修正の優先順位を付けるのに役立ちます。
このスコアカードルールについて
このサービス エラー率ルールは、デジタル エクスペリエンス成熟度モデルのレベル 1 (リアクティブ) の一部です。バックエンド サービスに、ユーザー体験やビジネス運営に影響を与える可能性のある未解決のサーバー エラーがあるかどうかを評価します。
これが重要な理由:サーバー エラー (5xx 応答) は、バックエンドが ユーザーrequestsを実行できないことを示し、トランザクションの失敗、ユーザー フローの中断、ビジネス チャンスの損失につながります。 サーバー エラーに遭遇したユーザーは、多くの場合、タスクを放棄し、戻ってこないことがあります。
このルールの仕組み
このルールは、応答で 5xx HTTP ステータス コード エラーを報告する APM サービスの割合を評価します。サーバー側の障害によりユーザーが意図したアクションを正常に完了できない可能性があるバックエンド サービスを特定します。
スコアを理解する
- 合格（緑）: APM サービスの低い割合でサーバー側エラーが発生しています
- 不合格（赤）: APM サービスの高い割合で未解決の 5xx エラーが発生しています
- 目標:すべてのサービス、特に重要なユーザー ジャーニーをサポートするサービスでのサーバー エラーを最小限に抑えます。
これが意味するもの:
- 合格点:バックエンド サービスはユーザーrequestsを確実に満たし、タスクの正常な完了をサポートします。
- 不合格スコア:ユーザーは失敗したrequests 、壊れたワークフロー、または重要なアクションを完了できないことに遭遇している可能性があります
5xx サーバーエラーの理解
サーバー エラーは、バックエンド インフラストラクチャまたはアプリケーション コードに問題があることを示します。
一般的な5xxエラーの種類
- 500 内部サーバーエラー:一般的なサーバー障害。多くの場合、アプリケーションのバグや未処理の例外が原因です。
- 502 Bad Gateway:上流サーバーが無効な応答を返しました。ロードバランサーやプロキシでよく発生します。
- 503 サービスは利用できません:サーバーが一時的に過負荷状態またはメンテナンス中です
- 504 ゲートウェイタイムアウト:上流サーバーとの通信時にリクエストがタイムアウトしました
ユーザー体験への影響
- 失敗した取引:ユーザーは購入、サインアップ、またはデータの送信を完了できません
- 壊れたワークフロー:複数ステップのプロセスが途中で失敗し、ユーザーに不満を抱かせる
- データの損失:エラーが発生すると、フォームの送信内容やユーザー入力内容が失われる場合があります。
- 信頼性の低下:エラーが繰り返されると、アプリケーションに対するユーザーの信頼が低下します。
サービスエラー率を下げる方法
スコアに高いサービス エラー率が示されている場合は、次の手順に従ってバックエンドの問題を特定し、解決してください。
1. 影響を受けるサービスを特定し、優先順位を付ける
- APM サービスの概要を確認する: 5xx エラーを報告しているサービスを調べる
- ビジネスへの影響を評価する:重要なユーザー ジャーニー (支払い、認証、コア機能) をサポートするサービスを優先します。
- エラーパターンを分析:エラーのタイミング、頻度、影響を受けるエンドポイントの傾向を調べます
- ユーザーへの影響を確認する:各サービスのエラーによって影響を受けるユーザーの数を特定します。
2. 根本原因を調査する
アプリケーション レベルの問題:
- 処理されない例外:適切にキャッチされ、処理されないコードエラー
- データベース接続の失敗:接続プールの枯渇またはデータベースの使用不能
- リソース枯渇:メモリリーク、CPU 過負荷、ディスク容量の問題
- 構成エラー:誤った設定によりアプリケーションの障害が発生する
インフラストラクチャレベルの問題:
- サーバー容量の問題:トラフィックのピーク時にリソースが不足する
- ネットワーク接続の問題:サービス間の通信障害
- ロードバランサの設定:不適切なルーティングまたはヘルスチェックの失敗
- 依存関係の障害:アプリケーションに影響を与えるサードパーティのサービス停止
3. 目標修正を実装する
即時解決:
- 重大なバグを修正: 500 エラーの原因となるアプリケーション コードの問題を修正
- リソースのスケール: 503 エラーが発生している過負荷のサービスに容量を追加します
- 再試行を構成する:一時的な障害に対する再試行ロジックを実装する
- ヘルスチェックの更新:ロードバランサーがトラフィックを適切にルーティングしていることを確認する
体系的な改善:
- エラー処理:包括的なtry-catchブロックと適切なエラー応答を追加します
- サーキットブレーカー:依存関係の障害を適切に処理するためのパターンを実装する
- 監視機能の強化:詳細なログとメトリクスを追加して診断を迅速化
- キャパシティプランニング:予想される負荷に対応できる適切な規模のインフラストラクチャ
4. エラー追跡と解決策を確立する
New Relicエラー受信トレイを使用する:
- 一元化されたエラー追跡:サービス全体の 5xx エラーを 1 か所で表示します
- エラーのグループ化:類似のエラーを自動的にグループ化してパターンを識別します
- エラーの帰属:エラーを特定のデプロイメントまたは変更に関連付ける
- 解決の追跡:エラーを解決済みとしてマークし、修復の進行状況を追跡します
欠陥追跡を実装する:
- チケットを作成する: 問題追跡システム (JIRA、GitHub Issues) にエラーを記録します。
- 責任の割り当て:各エラーに責任チームまたは担当者が割り当てられていることを確認します。
- 解決策の追跡:デプロイメントまでのエラー修正の進捗状況を監視します
- 効果の測定:修正によって実際にエラー率が減少したか確認する
改善の測定
これらのメトリクスを追跡して、サービス エラー削減の取り組みを検証します。
- エラー率の削減: 5xx エラーが発生するサービスの割合の減少
- ユーザーへの影響 メトリクス:サイト完了率の向上、ユーザーからの苦情の減少
- エラー解決時間:サーバー側の問題の特定と修正が迅速化
- サービスの信頼性:稼働時間とリクエスト成功率の向上
一般的なサービスエラーのシナリオ
データベース接続の問題:
- 問題:接続プールの枯渇またはデータベースのタイムアウトにより 500 エラーが発生する
- 解決策:接続プーリングの最適化、接続再試行ロジックの実装、データベース パフォーマンスの監視
サードパーティの依存関係の失敗:
- 問題:外部APIまたはサービスが失敗し、アプリケーションが502/503エラーを返す
- 解決策:サーキットブレーカー、フォールバックメカニズム、適切なタイムアウト処理を実装する
デプロイメント関連のエラー:
- 問題:新しいリリースで5xxエラーを引き起こすバグが導入される
- 解決策:テスト手順の改善、カナリアデプロイメントの実装、ロールバック機能の追加
容量とスケーリングの問題:
- 問題: Traffic急増によりサーバーが過負荷になり、503 エラーが発生する
- 解決策:自動スケーリング、負荷テスト、キャパシティプランニングを実装する
高度なエラー管理戦略
エラー防止の実践
- 包括的なテスト:単体テスト、統合テスト、負荷テストにより、本番前に問題を発見します。
- コードレビュー:エラー処理パターンとエッジケースカバレッジに焦点を当てる
- ステージング環境:本番環境と同様の環境で徹底的にテストする
- 段階的なロールアウト:機能フラグとカナリアデプロイメントを使用してエラーの影響を最小限に抑えます
自動エラー応答
- 自動スケーリング:エラー率が過負荷を示している場合に自動的に容量を追加します
- サーキットブレーカー:障害の連鎖を防ぐために、障害のある依存関係を自動的に分離します。
- ヘルスチェック:ロードバランサーのローテーションから不健全なインスタンスを自動的に削除
- 包括統合:エラー率が閾値を超えた場合に即時通知
変更追跡 (変更追跡機能) 統合
- デプロイメントの相関関係:エラーのスパイクを特定のデプロイメントまたは設定の変更に関連付けます
- ロールバック手順:変更によってエラーが発生した場合の迅速な復元機能
- 変更影響分析:コードの変更が時間の経過とともにエラー率にどのように影響するかを測定します。
- リリース品質メトリクス:リリースの主要な品質指標としてエラー率を追跡します
エラー条件の検証
エラー追跡が、実際にユーザーに影響を与える問題に焦点を当てていることを確認します。
誤検知を除外する
- ヘルスチェックエンドポイント：監視システムrequestsエラー計算から除外する
- 内部サービスコール:内部システム通信ではなく、ユーザー向けのエラーに焦点を当てます。
- 予想されるエラー:一部の 5xx 応答は意図的なものである可能性があります (メンテナンス モード、レート制限)
- ボットトラフィック:実際のユーザーへの影響を反映しない自動システムからのエラーを除外します
ユーザーに影響を与えるエラーに焦点を当てる
- 顧客対応サービス:エンドユーザーに直接サービスを提供するサービスのエラーを優先します。
- 重要なビジネスフロー:収益を生み出す活動に影響を与えるエラーに焦点を当てる
- 高トラフィックのエンドポイント:頻繁に使用されるAPIエンドポイントまたはページのエラーに対処する
- コンバージョンファネル:ユーザー登録、購入、または主要なアクションに影響するエラーを優先します
重要な考慮事項
- ビジネスへの影響の優先順位付け:収益に大きく関わるサービスに影響を与えるエラーにまず焦点を当てる
- ユーザー ジャーニーのコンテキスト:ユーザー フローのどこでエラーが発生するか、およびそのエラーがタスクの完了に与える影響を検討します。
- エラーの頻度と重大度:頻繁に発生する軽微なエラーと、稀ではあるが重大な障害の修正のバランスをとる
- リソースの割り当て:エラー解決の取り組みが利用可能な開発能力と一致することを確認する
次のステップ
- 即時の対応:ユーザーに影響を与える最も影響の大きい 5xx エラーを特定して解決する
- プロセス改善:エラートリアージワークフローと欠陥追跡手順を確立する
- 予防に重点を置く:より良いテストとデプロイメントの実践を実施して、新たなエラーを削減します。
- 監視の機能強化: Change Tracking (変更追跡機能) を使用して、エラーとデプロイメントを関連付けます。
- レベル2に進む:サービスエラーが制御されたら、 Core Web Vitalsの最適化に焦点を当てます。
サービス エラーの監視と解決に関する詳細なガイダンスについては、 APMエラー追跡ドキュメントとエラー受信ボックス ガイドを参照してください。