サポートエンジニアがやってるエラーや問題に対処する方法まとめ

サポートエンジニアがやっているエラーや問題に対処する方法

※当ブログではアフィリエイト広告を利用しています。

うわっ・・またエラーが出たよ・・

プログラムやシステムでエラーが起きるとつらいですよね。

調べればすぐにわかるものから、解決まで長時間かかってしまう問題まで様々です。

そんなエラーや問題に対し、現役のサポートエンジニアである筆者は日々お問い合わせを受けて対処しています。

プログラムやシステムのエラーに悩む方に参考になればと思い、エラーや問題への対処方法をご紹介します。

サポートエンジニアがやっているエラーや問題に対処する手順

サポートエンジニアがやっているエラーや問題に対処する手順は、大まかに以下のとおりです。

  • 発生している問題・エラーと状況を理解する
  • 発生しているエラーや問題を調査する
  • エラーや問題への対処方法を考える

それぞれ詳しくご説明していきます。

筆者について

本題に入る前に少しだけ自己紹介させてください。

fidn

この記事を書いている fidn(@lancork)は現役のサポートエンジニアです。

自社製品のサポートがメインですが、ときにはオープンソースソフトウェアや、趣味でやっているこのブログで出たエラーも調べることがあります。

それではサポートエンジニアがやっているエラーや問題に対処する手順をご覧ください。

1. 発生している問題・エラーと状況を理解する

まずは何が問題なのか、どんな状況なのかを確認していきます。

エラーの内容を読んで理解する

画面やログにエラーの内容が出ている場合は、その内容を読んで理解します。

「そんなの当たり前だろ!」と思われる方もいると思いますが、とても重要なフェーズです。

もちろんエラーの内容を見ただけで原因がわかったり、解決できるとは限りません。

しかし実際にサポートエンジニアとしてお問い合わせに対応していると、エラーの内容を読めばどんな問題なのかすぐわかるものも意外にあります。

エラーを読むことで原因や対処法がすぐにわかれば、その後に切り分ける手間や調査の時間を大幅に減らすことができます。

英語でエラーが出ていてよくわからない場合は、Google翻訳などの機械翻訳を使うのも全然アリです。(機密情報が含まれる場合、別の文字に置き換えたほうがいいかもしれません)

エラーや問題がいつ起きたのかを確認する

エラーや問題がいつ起きたのかを確認します。これによって以下のうちどの状況なのかを把握します。

  • はじめて発生したエラー
  • これまでも発生し続けていたエラー
  • いつから起きているのかわからない

例えばプログラムやシステムの設定などを変えて、すぐエラー起きたことに気づいた場合はほぼ変更した箇所が原因の可能性が高いでしょう。

しかし初めてではなく、これまでも発生していたエラーはいつから起きていて何が原因となっているのかを調べていくことになります。

いつから起きているかわからない場合は、システムログやアプリケーションのログなどから確認します。それでもわからない場合は再現する条件を調べていくことになります。

再現性を確認する

プログラムやシステムでエラーや問題が発生するのには、何らかの原因や条件があります。

さらに状況を把握していくために、以下のように再現性を確認します。

  • ある条件でいつも起きる(再現性がある)
  • たまにしか起きず、条件も不明(再現性がない)

再現性がある場合は、エラーや問題が起こる条件をもとに原因を調べていきます。複数の条件が絡み合ってエラーが起きている可能性もあります。

再現性がない場合は、再現できる条件を調べていくことになります。

ときには 1 か月に 1 回ぐらいしか起こらない・再現できない問題もあります。後述しますがこんなときは原因への対処とは別の方法を取ることもあります。

どんな環境で問題が起きているのかを確認する

プログラムやシステムそのものだけでなく、周りの環境が関係している場合もあります。

エラーの内容にもよりますが、場合によっては以下のような周りの環境についての情報も確認します。

  • OS やブラウザのバージョン
  • ライブラリを使っている場合、そのバージョン
  • システムの構成

たとえば Web システムがうまく使えないといった場合、システムそのものではなくブラウザに設定されているプロキシサーバーが原因の可能性もあります。

問題がどこにありそうか仮説を立てる

エラーの内容や起きた日時など、ひととおりの情報が集まったら問題がどこにありそうか仮説を立てます。

プログラムやシステムでエラーや問題が発生するのには、何らかの原因があります。大きく分けると以下のとおりです。

  • プログラムやシステムそのもの(データやシステム変更など)
  • プログラムやシステム以外のもの(外部のAPIやネットワーク・ハードウェアなど)

「何もしていないのに壊れた」ということもありますが、こんな場合はプログラムやシステム以外に原因があるか、何らかの変更にユーザー自身が気づいていないといった可能性が高いです。

仮説を立てることで、どんな順番で調べていけば効率がよさそうか簡単な調査プランをつくっていきます。

2. 発生しているエラーや問題の調査

仮説を立てたら調査に入ります。

ドキュメントやFAQを調べる

自社サービスやオープンソースソフトウェアなど、ドキュメントや FAQ がある場合は見ていきます。

例えばウェブサーバーの Apache や、リレーショナルデータベースシステムの MySQL だと以下が該当します。

