2009年7月1日水曜日

フォーラムで質問で最良の回答を得る方法

technetのILMフォーラムに面白い投稿があったので、紹介します。

How to get the maximum return on your forum question(フォーラムで質問で最良の回答を得る方法)」


内容を見ていくとILMに限った話だけでなく、このようなオンラインフォーラムで質問する際の心構え?的なことも多くのっていたので他でも参考になるのではないかと思います。

簡単に内容を紹介します。


■はじめに

 回答者が質問の内容を理解するためには環境や質問の背景を知る必要があるが、多くの場合最初に投稿される質問には回答する上で必要な状況が適用されていない場合が殆どである。

■的確な情報を集めること
 質問する際の第一歩として、質問しようとしていることに関連する情報を集める必要がある。この際、アーキテクチャや設計に関する、よりハイレベルな質問とトラブルシューティングに関する質問では情報収集に関するアプローチが異なる。

 まず、トラブルシューティングに関する質問をする際は、
 ・投稿する前に詳細なデータを集める
 ・環境に関する簡潔で基本的な情報を提供する
 ・エラー状況を詳細に記述する
 という点に留意する必要がある。

 また、アーキテクチャや設計に関する質問をする際は、
 ・現在の状況は?
 ・どこからスタートしたのか?
 ・何を達成しようとしているのか?
 ・具体例を挙げられるか?
 について考える必要がある。


#ここまではILM/MIISだけに関連する話ではありません。次のパートからILM/MIISに特化した話が深堀されていきます。


■情報収集すべき重要な構成要素
 ほとんどの場合に最初の質問で提供すべき中心的な構成要素は下記の通りである。
 ・基本的なILM/MIISサーバ構成
 ・SQL Server構成
 ・管理エージェント(MA)の情報
 ・エラーコードとエラー状況

・基本的なILM/MIISサーバ構成
 以下の項目が挙げられる。
 ・MIIS/ILMのバージョン(ビルド)
 ・SQL Serverのバージョン(ビルド)
 ・SQL Serverのロケーション(ローカルなのかリモートなのか)
 ・ライセンスタイプ(MSDN、ボリュームライセンス、評価版)
 ・サービス実行環境(開発環境、テスト環境、本番環境)

 サービス実行環境(開発、テスト、本番)に関する情報ははトラブルシューティングのアプローチに影響を及ぼす。例えば、開発環境においては抜本的な措置(完全にデータを削除するような)をとることが出来るが、本番環境において事前の計画や準備なしに多数のオブジェクトが入っているコネクタスペースを削除することはすべきではない。
 回答者が質問者のサービス実行環境を知っていれば、適切な処理方法を提案することが出来る。

・SQL Server構成
 フォーラムの投稿を見ているとパフォーマンスに関連する多くの質問が存在するが、例えばリモートのSQL Server上でILMを使用するときシステム全体のパフォーマンスに重大な影響を与えることがある。
 また、SQL Serverに関する情報を提供すべきもう一つの理由はネットワークとサーバのセキュリティが挙げられる。ILMサーバと同居しているSQL ServerとリモートのSQL Serverを比較すると若干異なるアプローチが必要となる。

 提供すべき典型的なSQL Serverパラメータは以下の通りである。
 ・SQL Serverはどこにインストールされているのか(ローカル or リモート)
 ・SQL Serverのバージョン(ビルド)
 ・SQL Serverのタイプ
 ・SQL Serverのセキュリティパーミッション
 ・ライセンスタイプ(MSDN、ボリューム、評価、、、)

・管理エージェント(MA)の情報
 管理エージェントはILMと関連するデータソースの間のデータ交換を行うので、利用している管理エージェントのタイプは回答に非常に大きな影響を与える。

 提供すべき情報としては以下のものが挙げられる。
 ・ILMが接続しているデータソースは何か?
 ・どんなMAを利用しているか?
 ・サードパーティMAやXMAを利用しているか?
 ・MAのオブジェクト数はいくつか?
 ・メタバース(MV)のオブジェクト数はいくつか?

 MAを構成する際にエラーが発生するようならば、まずFAQでデータソースのバージョンがサポートされていることを確認するべきである。

 MVとコネクタスペース(CS)のオブジェクト数はシステム負荷の指標ということが出来る。CSのオブジェクト数とMVのオブジェクト数の比率はJoinとProjectionルールの概要を把握するのに役立つ。


