インテリジェントな運用と保守における分散アクティブ知覚の実践

はじめに: 企業のデジタル化により、運用と保守のインテリジェントな変革が不可避になりました。 CreditEase は、テクノロジー企業や金融企業における AIOps の実装を積極的に推進しています。 この記事では、AIOps 実装の 1 つの形式について説明します。 動作収集、シミュレーション、アクティブ認識などの手段を通じて、ユーザーの実際のシステム使用経験から始めて、フルディメンションの監視データと組み合わせることで、より効果的なインテリジェントな異常検出と根本原因分析を実現できます。

1. 運用・保守の開発

1.1 運用と保守の価値

初期の運用と保守作業は比較的簡単でした。一般的に、システム統合エンジニアと研究開発エンジニアが最初にプロジェクトを開発し、その後それを提供します。次に、運用と保守を担当する担当者がバックグラウンドでいくつかの操作を実行し、システムの正常な動作を確保します。

ソフトウェア開発業界と技術の発展に伴い、運用・保守業務はますます多様化しています。この段階では、運用と保守の作業と価値は主に次の 3 つの側面に集中しています。

1) 効率性

多数のビジネスがオンライン化される中、運用・保守担当者は、リソースがシステムに迅速かつ効率的に提供されるようにし、ビジネスの変化に対応し、運用要求に応える必要があります。

2) 品質

運用と保守の目的は、システムの品質と安定性を確保することです。つまり、ユーザーにスムーズで快適な体験を提供するためには、ビジネスとシステムが24時間365日オンラインで安定して稼働していることを保証する必要があります。この目標を達成するために、運用および保守に関連するタスクには次のものが含まれます。

障害予測: 障害が発生する前にその可能性を予測します。
異常検出: 問題が発生すると、異常がすぐに検出され、特定されます。
根本原因分析: 問題の原因を分析し、問題の本当の根本原因を見つけ出します。
動的な容量拡張: 問題処理プロセスは複雑な要因の影響を受ける可能性があり、システムを動的に拡張する必要があります。
サービスの低下: コアサービスに影響を与えないエッジサービスでは、サービスの低下が必要になる場合があります。

3) コスト

企業が成長し続けるにつれて、入出力比率はますます重要になってきます。運用と保守のもう一つの価値はコストの削減です。主に以下の点に反映されます:

キャパシティプランニング: 毎年、IT 運用と保守に投資するスタッフとリソースの量を計画します。
柔軟なスケジュール設定: リソースを最大限に活用するために、リソースをスケジュールして割り当てる方法。
利用分析: 利用分析には、動的側面と静的側面の両方が含まれます。
トレンド分析: たとえば、今年 IT 運用と保守にどれだけの費用がかかったか、来年はこの部分にどれだけの費用が費やされるかなどです。これはトレンド分析です。
コスト分析: コスト分析には、今年の事業の数、各事業にかかる費用、IT 技術設備の数、人員の数などが含まれます。

1.2 運用と保守のジレンマ

図に示すように、横軸はサービスの規模を表します。同社の事業は成長を続けており、それに伴いサービスの規模も拡大しています。ここでは、ビジネスの急増を考慮せずに、これが線形の変化であることを単純に理解します。

ただし、ビジネス規模の拡大は、少なくとも次の 3 つの側面で O&M の複雑さの増大を反映しています。

サービス規模の拡大は、サーバーとネットワークのボリュームの拡大に直接つながり、続いてネットワークトポロジの拡大につながります。
ビジネスが成長するにつれて、サービスのテクノロジースタックも成長します。以前は、フロントでサービスを実行し、バックでデータベースを実行するだけで十分だったかもしれません。現在、サービス規模の継続的な拡大とさまざまなサービス形式の導入により、キューやキャッシュなどが発生する可能性があります。それに応じて、テクノロジースタックも継続的に拡大しています。
サービストポロジは拡大し続けます。従来はチムニー型のサービスで十分だったが、マイクロサービスが適用されるようになった現在では、サービス間のスケジューリングが多くなり、ニーズを満たすためにサービストポロジを増やす必要がある。

