ご存知のように、クライアントに対処するための黄金のルールは「わざわざしない」ことです。広告もニュースも、彼があなたのプログラムで好きなものとそうでないものについての思いやりのある問い合わせもありません。 技術サポートにも同じことが当てはまります。必要なすべてのデータを収集するために必要な電話、手紙、リモートセッションが少ないほど、お金を節約できる企業にとっても、時間を節約できるクライアントにとっても、より良いことです。両側の神経。 これが最終的に私たちに考えさせることです。ニュースレターや調査で再び顧客を混乱させることなく、すでにあるデータからリフレクションのために何らかの形で追加情報を抽出することは可能ですか？
この記事では、Parallelsで使用する方法の1つについて説明します。
したがって、このレシピには次のものが必要です。
- ユーザーデータストレージ（大企業にはおそらくサーバーがあります。クライアントコンピューター上のログとデータが追加されるサーバー）。
- 前述のユーザーデータのパーサー（オペレーティングシステム、構成、モデル、およびバージョンに関する不必要な統計情報を拒否するユーザーもいます）。
- 数人のプログラマー：1人は製品側から、もう1人は内部開発部門（ストレージとパーサーのメイン）。
- アナリスト（はじめまして）。
ポイント1：メッセージレジストリ。
参加者：製品プログラマー、アナリスト。
どのソフトウェア製品でも、ユーザーに表示されるメッセージには、エラー、警告、情報メッセージの少なくとも3種類があります。 それらをAPP_ERR、APP_WARN、およびAPP_INFOと呼びます。
注：「Cドライブを本当にフォーマットしますか？ はい/いいえ」このレシピに参加しないでください！
コードとログでは、これらのメッセージは、デジタルコード（APP_ERR_1以降）を使用するか、名前（APP_ERR_KABOOM）を使用するか、両方を組み合わせて構成できます。 原則として、組織方法は私たちのベンチャーにとって重要ではありません。 ユーザーに表示されるすべてのメッセージをファイルとフィード分析にアップロードします。製品プログラマーと協力して、各メッセージにコメントを追加します。いつ、誰に、このメッセージを表示できるのか、どのメカニズムが関与するのか。 例：APP_ERR_KABOOM-爆発しようとしている場合、そのような場合にコンポーネントによって表示されます。 考えられる理由：1）ディスク領域が不足している、2）ディスクへの書き込み権限が不足している、3）ディスク自体に問題がある。 このレジストリーは、メッセージを使用した後続の作業の過程で製品プログラマーを再度引っ張らないようにするために作成されます。 さらにメッセージは、コンポーネントまたはその他の任意の記号でソートできます。
ポイント2：検索アクティビティ。
参加者：両方のプログラマー、アナリスト。
これで、ログからメッセージコードを最小限の損失で取得する方法を理解できたらうれしいです。 これは、ユーザーベースのボリューム、各ユーザーのログ自体のボリューム、および利用可能な容量に直接依存します。 週に100人のユーザーがいて、それぞれが1キロバイトのログを送信し、サーバーが十分であれば、追加コストなしで実行でき、ログファイル自体を確認できます。 10万人のユーザーがいて、各ユーザーが1メガバイトを送信する場合、サーバーが不足していると想定し、おそらくプロセスを最適化するいくつかの方法を既に持っています。 この場合、最後のエラーコードは、ユーザー構成のまま、製品構成情報を含むxmlファイルの別の行に配置されます。これにより、問題が大幅に簡素化されます。
ポイント3：解析結果の発作と理解。
参加者：プログラマー、内部開発部門、アナリスト。
ログから必要なものすべてを抽出することを学習し、サーバーからメッセージに関するデータを送信できるようになったとします。 正確にこれを行う方法は、特定の各企業のアプローチに依存します。誰かがあらゆる好みに合わせて視覚化されたカラフルなダッシュボードを好み、誰かがサーバーで簡単なストアドプロシージャを管理し、その後Excelで並べ替えます。 頼む主なフィルタは、特定のデータサンプル内のさまざまなユーザーの数です。たとえば、バージョンごと、時間ごと、またはオペレーティングシステムごとです。 そして、楽しみが始まります-結論。
ポイント4：結論。
参加者：アナリスト。
間違い なぜ、ユーザーがテクニカルサポートでエラーを実行した場合、エラーメッセージを分析するような奇妙で複雑な方法であるのでしょうか。 そして、お気に入りのタイムアウトの例をポケットから取り出します。 誰もがタイムアウトを持ち、待ち時間はユーザーの現実と完全に一貫していない複雑な考慮事項から設定されることがよくあります。 したがって、最も一般的なタイプの問題：時々、いくつかの難しいプロセスがタイムアウトを報告します。 ただし、常にではありませんが、コンピューターまたはネットワークの負荷によって異なります。 ユーザーの再現は100パーセントではなく、操作の繰り返しは成功することが多く、技術サポートは遠く離れています。たとえば、メッセージが自動的に閉じられた場合にどうなるかを説明するにはどうすればよいですか。 したがって、タイムアウトが毎回または少なくとも2回はポップアップしない場合、かなり長い間このことを知らない可能性があります。 同時に、これらのメッセージは、作業を完全にブロックすることなく、プログラムに対して非常に否定的な印象を与えます。 同じことが、断続的な再生を伴う他の多くの状況にも当てはまります。
警告 実際、ここでの効果は同じです。プログラムのレプリカが絶えずポップアップするのは面倒です。 同時に、この時点で根本的に悪いことは何も起こりませんが、警告が繰り返されると、ユーザーが再び不快な可能性のあることをやりたくないように、インターフェイスまたはスクリプトを変更できるかどうか疑問に思われます。 たとえば、プロセスの中断が問題を引き起こす場合、それを中断する機能を無効にすることは可能ですか。 遅延再起動がプログラムのクラッシュやデータの損失につながる可能性がある場合、対応するフォームから[キャンセル]ボタンを削除しないでください。 などなど。
情報メッセージ 。 それらは非常に簡単です。 まず、警告と同様に、スクリプトやインターフェイスを変更して、その人が再びメッセージに出会わないようにすることができます。 次に、ユーザーがどのような情報を最も頻繁に必要とするか、どのようなコンテキストであるかを確認し、ドキュメントまたはナレッジベースの関連セクションを展開できます。
したがって、わずかな自動化を犠牲にして、会社はユーザーを煩わせることなく、豊富な追加の統計情報を受け取ります。 これらのデータは蓄積されると、さまざまな方法で分析できます。バージョンの比較、ソリューションの即時確認（または非確認）の受信、新しいオペレーティングシステムに典型的な問題の追跡などです。 しかし、彼らは間違いなく仕事に不必要ではありません。