ログはコードの実行過程を記録するもので、目的に応じてシステムログと操作ログに分けられます。
1. ログとは
ログにはコードの実行プロセスが記録されます。さまざまな目的に応じて、システム ログと操作ログに分けることができます。
1) システムログ
システム内のハードウェア、ソフトウェア、およびシステムの問題に関する情報を記録し、システム内で発生するイベントを監視することもできます。開発者はこれを使用して、エラーが発生した理由を確認したり、攻撃者が攻撃時に残した痕跡を探したりすることができます。システム ログには、システム ログ、アプリケーション ログ、セキュリティ ログが含まれます。システム ログは主に、開発者が問題をトラブルシューティングするための基礎を提供するために使用されるため、それほど読みやすいものではありません。
2) 操作ログ
ログイン記録や変更記録など、システム内の全ユーザーの操作過程や操作結果を記録します。操作ログは主にユーザーにサービスを提供し、過去の操作記録を表示するのに役立つため、可読性に対する高い要件が求められます。
2. 操作ログとは
具体的には、「誰が、いつ、どこで、何を、どのような操作を行って、どのような変更が行われたか」を記録するため、完全な操作ログには次の情報が含まれている必要があります。
- ユーザー (オペレーターおよびアカウント): 操作を実行した人
- 操作時間: 操作が実行された時間
- 操作箇所（業務メニュー）：ユーザー管理や注文管理など、どのモジュール上で操作を行っているか。
- 操作オブジェクト: 操作が実行されるオブジェクト (特定の問題、特定の試験用紙など)
- 操作タイプ: ログイン、参照、追加、削除など、具体的に実行された操作。
- 変更値：問題の難易度を[難易度1]から[難易度2]に変更するなど、主に「編集」系の操作を行った後にどのような変化が生じたか
上記の内容に加えて、ビジネス シナリオに応じて他のフィールドを補足できます。
- 操作ページ: 操作の実行時に呼び出されるインターフェイス (/crowd/system/user/list など) を記録します。例外が発生したときに、技術者が問題をすばやく特定するのに便利です。
- ログイン IP: ユーザーが操作を実行する場所を記録します (例: 125.71.135.54 Telecom, Wuhou District, Chengdu City, Sichuan)
- デバイス情報：Chrome101、Windows7、PCなど、ユーザーがどのデバイスを通じて行った操作を記録します。
- ビジネス関連フィールド: 以下の図に示すように、ビジネス ニーズを満たすために記録されるフィールド
拡張 1 : 上記のデフォルトでは、成功した操作のログのみが記録されます。ビジネス ニーズに応じて、「操作ステータス」フィールドを追加してログを記録することもできます操作失敗の状況を記録し、同時に失敗理由を記録します。
拡張 2 : 複数のプロジェクトでユーザー操作を記録する必要がある場合、プロジェクトごとに操作ログ機能を開発する必要はありませんが、ユーザー操作ログの公開コンポーネントを設計する必要があります (この記事では、プロジェクトのユーザー操作ログの設計についてのみ説明します)。単一のプロジェクト、コンポーネントの設計については本稿の範囲外ですが、コンポーネントを設計する際には、プロジェクトごとにユーザーの操作ログを整理し、どのように分離するかを開発側と検討する必要があります。）
ユーザー操作ログを設計するための 3、5 ステップ
1. 作業リストを整理する
操作リストの整理とは、ユーザーのどの操作をユーザー操作ログに記録するかをリストアップすることです。具体的な方法は、機能リストに基づいて、ビジネスニーズに応じて記録する機能を絞り込むことです。
上図のとおり、左側は製品の機能一覧ですが、プロダクトマネージャーによる調査・分析の結果、本プロジェクトのユーザー操作ログには閲覧操作や問い合わせ操作を記録する必要はないと考えられ、アナウンス管理では全ての操作を記録する必要はないので、右の操作リストが表示されます。
2. レコードフィールドを整理する
このステップでは、プロダクト マネージャーは各操作に対してどのフィールドを記録するかを明確にする必要があります。少なくともユーザー、操作時間、操作場所、操作対象、操作タイプを含める必要があり、ビジネス ニーズに応じて、変更値、IP アドレス、デバイス情報、操作ページなどのフィールドを追加する必要があります。
3. 特定のルールを入力します
操作リストや記録欄の枠組みが構築できたら、次は操作ログをどのように分かりやすく表示するかという具体的なルールを埋めていきます。
上の図に示すように、追加、削除、非アクティブ化などの操作には 1 つのオブジェクトの 1 つの状態のみが含まれるため、[2022-10-10 19:10:26][Xiao Wang 1816121315] のように比較的簡単に処理できます。 ]の[大学管理]の[追加][大学1(002)];
バッチ操作は、単一のオブジェクトを複数回操作するものと見なされ、[2022-10-10 19:10:26][Xiao Wang 1816121315] [Added] in [College Management][College One] のように 1 つの状態のみが関与します。 (002)、カレッジ 2 (003)、カレッジ 3 (004)];
最も複雑なのは編集操作の処理で、編集前と編集後という2つの状態が存在するため、以下では「編集」操作を例に操作内容を記録する方法を紹介します。 2つの状態。
注: ログ記録の粒度は、操作の種類のみを記録することも、各操作の詳細な内容を記録することもでき、業務のニーズに応じて決定する必要があります。
1) 限定値
限られたコンテンツ (ドロップダウン ボックス、複数選択ボックス、チェック ボックスなど) については、トピックの難易度など、前後の変更を直接記録できます。 [難易度 1] を [難易度 2] に変更します。 ]。
2) 短いテキスト
テキスト内容が短いため、大学名を[大学1]を[大学2]に変更するなど、編集前後の内容を直接記録することもできます。
3) 長文
テキストの量が多いため、すべてのコンテンツが短いテキストのように表示されると、ユーザーは変更内容を確認しにくくなります。このとき、最初に長いテキストの内容を「行」ごとに分類し、編集後に変更された行の内容のみをユーザーに表示することができます。以下の図に示すように、ユーザーが行を削除したことがはっきりとわかります285 ～ 294 に 289 ～ 298 行を追加しました。
4) 写真と音声とビデオ
写真、音声、ビデオはアドレス形式で保存されるため、添付ファイルなどもアドレス形式で記録する必要があります。 [https://cos.1.png] を [https://cos.2] に変更します。 .png]。
5) 複雑なコンテンツ
読解問題の編集には、有限値、短文、長文、写真、音声、動画を同時に含めることができ、選択肢や小問の数も制御できず、それぞれのデータを記録するのは非常に面倒で困難です。上記のスキームに従って個別に作成すると、ユーザーが読むのに便利です。したがって、複雑なコンテンツの場合は、全体として保存し、編集前および編集後のレコード (過去のバージョンと同様) の表示をサポートする必要があります。
4. その他の補助機能の補足
上記の主なルールに加えて、必要に応じてユーザー操作ログのその他の補助機能を設計することもできます。
1) クエリスクリーニング
ユーザーの検索を容易にするために、ユーザー情報によるあいまい検索、操作時間帯によるクエリ、業務メニューや操作の種類によるクエリなど、操作フィールドにクエリおよびフィルタ機能を提供する必要があります（フィルタリングする場合はタイプを組み合わせる必要があります。「」など） 「新入生」「新任教師」などはすべて「新」タイプに属し、審査などに利用されます。
2) ページネーション
データはページネーションで表示され、各ページに表示する項目数を設定できます。
3) 並べ替え
動作時間の順または逆順に並べます。
4) 表示列フィールドをカスタマイズする
一度に表示されるフィールドが多すぎる場合は、ユーザー定義のオプションを選択できます。
5) ダウンロード
ユーザーの操作ログを条件に応じてダウンロード可能。
6) 自動クリーニング
ユーザーの操作ログは頻繁に更新され、長期間にわたって大量のデータが蓄積されてストレージ容量を占有し、操作ログは時間に依存し、時期尚早のログにはクエリ価値がないため、不要なログを自動的に収集できます。保存される日数または記録を制限することでクリアされます。
5. プロトタイプと PRD の改善
前回の分析結果に従って、製品プロトタイプと製品要件文書の設計を完了します。
ここまで、5 つのステップをすべて紹介しました。