はじめに
株式会社ペライチのフロントエンドエンジニアの関です。
弊社では新人からベテランエンジニアまで一丸となってプロダクト開発を行っています。
設計・実装といったアウトプットはレビュープロセス[1]により品質の一定化を目指すしくみがあります。一方、それ以外のたとえばトラブル対応といった突発的で不確実性の高い業務では、エンジニアの経験・現場力への依存が大きく差が埋めにくいと感じています。
そこで今回テックブログ執筆の機会に合わせて、何気なくやっているバグ対応をナレッジ化してみようと考えました。まだまだトラブルシューティングやガイドといったマニュアルまでは落とし込めてませんが、何かしらの参考になれば幸いです。
※特定レイヤに限った話でもないと思いますが、Webアプリケーション開発のフロントエンドエンジニアという視点になっていることをご了承ください
📢 バグのエスカレーションを受けたら
バグに直面すると「なんで？どこが悪い？どう直そう」とつい考えてしまうかもしれません。ですが先に考えたいのは 今何をすべきか 優先順位の選別です。特に現場経験が浅いと見落としがちかもしれませんが、画面の先にいる大勢のユーザーを意識することはとても大事です。
何が起きているか、何ができるかを整理してみます。
例
| 項目 | 例 |
|---|---|
| 影響範囲 | 全ユーザーに影響、◯◯なユーザーに影響 etc... |
| 放置リスク | ◯◯といった実害がでる、使い勝手が悪くなる、etc... |
| 取れる手段 | 応急、根本、Revert、クローズ etc... |
| 想定時間 | 応急：N分、根本：不明、Revert：10分 etc... |
| リソース状況 | 対応者のアサイン可否、レビュー者のアサイン可否 etc... |
状況を言語化するとメンバー間での認識齟齬も防ぎやすいのでお勧めです。大したバグだと思っていなかった😨最優先でやるべきだと思っていた😨など少しのコミュニケーション不足で不用意に時間を使ってしまうことは珍しくありません。
状況から複合的に判断しいま何をすべきかを意思決定します。もちろん自分ひとりで判断できない、すべきではないことはチームや上長を巻き込んで進めましょう。
対応例
- 最優先でバグ対応（応急 or 根本）に取り掛かる
- ひとまずRevertして機能自体を取り消す
- ひとまず部分的にメンテナンス状態や入り口を潰したりして使えないようにする
- ひとまず通知する
- ひとまずissueを立て課題に積みつつ放っておく
- etc...
🕵️ バグ調査
さて、無事（？）にバグ調査が始まったらいかにすばやく原因を突き止められるか、腕の見せ所です。ここでは例として以下3ステップで調査していきます。
再現させる
↓
影響コードを見つける
↓
原因を見つける
再現させて自分の目で確認しよう
弊社ではサービスごとに 開発・テスト・本番 といった環境を用意しています。どの環境まで再現できるかによって、取れる手段が変わってきます。基本は開発環境で再現させることを目指します。
| 項目 | アクセス可能な範囲 |
|---|---|
| 開発環境 | エンジニアごと |
| テスト環境 | 主に社内メンバー。本番に近いデータが格納（ペライチでは複数存在） |
| 本番環境 | 全ユーザー |
開発環境でも再現できた
手元の開発で再現させることができれば9割方は何とかなります（個人の感想です）。
開発環境は自由に弄くり回せるので、引き出しを増やしておくとスピードが出ます。
影響コードを見つけよう
複雑なコードやドメイン知識のない機能は時間が掛かってしまいがちです。
開発環境なら大胆なアプローチができるので、いろいろと試して影響コードを探します。
- エラー情報を収集する
- commitを適当に切り替えて影響commitを絞り込む
- ファイルやコードを適当に消して影響箇所を絞込む
- データを空にしたり改ざんしたり... etc
影響コードから原因を見つけよう
コードが絞り込めたら原因を探ります。
デバッグ手法としてフロントエンドでは以下覚えておくと便利です。
テスト環境でも再現できた
開発環境では再現できないケースもあります。
取れる手段は減りますが、逆にそこがヒントにもなります。
影響コードを見つけよう
- エラー情報を収集する
- DB・URL・環境変数・インフラ構成など開発環境と違うところを重点的に探る
- devtoolのブレークポイント機能を使って影響箇所を絞り込む... etc
影響コードから原因を見つけよう
バグへの解像度があがり、開発環境でも再現できるようになれば前述の通りです。
どうしても開発環境で再現できない場合は、調査ブランチを作って反映させたり、直接コードを書き換えたりして原因を探っていきます。
本番環境のみ再現できた
本番でしか再現できないケースもあります。
さらに取れる手段は減り工数も増してくることが多いです。
影響コードを見つけよう
- エラー情報を収集する
- ファイアウォール・アクセス数など・外部APIの設定など、さらに開発・テスト環境と違うところを重点的に探る
- devtoolのブレークポイント機能を使って影響箇所を絞り込む... etc
影響コードから原因を見つけよう
開発・テスト環境と違って気軽にコードを書き換えることはできません。
どうしてもテスト環境以下で再現できない場合は、アプリケーションに影響の出ないようログを仕込んでリリースしたり、逆に開発・テスト環境で再現させられるよう改善をも視野に入れます。
🧗 バグ調査でつまずいたとき
影響コードが見つからない、もしくは原因がまったく分からない
再現から先が。。。という状態に陥ることがあります。
コードが難解で理解できていない可能性もありますが、そもそも再現条件を把握できていないケースも考えてみます。コードは要因のひとつに過ぎず何か別のものと重なってバグを引き起こしているかもしれません。
- 情報の解像度を上げる。事実と推測が混じっていないか。前提条件が間違っていないか
- 社内ドキュメントやSlackなど先人たちの知見がないか
- 該当コードだけ抜き出して単体もしくは別環境で実行したらどうなるか
- 該当機能に詳しそうな人へ相談する
そもそも再現できない
誤認もしくは情報不足によりバグの全容を把握できていない可能性があります。
エスカレーションもとやユーザーへのヒアリングなども含めて情報収集が必要かもしれません。
- 開発側で取得できる情報を集める
- ユーザー情報、アクセス情報、ログ情報 etc...
- あらためて情報を整理し、事実と推測が混じっていないか確認する
- 再現できている人にヒアリングを行う
- 再現の手順に認識齟齬はないか
- 環境を変えるとどうなるか（シークレットやゲストモード、ブラウザやデバイス変える）
- 何かスクリプトエラーは出ていないか
♻️ バグ対応の後はチャンス
対応お疲れ様でした！
さて次の仕事へ、と終わる前に、簡単でもよいので振り返りすることをお勧めします。エンジニア・チーム・プロダクトどれも成長できるチャンスです。
- バグを起こしたコードに改善ポイントはないか
- 調査プロセスに改善ポイントはないか
- エスカレーションに改善ポイントはないか... etc
終わりに
ペライチでは未経験から始め最前線で活躍を続けているエンジニアも多くいます。現場に出てどんどん成長したい、情熱あふれるエンジニアを募集しています！！
採用情報
現在エンジニア募集しています！
▼ 採用ページ
▼ 選考をご希望の方はこちら（募集職種一覧）
▼ まずはカジュアル面談をご希望の方はこちら
募集中の職種についてご興味がある方は、お気軽にお申し込みください（CTO がお会いします）
-
弊社のレビュー文化については以下記事をご覧ください。
ペライチ流のコードレビューをご紹介します ↩︎ -
console.logにオブジェクトや配列を渡すと、意図しない値が出力される可能性に注意しましょう。 ↩︎
-
devtoolとブレークポイントについて昔自分で書いた記事があるのでリンクを貼っておきます（古い記事ですが、まぁ今も使えると思うので...） https://qiita.com/nekoneko-wanwan/items/02aed17773833c3ad3b2 ↩︎
Discussion