【トラブルシューティング】エラーが出た時、動作しない時にすべき3つのこと

プログラミング言語
スポンサーリンク
色

こんにちは!ブログカフェChromaの色です。

随分久しぶりの投稿です。毎回言っているような気がします。

今回は、システムを構築する時、うまく行かない場合のトラブルシューティング方法について得たものがあったので記事にしました!

サーバを構築したり、サービスを構成する人にとっては頭が痛くなる話題ですね。

要点はズバリ、以下の3つです!

  1. 症状を明確にする
  2. 原則、公式サイトの情報を参考にする
  3. PCのログを確認する

これだけ言われてもイメージがつきづらいと思うので、詳しく説明していきます!

症状を明確にする

「症状を明確に」というとなんだか風邪みたいですね(笑)

エラーにも風邪にも共通して言えることですが、まず何がおかしいかわからなければ対処できません

このことを、簡単な例で考えてみましょう。

電源ボタンを押しても画面が真っ暗なままのPCがあったとします。

考えられる症状としては、

  1. そもそも電源が入っていない
  2. 電源は入っているが画面だけ映っていない

この2パターンがあるでしょう。

電源が入っていなければ電源ユニットの交換を、画面が映っていないだけであればディスプレイ周りの設定を確認するなど、症状によって対処も変わってくるわけです。

症状が分かれば検索で情報を見つけやすくなる

解決策をgoogleで探そうにも、なんて入力したらいいかわからない!」では困りますよね。

症状が明確であれば、検索すべき語句も自ずと分かるものです。

結果的に目的の情報に早くたどり着け、解決までの時間も短縮されるかもしれません!

しかし、その検索にも注意点があります。

検索結果の一番上のページの情報を参考に…では本当に正しい情報かわかりませんよね?

では、どのような点に注意すればいいでしょう。

原則、公式サイトの情報を参考にする

結論から先にいうと、公式の情報優先です。

解決策らしきページがあれば、真っ先に試したくなるのはわかります。

でも、それは本当に正しい情報でしょうか?

真偽が定かでない情報を鵜呑みにして痛い目を見た話

実は私がそれでしくじったことがあるんです…

あるプログラムが動かなくなったときのことです。

私は一生懸命解決策を探し、ついにそれらしき方法を見つけました。

藁にもすがる思いで実践したのですが、結果はプログラムが完全に停止してしまうという悲惨なものでした。

後から知ったのですが、その情報は古いバージョンのみに該当するものだったのです。

構築は初めからやり直しになり、相当凹みました…(笑)

バージョン確認+公式情報で盤石の体制を

情報源として一番信頼できるのは、開発元いわゆる公式ですよね。

トラブルシューティングを行う時も必ず公式の情報から確認するようにしましょう。

そうすれば、バージョン違いによる操作ミスも防げたかもしれない…

注意点として、公式サイトが存在しないプログラムもあるということがあります。

その場合、開発元のGithubリポジトリなどが公式サイトと化していることがあるので、確認してみましょう。

PCのログを確認する

もう一つ、エラーの原因が特定できないときに効果的な方法があります。

それはPCのログを確認することです。

ここでは、Linuxを例にとって話を進めて行きます。

とっても頼れるsyslog

syslogってなんぞやというと、PCが行った作業の結果を逐一記録してくれているログファイルです。

これをうまく活用して、エラーの原因究明を行えます。

配置場所はDebianであれば/var/log/syslogです。

内容はかなり長いので、lessコマンドなどで表示してあげましょう。

原因究明のコツは、

  1. error」や「faild」などの記述を探すこと
  2. 疑わしいプログラムの動作を追跡すること

この2点です。

「error」や「faild」などの記述を探す

前者は分かりやすいのではないでしょうか。

内部での処理に失敗した部分を探すということです。

errorなどの記述の後にある文章で、大まかな原因を絞り込みます。

個人的にありがちなのが、permisson deniedauthentication failureなどの権限周りのエラーです。

こんなのが出た人はファイルのpermissonを確認したり、設定したパスワードが間違っていないかを確認してみましょう。

疑わしいプログラムの動作を追跡すること

もし「このプログラムが怪しい」とわかっていれば、こんなこともできます。

先程のsyslog内で、そのプログラム名のある行を見ていけばよいのです。

その中で予定外の動作がないかなどを確かめましょう。

ただ、量が膨大なので、grepコマンドで絞り込むとより快適です。

# cat /var/log/syslog | grep (絞り込む文字列)

結局は焦らないことが大事

色々書きましたが、もしエラーが出てうまく行かなかったときは焦らないことが第一です。

報連相をしっかり行い、冷静に対処すると案外うまく行ったりします。

複数人でトラブルシューティングを行うことも一つの手だと思います!

この情報が少しでも役に立つことを願っています!

コメント

タイトルとURLをコピーしました