エラーをチームに割り当て、エラーステータスを更新する

エラーを正しいチームに割り当てる

Error group summary [エラー グループの概要] ページから、エラー グループを正しいチームに割り当てることができます。

エラーを個人またはチームに割り当てると、コミュニケーション上のミスが発生する可能性がなくなります。エラーの解決に役立つ情報はコード所有者に直接配信され、コード所有者は中断したところから作業を再開できるようになります。

その後、課題は電子メールでチームに配信されます。

エラーのステータスをマークします

割り当てが完了すると、エラーのステータスを更新できます。

この機能には、いくつかの異なる利点があります。

• エラー グループが予期される場合は、エラーを Ignoredとしてマークできます。予期されるエラーは、あなたとチームが知っています。重大ではないバグである場合もあれば、エンド ユーザーに関連するエラー (誰かが間違ったパスワードを使用している場合など) である場合もあります。
• ただし、予想されるエラーをできる限り解決することをお勧めします。エラー グループを無視しても、今後 New Relic がエラーを報告することは妨げられず、これがデータの取り込みに影響します。
• New Relic は、エラーのステータスを時間の経過とともに追跡します。たとえば、エラー グループを Resolved [解決済み] としてマークした後、新しいデプロイメントでエラー グループが表示された場合、New Relic はそのエラーを Regressionとしてマークします。

根本原因を調査する

一般的なエラーを削減する場合でも、重大な機能停止に対応する場合でも、エラー発生の直接の原因につながるデータを追跡することになります。庭に水浸しになったパイプの漏れは修理したかもしれませんが、そもそも亀裂の原因は見つかっていません。

エラー グループをチームに割り当てると、どのプロセスが停止につながったのかを全員で特定する振り返りの開催が容易になります。ひびの入ったパイプを元に戻すには、配管工に会い、庭の木がすべてのパイプに成長していると教えてくれました。全員が同じデータを確認できる振り返りは、チームのワークフロー全体の改善に自然とつながります。

サービス停止の一般的な根本原因は次のとおりです。

• 実稼働前環境での不適切な保証テスト。

• コードベース内のすべての関数またはメソッドをテストして、結果が期待どおりであることを確認できない。

• 上流の依存関係の要件、容量、またはその制限について誤解しています。たとえば、データベース クエリが実稼働前では負荷が低くても問題なく実行されていたが、負荷がかかると速度が低下し始めた場合です。

• 容量計画の欠如。おそらく、コードは通常の負荷ではすべての通常のテストに合格しますが、需要がピークに達すると実行されなくなる可能性があります。

  根本原因は、存在するチームの数と同じくらい変化する可能性があります。ただし、重要なのは、データを追跡し、コミュニケーションをとり、直接的な原因を超えて深く掘り下げることです。