サービスの規模が大きくなるにつれて、運用と保守の複雑さは指数関数的に増大します。ということは、運用・保守要員の数も増えているということでしょうか？各部門を見渡せば、答えはノーです。コスト削減のため、サービスの複雑性が増しても各部門・役職の人員数は増加せず、むしろ安定していきます。この比率に基づくと、運用・保守の複雑さが増すにつれて、運用・保守要員の数が減少することを意味します。

真ん中の隙間をどうやって埋めるのでしょうか？これには、操作および保守方法の使用が必要です。上図に示すように、運用保守品質 = 運用保守人員 x 運用保守手段となります。運用保守担当者は、さまざまな運用保守手段を使用して、運用保守の困難を解決し、運用保守の発展を促進する必要があります。

1.3 運用と保守の開発

図に示すように、運用と保守の開発は、大きく 4 つの段階に分けられます。

1) 手動ステージ

手動ステージは比較的わかりやすいです。研究開発担当者がシステムを納品し、運用・保守担当者が手動で操作を行ってシステムの正常な動作を確保します。現段階では運用・保守作業に関する基準は存在しません。

2) 標準化段階

企業のITシステムが運用保守化され、あらゆる業務がシステム化されてオンラインで運営されるようになると、運用保守業務の重要性はますます高まりますが、同時に運用保守と研究開発・業務担当者の業務との間にコミュニケーションの壁も生じています。この時、いくつかの標準が導き出されましたが、その中で最も重要なのはITSM (IT サービス管理) です。 ITSMの目標は、プロセス、情報管理、リスク管理など、日常の運用・保守業務すべてをシステム構築と標準化によって定着させることです。組立ラインと同様に、人員は標準に従って参加するだけで済みます。

3) 自動化段階

インターネットの爆発的な普及に伴い、サービス提供モデルはますます多様化し、インターネットと IT に対するユーザーの要求もますます高まっています。 ITSM の欠点はますます明らかになりつつあり、主に時間がかかりすぎる、コストがかかりすぎる、急速に変化するニーズに適応できないといった点に現れています。その結果、エンジニアリングや運用・保守の観点から DevOps という文化が自然発生的に生まれました。 DevOps では、運用保守、R&D、QA エンジニアの作業の高度な統合を重視しており、エンジニアリング提供の観点から運用保守を継続的に反復する必要があります。

同時に、企業のIT管理や運用の要求の観点から、急速な進化の問題も解決する必要があり、そのため標準ITOMが進化してきました。 ITOM は ITSM と非常によく似ていますが、違いは「S」が「O」に変更されていることです。つまり、ホスト、操作、リリースシステムなど、操作自体とそれがもたらすさまざまな自動化ツールがモデルに含まれています。

DevOps は発展を続け、現在の ChatOps へと進化しました。 ChatOps の目標は、R&D、運用保守、QA を統合し、会話 (チャット) 形式でコミュニケーションを図ることです。ただし、ChatOps はコミュニケーションの形式のみを考慮しており、チャット方式に基づいた全体的なソリューションは提供していません。 ChatOps は DevOps のジレンマをうまく解決しません。
ITOM によってすべての操作がオンライン化され自動化された結果、IT の運用と保守によって生成される大量のデータが、特に企業のデジタル化にとって非常に有意義であることがわかりました。これらのデータは処理および分析後、日常業務に価値を生み出すことができます。そこでガートナーは新しい標準「 ITOA 」を提案しました。 ITOA は IT データの価値を強調し、IT 運用と保守の分析を求めていますが、このデータを何に使用できるかは説明していません。すぐにガートナーは ITOA を「AIOps」へと進化させました。このとき、AIOps の「AI」は「アルゴリズム」を指し、オンラインでの障害検出や日常的なやり取りなどの運用上の問題を解決するためのアルゴリズムの使用を含め、データ分析自体によって生成される価値を重視します。

4) インテリジェントステージ

業界の IT 運用と保守の要件が増加し続けるにつれて、 AIOps と ChatOps はどちらも深刻な問題に直面しています。それは、人間が対応できなくなることです。エンジニアリングの観点から見ると、運用と保守が直面している現状は、異質性が非常に高く、サードパーティのアプリケーションやさまざまな機器を導入する必要があるということです。配信モデルもますます増えており、運用と保守の複雑さも飛躍的に増大しています。

