プロダクト開発を行っている皆さん、ちゃんとエラー管理してますか？
この問いに自身を持って「はいっ！」と答えられる人は結構少数派ではないでしょうか？
かくいう我々「戦略的OMOを実現するプラットフォーム prismatix」の開発チームもその少数派の一員で、なんとなくエラー管理SaaSの Sentry を導入して使ってみてはいたものの、いまいち使いこなせていないなと感じている状況でした。
そんなとき、Findy社主催のイベント「Sentry本国のエンジニア登壇！Sentry 活用できてる？利用企業から学ぶエラー管理LT - connpass」に登壇しないかとオファーをいただきました。
近年、多くの企業が開発生産性向上のためにDevOpsツールに注目しています。中でもエラー管理はサービスの信頼性向上、ユーザーエクスペリエンスの向上に寄与する重要なファクターです。日本では、すでに800社以上の企業がこのエラー管理のために、Sentryを導入しています。一方で、その機能を十分に活用できている企業は多くないのが現状です。
本イベントでは、海外の企業でSentryを活用している事例や、日本国内の企業でツールを活用してエラー管理体制を構築しているエンジニアの方々にお話いただきます。その有用性やベストプラクティス、失敗経験、工夫している点などの知見を広く共有することで、より生産性を高めた状態を目指します。
我々がどう使っているかを整理でき、他社ではどう使っているのかの事例を知れるいい機会と思い、二つ返事で登壇させていただくことにしました。
本エントリはその登壇内容の紹介、並びに参加レポートです。
イベント動画
LT
LT①『なんとなく使っていたSentryに向き合い始めた話』
私の発表です。
元々は数年前に「運用担当」が主導してSentryを導入しましたが、どう活用するかや運用フローを決めずに遊ばせていたところから、役割を決めて運用を始めた段階、そして今取り組んでいる「開発者がエラーを主体的に見る」ことを紹介しました。
この資料をまとめる中で、改めて「開発と運用は一体である」ということを強く感じました。まだ「開発者がエラーを見る」活動に取り組み始めたばかりですが、すでに少し意識が変わってきたのを感じています。今後さらにどのように変化していくのか、またこのブログなどで紹介できればと思います。
LT②『1人で頑張らない！チームでSentryを活用するエラー管理体制の構築について 』
営業行動支援システム「Magic Moment Playbook」を提供している株式会社Magic Moment(株式会社マジックモーメント) 様のフロントエンドテックリードである石田さん(@solnce3)の発表です。
我々のprismatixとは違い、Webフロントエンド(React / SPA)のエラー管理でSentryを活用していて、その運用に関するあれやこれについてお話を聞けました。チームでエラーを管理する上での課題感については、わたしたちの組織でもやはり同じようなものがあり、どこでも大変そうで親近感が湧きました。
そんな中でも、大事なのはタイトルにもある通り「チームで」エラーを見るんだという体制を作っていくことなんだなというのを、改めて感じました。属人化することで負荷が集中したり、いざというときに何もできないという状況が一番怖いことであり、仕組みとして解消するように取り組んでいるのが印象的でした。
また、「3回発生したら調査対象のエラーとする」といった、ある程度のしきい値を設けるというのも、良い取り組みだなと思いました。エラーはそれこそ大量に発生するので、すべてに等しく迅速に対処しようとしても限界があります。そこで「3回」というしきい値を設けることで、取り組むべき問題に集中できるルールを作る、というのは我々もぜひ取り込んでいきたいと思います。なお、なぜ「3回」なのかについてはイベント内で質問があり、「最初エイヤで3回と決めたが、実際に計測してみたら2回以下はほぼ発生しないエラーで、3回以上は継続的に発生するエラーであることが多かった」ということでした。
LT③「食べログフロントエンドのエラー管理について」
グルメ・レストラン予約サイト「食べログ」を運営する株式会社カカクコム様のフロントエンドエンジニアである遠藤さん(@shikky0331)の発表です。
フロントエンドのエラー管理の場合、発生しているユーザーやブラウザも知ることができるので、それを活用した運用方法が印象的でした。
例えば、発生しているユーザー数が多い順にソートしたり、10名以上で発生したらアラート通知するようにすることで、「多くのユーザーで発生している→環境でなくアプリの問題である可能性が高い」と判断したり、サポートブラウザ内外で切り分けたりと言った感じです。
また、PVも19億/月と大量のため、「エラーをいつ見るか」の運用手順も参考になりました。
- アラートは即時
- アラートにならなかった新規エラーは日次
- 既存エラーは月次
この考え方も今後我々で取り組んでいきたいなと思える発表でした。
LT④「Sentry本国のエンジニアによるエラー管理のケーススタディ（日本語字幕付き）」
※資料公開されたら埋め込みます
最後は、日本のSentry公認販売業者であるIchizoku様より、Sentryの事例紹介です。
「これでもか」というほどのSentryフル活用ぶりが見れて、「こんな事もできるのか」「まだまだやれることはたくさんある」という驚きがたくさんありました。
中でも、CI/CDの自動化を勧め、新バージョンデプロイにSentryで問題を検知したら、自動でロールバックのデプロイを行う仕組みが印象に残りました。これは結果的に「安心してデプロイできる」ことに繋がり、開発者の挑戦、やってみるをサポートする非常に良い仕組みだなと感じました。
紹介された各種の機能は、背景が違うためそのまますぐに活用というわけにはいきませんが、取りうる武器の一つとして覚えておきたいと思います。
まとめ
各社のエラー管理の様々な事情が聞けて非常に面白かったです。自分たちと同じような課題を持っているところ、それを組織として解決しようとしているところ、ツールの機能を使いこなして解決しているところなど、可能性を感じるいいイベントでした。
Sentryを知らない方、知っているがうまく活用できていないなーと感じている方は、Ichizoku様から日本語リソースが公開されているので、まずはこちらからSentryを知っていってはいかがでしょうか？
2
