例外通知のノイズを減らすための実践ヒント――エラー監視を快適にする3つのパターン

どんなアプリも、実際のユーザーとの最初の接触には耐えられません。ユーザーが使い始めると、必ずどこかでエラーに遭遇するからです。

そのため、本番環境にデプロイした後は、多くのアプリが何らかの方法でエラーを追跡・報告する仕組みを持っています。exception_notification のようなシンプルな gem を使ってもよいですし、Honeybadger や Raygun のような Web サービスを利用するのも一案です。

しかし運用を続けていると、同じ例外ばかりが繰り返し報告されることに気づきます。依存している外部 Web サービスが不安定なのかもしれませんし、ユーザーがメールアドレスを打ち間違えたせいで、送信したメッセージが一切届いていないのかもしれません。例外は「例外的」であるべきで、「予期しないもの」であるべきです。1日に30回も目にするエラーが、果たしてどれほど「予期しない」と言えるでしょうか?

こうした問題は、報告して無視する以外にもっと良い解決策があります。ノイズの多い例外のほとんどは、いくつかの基本的なカテゴリに分類できます。そしてそれぞれのカテゴリに対して、ノイズを削減しながら同時にユーザー体験を向上させるパターンが存在するのです。

ネットワークがダウンした!

単体で完結するアプリはほとんどありません。多くのアプリは他のサービスと通信しています。しかし、位置情報 API が落ちたり、EC2 に不具合が起きたりしたときに、こちらではどうにもできない例外が何千件も通知されてくるのは避けたいところです。

信頼性の低いサービスを扱うときは、Michael Nygard の著書『Release It!』で紹介されているサーキットブレーカー(Circuit Breaker)パターンを試してみてください。

サーキットブレーカーの基本的な考え方は非常にシンプルです。保護対象の関数呼び出しを、障害を監視するサーキットブレーカーオブジェクトで包みます。障害が一定のしきい値に達すると、サーキットブレーカーが「落ち」、以降のすべての呼び出しは、保護された処理を実行することなくエラーを返します。

つまり、サービスがダウンしたとき、自動的に接続の試行をやめることができます。その機能がなくてもアプリは動き続けます。さらに自己修復機能を持たせることもでき、一定時間が経過したら自動的にサービスを再チェックさせることも可能です。

サーキットブレーカーパターンは本来、連鎖的な障害(カスケード障害)を防ぐために設計されていますが、例外通知を制限する目的でも活用できます。このパターンを使えば、通知が必要になるのは「ブレーカーが落ちたとき」と「復旧に失敗したとき」だけ。何千件もの例外をわずか数件にまで減らせるのです。それでも多すぎると感じたら、連続して数回リトライに失敗した後でのみ報告するよう設定すればよいでしょう。(あるいは、もっと信頼できる別のサービスへの乗り換えを検討するのも手です!)

このパターンの導入には手間がかかりますが、ユーザー体験も同時に向上します。真っ赤なエラーページの代わりに、「この機能は現在利用できません。お手数ですが後でもう一度お試しください」という親切なメッセージを表示できます。適切なタイミングで、より良い情報をユーザーへ届けられるのです。

実は gmaaaail.com はあなたが意図したドメインではなかった

私がよく目にするもう一種類の例外は、不正なユーザーデータが原因のものです。

たとえば、誰かが新規登録時にメールアドレスを打ち間違えたとします。「justinweiss@gmaill.com」と入力しましたが、本当は「justinweiss@gmail.com」のつもりでした。前者は理論上は有効な形式のメールアドレスですが、あなたが送信するメールはすべてバウンス(宛先不明で戻る)します。そして、そのバウンス通知がメール配信サービスから次々と届くわけです。

こうした通知は、ただのノイズでしかありません。

代わりに、両側からのアプローチを取りましょう。事前に不正なデータの入力を防ぎ、それでも後で失敗した場合には該当機能を無効化してユーザーに通知するのです。

メールアドレスの場合、私は新規ユーザーの登録時に mailcheck-js のようなライブラリを使い、「gmail.com」や「yahoo.com」などの主要ドメインのスペルチェックを行っています。

{% img img-responsive /images/posts/email-spellcheck.gif 477 451 Ooh, fancy. %}

そのうえで、それでも後からメールがバウンスした場合は、そのユーザーへのメール送信をオフにします。

あるユーザーに対して機能を無効化したら、その事実と修正方法を必ず伝えましょう。サイト上部にバナーを表示するのが一般的によい解決策です。たとえば「最近お送りしたメールが届かなかったため、メール送信を一時的に停止しました。こちらからメールアドレスを更新いただければ、すぐに再開いたします」といった文言が効果的です。

より正確なデータが得られるうえ、ユーザーのメールが虚しく消えていくこともなくなります。ただ黙って無視していたエラー通知よりも、はるかに良い状態だと言えるでしょう。

404 エラーと RoutingError

サイト内の壊れたリンクや欠落しているアセットについては把握しておきたいものですが、それらは例外トラッカーに入れるべきものではありません。

こうした「半ば予期されるエラー」は、個別に通知を受けず、まとめて一括処理しましょう。発生するたびにプッシュ通知を受ける必要はありません。必要なのはプッシュではなくプルです。

RoutingError や 404 であれば、Google Search Console(旧 Google ウェブマスターツール)などを活用できます。Google が認識している、404 を返しているページを一覧で確認可能です。また、link-checker のようなツールを使い、リリース前のチェック工程としてサイト内のリンクを検証するのもよいでしょう。

例外は「対応可能」であるべき

例外通知のメールが届くのは、まれであるべきです。エラートラッカーにノイズが多すぎると、本当に重要な問題に気づいて迅速に修正することができなくなります。

目にする例外について、恥ずかしいと感じるよりもイライラする方が勝っているなら、それはノイズ問題を抱えている証拠です。ここで紹介したパターンを活用してノイズを削減し、あわせてユーザーにより良い体験を提供していきましょう。

今回は、私が最もよく目にするノイズの多い例外のカテゴリをいくつか取り上げました。しかし、すべてを見尽くしたわけではありません。あなたのアプリではどの例外が最大の悩みの種になっていますか? 既存のカテゴリに当てはまりますか? それとも新しいカテゴリを定義するものでしょうか? 1日に何百回も邪魔されないように、皆さんはどう対処しているのか、ぜひ教えてください。