上記の問題を解決するために、ガートナーはタイムリーに「AIOps」という概念を提案しました。ここでの「AI」は人工知能を意味します。ロボットの参加により、人工知能技術システムが運用と保守のあらゆる側面に導入され、運用と保守の問題の解決に役立ちます。このように、運用と保守の開発はインテリジェントな段階に入りました。

2. インテリジェントな運用と保守とは何ですか?

2.1 インテリジェントな運用と保守 (AIOps) とは何ですか?

BMC は AIOps を次のように定義しています。

AIOps とは、1) 分析機能と機械学習を使用してさまざまな IT 運用ツールやデバイスから収集されたビッグデータを分析し、2) 問題をリアルタイムで自動的に特定して対応することで、IT 運用を自動化および強化する多層テクノロジープラットフォームを指します。

簡単に言えば、多層プラットフォームを導入し、ビッグデータ分析や機械学習などの手法を活用して、IT運用・保守自動化の能力を高めることです。

上の写真の下部にある 3 つの小さな写真は、それぞれ 2016 年、2017 年、2018 年の AIOps アーキテクチャの進化を表しており、いずれも機械学習とビッグデータを中心に構築されています。

2.2 テクノロジー、シナリオ、アルゴリズム

AIOps に関係するテクノロジー、シナリオ、アルゴリズムを図に示します。

1) 技術レベル

ビッグデータ分析：膨大なデータに基づく分析など、分析部分に重点が置かれています。
機械学習: データ量が多すぎるため、単純な手動分析では不十分です。独自に知性を生み出す必要があります。これが機械学習の価値です。
ナレッジグラフ: 日々の運用・保守により、さまざまな経験データが生成されます。これらのデータがどのようにして運用および保守作業に真の価値を生み出すかには、ナレッジグラフが関係します。
自然言語処理: 自然言語処理は、ChatOps を AIOps の分野に導入できる理由です。私たちは、チャットプラットフォーム Chat のような、比較的シンプルで受け入れやすいインタラクティブインターフェースを見つけたいと考えています。これには、人間の言語を理解して人々にフィードバックを提供し、関連する実行アクションを理解するために、自然言語処理を使用する必要があります。

2) 関連するシナリオ

単一指標の異常検出: たとえば、リアルタイムデータの指標に異常があるかどうかを知りたい場合、それを検出し、異常がある場合はフィードバックを提供できます。
多次元指標異常検出: 指標は互いに関連しており、クラスタリングなどの操作を通じてより多くの異常を検出できます。
トレンド予測：主にコスト部分に反映され、人工知能を通じて将来の成長と変化を予測し、意思決定をより適切に導くことができます。
ログ異常検出: ログに異常があるかどうかを検出します。
根本原因分析: 障害が発生した場合、時間次元と空間次元から障害の原因を見つけることができます。
インテリジェントな Q&A: これまでは、操作を変更するたびに、運用および保守部門にリクエストする必要がありました。現在、これらすべての機能が引き継がれ、インテリジェントなプラットフォームになっています。日常の運用および保守作業は、インテリジェントプラットフォームまたはロボットを通じて直接完了できます。
インテリジェントな実行: これは私たちが期待する方法です。チャットウィンドウを通じて、オンラインビジネスの変化をリアルタイムで把握できます。要求がプラットフォームに送信されると、プラットフォームはそれを自動的に実行します。

3) アルゴリズムレベル

ルール
統計
機械学習

変分オートエンコーダ、GBRT、EMA、極限理論
ピアソン相関係数、DBScanアルゴリズム
FPツリー
パスランキング

2.3 AIOps プラットフォームアーキテクチャ

上の図は、典型的な AIOps プラットフォームアーキテクチャを示しています。

最下層はすべてのデータのソースです。大量のデータを収集し、リアルタイム分析を通じてアルゴリズムプラットフォームに配信します。アルゴリズムプラットフォームは 3 つの部分で構成されています。 1 つ目はルールとパターンに基づく単純な分類、2 つ目はドメインアルゴリズム、そして最後に機械学習と AI によって操作に影響を与え、自動化を実行します。

