【SE仕事術】ログ調査が遅い人へ｜原因特定が速い人の確認順序
障害調査で時間がかかる人ほど、最初からログを全部読もうとします。
そして、
「とりあえずgrep」
「エラーっぽい文字列検索」
「大量ログを眺める」
を繰り返して、気づけば数時間経っている。
SEの実務ではかなりよくある状態です。
一方で、調査が速い人は「ログを見る前」にかなり整理しています。
実際、障害対応が速い人ほど、
- どこから見るか
- 何を切り分けるか
- 何を捨てるか
を先に決めています。
今回は、ログ調査が遅くなりやすい原因と、原因特定が速い人の確認順序を、実務ベースで整理します。
ログ調査が遅い人は「全部見よう」としている
まず結論ですが、ログ調査で最も危険なのは「全部読もうとすること」です。
実際の現場では、
- APログ
- バッチログ
- DBログ
- サーバログ
- ジョブログ
- FWログ
など、大量にあります。
ここで全部を順番に追い始めると、かなり時間を失います。
特に経験が浅い時期ほど、
「ログを全部確認しないと不安」
になりやすいです。
ただ、実際の障害調査は「読む量」より「捨てる量」の方が重要です。
調査が速い人ほど、「今回は関係ないログ」をかなり早く切っています。
まず確認すべきは「何が起きたか」ではなく「どこで起きたか」
ここはかなり差が出ます。
調査が遅い人ほど、
「何のエラー？」
「どんなメッセージ？」
から入ります。
ただ、実際は先に、
- どのシステムか
- どの処理か
- どのタイミングか
- どのサーバか
を固定した方が速いです。
例えば、
- 特定バッチだけ失敗
- 特定画面だけ異常
- 特定時間だけ発生
- 特定ユーザだけ発生
などが分かるだけで、見るべきログはかなり減ります。
つまり、最初にやるべきは「エラー解析」より「発生範囲の限定」です。
ここを飛ばすと、永遠にログを眺めることになります。
速い人は「正常系」を先に知っている
これはかなり重要です。
ログ調査が速い人は、「異常ログ」だけでなく「正常時の流れ」を把握しています。
例えば、
- リクエスト受付
- API呼び出し
- DB更新
- コミット
- レスポンス返却
という正常ルートが頭にあると、
「どこまで進んでいるか」
だけで切り分けができます。
逆に、正常動作を知らないままログを見ると、
「大量ログの中から違和感探し」
になりやすいです。
結果として、調査がかなり遅くなります。
仕様理解については、こちらの記事でもかなり重要です。
関連記事：
https://ryman-money.tokyo/spec-thinking/最初に見るべきは「最初のエラー」ではない
これも実務でかなり多いです。
ログ調査が苦手な人ほど、「最初に見つけたERROR」に飛びつきます。
ただ、実際は、
- 二次エラー
- 後続失敗
- 連鎖異常
であるケースもかなり多いです。
例えばDB接続失敗が原因なのに、
- 更新失敗
- APIエラー
- タイムアウト
などが大量に出ることがあります。
この場合、本当に見るべきなのは「最初の失敗地点」です。
調査が速い人ほど、
「このエラーは原因か？結果か？」
をかなり意識しています。
「時系列」で並べるだけでかなり速くなる
ログ調査が苦手な人は、単発検索が多くなりやすいです。
ただ、実際の障害解析では「流れ」がかなり重要です。
例えば、
- リクエスト開始
- SQL実行
- タイムアウト
- リトライ
- 異常終了
のように並べるだけで、かなり見え方が変わります。
特に分散システムや複数サーバ構成では、
「時系列を揃える」
だけで原因が見えることがあります。
逆に、単発grepだけだと、
「ログは見ているのに流れが見えていない」
状態になりやすいです。
調査が速い人は「仮説」を持ってログを見る
ここが一番大きいかもしれません。
ログ調査が遅い人は、
「とりあえず見る」
になりやすいです。
一方で、速い人は、
- DB系っぽい
- 排他っぽい
- タイムアウトっぽい
- データ不正っぽい
など、仮説を持って見ています。
もちろん最初の仮説は外れることもあります。
ただ、仮説があるだけで、
- 見るログ
- 検索条件
- 確認順序
がかなり整理されます。
結果として、不要調査が減ります。
レビューや障害切り分けについては、こちらの記事とも相性が良いです。
関連記事：
実務でかなり効く「確認順序」
個人的にかなり重要だと思う順番はこれです。
まず、
- 何が起きたか
- どこで起きたか
- いつ起きたか
- 誰に起きたか
を固定します。
次に、
- 正常時の流れ
- 異常発生地点
- 前後ログ
- 関連システム
を見ます。
最後に、
- エラー内容
- SQL
- スタックトレース
- 詳細ログ
へ入ります。
逆に、最初から詳細ログへ潜ると、かなり迷子になりやすいです。
結論｜ログ調査は「読む力」より「切る力」
ログ調査が速い人は、特別な検索技術だけを持っているわけではありません。
むしろ、
- 発生範囲を絞る
- 正常系を知る
- 仮説を持つ
- 不要ログを切る
この順番がかなり上手いです。
特にSE実務では、ログ量は年々増えています。
そのため、「全部読む」より、「どこを見ないか」を決められる人の方が強いです。
ログ調査で毎回時間がかかる人は、まず「エラー内容を読む前に範囲を絞る」だけでもかなり変わると思います。
最後に、ログ調査や障害対応が多い人は、テキスト比較やログ解析ツールを整えるだけでもかなり効率が変わります。
特にWinMergeや高機能エディタは、
- 差分確認
- 大量ログ比較
- 文字コード確認
- grep検索
がかなりラクになるため、実務SEなら一度環境を整えておく価値は大きいです。