はじめに
マーケティング開発チームの鷹野です。私のチームは、サービス紹介のページ作成やシステムのフロントエンド部分を主に担当しており、日々プロダクトの開発や改善に取り組んでいます。新卒で入社して1年目が過ぎ、2年目を迎えようとした矢先、予期せぬタイミングで慌ただしい状況に直面しました。
システムを取り扱っている以上、インシデントは避けられません。しかし、私たちのチームが担当するプロダクトは比較的インシデントが少なく、どこかで油断していた自分がいました。
そのようなことは関係なく先日インシデントは突然やってきました。
本記事では、インシデント対応の経験が少ない私がどのように対応したか、そしてその中で得た学びについてお伝えします。
エラーログの確認
インシデントを受けて、最初に確認したのはエラーログでした。
ログ画面を開くと、口座開設申し込みのプロセス中に発生したabortedエラーが記録されていました。
しかしそれ以上の詳細な情報はありませんでした。
わかっていることは、画像アップロード時にエラーが発生し、その後ユーザーが何度か再試行した結果、最終的には口座開設申し込み完了画面に進んだということだけでした。
そのため、ユーザーと同じ状況を再現し、エラーの原因を特定する必要があると考え調査に移りました。
調査
1. stg環境での仮説検証
まずabortedエラーによってリクエストが中断された原因は何が考えられるか洗い出しました。
- ブラウザのタイムアウト
- ネットワークの速度や接続
- ファイルの容量
- サーバー側のリソース不足 など
インシデントが頻繁に発生していないことから、ユーザーの環境や操作が原因である可能性が高いと考え、アップロードする画像のファイル容量やネットワーク環境の問題の可能性が高いと推測しました。
そのため以下のパターンでネットワーク環境とファイル容量を変えた場合の挙動を確認しました。
- パターン1（通信速度：3G、画像サイズ：10KB×4枚）
- パターン2（通信速度：4G、画像サイズ：1MB×4枚）
- パターン3（通信速度：3G、画像サイズ：1MB×4枚）
2. 結果
- パターン1（3G、10KBの画像×4枚）は問題なくアップロード成功。
- パターン2（4G、1MBの画像×4枚）は問題なくアップロード成功。
- パターン3（3G、1MBの画像×4枚）はリクエストにかかる70秒ほどかかり、最終的にアップロードに失敗し、モーダルでメッセージが表示されました。
ログを確認しにいくと同様のabortedエラーのログが確認でき、再現に成功しました！
パターン3に関してリクエストに長い時間がかかっており、おそらくタイムアウトしたのだろうとわかりました。
実装を確認すると70秒を超えたらブラウザがタイムアウトとなり、リクエストが中止する仕組みになっていました。
3. 結果の検証
検証結果が偶然によるものではないことを確認するため、パターンごとのリクエストにかかる時間を計算しました。その結果、パターン3のみが70秒を超えており、ユーザーのネットワーク環境とファイル容量が原因であることが明確に特定できました。
パターン1：3G (400Kbps)10KBの画像×4枚
- アップロード速度：
- 400Kbps = 50KB/s
- 合計データ量：
- 10KB × 4 = 40KB
- アップロード時間：
- 40KB ÷ 50KB/s = 0.8秒
パターン2：4G (8.2Mbps)1MBの画像×4枚
- アップロード速度：
- 8.2Mbps = 1.025MB/s
- 合計データ量：
- 1MB × 4 = 4MB
- アップロード時間：
- 4MB ÷ 1.025MB/s ≈ 3.9秒
パターン3：3G (400Kbps)1MBの画像×4枚
- アップロード速度：
- 400Kbps = 50KB/s
- 合計データ量：
- 1MB × 4 = 4MB = 4000KB
- アップロード時間：
- 4000KB ÷ 50KB/s = 80秒
4. まとめ
今回のインシデントはユーザーの環境や操作による違いが原因で発生しました。しかし、リクエストが送信できなかった際にユーザーにはエラーメッセージで適切に理由が伝えられ、その後口座開設申し込み完了画面まで進んでいることが確認されているため、ユーザー体験に大きな影響はありませんでした。
インシデント対応で学んだこと
今回のインシデント対応を通じて、ユーザーの画面や環境が分からない状態で原因を考えることの難しさを実感しました。そのため、限られた情報から論理的に原因を推測し、調査を進めることが重要だと感じました。今回の再現調査ではネットワーク速度やファイル容量の影響をおおまかに進めただけでしたので、再現ができていなかった可能性もあり、もし最初からブラウザのタイムリミット設定を調べていれば、より迅速かつ確実に行えたと考えています。
また、ログの重要性を改めて認識しました。今回のabortedエラーのように具体的な原因が分かりにくいログでは、問題の特定に時間がかかります。ユーザーへの影響を最小限に抑えるためには、インシデント発生時に迅速な対応が求められます。そのため、エラー発生時に原因を特定しやすいログを用意し、品質を維持することが重要だと感じました。
Discussion