エラーの原因特定
エラーの原因特定
2021年6月14日
エラーの原因特定
プログラムの実行中にエラーが発生した場合やプログラムに問題がある場合、その原因を特定する事が重要です。 一つのプログラムの場合には殆どの場合、そのプログラムの中に問題があると考えるのが一般的です。 しかし、Web サービスなどの場合は、フロントエンドとバックエンドで別々のプログラムを動かす場合も多いので原因の特定が難しくなる場合が殆どです。この記事では、Web サービスでの問題の見つけ方を簡単に紹介します。
プログラムを取り巻く環境
プログラムを作成して実行して問題が発生した場合、その原因の殆どはプログラムその物にある事が多くなります。 しかし、実際にプログラムが動く仕組みを考えると問題の発生は、そのプログラム事態以外にも要因があることがあります。
例えば、ある PC 上で実行できるプログラムを作った場合でも、作成したプログラムは、実行している「システム」という観点から考えると極一部です。
どういう事かというと、作成したプログラムを動かすために必要になる要素にはいろいろな物が含まれています。
- 実行するコンピュータ（スマホや PC）
- プログラムを実行する OS(オペレーティングシステム)
- プログラムが利用しているライブラリや外部のモジュール
- 作成したプログラム
実際にプログラムを実行するには、これらの要素が必要になるので、どの部分にも問題がある可能性があります。
さらに、一般的な Web サービスのプログラムになるとさらに別の要素が増えるのはこれまで紹介してきた通りです。
- Web サーバー（ホスティングをする、サーバーから、OS、HTTP のサービスなど）
- ネットワーク
- バックエンドのプログラム
- データベースを利用している場合はデータベース
などと、要素はさらに増えていきます。
プログラムを作成して実行して問題が発生した場合、その原因の殆どはプログラムその物にある事が多くなります。 しかし、実際にプログラムが動く仕組みを考えると問題の発生は、そのプログラム事態以外にも要因があることがあります。
例えば、ある PC 上で実行できるプログラムを作った場合でも、作成したプログラムは、実行している「システム」という観点から考えると極一部です。
どういう事かというと、作成したプログラムを動かすために必要になる要素にはいろいろな物が含まれています。
- 実行するコンピュータ（スマホや PC）
- プログラムを実行する OS(オペレーティングシステム)
- プログラムが利用しているライブラリや外部のモジュール
- 作成したプログラム
実際にプログラムを実行するには、これらの要素が必要になるので、どの部分にも問題がある可能性があります。
さらに、一般的な Web サービスのプログラムになるとさらに別の要素が増えるのはこれまで紹介してきた通りです。
- Web サーバー（ホスティングをする、サーバーから、OS、HTTP のサービスなど）
- ネットワーク
- バックエンドのプログラム
- データベースを利用している場合はデータベース
などと、要素はさらに増えていきます。
一番怪しいのは、「新規に作った部分」
どの要素にも問題がある可能性がありますが、一番怪しいとされるのは、「新しく作った部分」です。 つまり、作成したプログラムを最初に疑うのが一般的です。
多くの場合、新たに作成した部分以外には「実績」があるので、「動くはず」という仮定の元に、調べる場所を絞るのが普通です。 他のプログラムとの組み合わせでは問題なく動作している事を考えると、そこに問題がある可能性は少ないという「仮定」の元に調査を行います。もちろん、他のプログラムとの組み合わせで正常に動いているということは、「問題がない」という事ではありません。
まずは、自分の作ったプログラムは、中身もよくわかっているので、そこから調べると原因を見つけやすくなります。 ここを出発点に原因を特定するのが一般的な方法です。
最初に調べるの作成したプログラムの処理の流れとデータの変化をデバッガーやデバッグメッセージを入れて想定通りになっているかを確認します。
どの要素にも問題がある可能性がありますが、一番怪しいとされるのは、「新しく作った部分」です。 つまり、作成したプログラムを最初に疑うのが一般的です。
多くの場合、新たに作成した部分以外には「実績」があるので、「動くはず」という仮定の元に、調べる場所を絞るのが普通です。 他のプログラムとの組み合わせでは問題なく動作している事を考えると、そこに問題がある可能性は少ないという「仮定」の元に調査を行います。もちろん、他のプログラムとの組み合わせで正常に動いているということは、「問題がない」という事ではありません。
まずは、自分の作ったプログラムは、中身もよくわかっているので、そこから調べると原因を見つけやすくなります。 ここを出発点に原因を特定するのが一般的な方法です。
最初に調べるの作成したプログラムの処理の流れとデータの変化をデバッガーやデバッグメッセージを入れて想定通りになっているかを確認します。
ポイントはインターフェース
データの流れを追いかける際のポイントは「インターフェース」です。 特に外部のモジュールなどを呼び出している場合は、モジュールに渡しているデータと、モジュールからもらう処理結果が想定通りかを確認するのが重要です。
渡しているデータに問題がある場合は、渡す側、つまり自分で作成した側に問題がある可能性が高くなりますし、処理結果に問題がある場合はモジュール側にある場合が多くなります。このようにして、問題がありそうな場所を絞り込んでいきます。
つまり、確認するのは、「データの流れ」を「インターフェース」に着目して確認するという事です。
殆どの問題は、データの流れを見ると原因がわかる場合が殆どです。
データの流れを追いかける際のポイントは「インターフェース」です。 特に外部のモジュールなどを呼び出している場合は、モジュールに渡しているデータと、モジュールからもらう処理結果が想定通りかを確認するのが重要です。
渡しているデータに問題がある場合は、渡す側、つまり自分で作成した側に問題がある可能性が高くなりますし、処理結果に問題がある場合はモジュール側にある場合が多くなります。このようにして、問題がありそうな場所を絞り込んでいきます。
つまり、確認するのは、「データの流れ」を「インターフェース」に着目して確認するという事です。
殆どの問題は、データの流れを見ると原因がわかる場合が殆どです。
厄介な問題も！
厄介な問題は、同じデータでも実行の度に結果が違う場合があります。 こうした場合は、単純なデータ処理だけではなく、何らかのタイミングなどの要素が入っている場合があります。 特に、ネットワークを介して受け取るデータは、前回の記事でも紹介したようにデータが届くタイミングが変わります。 Javascript の処理も非同期で行われるため、こうした問題の原因を特定するのは難しい場合が多くなります。
このような場合は、まずは、テスト環境を docker や、VM を利用して作成して試すと、糸口が見つかる事が多くなります。 実際のネットワークとは違って、データが届くまでの時間の差も比較的少ないので、まずは、実際のシステムとこうしたテスト環境の比較を行なって、問題の発生頻度や、繰り返し行った場合の違いなどを元に原因を特定します。
厄介な問題は、同じデータでも実行の度に結果が違う場合があります。 こうした場合は、単純なデータ処理だけではなく、何らかのタイミングなどの要素が入っている場合があります。 特に、ネットワークを介して受け取るデータは、前回の記事でも紹介したようにデータが届くタイミングが変わります。 Javascript の処理も非同期で行われるため、こうした問題の原因を特定するのは難しい場合が多くなります。
このような場合は、まずは、テスト環境を docker や、VM を利用して作成して試すと、糸口が見つかる事が多くなります。 実際のネットワークとは違って、データが届くまでの時間の差も比較的少ないので、まずは、実際のシステムとこうしたテスト環境の比較を行なって、問題の発生頻度や、繰り返し行った場合の違いなどを元に原因を特定します。
まとめ
Web サービスや Web アプリの問題の原因特定は意外に面倒です。 前回の記事で紹介したように、ネットワークを介したデータのアクセスには多くの要素が関連してくるので、調査の範囲が広がる傾向にあるので、問題のある箇所を特定するのが難しくなります。
それでも、問題特定の基本は、「データの流れ」を「インターフェース」を元に追いかけることにあります。
データの流れを追いかけると、問題のある箇所を特定しやすくなります。
一方で、実行の度に結果（現象）が異なる場合は、タイミングなどの要素が関係している事が多く、特に非同期で処理が行われる Javascript ではデバッグを難しくしています。こうした検証や問題点の洗い出しには、docker や VM などを利用したテスト環境を構築すると見つけやすくなります。
Web サービスや Web アプリの問題の原因特定は意外に面倒です。 前回の記事で紹介したように、ネットワークを介したデータのアクセスには多くの要素が関連してくるので、調査の範囲が広がる傾向にあるので、問題のある箇所を特定するのが難しくなります。
それでも、問題特定の基本は、「データの流れ」を「インターフェース」を元に追いかけることにあります。
データの流れを追いかけると、問題のある箇所を特定しやすくなります。
一方で、実行の度に結果（現象）が異なる場合は、タイミングなどの要素が関係している事が多く、特に非同期で処理が行われる Javascript ではデバッグを難しくしています。こうした検証や問題点の洗い出しには、docker や VM などを利用したテスト環境を構築すると見つけやすくなります。
コメント
コメントを投稿