エラーが出たらまず何を見る？現場で学んだトラブルシューティングの考え方

システム開発やインフラ、機器の保守など、エンジニアの仕事をしていると避けて通れないのが『トラブル対応』です。
「さっきまで動いていたのに、突然動かなくなった」
「設定変更したら、エラーが出るようになった」
「自分の環境では正常なのに、別の環境では動かない」
このような経験をしたことがある方も多いのではないでしょうか？
エラーが発生すると、つい表示されているメッセージだけを追いかけたり、
思いついた設定を片っ端から変更したりしてしまいがちです。
しかし、トラブル対応では「すぐに直すこと」以上に原因を切り分けながら順番に調査することが重要です。
今回はこれまで現場のトラブル対応を経験する中で意識するようになった基本的なトラブルシューティングの考え方について紹介します。

まずは「何が起きているか」を整理する

エラーが発生したとき、最初に確認したいのは原因ではなく「現象」です。
例えば、
・いつから発生しているのか
・常に発生するのか、特定の操作をした時だけなのか
・全員に発生しているのか、特定のユーザーだけなのか
・特定の端末や環境だけで発生しているのか
・直前に設定変更やアップデートを行っていないか？
といった情報を整理します。
「動かない」という情報だけでは原因の候補が非常に多くなります。
一方で、
「昨日まで正常だった」
「今日の設定変更後から発生した」
「Aの端末では発生するが、Bの端末では発生しない」
という情報がわかれば、調査する範囲をかなり絞ることができます。
トラブル対応では、まず事象をできるだけ具体的にすることが重要です。

エラーメッセージやログを確認する

次に確認したいのが、エラーメッセージやログです。
エラー画面を見ると、長い英語のメッセージや意味に分からないコードが表示されることがあります。
慣れていないと、そのまま閉じてしまいたくなりますが、実はそこに原因を特定するための重要なヒントが含まれている場合があります。

特に確認したいのは、
・エラーが発生しているファイル
・エラーが発生している行
・エラーコード
・接続先や対象となっている機能
・エラーが発生する直前のログ
などです。

エラーメッセージをそのまま検索することで、同じ問題に遭遇した人の事例や公式ドキュメントが見つかることもあります。
ただし、検索して見つかった解決方法をそのまま適用するのではなく、「自分の環境でも同じ原因なのか」を確認することが大切です。
直前に変更したものを疑う
個人的に、トラブルが発生したときに意識しているのが、
「最後に何を変更したか」
という点です。

正常に動作していた状態から何か問題が発生したのであれば、その間に行われた変更の中に原因がある可能性があります。

たとえば、
・プログラムを修正した
・設定ファイルを書き換えた
・ソフトウェアをアップデートした
・新しい機能を追加した
・ネットワーク設定を変更した
・ほかのシステムと連携させた
などです。

変更箇所が複数ある場合、一度すべてを疑ってしまうと調査が難しくなります。
可能であれば変更前の状態に戻したり、変更した部分を一つずつ確認したりすることで、原因となっている個所を特定しやすくなります。
そのため普段から「どこを変更したのか」を記録することも重要です。

一気に全部触らない

トラブル対応でやってしまいがちなのが
「ここかもしれない」
「こっちもかもしれない」
と複数の設定を同時に変更してしまうことです。

運がよく治る場合もありますが、これをすると結局、
「何を変更したことで直ったのか分からない」
という状態になってしまいます。
また、新しい問題を発生させてしまう可能性もあります。

基本的には、
１．原因の仮説を立てる
２．一つ変更する
３．動作を確認する
４．結果を記録する
５．次の仮説を試す
という流れで調査します。

少し遠回りに感じるかもしれませんが、結果的にこちらのほうが早く原因にたどり着けることが多いです。

「どこまで正常か」を探す

原因が分からない場合は、問題ある場所を探すのではなく、
「どこまでは正常に動いているのか」
を確認する方法も有効です。
例えば、システムが
「画面→アプリケーション→データベース」
という構成になっていたとします。
画面にデータが表示されない場合でも、
データベースにはデータが存在しているのか。
アプリケーションまでデータが取得できているのか。
画面に渡す処理で止まっているのか。
このように、一つずつ確認していけば問題が発生している範囲を絞ることができます。
これはITシステムだけではなく、機械や設備のトラブル対応でも同じです。
「電源が入っている」
「信号はここまで来ている」
「このセンサーまでは正常に反応している」
というように正常な範囲を確認していくことで、異常が発生しているポイントを探していきます。

再現できるかを確認する

トラブルを解決するうえで、「再現性」も非常に重要です。
同じ操作をしたときに毎回発生するのであれば、原因を調査しやすくなります。
反対に、
「10回に1回だけ発生する」
「しばらく使っていると発生する」
「特定の時間帯だけ発生する」
といった問題は、原因を特定するのが難しくなります。
そのため、
「何をしたときに発生したのか」
をできるだけ具体的に記録しておくことが大切です。
操作手順だけでなく、時刻や使用していた環境、表示されたメッセージなども残しておくと、後からログと照らし合わせやすくなります。

分からないときは、一度情報を整理する

調査を続けていると、どうしても原因が分からなくなることがあります。
そのような場合に、同じ場所を何度も確認し続けてもなかなか解決しません。
一度、
「分かっていること」
「分かっていないこと」
「確認したこと」
「まだ確認していないこと」
を整理すると、新しい原因候補が見えてくる場合があります。
また、他の人に相談する際にも、
「動きません」
だけではなく、
「ここまでは正常で、この処理を行うとこのエラーが出ます。AとBは確認済みです」
と説明できれば、相手も状況を把握しやすくなります。
トラブルシューティングは、一人で問題を解決する技術だけではなく、状況を整理して相手に伝える技術でもあると感じています。

トラブル対応で大切なのは「切り分けること」

エラーが発生すると、できるだけ早く原因を見つけようとしてしまいます。
しかし、実際のトラブル対応では、最初から原因が分かることの方が少ないと思います。
だからこそ、
「何が正常で、何が異常なのか」
「いつから発生しているのか」
「どの変更が影響している可能性があるのか」
を一つずつ確認し、原因の範囲を狭めていくことが大切です。
私自身も、現場でさまざまなトラブルを経験する中で、「すぐに答えを出すこと」よりも「順番に切り分けること」の重要性を感じるようになりました。
エラーが発生した際には、焦って設定を変更する前に、
「まず何が起きているのかを整理する」
ところから始めてみると、意外と早く解決につながるかもしれません。