AI を理解していれば、これは実際には感知から思考、行動、つまり認識から思考、実行までのプロセスを含む AI インテリジェントエンティティであることがわかります。

3. CreditEase インテリジェント運用・保守プラクティス

3.1 CreditEase IT運用アーキテクチャ

CreditEase は「ミドルオフィス戦略」を実施し、技術ミドルオフィス、データ/インテリジェンスミドルオフィス、運用保守ミドルオフィスに再利用可能なテクノロジーを集中させ、統一された方法でサービスを提供して、人員とリソースを節約し、需要応答速度を向上させています。

CreditEase の IT 運用アーキテクチャは、次の 4 つの部分に分かれています。

中心となるのは、実際にビジネスを担う技術的なミドルプラットフォームです。テクニカルミドルプラットフォームは、IaaS、PaaS、SaaS などの基盤となる物理環境から始まるクラウドプラットフォームの概念を採用しています。ここでの SaaS は、実際にはミドルプラットフォームの概念であり、汎用的なシステムソフトウェアをミドルプラットフォーム上に配置して、業務システムに統一されたサービスを提供します。
データ/インテリジェンスミドルプラットフォームは、他のビジネスやプラットフォームに統合され再利用可能なデータとインテリジェントサービスを提供します。
運用保守ミドルプラットフォームは、 R&Dやビジネスからの要求に積極的に対応し、オンラインビジネスシステムを保守します。運用・保守面では、従来の運用方法とインターネットの迅速な反復・対話方式を採用し、監視、情報、自動化などの垂直分野におけるあらゆるスイートを確立しています。

運用と保守では、データ/インテリジェントミドルプラットフォームのデータとアプリケーションをどのように使用しますか?運用・保守で生成される貴重なデータをデータ/インテリジェントミドルプラットフォームに伝送するためのユニバーサルパイプラインを構築します。データ/インテリジェントミドルプラットフォームは、データを分析し、運用と保守に必要なシナリオに基づいてインテリジェントアプリケーションにフィードバックを提供します。

3.2 運用・保守管理

上図は運用保守管理アーキテクチャを示しています。

左から右へは運用から運用保守、あるいは運用から DevOps へと言えます。左側は ITSM の概念に傾倒しており、右側は DevOps の概念に傾倒しています。上から下は、エントリーから実行までです。 DevOps のほうが馴染みがあるかもしれないので、この部分を例に、上図のアーキテクチャを紹介しましょう。

私たちの構築方法は、継続的インテグレーションと継続的リリースプラットフォームに接続されたセルフサービスエントランスから開始します。継続的インテグレーションおよび継続的リリースプラットフォームでは、ホスト、ドメイン名、データベース、負荷分散、その他のコンポーネントを含むすべての自動化された構築を使用して自動化を実現します。最後に、インジケーター、追跡、ログなどのオンラインシステムデータを収集します。これが監視部分です。

上記の DevOps 運用・保守管理アーキテクチャは、2C 製品の提供に非常に適しています。しかし、CreditEase のように社内担当者向けのシステムが多数あり、ユーザーの質問に迅速に対応し、より価値の高い運用保守の要求やデータを迅速に蓄積する必要がある企業の場合、単一の運用保守管理アーキテクチャでは上記の要件を満たすのに十分ではありません。

そのため、運用、管理、監査に重点を置いた ITSM 部分も構築します。 ITSM 部分はサービスデスクを入り口として使用します。関連する内部管理には、リクエスト管理、イベント管理、問題管理、変更管理、需要管理、オーケストレーション管理などが含まれます。関連する情報管理には、資産管理と CMDB が含まれます。

ITSM の価値を例を通して見てみましょう。

システム障害が発生しました: ビジネス担当者がユーザーの携帯電話番号を送信すると、システム障害が発生したため開発者に連絡する必要があることを示すエラーメッセージが表示されました。この問題を DevOps 分野で処理すると、非常に簡単になります。問題を R&D に報告するだけで解決されます。しかし、このように対処すると、次回同じ問題が再び発生する可能性があります。

