はじめに
不具合調査やパフォーマンス改善をするとき、どのくらい "手札" を持っていますか？
私はよく、細部に入り込みすぎて全体を見失うこともあれば、逆に全体に意識を向けすぎて手が止まることもあります。そんなとき、先輩エンジニアの問いかけで状況の見え方が変わります。
同じ情報を見ているはずなのに、切り分けの速さがまるで違う...！
この記事では、日々のやり取りの中で学んだ思考パターンを整理してみました。
調査 / 切り分けの思考パターン
1. まず全体を見る
- いきなり一点を疑わない
- まずは全体像を把握する
→ 局所ではなく構造を見る
2. 見る前に予測する
- ログやコードを開く前に「おそらくここだろう」を言語化する
- 仮説なしに掘り始めると、異常を見逃しやすい
→ 観測は仮説とセットで行う
3. 外から内へ絞る
- 全体 → サービス境界 → コンポーネント → コード の順に見る
- いきなりコードを読み始めない
→ スコープを段階的に狭める
4. 計測してから動く
- 「遅そう」「怪しそう」で修正しない
- APMやダッシュボードで実測してから手を動かす
→ 体感ではなく数値で判断する
5. 変化点を探す
- 「昨日まで正常だった」なら、変わったものを探す
- デプロイ・設定変更・トラフィック・依存サービスの更新など
→ 状態ではなく変化を見る
6. 1つずつ変える
- 複数の改善を同時に入れない
- 影響を限定し、すぐ戻せる形で小さく変更する
→ 小さく刻んで検証する
7. 調査ログを残す
- 何を見て・何を考え・なぜそう判断したかを書く
- 仮説と結果をセットで記録する
→ 思考の履歴を共有資産にする
8. 境界条件を叩く
- 「正常か異常か」だけでなく、「どこまでなら正常か」を探る
- 前提が破綻する条件を意図的に試す
→ 暗黙の前提をあぶり出す
9. 再現手順を最小化する
- 複雑な手順のまま調査しない
- 「これさえあれば再現する」という最小構成を見つける
- 不要なコードや依存関係を削ぎ落とし、純粋にその事象だけが発生する環境を作る
→ ノイズを排除する
まとめ
今回は、現場で学んだトラブルシューティングや意思決定のプロセスを言語化してみました。
鮮やかな課題解決を前にすると、つい "特別な魔法" があるように思えます。
ですがその差は、単なる経験や知識量だけではなく、不確実性を1つずつ削り落としていくプロセスの徹底にあるのだと思いました。
最後までお読みいただき、ありがとうございました！
この記事が、調査で行き詰まっている誰かの "手札" になれば幸いです。
Discussion
個人の経験的には、仮説を持って調べると大体遠回りな印象です。
ITにおけるトラブルは必ずコードの中に答えがあるので、学生の頃のテスト問題で言うなら、「答えは必ず問題文の中にある」タイプの問題しか出ません。
学生の頃を振り返るとその手の問題で失点してしまう人は大体「問題文を最初から最後までちゃんと読んでいない」だとか「中途半端に読んで理解した気になり自分の中で作り上げた前提や仮説で問題を解いてしまう」というようなパターンばかりです。
逆にこの手の問題で確実に点を取る学生は「丁寧すぎるくらい問題文を読む」、「自分の感情や意思を含めずに淡々と順に情報を整理する」が得意な人です。
仮説を持って問題を解き進めようとすると外れた時に大きく手戻り、また次の仮説を考えるところから始まり、となってテスト時間を大きく消耗します。
ある程度問題を解くのに慣れているのであれば、仮説が当たる確率も上がりますので戦略としてはありだと思います。
例えば、もし3×5=？という問題の解き方がわからない時、1番の近道は3本線を5回書いて1から15本全部数えることです。
ところが多くの人は横着をして既に知っている別の知識を流用できないかと考え、「4×6=24だから答えは24より小さいはず〜」だとか訳の分からない考察を始めます。
問題文には3と5しか出てきてないのに他所から別の情報を持ってきて余計に難しくしてしまう。
問題に対して愚直すぎるくらいで丁度良いことの方が私の経験上は多いです。