はじめに

出力されたエラー文をうまく理解できず、行き詰ってしまったことにより、エラーLogに対して苦手意識がありました。しかし、エンジニアとエラーLogは切っても切れない関係です。
そこでエラーLogと仲良くするために、解決するまでの流れを考えて、まとめてみようと思います。

まず、エラーLogを読む

エラー文をコピペ翻訳する

英語のエラー内容を理解するために、出力されたエラー文を翻訳します。私はDeepLをよく使用します。うまく翻訳できない時もありますが、エラーを解決するためのコマンドが記載されていたり、エラー発生の原因を推測する為のヒントがあるので、しっかり読み込みます。
注意点として、ログに個人情報などの機密情報が載っていることがあります。情報漏洩しないように機密情報の有無を確認してから、翻訳サイトを使うようにします。

ログレベルから、ログの重要度を確認する

エラーが発生した際は、ログレベルも参考にしています。ログレベルを確認することで、エラーLogの重大度を把握することができます。複数のエラーが発生しているとき、どれから手を付けて良いか分からなくなる時があります。私はそんな時にログレベルを確認することで、優先順位をつけて対応するようにしています。

以下は例として、syslogを挙げています。

値	重大度	キーワード	説明
0	Emergency	emerg	システム使用不可
1	Alert	alert	早急な対処が必要
2	Critical	crit	致命的な状態
3	Error	err	エラー状態
4	Warning	warning	警告状態
5	Notice	notice	正常だが注意が必要な状態
6	Informational	info	通知メッセージ
7	Debug	debug	デバッグメッセージ

検索エンジン、公式ドキュメントを調査する

単語の組み合わせを意識して、なるべく可変的な部分を除いて検索をかける

エラー文を原文のままで検索しても、満足のいく結果が得られません。自分で決めた名前(ファイル名など)が含まれているからですね。

そこで、私は以下を意識して検索ワードを考えています。

エラーコードがあればそれを含める
ソフトウェアやフレームワーク、プログラム言語名を検索に入れる
プログラム内で定義したファイル名やクラス名、メソッド名などを除く

また、「バージョンアップで仕様変更がある」「そもそも使い方、設定が間違っている」という原因も多いので、調査に含めます。

公式ドキュメントで確認する

調査をして仮説が立てば、Stack Overflowや技術系記事で見つけた方法が正しいのか、公式ドキュメントで確認します。私は公式ドキュメントを読むのが苦手です。Qiitaの様に読みやすくなく情報量が多いので、中々知りたい情報にたどり着けない為です。しかし、公式ドキュメントはエンジニアをする上で避けては通れない道なので、知りたい単語を全体検索するなどで対象を絞ることで、サボらずに目を通すようにしています。

また、公式サイト自体を見つけられない時は、グーグルのサイト指定検索を使うとスムーズに見つけることができます。

[検索ワード] site:[検索したいサイト]で検索したいサイトを指定することができます。

デバックする、仮設の実施

経験則的にデバックが一番解決に近づくように感じます。コードのエラーであれば、一番初めにデバックしてプログラムの動きが想定通りか確認する方が良いと思います。また仮説を試す際には、それ以上悪化しないようにバックアップを取るなどをして、後戻りできる状況を確保します。

最後に

エラーの被害を最小限で抑える為に、重要な事が二つあると考えています。一つ目は常に書跡を残しておくことです。多くの場合、直前の操作からエラーが発生しますし、他人に相談する際に書跡があれば、最低限の事を伝えることができます。二つ目はシステムの理解です。全体のコンポーネントを把握していれば、どこでコケてしまっているかを簡単に推測でき、調査の範囲を小さくすることができます。

また、コメントに皆さんがしているエラーLog検索のコツを教えて頂けると嬉しいです!