MIXI DEVELOPERS NOTE
💁‍♂️

バグ報告が来た時にデキるエンジニアの動き方

2024/05/28に公開

❗❗問題発生❗❗



作った機能のバグの発見報告が上がってきました。

この時点で何となく 「ヤバさ」「あたり」 を自分の中でつけます

  • 売上に響くやばい?
  • 条件がある?全員?
  • ボタンが押せないならクライアントだし、API飛んで成功してないならサーバ?届いてないならネットワークもあるか。
  • モバイル、Webどっち?両方?
  • そもそもどこの環境?開発中のもの?
  • 購入ボタンってどこのこと?特定のアイテム?それとも全部?
  • 購入できてないってどういうこと?DBはどうなってる?

まずは 👀 をつける

これは 「見ていますよ」 という表現です。
もしくはリプライで 「見ます!」 と宣言するのも良いですね。

これにより投稿者は 「対応してくれるな」 と安心できます。

必要な情報をもらう

  • 発生している環境
  • 発生時間
  • アカウント名+ログイン情報
  • スクリーンショット・録画

この時点で試せることは色々試してもらいます。ただしブラウザのリロードや、アプリ・端末の再起動などは再現しなくなる可能性があるので、避けてもらうようにしましょう。

また、QAチームがいる場合は再現手順を探してもらいましょう。
自分たちが調査するときに再現手順があると簡単に調査を進めることができます。

本番環境でも発生しているかさっと見る

問題によっては本番環境でも同じことが起きている可能性があります。
本番で起きている場合は一気に優先度が上がるため確認しておきましょう。

万が一起きている場合は、今時点でわかる範囲でまとめて上長にエスカレーションし、プロジェクトやチームで規定しているインシデントハンドリングに移りましょう。

  • 影響範囲
  • 発生条件
  • 起きている事象
  • ユーザが被る不利益

などをまとめて調査していく感じです。この時点で問題が大きいなら、サービスをメンテナンスにいれる判断もあります。

ざっくり調査する


システム構成によりますが問題の多くは

  • クライアント
  • サーバ
  • インフラ
  • その他

に大別できます。

まずはログを見たり発生しているアカウント情報をもらって切り分けしましょう。

例えばこんな感じに調査します。

※わかりやすさのために簡単にしていますが実際はもっと複雑です
※例えば 403 forbidden の場合、図ではクライアントの問題ですがサーバで誤って判定してるならサーバが問題です

切り分けしたら、担当者/担当チームにメンションを飛ばしましょう。(ただし本番で起きている問題など、解決が急務な場合は初めから関係してそうな全チームにメンションを送ると良いです)

確度が高くなくても問題ぽいものをみつけたら書き込む

  • エラーメッセージ、エラーログ
  • 似てる issue
  • 過去の slack メッセージ

など、とりあえず事象に似ている・関係ありそうな情報を貼り付けます。問題が起きた時に一発で根本原因を探れることは少ないので、まずはあたりをつけるために類似の事象をせめます。

自分が見つけた情報を他の人はまだ見つけていないことも多々ありますので、積極的に貼り付けましょう。オフラインで話していたとしても書くことをお勧めします。

  • ログに残るので後で振り返れる
  • オフラインメンバーも参加できる
  • 書くと自然と整理される
  • 質問した人も調査してくれてるという安心感が生まれる
  • 意思決定者が判断を下しやすくなる(そこまでコストかけるなら追わなくていいよとか)

そんなことをしていると、いろんな観点から情報が集まり集合知で解法に向かいます。

問題が難しく、スレッドが長くなったら

まずは GitHub Issue を立てましょう。(他にもチームによってやっているやり方があると思うのでそれに合わせて構いません)

投稿が長くなるということは問題が複雑であったり、原因が解明できない状態です。

このあとバグをみつけ直す時にも、時系列がまとまっている方がレビューしやすいので、一度起きたこと、考えられる問題、無視できることなどをまとめましょう。

リアルタイムで情報を書き込む必要がある問題の場合は Goole Docs などのリアルタイムに複数人で書き込めるツールがお勧めです。特に時系列に事象をまとめるときに強力です。

そして解決 or お蔵入りへ

問題がわかったら直すor直さないの判断。
わからなかったら回避策or放置の判断。

って感じですかね。

バグ調査のうまみ

バグ調査は格好のスキルアップの機会です。
(迷惑をかけている手前大きな声では言えませんが…)

バグ発生時にはシステム全体の構成から事象の切り分けを行うことも多いので、クライアント・サーバ・インフラの知識が必要です。そして特定した後はそのドメインの知識が必要になります。

これだけでも相当です。

また、サービス独自で使っているいろんなサービスなシステムの問題の場合もあるので、その知見も溜まります。(例えばマスターデータや、管理ツール、運用スクリプト、外部サービスなど)

また、調査結果や問題の要点をまとめるには文書作成スキル要点を掴む力も必要になりますし、適切にエスカレーションをしなければならないので勘所も養われます。

ということで大変ですがいいことづくめなのでぜひやっていきましょう!

MIXI DEVELOPERS NOTE
MIXI DEVELOPERS NOTE

Discussion