不具合調査手順をまとめてみた！

こんにちは。CREエンジニアの田中です。日々不具合の調査や対応をしています。

今回は、日頃行っている不具合調査の手順をまとめてみたいと思います！

ひとえに不具合といっても、色々なパターンがあるので、今回の記事では、「Webアプリケーションの不具合」の場合をイメージしてまとめてみます。

調査手順

CS(カスタマーサポート)から、不具合のお問い合わせの連絡をいただく
1. 問い合わせ内容の確認
2. 調査に必要な情報をヒアリング
  1. CSからお客様に質問してもらう
3. 不具合検知のツールでエラーログが吐かれているか確認
  1. bugsnagを利用しています(Datadogに移行予定)
再現確認
1. 再現手順がわかっている場合
  1. 自分の環境でも再現できるかの確認
  2. ブラウザのdevtool>networkタブで問題となる処理を確認する　　　
    1. 1-cで把握できている場合もある
2. 再現手順がわかっていない場合
  1. きつい。。この場合、自分であれこれ確認しにいきます
  2. それでも、再現手順が分からない＝CSの方やテスターの方が確認して分からないということ
    1. エンジニア視点で、不具合の絞り込みをする ⇒ 3へ進む
ソースコードを確認
1. エディタの検索ツールで、エンドポイント or 関数名を検索　
  1. 上流のControllerから問題となる処理箇所まで追っていく
2. デバッグをする
  1. デバッグのプラグイン(Xdebugなど)を入れていれば、ツールのブレイクポイント置いて、デバッグ
  2. 各言語やフレームワークのデバッグ方法でデバッグする
    1. 弊社はLaravelを用いているので、loggerヘルパーだったり、Facadesのクラスを利用してログを出力しています
3. 問題を切り分ける
  1. 自社のソースコード or 連携している外部サービスが問題かを切り分ける
    1. 自社のソースコードの場合、デバッグをしていけば、原因は突き止められる(はず)
      1. 勿論、ネットワークやインフラなど、ソースコードのレベルではない場合はあるので、問題が何なのかを切り分ける
    2. 連携している外部サービスの場合
      1. 社内の詳しい人とコミュニケーションを取る or 外部サービスの窓口の方に質問する
原因を特定
1. 3の作業を進めていくと、不具合の詳細や原因が突き止められる
  1. 原因が突き止められなかったにせよ、少なくとも、最初のお問合せ時点での不具合内容(実際の不具合状況とは異なる場合が割とある)よりは、詳細になっている
2. 調査内容を情報を起票されたチケットやスレッドに記載していく
  1. 現在CREチームでは、調査の効率化目的で、対応した不具合に対して、メモを残すようにしている(Notion)
  2. 対応後、メモ→ドキュメントにしていくことで、対応の可視化をし、フローの洗練を行なっている
CSや関係者に進捗や原因を報告
エンジニアに依頼 or 自分で対応
1. 依頼する際は、調査結果、該当部分のGithubリンクと不具合のチケットリンクをまとめて送っている
  1. 依頼先のエンジニアがスムーズに不具合内容の把握改修作業に取り組めるように、なるべく簡潔かつMECEになるよう心がけている(ただ、いつも長くなってしまう、、)