こんにちは。クルーズ株式会社CTOの鈴木です。
SHOPLISTでは、2021年の10月ごろからフロンエンドのエラー監視としてSentryを導入してしています。
導入から6ヶ月が経ち、運用にも乗ってきたので事例として共有したいと思います。
JSのエラーが原因で立て続けに問題が起こった
当時、特定ブラウザだけボタンを押しても動作しない問題や、サービスとしては正常に動くんだけど効果測定用に送っているイベントが発火しない問題が立て続けに起き、原因の特定と修正に長いものだと３営業日かかってしまうことがありました。
この件で問題だと感じた点は以下です。
- サーバと違って、ブラウザ上で動作するものは明示的にログをどこかに送ってやらない限り実行しているブラウザ上でしかエラーに気づけない。
- 特定ブラウザのみで発生する場合、問題が発覚しても開発者がその問題を特定するまで時間がかかる。（再現条件の特定に時間がかかる）
- 表示に影響しない計測系のイベント発火は見落とされやすい。（表示上は正常なため）
上記問題を解決する方法の一つとして、以前にAWS Fargate上に構築したコンテナ上で動作するLaravelのエラー送信で使っているSentryでJSのエラー監視を行うことにしました。
Sentryの導入
導入はドキュメントの通りに行い、非常に容易に出来ました。
検知されたエラーはIssuesという形でチケットとして上がってくるので、運用としては
- 検知されたエラーはフロントエンドの専門職種長が対処が必要かどうかをまず判断する。
- 対処が必要なものは担当者をアサインして、リファクタリングタスク化する
- アサインされた担当者は修正し、直近のリリースに混ぜ込んで修正リリースする。
という形で行っています。
またエラー内容や件数といった情報は、エンジニア全員の参加する会議体の中で共有し、今どのような問題は発生しているかについてエンジニア全員が知ることができるようにしています。興味のある人はSenty上から詳細レポートを見れるよう、アカウントもエンジニア全員に配布しています。
Sentry以外で実施していること
実際にサービス側で発生していたエラーの中では、開発環境でも起こっていたけど気づかずにリリースされてしまったものも含まれていたため、eslintも合わせて導入しています。
これは各個人の開発環境と、GitLabに連携したJenkinsのCI/CD環境で動作しており、前者はデプロイ前にエラーが出ていないことの確認に、後者はエンジニア全体に共有するためノレポーティングとして活用しています。
なので、リリース前にエラーを最小にする＋サービス上で発生していたエラーを早期検知できるようにするという２段構えでJSエラーへの対応を行なっています
運用していてよかったこと・課題感
ざっくりとですが、
よかったこと
- 品質メトリクスとしてエラー件数が可視化ができること（共通の品質目標としてエラー0件を目指すんだ！と言えることと、実際に件数が見えること）
- 発生しているデバイス・ブラウザの情報が取れるため、原因の特定にかかる調査時間が短縮できること
課題感
- 動作保証ブラウザで発生以外からのエラーレポートが雑音になる
- タグマネージャによってソースコード管理外でHTML内に挿入されるJSのエラーの場合、検知しても問題の特定に時間がかかるケースがある（ソースコードから追えないため）
- ダッシュボードなどまだ効果的に活用しきれていない部分がある。
です。
自分自身がサーバの経験の方が長く、フロントエンド分野について全てが把握できているわけではないため、技術寄り視点というよりは管理寄りな視点での感想となってしまいましたが上記のように感じています。
その他、エラー検知だけでなくパフォーマンス計測にもSentryを活用すべく、Performance Monitoring の運用も並行して進めていてその内容についても改めて共有します。
