なんとなく使っていたSentryに向き合い始めた話 / Recently, we have been facing Sentry.

Sentry本国のエンジニア登壇！Sentry 活用できてる？利用企業から学ぶエラー管理LT - connpass
https://findy.connpass.com/event/292659/

---
運用/開発と分かれていたチームが過去に導入してなんとなく使っていたSentryに、ちゃんと活用しようと向き合い始めた話です

Transcript

1. なんとなく使っていたSentryに 向き合い始めた話 2023/8/30 1 髙野 将 a.k.a @masaru_b_cl
2. 2 ⾃⼰紹介 髙野 将 a.k.a @masaru_b_cl 産業⽀援グループ ⼩売流通ソリューション部 Devチームマネージャー
3. prismatixとは︖
4. 4 prismatixとは︖ l EC / CRM 特化型 PaaS l クラスメソッドのB2B⾃社プロダクト l エンゲージメントコマース l 伴⾛型コンサルティング https://prismatix.jp/
5. 5 EC / CRM システムの課題 l パッケージの限界 l 複雑なシステム連携 l 帯に短し襷に⻑し
6. 6 EC / CRM システムの課題 l パッケージの限界 → ヘッドレスコマース l 複雑なシステム連携 → 700を超える汎⽤API l 帯に短し襷に⻑し → マイクロサービス
7. 7 プロダクトの特徴 シングルテナントで環境を構築・提供 l 顧客と⽤途ごとに独⽴した環境を提供 l 本番⽤ / ステージング⽤ / 開発⽤ / 性能試験⽤ など l 必要なマイクロサービスだけ構築 l 認証のみ / 認証と会員基盤 / 認証とEC基盤 など l フロントシステム側でAPIを組み合わせて機能を実現 l 専任のソリューションアーキテクトが導⼊⽀援
8. 8 チーム体制 いわゆる機能別組織 l Devチーム︓開発担当 l アプリの機能追加・改善 l Kibanチーム︓運⽤担当 l アプリ実⾏環境構築・設定変更・維持管理 l CSチーム︓顧客担当 l 導⼊⽀援、顧客サポート窓⼝、要望や問題などの課題解決
9. 9 Agenda l Sentry導⼊〜これまで l 今取り組んでいること l チームに起きた変化
10. Sentry導⼊〜これまで
11. 11 Sentry導⼊ 「モダンな運⽤」をしたかった運⽤担当が主導 l 開発担当の積極的な巻き込みはなかった l アプリに⼿を⼊れずに導⼊する⽅法を選択 l エラーログを元にSentryに連携する仕組みを構築 AWS Cloud 1 Amazon ECS マイクロサービス コンテナ Amazon CloudWach Logs AWS Lambda Put lerror ogs Subscribe error log Capture message AWS Cloud 2 AWS Cloud n
12. 12 導⼊してどうなった︖ あまり活⽤されず……
13. 13 導⼊してどうなった︖ あまり活⽤されず…… l 開発側には「⾒たければ権限付与します」という共有だけ l 誰もが気軽に⾒れる状態ではなかった l 活⽤⽅法および処理フローを決めていなかった l Sentry Issueを⾒て気づいた運⽤担当が そのことを開発担当に知らせたりはしていた l 開発担当が積極的にアプリ修正につなげるような感じではない
14. 導⼊から1年後
15. 16 導⼊から1年後 エラーを処理するプロセスを決めた
16. 18 エラーを処理するプロセスを決めた エラーごとに対応マニュアルを作って処理する 1. 運⽤担当︓マニュアルを開発担当に作成依頼 2. 開発担当︓マニュアルを作成して運⽤担当に処理依頼 3. 運⽤担当︓作成されたマニュアルを参照して処理
17. それからしばらくして何が起きたか︖
18. 20 それからしばらくして何が起きたか︖ エラー処理の⼿間が増え続け 運⽤負荷が増⼤した
19. 21 直接的な要因 顧客の増加に伴って エラーもマニュアルも増え続けたため
20. 22 根本原因 エラー処理の⽬的がうまく共有されていなかった l 開発担当︓ マニュアルは作るが処理は運⽤にお任せ l ⽇々どれだけエラーが発⽣しているかを知らない l エラー処理にどれだけ⼿間がかかっているかを知らない l 運⽤担当︓ マニュアルで処理はするがアプリのことは開発にお任せ l なぜそのエラーが発⽣するかを知らない l どうやったらエラーが発⽣しなくなるかを知らない 分断がある
21. いま 取り組んでいる こと
22. 24 いま取り組んでいること エラー処理を開発担当の責務にする
23. 25 エラー処理を開発担当の責務にする エラー処理を 楽にしたい という動機を⽣む l ⾃分たちが処理することで ⾯倒事 に気付けるようになる l ⾯倒に感じれば 改善したい という気持ちが⽣まれる
24. 26 実際何をやっているか 〜 その１ 開発担当がエラーの仕分けと処理をする l マニュアルを探して対応要否の判定、対応依頼を実施 l データ補正など権限が必要なものは運⽤担当に依頼 l エラー処理の 課題 を⾒つけ出して対処する l 対応不要なエラーを発⽣させないようアプリを修正する l 対処がしやすいエラーメッセージに修正する l マニュアルを⾒つけやすくわかりやすくする
25. 27 実際何をやっているか 〜 その２ Sentry連携の仕組み⾒直し l 処理しやすいように Lambda を改善 l ⾊々なエラーが単⼀の Issue にまとまってしまっていた l 例外名から fingerprint を⽣み出していたため l 扱いたい単位で⼀つの Issue にする l マイクロサービスや内部例外の違いを考慮する l 対処不要ならIgnoreしやすくなる l Ignore してできた余裕を アプリ改善 に向ける
26. 28 チームに起きた変化
27. 29 チームに起きた変化 エラーを意識したふるまいが 少しずつ⾒えてきた
28. 30 チームに起きた変化 エラーを意識したふるまいが少しずつ⾒えてきた l 「エラーを減らせるタスクを先にやったほうがいい」 みたいな意⾒が⾃発的に出てきた l 「このサービスのエラーなんかいつもより多くない︖」 みたいな発⾔が出てきた l 他のメンバーが作ったマニュアルについても 改善点を相談するようになった
29. 最後に
30. 32 最後に エラーはプロダクト開発にとっての 学び l 想定外 を 想定内 にするための元ネタ l 考慮していなかった使われ⽅ l 思ってもいなかったアクセス量 l あると思っていなかった外部システムの挙動 l 運⽤/開発担当だからと思わず ⼀緒に取り組もう l 組織としてのパフォーマンスアップにつながる