エラー監視とテスト体制への改善作戦 / PHPerKaigi2022

Transcript

1. エラー監視とテスト体制への改 善作戦 2022/04/09 #phperkaigi @zosokh
2. ヒエイカザト 株式会社ウエディングパーク Photorait サーバーサイドエンジニア・チーフ エンジニア 　　@zosokh #野球観戦　#ちなヤク🐧 #娘は2歳
3. Photorait フォトレイト フォトウエディング、前撮りなど結婚 写真の撮影スタジオ・サロンを検索 できる情報サイト www.photorait.net
4. 今日の話 • 以下の流れで話を進めてゆきます エラー監視体制の話 テストコード体制の話 施策活動の活性化
5. エラー監視体制について サービスのエラー監視と向き合い方
6. これから話すエラーとは • アプリケーションエラー ◦ バグ起因、SQL、負荷 • クライアントサイドで発生したエラー つまりアプリケーション側ソース経由で発生したエラー全般
7. ところで みなさんエラーログ見ていますか？
8. あまり見れていませんでした
9. エラー監視：Sentryの活用 • Photoraitではエラー検知にSentryを利用 • 数年前から使っている。 • PHPエラーだけでなく、js側エラーも拾える • ブラウザで確認出来る。通知など便利
10. Sentry
11. じゃあエラーへの監視は万全だね 先述通りあまり見れていませんでした。 新規のエラーは出てないかな・・ぐらい。
12. じゃあエラーへの監視は万全だね 場当たり的なエラー解消は品質向上にはならない。 👉アプリケーションチームで監視体制を作った話
13. 監視体制以前 • とにかくエラーがい・ろ・い・ろ出ている • 新規issue（エラー単位）発生時にslack通知が沢山くる • リリース時はSentryのエラーを見て、「リリース物」からエラーが出てない かは見ていた • 自分のリリース物以外のエラーには、あまり関心なし。 ◦ 既存のエラーね〜 • メイン開発タスクで手一杯 いつかエラーの大掃除をしたい
14. 問題点をまとめる • 明確な監視体制がない • どんなエラーが出ていて、どれだけのエラー数があるのか把握しきれてい ない。 • エラー解消対応に手が回っていない。
15. 体制を築くアクション • エラーの数と内容を把握する • エラー数を定点観測 • 対応フローを決める • 週次エラー数値を目標に置く
16. エラーを知る • 発生したissue数やエラー内容を開発陣が俯瞰して見れる必要がある ◦ 自動集計させる • プロジェクト毎に発生したissue数は毎週slackに通知するようにする • 開発陣は通知と集計結果が見れる画面から対応すべきエラーを探す事が できる 👉スプレッドシートに集計させる
17. 自動集計スクリプトの作成 Sentry apiを使用 • List a Project'sエンドポイントを使ってエラー一覧を取得 ◦ https://docs.sentry.io/api/events/list-a-projects-issues/ curl https://sentry.io/api/0/projects/{organization_slug}/{project_slug}/issues/?query=is:unresolved&statsPeriod=14d \ -H 'Authorization: Bearer <auth_token>'
18. issueに対するエラー 数を集計 [ { … "permalink": "Sentryのエラー画面URL", "platform": "PHP", "metadata": { "value": "Fatal Error (0): Call to a member function result()....." }, … "stats": { "14d": [ [ 1541455200, // timestamp 473 // error count ], … ] }, … "title": "This is an example PHP exception" } ] • 14d制限でリクエスト • エラー内訳取得 • stats内のパラメータに日付事 のエラー数が格納 https://docs.sentry.io/api/events/list-a-projects-issues/
19. 集計と通知を自動化 集計内容はスプレッドシート吐き出しと、slack通知も行う。
20. issue数を一覧化 issue数をグラフ化 エラー一覧
21. 集計フロー issue数やエラー内訳、エラー数をスプレッドシートに吐き出し • 週毎に集計を実行 • issue毎のエラー数を可視化 ◦ エラータイトル・内容・週間エラー数・SentryのURLなど • グラフ化する事でissue数の遷移を確認 このシートからサイトのエラー対処履歴も追う
22. 対応と監視フロー 通知と集計シートを使って改善実対応をします。 • エラー数の目標を開発陣全員で設定。 • 発生したエラー数が多いissueを優先度高として対応をする • 対応した（resolve・ignore）ものは必ずSentry内でコメント • 対応中のissueはassign設定 👉１つでも多く（できればインパクトの大きいものから）エラーを少なくしてゆく
23. 対応をはじめて • エラー数を定点観測してゆくと、現状のエラー内容を把握ができる • 最初は簡単に対処できるエラーが多い。サクサク削減対応が進む ◦ 「なんで野放しになってたんだ」の気持ちは持たない ◦ 数値が減っていくと楽しい • slack通知される新規issueへの会話が増えた
24. エラー対応フェーズの移行 • 解消できるエラーも減ってくる • 無視できるエラーもちょこちょこある ◦ ブラウザ拡張によるものなど、クライアントサイド側起因のエラー ◦ 突発的な通信エラー 対応基準を設定してゆく
25. エラー対応フェーズの移行 • 発生したエラー数によって対応閾値を定める • ルールとフローの厳格化
26. テストコードを書く チームでテストコードを書いてゆくために
27. エラー・バグを出さない 発生するエラーに対する監視と対応体制はできてきた NEXT ACTION • バグ起因のエラーを出さない体制 👉 テストコード
28. テストコードとチーム • テストコードを書く習慣がない ◦ 書く方法がわからない ◦ 書く環境がない ◦ 書いて何が良くなるのかわからない • いくつかは設置してあるテストコード • 書く人と書かない人がいる
29. テストコード体制のために • テストコードを書きやすい環境作成 • ルールとフロー作成 • テストコード量の把握
30. 環境作成 • Dockerでテスト実行 ◦ 他アプリケーションに依存しないテストコード設計 • GitLab CI上での自動テスト 誰でも実行しやすいphpunit テストコードの認知
31. PHPStormからDocker環境上でPHPUnitを実行させる。 PHPStormでのPHPUnit Preferences > PHP > CLI Interpreter > 「...」 「+」 > 「From Docker, Vagrant, VM, WSL, Remote...」 Preferences > PHP > Test Frameworks > 「+」 作ったRemote Interpreterを選択
32. PHPStormからDocker環境上でPHPUnitを実行させる。 PHPStormでのPHPUnit テストクラスやメソッドの ▶ボタンからテストを実行
33. カバレッジ値監視 • CI実行とGitLabでのカバレッジ監視 ◦ カバレッジ数値目標を設定しテストコードを拡張対応 レビュー時のテスト状態とカバレッジ値表示 GitLabにメインブランチのカバレッジ数値表示と GitLab Pagesを用いたカバレッジレポート閲覧
34. しかしうまくいかない • 既存プロジェクト（テストコード無し）にテストを書いてゆくのは大変。 • カバレッジ目標は達成できても、カバレッジ目標のためのテストコードにな る ◦ テストコード量産が目的になる。テストの質が下がる。 ◦ カバレッジ値に追われてしまう。 • テストコードを書いている人が偏る
35. 対応方針の改善をしてゆく • 目標達成に追われないカバレッジ値設定 ☞テストの質を担保 • テストコード設置タイミング決め ◦ リリースにテストコードを混ぜる。 ◦ E2Eテストとテストコードの棲み分け。 • ペアプロを用いたチームでのテストコードお作法の認識共有
36. 改善を繰り返す事で • テストコードによるエラー検知数が増える • CIによるエラー検知を無視させない • テストコード工数の見積もり精度が向上
37. 施策活動の活性化 チームへのアピール
38. 活動を事業メンバーにアピール エラー監視もテストコードもエンジニアが主導として動いている施策活動だが、 事業に関わるメンバーに職種関係なくアピールをする エンジニア以外の他職種メンバーへ活動を共有 →「活性化」 👉施策活動がサービスへの恩恵という理解につながる。 👉施策活動を応援してもらう事で、やる気がでる！
39. • 事業の定例で、紙芝居・スライドを用いてSentryやテストコード施策を紹 介 👉ディレクターや営業陣などエンジニア以外のチームメンバーへ分かりや すく施策を説明 • 減ってきたエラー数やテストカバレッジ進捗をチームに発表 👉数字という定量値は報告と応援がしやすい • テックブログに書く 👉全社へのアピール 活性化
40. 活性化を行って • 事業メンバーが施策活動の理解。エラー対策を施した際、リリース前に挙 動テストを一緒に行うことが増えた • 開発チーム（ディレクター・エンジニア）のテストコードへの工数認識が生ま れた
41. まとめ • Sentryを利用したエラー監視体制 • エラー数の集計と通知とグラフ化 • 対応ルールとフロー作成。フェーズづくり • テストコード環境作成と見える化 • カバレッジだけでは救われない • 習慣を作る事が大切 • 活性化活動によるチーム全員でのテスト・エラー監視 • 応援してもらう
42. ご静聴ありがとうございまし た。 以下でもエラー集計について書いてますので是非。 https://engineers.weddingpark.co.jp/sentry/