ITSM 部分で障害を分析すれば、より根本的に問題を解決することができます。障害が発見された後、リクエスト管理を通じてバックエンドスタッフに問題が報告されました。バックエンドスタッフは、リクエストを確認した後、障害を「インシデント」にアップグレードし、R&D スタッフに提出しました。研究開発スタッフが分析した結果、障害の原因は携帯電話番号がリスク管理プラットフォームをトリガーしたことにあることが判明しました。リスク管理プラットフォームが立ち上げられたばかりだったため、ステータスコードの説明が不十分でした。 R&D スタッフはプラットフォームをクローズし、障害処理を完了し、「インシデント」を「問題」にアップグレードしました。問題を分析した後、R&D および製品担当者は、関連するサービスを変更し、より詳細なステータスコードとより明確なエラープロンプトを提供する必要があると考え、「問題」を「要件」として提出しました。最終的に「要求」は満たされ、「問題」は解決され、同様の状況は二度と発生しなくなります。

3.3 収集と処理

前述したように、運用保守センターとデータ/インテリジェントセンターの間には共通のパイプラインが存在します。運用保守センターは、すべてのデータを収集し、簡単な処理を実行して、データ/インテリジェントセンターに送信する役割を担います。インテリジェントセンターはデータを分析および処理し、データとインテリジェントアプリケーションを運用保守センターにフィードバックします。

上の図は、データの収集と処理のアーキテクチャを示しています。

収集されるデータは、動的と静的の 2 つの形式です。動的データには、ビジネス、アプリケーション、リンク、技術設備、ネットワーク全体、ログデータなどが含まれます。静的データには、構成、トポロジ、作業指示データなどが含まれます。

当社独自のシステムを通じてすべてのデータを収集し、統合パイプライン（統合パイプラインには、構造化データを構成または前処理する Kafka と CreditEase のオープンソース DBus が含まれます）を介してリアルタイム分析プラットフォームに送信し、関連操作を含むデータの後処理を実行します。最終データは分類され、データセンターのデータベースに保存されます。たとえば、関係、インジケーター、ドキュメント/ログデータは ElasticSearch に保存され、構造化データは Hive に保存され、その他の履歴データは HDFS に保存されます。

3.4 スマートシーン

運用と保守におけるインテリジェントなシナリオを上の図に示します。

インテリジェントミドルプラットフォームは、運用保守ミドルプラットフォームによって提供される作業指示書、オーケストレーションルール、CMDB、ポートレート、トレース、KPI、ログなどのデータに基づくアルゴリズムを通じて、運用保守ミドルプラットフォーム用の一連のモデルとアプリケーションを構築します。

配置ルールに注目してみましょう。私たちが使用するオーケストレーションツールは StackStrom です。サービスの再起動、マシンの再起動、構成の変更など、自動化された各アクションをアトムに抽象化します。これらのアトムは、StackStrom を通じてワークフローに組み込まれます。これらのワークフローは、当社の経験豊富な運用および保守の専門家によって構築された、より高レベルの抽象的でよりセマンティックなモデルです。例えば、マシンの容量拡張、シームレスな切り替え、フロントエンドの負荷分散に関する調整、バックエンドアプリケーションの調整などを含むシステムをリリースしたい場合、これらはすべてオーケストレーションルールになります。

インテリジェントプラットフォームは、NLP 分析、根本原因分析、傾向予測、異常検出などのアルゴリズムを使用して、ナレッジグラフと検索エンジンの 2 つのモデルを生成します。これら 2 つのモデルは、運用保守センターの質問応答バックグラウンド、オーケストレーション管理、監視システムに適用されます。

1) インテリジェントなQ&A/実行

図に示すように、これはインテリジェントな Q&A/実行のケースです。ユーザーはサービスデスクの会話ウィンドウを通じて質問します。これらの質問はリクエストの形式で Q&A バックエンドに送信されます。バックエンドは、検索エンジンとナレッジグラフデータを使用して、Q&A、アクション実行などの情報を自動的にフィードバックします。

2) 障害検出

