Sentryリテラシー向上への道：スタートアップの段階的ツール導入術

課題の背景や状況

スタートアップであるため開発リソースが限られており、エラーが発生した際に速やかにキャッチアップしてCSコスト（カスタマーサポートコスト）を削減することが目的でした。エラーの発見から解消までの速度を向上させ、できるだけ前段階で問題を把握したいという状況でした。

特に他のサービスとの比較検討は行いませんでした。Sentry導入前は、CloudWatch Logsに流れてきたデータをLambdaでキャッチして、SlackのWebhookで直接Slackに流すという原始的な方法をとっていました。

エラーの内容を検索したりオーガナイズされていることはもちろんですが、特に重視していたのはSlackのアラート通知をカスタマイズできることでした。同じエラーが連続で起きた時に一通にまとめて通知できる機能があり、創業初期でたくさんエラーが起きていた時にも大量の通知に悩まされることなく、効率的にエラー管理ができる点を重要視していました。

いつの間にかチームに馴染んでいったという点が大きいです。エラー通知の内容がかなりリッチになり、スタックトレース、端末の情報、ユーザーIDなど様々な情報を簡単に付与できるため、Sentryの通知のおかげで問題解決が早くできた実績が創業初期から何度も積み上がりました。この成功体験により、本格的に導入する意思決定や、より上位のプランに課金していくという意思決定が社内として取りやすくなったことが決め手となりました。

解決したかった課題はどれくらい解決されたか

そもそもやりたかったことはかなりできたと思っています。一歩進んだ解決として、フロントエンドとバックエンドを別々のプロジェクトで作っているため、それぞれが複合的に重なり合った問題はなかなか解決できないという課題があります。分散トレーシングの設定を一時頑張っていましたが、未だに完璧にできているかというと微妙で、そもそも設定のハードルもすごく高かったです。そこをちゃんとトレーシングできるような設定がより簡単にできるようになって、問題解決にスムーズに活かせるようになるといいなと思います。

どのような成果が得られたか

特筆すべき点として、まだスタートアップということもあってSentryのエラーは正直全然多いわけではないので、例えばリリース直後の機能や何か不安がある機能の時に、意図しない分岐にソースコードが到達した場合に軽率にSentryにエラーを流してみるということが結構できます。それでエラーが出たのを検知して「ここに処理が通るということは本番のデータにおかしいものが紛れているのではないか」といった障害をさらに未然に防ぐように、エンジニアが先回りしてエラーログを入れてSentryに通知させるような手法が取れるようになったという成果があります。

導入自体はそれほど苦労しませんでしたが、breadcrumbやユーザーIDなどの設定をちゃんと行わないと取得できないため、最初にそれらの情報がうまく取れなかった時に、自分たちの設定ミスなのかSentryの問題なのかの区別がつかなかったことが少し大変でした。また、ステージングと本番でプロジェクト自体を分けるのか環境で分けるのかの判断が最初決めきれず、運用がバラバラになった時期もありました。

無意識的にSentryに頼れないエラーもまだまだ世の中にたくさんあるので、どんどんSentryに頼ってエラー解決できる範囲を増やしていきたいと思います。また、エンジニアチームの中にもSentryリテラシーを上げていきたいというか、Sentryのイシューを見て問題解決できるという再現性をチーム全体で上げていきたいと思っています。