例外ノイズを削減するためのいくつかのヒント

実際のユーザーとの最初の接触を生き残るアプリはありません。人々がそれを使い始めると、彼らはエラーに遭遇するでしょう。

そのため、本番環境に入ると、ほとんどのアプリにはエラーを追跡して報告する方法があります。単純にexception_notificationを使用するか、HoneybadgerやRaygunなどのWebアプリを使用できます。

しかしすぐに、同じいくつかの例外が何度も表示されます。依存しているWebサービスが完全に安定しているとは限りません。または、サイトを使用しているユーザーがメールをタイプミスしたため、メッセージが届きません。例外は例外的である必要があり、予期しないものである必要があります。 しかし、1日に30回エラーが発生した場合、エラーはどの程度予期しないものになる可能性がありますか？

これらの問題を解決するには、報告して無視するよりも良い方法があります。ほとんどのノイズの多い例外は、いくつかの基本的なカテゴリに分類されます。そして、これらのカテゴリごとに、パターンを使用してノイズを削減し、同時にユーザーを幸せにすることができます。

ネットワークがダウンしています！

単独で動作するアプリはほとんどありません。ほとんどが他のアプリと通信します。ただし、ジオロケーションAPIがダウンしたり、ec2に問題が発生したりした場合は、何もできない何千もの例外でスパムを送信したくありません。

信頼性の低いサービスを扱う場合は、サーキットブレーカーパターンを試してください 、MichaelNygardのReleaseItから：

サーキットブレーカの背後にある基本的な考え方は非常に単純です。保護された関数呼び出しを、障害を監視する回路ブレーカーオブジェクトでラップします。障害が特定のしきい値に達すると、回路ブレーカーが作動し、保護された呼び出しがまったく行われずに、回路ブレーカーへのそれ以降のすべての呼び出しがエラーで返されます。

そのため、サービスがダウンすると、サービスへの接続の試行が自動的に停止します。その機能なしで続行します。自己回復させることもできるので、アプリは一定時間後にサービスを自動的に再度チェックします。

回路ブレーカーパターンは、カスケード障害を防ぐように設計されていますが、例外通知を制限するために使用することもできます。このパターンでは、実際には、トリップしたときと回復に失敗したときにのみ通知を受け取る必要があります。何千もの例外をいくつかに変えることができます。それでも多すぎる場合は、ブレーカーに、数回の再試行が連続して失敗した後にのみ報告するように指示できます。 （または、別のより信頼性の高いサービスを見つけてください！）

このパターンを使用すると手間がかかりますが、ユーザーのエクスペリエンスも向上します。 ハードエラーページの代わりに、この機能が現在機能していないことを示すメッセージが表示されます。後で再試行する必要があります。適切なタイミングで配信される、彼らにとってより良い情報です。

gmaaaail.comが意図したものではないことが判明

私がよく目にする別の種類の例外は、悪いユーザーデータから来ています。

たとえば、登録時に誰かがメールをタイプミスしたとします。彼らは「[email protected]」と言いましたが、「[email protected]」を意味していました。最初のアドレスは理論的には有効な電子メールアドレスである可能性がありますが、送信するすべての電子メールは返送されます。そして、あなたはあなたの電子メールプロバイダーからそれらのバウンスについて通知を受けます。

これらの通知は単なるノイズです。

代わりに、両面アプローチを採用してください。 不正なデータを事前に防止し、機能を無効にして、後で失敗した場合はユーザーに通知します。

メールの場合、mailcheck-js gemを使用して、新規ユーザーの登録時に「gmail.com」や「yahoo.com」などのスペルチェックを行いました。

{％img img-response /images/posts/email-spellcheck.gif 477 451ああ、空想。 ％}

その後、メールがまだ返送される場合は、そのユーザーへのメールをオフにします。

誰かのために機能をオフにしたら、それが無効になっていることとその修正方法も伝える必要があります。通常、サイトの上部にあるバナーが良い答えです。 「最後の数通のメールを送信できなかったため、メールの送信をオフにしました。ここをクリックしてメールアドレスを更新してください。すぐに有効になります。」

より良いデータが得られ、ユーザーのメールが単に無効になるだけではありません。 無視していたエラーよりもはるかに優れています。

404sとRoutingErrors

あなたはおそらくあなたのサイトの壊れたリンクや資産について知りたいでしょう。ただし、これらは例外トラッカーには含まれません。

これらおよびその他の「予想外のエラー」については、それらをまとめて一度に処理します。それらが発生したときに通知を受け取る必要はありません。 プッシュするのではなく、プルする必要があります。

RoutingErrorsや404のようなものは、Google Webmaster Toolsのようなもので処理できます。これにより、Googleが知っている404をスローしているページが表示されます。または、リンクチェッカーのようなものを実行して、プレリリースプロセスの一部としてサイト上のリンクをチェックすることもできます。