現在、最も研究されている AIOps は KPI であり、ログなどのさまざまなデータを使用して、根本原因分析、傾向予測、異常検出などのアルゴリズムを通じて対応するアルゴリズム/モデルを生成します。これらのアルゴリズム/モデルを監視システムに適用するのが監視アラーム部分です。監視アラームの結果はディスプレイボードに表示され、ユーザーに通知されます。

4. 能動的な知覚を実現する方法

4.1 問題点

私たちのビジネスは IT 環境で運営されています。この IT 環境とは、データセンター、サーバー、各種システム、サードパーティのアプリケーション、ネットワークユーザーの機器など、ビジネスを担う IT のことです。クラウドプラットフォームの構築やマイクロサービスの発展により、運用保守担当者が観測できない部分が多くなっています。また、入出力比率を考慮し、一部観測しない部分もございます。そのため、運用・保守担当者が監視できる IT は、実際に業務を担う IT に比べてはるかに少ないのが実情です。

運用と保守によって観測可能な IT 環境では、実際に観測される IT データには、スイッチトラフィックパケット、プロセスの実行状態、ネットワークカードトラフィック、CPU 使用率、リクエスト数などのデータのみが含まれることがよくあります。 AIOps を構築する場合、データの整合性が非常に重要です。観察する IT 環境が増え、取得するデータがより完全になればなるほど、AIOps の構築に役立ちます。能動的な認識が必要なのはこのようなときです。

4.2 能動的知覚の定義

Wikipedia ではアクティブセンシングを次のように定義しています。

アクティブパーセプションとは、エージェントの動作を選択して、問題の環境内でそれらの動作によって取得されたセンサーデータのフローから得られる情報コンテンツを増やすことです。 ——ウィキペディア

簡単に言えば、能動的な知覚は実際に各参加者にアイデンティティを与えます。参加者は、環境からデータを積極的に取得し、環境から取得したデータに基づいて、さらなる発見や新しいデータの取得を積極的に行います。取得データの情報量と情報価値を高めることが目的です。

上の図は、知覚部分に焦点を当てた典型的な能動知覚プロセスを示しています。センサーは、状況認識、状況理解、先見を通じて環境を認識し、決定を下し、その決定によってアクションが生成され、そのアクションが認識にフィードバックされます。

4.3 アクティブ知覚フィールド

能動知覚は人工知能の分野では珍しい用語ではありません。次のような多数のアプリケーションがあります。
ロボットはどのようにして環境を観察し、エッジ情報をどのように確認し、物体をどのように識別するのでしょうか。
自動運転では、実際に取得した画像データをすべてセンターに送って処理すると、情報量と計算能力が非常に大きくなり、現在のチップではそのような大量処理の要件を満たすことができません。私たちのアプローチは、環境データを検出するときに変化を認識し、変化データを取得することです。
スマートフォンは主にGPSとカメラを搭載しており、環境の変化を感知することができます。直接行動し、人々に影響を与えます。
道路ネットワークの監視と道路ネットワークの識別。これには、車両速度の変化の積極的な認識と、移動中の車両が速度超過しているかどうかの判断が含まれます。

4.4 分散能動知覚

AIOps は分散アクティブ認識を導入します。

実際の IT 環境の参加者向けのモデルを構築することで、関連する IT データを意図的に取得し、取得したデータに基づいて取得したデータと方法を継続的に最適化し、実際の IT のリアルタイムかつ完全な監視を実現します。

従来の監視方法は受動的です。受動的な収集ではすべてのデータを収集することは不可能であり、データの信頼性と完全性は保証されません。すべての IT 参加者をモデル化し、そのモデルを使用して実際の参加者の ID と彼らが所有するデータを把握できれば、よりリアルタイムで完全なデータを収集できます。

1) 能動的な知覚モデリング

アクティブ知覚モデリングには、ローカルモデリングとグローバルモデリングが含まれます。ローカルモデリングでは、職場やホストなどの IT 参加者にのみ焦点を当てる必要があります。グローバルモデリングでは、国内に職場がいくつあるか、それらがどこに分布しているか、そしてそれらをどのように結び付けるかを考慮する必要があります。

2) アクティブセンシングアクション