・エラーコードとエラー状況
 エラーコードはトラブルシューティングにおいて重要な役割を果たす。しかし、多くの場合質問者はエラーに関する不完全な情報しか提供していない。
 情報を提供する際は、エラーコードと併せ以下のガイドラインに従い情報を収集/提供すべきである。
 ・システムから取得する「正確な」エラーメッセージを含める
 ・メッセージの詳細な内容まで掘り下げる
 ・関連するメッセージを確認するためにイベントビューアをチェックする
 ・Extensionのログについても確認する
 ・詳細(冗長)なログを提供する

■Rules Extensionのトラブルシューティング
 MAおよびMVのExtensionのトラブルシューティングを行う時、Extenrionをデバッグモードでコンパイルする。その際、デバッグ情報の生成オプションに「完全」を指定する。


■構成状況に関する情報
 ILM基盤は複数のコンポーネント(ILM、OS、SQL、.NET Framework、Visual Studio Extension、、)が複雑に絡み合って構成されており、これらの構成要素のほんの少しの変更がトラブルを引き起こす可能性がある。それらすべてのコンポーネントを一人で管理できていれば良いが、経験上これらの環境は複数の人や組織で管理されており、チームを構成する全メンバがそれぞれの担当部分のI/O
を把握しているわけではない。
 そのため、ある程度の期間運用されているILMが突然/断続的に不具合を起こした際、根本的な原因にたどり着くのは非常に困難である。
 そのような環境においてILMのトラブルシューティングを行う場合、技術基盤に関して幅広い視野で臨む必要がある。

 例えば、システムの変更記録やイベントログから下記の情報を取得する必要がある。
 ・最近システム構成に変更があったかどうか(アップデート、アップグレード、ホットフィックス適用など)
 ・エラーはいつ起きるのか?
 ・エラーは再現可能か?
 ・エラーは断続的に発生するか?
 ・特別な環境は存在するか?(高度にセキュアなネットワーク、サービスのロックダウンなど)

■そのた付加情報
 技術的な話ではなく、且つILMに特化した話でもないが以下は重要である。
 ・それまでにどの投稿を見たか?
 ・特定にホットフィックスをインストールしたか?
 ・どのRun Profileを実行したか?

■提供すべきではないシステム情報
 逆に提供すべきではない情報としては以下が挙げられる。
 ・パスワード
 ・個人情報
 ・実行環境のコンピュータ/ドメイン情報
 ・サービスアカウント名
 ・IPアドレス
 など。

■アーキテクチャや設計に関する質問
 トラブルシューティングではなく、アーキテクチャや設計に関する質問を行う場合は下記の情報を提供する必要がある。
 ・セットアップに関する若干の基礎データ
 ・すでに何をインプリしたか?
 ・何をしたいのか?どこに到達したいのか?

 具体例や画面ショットなどで出来るだけ詳細な情報を提供することが必要である。


■まとめ
 質問をする際は目的によって提供すべき情報/アプローチは異なる。

 ・トラブルシューティングを行うとき
  ・投稿する前に詳細なデータを集める
  ・環境に関する簡潔で基本的な情報を提供する
  ・エラー状況を詳細に記述する

 ・アーキテクチャや設計に関する質問をする際は、
  ・セットアップに関する若干の基礎データ
  ・何をしたいのか?どこに到達したいのか?

■チェックリスト
 ここまでの情報をまとめたチェックリストを提供するの参考にされたい。
 ※リンク切れしているみたいです。復活したら貼りなおします。。

0 件のコメント:

コメントを投稿