はじめに
今日は, 昨日テストした内容のログ解析を一日 (+ 残業時間含む) やってた.
途中でよくわからなくなってきて, WireShark のバグを疑ったりしたけれども残念ながら自分のバグだった.
どうすれば, ログ解析を素早くできるようになるのだろうか?
そこで, 思いつくままにアイデアを書いてみる.
[toc]
事象を把握する
まずは, エラーメッセージ見るところからスタート.分析の前提となる
- 試験手順
- 環境
を確認する.メールで依頼がきたら欲メールを読む.これは, まずは頭の中に前提を把握したほうが分析がしやすいから.
前提を見逃していて全然関係ないところを防ぐためでもある.
分析
ロジカルシンキングの方法で有名なものが 2 つある.
- 仮説思考
- なぜなぜ分析
この二つは真逆のアプローチだが, 両者を状況によってつかいわけるのがいい.
仮説を立てる
一番大事なことは, アタリ をつけること.
障害が入り組んでいるときは, 注意深くログをチェックする部分を絞り込む必要がある.
これが原因だろう というアタリをつけて調べることで, 時間を節約することができる.
コンサルの世界では, 仮説思考がもてはやされているのも, 限られた時間内で, 素早く成果にたどり着くため.
なぜなぜ分析
これが王道の手段.
エラーログから始まって,
- なぜ -> なぜ -> なぜ ->
と原因を探っていく.複雑な事象の場合は, 複数のバグがいりまじっていた り, 二次障害, 三次障害と絡み合っている.ロジカルに注意深く, 事象を追いかける.
追いかけているうちに迷子になったら次の項へ.
時系列にテキストに整理する
やみくもにログをおっていると, ときどき迷子になる.
そういうときは, テキストとログを交互に並び替えながら事象を列挙していく.
ログを別のテキストに転記することは, やや面倒ではあるものの, これをすると, わからなくなったときの地図になる.
その他
相談する
これは自分の悪いところではあるけれども, わからなくても一人で悩みつづけることがある.
きいてしまったほうがはやいときは, 相談したほうがいい. 実は, 相手はもう答えを知っているかもしれない.
そのためには, 普段からよい人間関係を保つことも必要.
諦めない
原因を曖昧にしたまま先に進んではいけない. その場で発生したことは最低限原因判明させてから次へいくクセをつける.
それはかならず再発する. 定時で帰りたくたって, 原因を判明させるまで は会社に残って頑張るほうがいい. 明日になるとわすれてしまうので.
この姿勢は, 最近チームメンバの先輩から学んだ.
ツールを揃える
ログを解析するには, ログ解析を助けるツールがあると便利.
- ログをダウンロードするためのコマンドラインツール.
- キーワードによる検索, フィルタリング
- ログのハイライト.
- 容易なテキスト抜きだし & 整形
- これは,時系列にテキストに整理するため
今のプロジェクトでは, 決まりきったログツールがないので, テキストで吐き出されたプログラムのログを解析している.
自分は Emacs を駆使しているけれども, Emacs は大規模ファイルに大して遅い のが最近のストレス. 軽さでは秀丸に勝てない.