$30 off During Our Annual Pro Sale. View Details »

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

zosokh
April 09, 2022
3.5k

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

zosokh

April 09, 2022
Tweet

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設定

    👉1つでも多く(できればインパクトの大きいものから)エラーを少なくしてゆく
  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/