能動的な知覚の作用には、能動的なスクリーニングを伴う受動的な知覚と能動的な行動を伴う能動的な知覚という 2 つの側面が含まれます。

能動的なスクリーニングには受動的な認識が伴います。たとえば、ネットワークカードのトラフィックデータはリアルタイムで監視されますが、すべてのデータを収集するわけではありません。データが急増したり、異常が発生したときのみ収集します。これはアクティブスクリーニングです。
能動的な行動を伴う能動的な知覚は、実際に環境データを取得する際に、イントラネット内のマシンのいくつかのポートのみを大まかに取得します。危険なポートが見つかった場合、これらの動作をシミュレートするためのプロトコル要求を送信するなど、これらのポートは慎重に検出されます。これは能動的な行動を伴う能動的な認識です。

3) アクティブセンシング方式

アクティブ知覚には、ルールベースとインテリジェントアルゴリズムベース（ベイズ決定木など）の 2 つの方法があります。現在、ルールベースの方法が最も一般的に使用されています。

4) アクティブに感知されるデータの種類

アクティブ知覚のデータの種類には、ポートレートデータ、参加者間の関係、アクティブスクリーニングとアクティブ行動の詳細のキャプチャ、位置追跡などが含まれます。

5) アクティブセンシングシステム

アクティブパーセプションシステムには、ネットワークエージェント全体、ビジネスエージェント、ネットワークエージェント、アプリケーションエージェントが含まれており、これらはすべてセンサーです。

4.5 ネットワーク全体の認識モデル

分散アクティブセンシングとは何かを例を使って説明しましょう。

完全なネットワーク認識の背景: CreditEase には全国に多くの職場があり、それらはすべて重要な参加者です。各職場には業務システムを利用する業務担当者が多く存在し、これらの職場を監視する必要があります。

まず、分散アクティブセンシング方式を使用して、職場ネットワークというモデルを構築します。職場にエージェントを配置します。勤務地が全国に分散しており、フルネットワークエージェントであることから、フルネットワークエージェントと呼ばれます。認識内容には、どの出口があるのかなどが含まれます。ネットワークとアイデンティティの識別。ネットワークの大きさ。エッジ検出;および一連の内部統計データ。同時に、社内イントラネットのリスク監視も実施し、シミュレーションデータや誘発攻撃を通じてイントラネットにセキュリティリスクがあるかどうかも発見します。

4.6 ネットワーク全体の認識アプリケーション

ネットワーク全体のエージェントは、出口、ネットワークセグメント、地理的位置、オペレータ情報などのローカルワークプレイス情報を取得し、それをトポロジとマップにフィードバックします。同時に、ITSM は組織および職場のすべての情報を管理します。これらの職場のアイデンティティ情報と、アクティブに認識されたエージェントによってフィードバックされた情報が組み合わされ、正確で詳細なトポロジ/マップが描画されます。
ネットワークエージェント全体は、ネットワークからすべての職場デバイスとその配布を取得してフィードバックします。
ネットワーク全体のエージェントは危険なポートをスニッフィングし、攻撃をスキャンし、リスクに関する詳細なスキャンデータを提供します。
ネットワークエージェント全体がネットワーク統計をシステムにフィードバックし、トポロジと監視の改善に役立ちます。
グリッドデータと職場の ID を使用して、さまざまなエージェントにさまざまな監視シミュレーション構成を追加することができ、エージェントはシミュレーション監視データを開始します。異常が発見された場合、ネットワーク全体からより詳細なトポロジネットワーク監視と集中的なシステム検出データを取得できます。

上の図は、職場情報、組織情報、シミュレートされた監視データ、動的監視構成など、ネットワーク全体の認識の例を示していますが、詳細については説明しません。

4.7 ネットワーク認識モデル

上の図はネットワーク認識モデルを示しています。まずはモデリングを行います。モデリングのポイントはネットワークの参加者、つまり各スイッチであり、ネットワーク内のすべてのサーバーをリアルタイムで監視およびスキャンします。このモデルを通じて、異常な詳細データを直感的かつリアルタイムで確認し、ネットワークの品質を確保できます。

上の図はネットワーク認識の例を示しています。