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