プログラムやシステムがどう動くのが期待されるのか調べるには、一次情報であるドキュメントを見るのが基本的には最も信頼できます。(ドキュメントが間違っていることがないわけではありません)

次に記載する検索エンジンでの検索のあと、裏付けのために使うのも有効です。

Google で検索する(ググる)

発生したエラーの内容や、起きている問題について検索エンジンで検索します。

広く使われているソフトウェアや一般的な構成の場合、他の誰かが既に同じような問題を踏んでいる可能性も高いです。

よく検索に引っ掛かってくることがあるのは以下のようなウェブサイトです。

ただエラーは同じでも原因が異なったり、環境が実は少し違ったりすることもあります。

また上記のようなサイトに載っている情報が本当に正しい情報である保証はありません。このため自分で検証を進めたりドキュメントを見るという裏付けをすることが望ましいです。

既知の問題として報告されていないか調べる

オープンソースソフトウェアの場合、エラーが既知の問題として報告されている可能性もあります。

これらは以下のような場所から見つけることができます。

  • Issue トラッキングシステム
  • GitHub Issue

例えば Apache のソフトウェアは Bugzilla や JIRA で既知の問題が管理されています。影響を受けるバージョンや修正バージョンなども参考にできます。

全文検索エンジン「Elasticsearch」の例では GitHub に Issues が記録されています。

既知の問題であれば誰かが対応方法を記載してくれているかもしれません。またはソフトウェアが修正されないと対応が難しいことがわかる場合もあります。

ソースコードを調べる

ドキュメントや類似の事例がなく、既知の問題でもない場合の方法の一つです。

オープンソースソフトウェアなど、ソースコードを確認できる場合はソースコードも貴重な情報源です。

ソースコードからは以下のような情報を得られることがあります。

  • エラーを出している箇所(スタックトレースとの突合せ)
  • 例外が発生する条件
  • バージョンによる処理の違いの有無

たとえばソフトウェアのバージョンを上げたら挙動が変わったという場合は、バージョン間の差分からその原因がわかることもあります。

エラーや問題が再現できる最小の環境をつくる

絞り込みの方法として、エラーや問題が再現できる最小の環境をつくることで調査のスピードが上がることもあります。

再現できる最小の環境を作ることで、以下のようなメリットがあります。

  • 再現できれば仮説と検証のサイクルを早めることができる
  • 最小の構成にすることで、問題になっている範囲を絞り込むことができる

再現できる環境が整えば、以下のような変更をすることで検証のスピードを早めることができます。

  • 違うデータや設定で試してみる
  • log4j などでログの出力レベルを変える(INFO から DEBUG にする等)

また最小の構成にすることで問題の絞り込みだけでなく、調査が早まることも期待できます。

極端な例を出します。以下の 2 つの場合でどちらでも再現できるとしたら、どちらのほうが効率が良いでしょう。

  • 10個の処理で構成される 50 分かかるジョブ
  • 処理のうち 1 つだけ実行(5 分で終わる)

どちらでも同じエラーが起きるのであれば、もちろん後者ですよね。

正常な場合とエラーが出る場合を比較する

あるときはエラーが出るものの、あるときはエラーが出ない。

こういった場合はそれぞれの場合を比較し、どこかに違いがないか調べることで原因にたどり着けることがあります。

状況によっても異なりますが、違いを見るところの例としては以下のものがあります。

  • ソフトウェアのバージョン
  • ソフトウェアや周りの環境の設定
  • ログの出力内容
  • データの量

どんなところを見れば良いかというのは経験や勘によっても左右されるため、なるべく広い知識があると良いですね。

3. エラーや問題への対処方法を考える

調査が終わったらどのように対処するのか考えます。

原因そのものに対処する

エラーや問題の原因を突き止めることができた場合は、原因そのものに対処します。

原因そのものへの対処には以下のような方法があります。

  • ソースコードそのものを修正する
  • データの量によって起きる場合は、データを減らしてみる
  • 設定を変えれば対処できる場合、設定を変更する

これらによってエラーや問題が起きなくなれば解決です。

回避する方法や、次に問題が起きたときの対応を検討する

根本の原因が解決できればそれが一番ですが、ときにはそうもいかないときもあります。

例えば以下のような状況でエラーには大した情報が出ておらず、再現もできないような場合です。

  • 同じ条件で実行した時、1 か月に 1 回エラーになる
  • 次に実行するとエラーは起きない

こういった場合は以下のように問題そのものを回避する方法を取ったり、次に起きたときにもっと情報が取れるよう対処する方法があります。

  • エラーが出たら何回か追加で実行する(リトライする)ことで対処する
  • ソースコードの中にログ出力を増やす
  • ログレベルをより詳細なものに変更する

たまに発生するエラーや頻度が高くない問題などは、原因にこだわるよりもリトライで対処するのが工数やコスト的に好ましいことも多いです。

おわりに

サポートエンジニアがやっているエラーや問題に対処する手順をもう一度まとめます。

  • 発生している問題・エラーと状況を理解する
  • 発生しているエラーや問題を調査する
  • エラーや問題への対処方法を考える

エラーが出るとつらいですが、解決できた時にはちょっとした快感も味わえると思います。参考になれば嬉しいです。