システムで何らかのエラーが発生したという場合や、やりたいことができないといった場合に、トラブルシューティングを行うことになりますが、その際の一般的なトラブルシューティングの流れについてご紹介します。私たちサポートチームもだいたいこのようなフローの考え方をもとに調査を行っています。また、テクニカルサポートでは、インシデント単位で承っているプロフェッショナルサービスと、時間単位で承っているプレミアサービスがあります。トラブルシューティング内容に応じた、それらのサポートサービスの違いについても、参考としてご案内します。
大きく、運用でのエラー発生、開発時の How-to では考え方も異なりますので、それぞれ分けて見ていきます。
エラー発生
A) いま事象が発生しているか
これは一番重要なポイントになります。いま事象が発生している場合には、すぐに対処が必要なため緊急度は高くなり、できることも多くなります。復旧優先で対処となりそうな対応をすぐに行ったり、原因調査のためにいったん情報も採取してから対処を行うといった対応があります。
一方、いま発生していないけれども、過去発生していたエラーをさかのぼって調査することもあります。この場合には、どれだけ手掛かりとなる情報が残っているかが重要です。
B)エラーメッセージやログから調査
いま事象が発生している場合には、エラーメッセージやログを確認します。
SQL Server を例にとると、既定で出力されている情報として参考になるのは、下記があります。
既定の情報
- SQL Server エラーログ (ERRORLOGファイルや、同じフォルダにあるデフォルトトレースやダンプファイル等)
- Reporting Services ログ (ログファイルや同じフォルダにあるダンプファイル、ExcecutionLog ビュー)
- Analysis Services ログ (msmdsrv.logやフライトレコーダー)
- イベントログ
その他、事象に応じて、次のような情報を採取することもあります。
追加情報
| プロフェッショナルサービス、プレミアサービスのいずれでも、これらの情報からの調査は承っています。違いとしては、下記があります。
プロフェッショナルサービス |
C) 発生状況の切り分け
事象によっては、情報採取よりも、事象が発生するパターン、発生しないパターンを切り分けることによって、問題点が特定できる場合があります。また、発生しないパターンが確認できると、それが対処方法に直結する場合もあります。例えば、次のような切り分けがあります。
- 特定の環境で発生する、もしくは複数の環境で発生する
- 特定のクライアントで発生する、複数のクライアントで発生する
- 特定のユーザーで発生する、複数のユーザーで発生する
- 設定を変更することで発生しない
- 操作する順番によって発生しない
また、何らかの違いが確認できた場合には、発生する場合と発生しない場合の、B) の情報や設定を比較することで、問題点を特定しやすくなります。
| プレミアサービスでのみ、切り分け調査は承っています。 |
D) 残っている情報から調査
すでに発生していない事象であれば、残っているログから手掛かりとなる情報を探します。
まずは、既定で残っている B) の「既定の情報」があります。B) の「追加の情報」もうまく採取できていましたら、それらの情報も参照します。
| プロフェッショナルサービス、プレミアサービスのいずれでも、これらの情報からの調査は承っています。 |
E) 次回発生時の情報採取
何も手掛かりとなる情報が残っていなかったり、残っている情報からは判断がつかない場合も多くありますので、その場合には、再発時にしっかりと調査できるように採取する情報を検討します。
| プロフェッショナルサービス、プレミアサービスのいずれでも、再発時に有効な情報採取の検討は承っています。 |
F) 再現手順の確立
再発させたくない、あらかじめ仕掛けておくような情報採取が困難といった場合には、再現手順の確立、発生パターンの切り分けが必要となります。例えば、下記のような発生パターンを見極めて、検証環境でも同様の事象を発生させて、E) で検討したような情報を狙って採取します。
- 特定の操作をすると100%発生
- 一度発生すると発生し続ける
- リトライ等によりすぐに発生しなくなる
| 再現手順の確立のご支援は、プレミアサービスでのみのサービスとなっています。プレミアサービスでは、マイクロソフト社内でも再現手順確立のために、同様の環境を構築して調査します。 なお、プロフェッショナルサービス、プレミアサービスのいずれのサービスでも、1つの事象について、上記の対応を組み合わせてご提供します。 例えば、先月発生していたエラーの調査という場合では、D) の残っている情報からまずは調査します。ログに有効な手掛かりが残っていたり、特徴的なエラーで過去事例も多くあるという場合であれば、そのまま原因や対処方法をご案内できます。しかしながら、特定できないような場合には、E) の次回発生した際に有効な情報採取を検討した上でご案内します。 |
How-to
A) 参考となる情報があるか
マイクロソフトのサイト(msdnやTechNet、KB等) や書籍で、サンプルや実現方法が説明されている場合には、それを参考に実装します。また、マイクロソフト以外のサイトやフォーラム等有効な情報は数多くありますので、参考となる情報を探します。
| プロフェッショナルサービス、プレミアサービスのいずれでも、参考となる情報の調査は承っています。公開されている情報以外には、マイクロソフト社内の事例や不具合情報等から、参考となる情報をご案内します。 |
B) 情報をもとに実装
参考となるわかりやすい情報があれば、実装できると思います。
| 情報があったとしても、分かりにくい場合や実装するにはもっと例がほしいといった場合も多くあります。プロフェッショナルサービス、プレミアサービスのいずれでも、参考となる情報についての補足説明を承っています。 |
C) 動作確認のサンプルはあるか
参考となる情報がなければ、少し厄介です。その場合には、何かエラーが発生するようなわかりやすい場合には、そのエラーを手掛かりに上記の「エラー発生」のようなトラブルシューティングを行うことになります。
D) サンプルをもとに動作検証
サンプルがあれば、それをもとに動作検証し、プロパティを変更したり、コードを変更したりして、実現できる方法を探します。
| シンプル化したサンプルを提供いただくことで、プロフェッショナルサービス、プレミアサービスのいずれでも、これらの情報からの調査は承っています。あらかじめサンプルをご用意いただくことで、すぐに動作検証をしたりデバッグも可能となるため、有効な回答を早く提示できる可能性が高まります。 |
E) シンプル化したサンプル作成
サンプルがまだない場合には、遠回りになるかもしれませんが、まずはやりたいことを最小限に実行できるようなサンプルを作成します。それにより、やりたいことはできるのか、他の手法を検討する必要があるのか確認します。
| シンプル化したサンプル作成のご支援は、プレミアサービスでのみ承っています。 |
F) 期待する動作にならない環境で情報を取得して調査
サンプルの作成も困難な場合には、期待する動作にならない環境で、「エラー発生」の 「B)エラーメッセージやログから調査」のようにトラブルシューティングを行います。
「調査」とは？
上のトラブルシューティングでは、情報を採取して「調査」すると説明していますが、具体的には私たちサポートエンジニアは次のようなことを行っています。
- msdn や TechNet、KB 等の公開情報を確認する
- 事例データベースや不具合データベースを検索し、合致している事例や不具合、すでに実績のある手法を確認する
- ホワイトペーパーや社内インターナルの技術情報を確認する
- 検証環境を構築して、テストにより実際の動作を確かめる
- シンプル化したプログラムを作成して、テストにより実際の動作を確かめる
- 検証環境で再現させた上で、設定を変更したり、違う操作をしてみる
- 検証環境で再現させた上で、詳細なログを採取して問題点を特定する
- 問題の環境で採取したダンプファイルをソースコードと紐づけてデバッグする
- 検証環境で再現させた上で、ステップ実行させてデバッグする
最後に
トラブルシューティング時のフローが、今後トラブルシューティングを実施される際の参考になりましたら幸いです。
また、エラー発生、How-to という非常にざっくりした分類とともに、サポートサービスについてもご案内しました。もちろん実際の問題は、これらの分類に該当しなかったり、サポートサービスのサービスレベルで分けられるものではなかったりしますので、お問合せいただいた際に伺った問題に応じて柔軟に対応していきます。お気軽にお問合せください。