JP6847590B2 - 統合監視運用システムおよび方法 - Google Patents

Description

本発明は、複数の監視運用システムにおける運用状況を統合して監視運用することが可能な統合監視運用システムおよび方法に関する。

ネットワーク監視システムに関する技術として例えば、特開２００４−２１５４９号公報（特許文献１）、特開２０１４−０６０７７２号公報（特許文献２）がある。また、類似技術として、例えば、特開２０１２−８８７７０号公報（特許文献３）がある。

特許文献１には「監視対象装置に対する監視をネットワークを挟んで監視装置で行うネットワーク監視システムであって、上記監視対象装置に設けられ当該監視対象装置の少なくとも性能情報を含む監視情報を収集する情報収集エージェント手段と、上記監視装置に設けられ上記情報収集エージェント手段で収集した稼動情報を取得し、該稼動情報に基づき当該監視対象装置における障害の発生を検知する監視マネージャ手段と、該監視マネージャ手段が上記情報収集エージェント手段における上記稼動情報を収集する際に、当該監視装置の正当性の認証を行う認証手段とを有することを特徴とするネットワーク監視システム。」との記載ある。

また、特許文献２には「起こり得る攻撃又は異常態様の指標を用いてトラフック特性をエンコードし、ネットワーク攻撃を正確に検知するために前記指標のセットのコード化された値における時系列パターンを参照する、方法。」との記載がある。

また、特許文献３には「コンピュータリソースの状況を監視して状況に応じた制御を行う制御システムにおいて、前記制御システムの備える処理装置が処理を行う方法であって、前記処理装置が、複数の監視エージェントから収集された計測値と予め定義された制御ルールとを比較して、前記コンピュータリソースに対するアクションの要否を判断するステップと、前記コンピュータリソースに対するアクションを要すると判断された場合に、前記コンピュータリソースに対するアクションを実行するための指示を出力するステップと、前記監視エージェントと前記制御システムとの間でデータを非同期的に交換するステップと、を備え、前記制御システムは、複数の仮想サーバによって構成され、第１の監視エージェントが、前記交換するステップを処理する仮想サーバの状況を監視し、前記アクションは、前記第１の監視エージェントから収集された計測値に基づいて、前記制御システムに含まれる仮想サーバの数を増減させる処理を含む、ことを特徴とするコンピュータリソース制御方法。」との記載がある。

特開２００４−２１５４９号公報 特開２０１４−０６０７７２号公報 特開２０１２−８８７７０号公報

特許文献１では、環境の異なる複数の監視運用は想定されていない。そのため、「大規模なマルチベンダ環境の分散コンピュータネットワークの運用管理者の負担の軽減とＴＣＯの削減を可能」とする効果に留まる。

情報漏洩防止などの理由により、データ共有ができない環境の異なる複数監視運用を行う場合、環境対応ごとに独立した監視運用を行うのが通常である。そのため、障害、障害時の各データ、分析結果なども共有できない。つまり、障害の監視分析のため取得しているパフォーマンス情報やログなどのデータは、環境同様に共有してはならない。もし、各環境で取得した情報（データ）を同じデータベース（ＤＢ）へ登録し、当該ＤＢにおけるデータを共有するためには、何等かの情報漏洩対策、例えば、機密情報の削除又は情報置換や情報にタグを付与するなどで区別する必要がある。

しかし、このように機密情報の削除又は情報置換や情報にタグを付与するなどして情報を区別すると、発生した障害や障害発生時のデータや分析結果などの情報、いわゆるノウハウもそのままでは共有することができなくなる。ノウハウを共有する場合は、一般的には、対象データから情報漏洩の可能性がある機密情報、例えば、ログに含まれるＩＰアドレスやサーバ名などに対しマスク／削除、置換などの修正が必要となり、どのログにどのような情報が記録されるかなどを調査する必要がある。また、修正漏れは情報漏洩を意味するため修正後のチェックも厳重に行う必要がある。その結果、修正作業にかかる工数は非常に高くなり、実用向きとは言えない。

特許文献２に記載された発明は、ＤＤｏＳなどの攻撃を受けていることを機械学習により、推測するものである。しかし、特許文献２では、攻撃の影響を排除および低減するための対策を示唆する装置等を構築に留まり、情報漏洩防止、データを共有できない環境の異なる各監視運用システムとの連携までについては何ら考慮されていない。

特許文献３に記載された発明は、監視対象システムに含まれるコンピュータリソースの状況をリアルタイムに把握し、制御するものであるが、環境の異なる複数の監視運用システムにおいて、それぞれ教師データを作成し、環境の異なる複数の監視運用システム間において、当該教師データを含むリソース貸与を行い、教師データを共有することまでは考慮されていない。

そこで、本発明では、上述したような修正作業を行うことなく、全ての環境でノウハウを共有可能とし、効率的に監視運用を行う技術を提供することを目的とする。

上記課題を解決するために、代表的な本発明の統合監視運用システムおよび方法の一つは、
第１環境対応の第１監視運用システムと、第２環境対応の第２監視運用システムと、を備え、
データを共有できない環境にある前記第１環境対応の第１監視運用システムおよび前記第２環境対応の第２監視運用システムは、
各環境にある監視運用システムから取得した取得データと、障害の原因を特定するに足りる障害区分を含む教師データを記憶する記憶装置と、前記取得データは、機密情報を含み、前記障害区分は、機密情報を含んでいないものであり、
前記記憶装置における教師データを元に識別モデルを作成し、新たに発生した障害時における取得した前記取得データと前記教師データを元に作成した識別モデルから障害区分の判定、障害の原因の決定を機械学習機能により可能とする機械学習装置と、
前記記憶装置と前記機械学習装置に接続された演算装置を備え、
前記教師データは、各環境における第１監視運用システムおよび前記第２監視運用システムにおいて共有される機械学習用のデータであり、
前記演算装置は、
各環境における第１監視運用システムおよび前記第２監視運用システムの運用状況を監視し、システムに障害が発生した場合、障害情報を検知する運用状況監視部と、
前記運用状況監視部にて障害情報を検知した場合、当該障害情報に対応し、前記機密情報を含んでいるデータを取得するデータ取得部と、
前記教師データにおける障害情報、前記データ取得部にて取得した取得データを分析するデータ分析部と、
新たな障害が発生した場合、新たに検知した障害における取得データと前記記憶装置における教師データを元に作成された識別モデルから、前記新たな障害が発生した取得データの、パターン化した障害区分を判定し、障害の原因を決定する障害区分判定部と、
を有し、
データを共有できない環境にある前記第１監視運用システムおよび前記第２監視運用システムにおいて、各環境における前記第１監視運用システムおよび前記第２監視運用システムで共有化される前記障害区分を含む教師データを使用して各環境における前記第１監視運用システムおよび前記第２監視運用システムにて収集したデータの障害の原因を機械学習機能により判定可能とすることを特徴とする。

本発明によれば、環境の異なる全ての環境でノウハウを共有可能とし、効率的に監視運用を行うことができる。

つまり、データを共有できない環境にある監視システムにおいて、そのままでは共有できないデータに一切の修正を行うことなく、障害区分を追加し教師データとして使用し、機械学習により障害の原因を判定することができる。教師データは、各環境における第１監視運用システムおよび第２監視運用システムにおいて共有される共有データであって、当該共有データ（教師データ）から得られる結果は、機密情報が含まれていない障害区分の判定結果のみであるため、機密情報が漏洩することはない。
上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

図１は、本発明の統合監視運用システムが適用されるクラウド向け統合運用サービスシステムとサービス利用者側およびシステム提供者側をネットワークで接続した構成例を示すブロック図。 図２は、クラウド向け統合運用サービスシステムにおける監視サービスを実行する統合監視運用システムの一例を示す図。 図３は、本発明の実施例１における監視運用システムを構成するサーバの構成例を示す機能ブロック図。 図４は、記憶装置のＤＢに記録された教師データの構成例を示すテーブル。 図５は、障害を検知した際における障害区分を判定するフローチャート。 図６は、障害検知の有無にかかわらず定期的に障害区分を判定するフローチャート。 図７は、本発明の監視運用システムを製品サポートシステムと連携した場合における監視運用システム（サーバ）と製品サポートシステムの構成例を示す機能ブロック図。 図８は、図７の実施例２における教師データの構成例を示すテーブル。 図９は、図７の実施例２における処理手順を説明するフローチャート。 図１０は、図９におけるサポートフローの処理手順を説明するフローチャート。 図１１は、実施例２における障害検知の有無にかかわらず定期的に障害区分を判定するフローチャート。 図１２は、障害区分／障害対策判定を説明する図。 図１３は、図１における環境Ａの監視運用システムおよび図８における製品Ｃサポートシステムから環境Ｂの監視運用システムへリソース、製品Ｃサポートシステムから製品Ｄサポートシステムへのリソースを貸与する様子を模式的に示した図。

以下、本実施例について図面を用いて説明する。
以下の説明では、「情報」を「データ」と呼ぶことができる。また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、情報処理装置／コンピュータにおける演算装置／制御装置（プロセッサ、例えば、ＭＰ／Micro ProcessorやＣＰＵ／Central Processing Unit）によって実行されるものであり、定められた処理をするものである。プロセッサは、適宜に記憶資源（例えばメモリ）および通信インターフェース装置（例えば、通信ポート）を用いながら処理を行うため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していてもよい。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであってもよい。

本発明は、機密情報を含む情報を情報漏洩なく共有する方法として、機械学習を用いて障害区分を判定し、複数の監視運用システムが取得したデータに障害区分を設定し集約することで、全監視運用システム間で共有する教師データとするものである。以下、その一実施例について説明する。

図１は、本発明の統合監視運用システムが適用されるクラウド向け統合運用サービスシステム３とサービス利用者側１およびシステム提供者側２をネットワーク４で接続した構成例を示すブロック図である。

サービス利用者側１は、利用者通信端末１１を備え、システム提供者側２（２１，２２）は、図示していないが、例えば、ソリューションベンダ、ユーザ企業、情報システム会社、パッケージソフト会社、他であり、ＩＴサービスを提供するＩＴ基盤／ＩＴシステムの運用などを委託するＩＴ管理部門端末（ＰＣなどの情報処理装置）、を備えている。

システム提供者側２におけるＩＴ基盤／ＩＴシステムは、
システム提供者側２にて構築したクラウド、例えば、パブリッククラウド（public cloud）、プライベートクラウド（private cloud）、又はハイブリッドクラウド（hybrid cloud）を有する。

これらのクラウドは、例えば、在庫管理システムや、ＥＤＩ（Electronic Data Interchange）、つまり、商取引に関する情報を標準的な形式に統一して、企業間で電子的に交換し、例えば、複数の企業や団体などの間で、商取引のための各種情報（注文書や請求書等）を、お互いのコンピュータが通信回線（ネットワーク）を介してコンピュータ同士で交換するソリューション、また、クラウド上のＩＴリソースを、必要なときに低価格で可能なリソース、Ｗｅｂ・メールホスティングサービス、多言語会計システムなどを提供するものである。

パブリッククラウドとは、例えば、データセンタ事業者などが、広く一般の利用者に提供するクラウドコンピューティング環境のデータセンタにおいて、顧客の要望に応じてソフトウェアやハードウェアの利用権などをネットワーク越しにサービスとして提供するものであり、その中で運用されているサーバ群などのことである。

プライベートクラウドとは、例えば、企業などが自社内で利用するために構築したクラウドコンピューティング環境において、社員や関連会社、取引先など、内部の限定された利用者に向けて、ソフトウェアやハードウェアの利用権などをネットワーク越しにサービスとして提供するものであり、その中で運用されているサーバ群などのことである。

ハイブリッドクラウドとは、クラウドコンピューティングの実現形態の一つであるパブリッククラウドとプライベートクラウドを組み合わせたものである。また、仮想化システム上で実行されている仮想マシン（VM：Virtual Machine）を、プライベートクラウドとパブリッククラウドをまたいで移行できるような運用形態のことである。

プライベートクラウドは、例えば、データセンタを有し、データセンタは、データセンタサービスを提供するソリューション機能を有するものである。

データセンタサービスは、データセンタにおいて、運用ノウハウを基に、顧客の業務システムの運用まで幅広く対応するサーバ／メインフレームアウトソーシングサービス、ハウジングをはじめとしたＩＴシステムのライフサイクルを支援する各種ソリューションを提供するライフサイクルソリューションセンタサービス、開発、運用、保守などＩＴシステムのライフサイクル全般に必要なＩＴリソースを、必要なときに必要なだけ提供するリソースオンデマンドサービス、などを含む。
そして、プライベートクラウドのデータセンタは、オンプレミス（on-premises）環境にある。

オンプレミス環境とは、ＩＴ基盤／ＩＴシステム（情報システム）を使用者（通常は企業）自身が管理する設備内に導入、設置して運用するものであり、企業の業務システムなどで、自社で用意した設備でソフトウェアなどを導入・利用することができる環境である。

ＩＴ管理部門担当通信端末は、ＩＴ基盤／ＩＴシステムを管理するＰＣなどの端末であり、また、当該ＩＴ基盤／ＩＴシステム（パブリッククラウド、プライベートクラウド）の運用を代行する企業に依頼する端末でもある。

サービス利用者側１は、利用者通信端末１１を備えている。
利用者通信端末１１は、システム提供者側２からＩＴ基盤／ＩＴシステムなどの運用の委託を受けた企業に対して、システムに関する問い合わせを行うための電話やＰＣなどの端末であり、また、運用委託企業やシステム提供者側２からの問い合わせに対する対応応答、応急措置指示や作業指示、配信情報などの送受を行う端末でもある。

クラウド向け統合運用サービスシステム３は、ネットワーク４を介してシステム提供者側２のシステムや通信端末、およびサービス利用者側１の利用者通信端末１１に接続する。
そして、クラウド向け統合運用サービスシステム３は、システム提供者側２からのＩＴ基盤／ＩＴシステムに関する運用委託を受け、環境Ａにおいて運用されているシステムおよび環境Ｂにおいて運用されているシステムに各種サービス、例えば、業務ＢＰＯ（Business Process Outsourcing）サービス（一般業務の問い合わせ、業務代行）、ＩＴシステムサービス（窓口一元化、ワンストップ対応）、運用監視サービス（２４時間、３６５日対応）、などを体系化、一本化して運用し、サービスクラウド向け統合運用サービスとしてお客様（顧客側、利用者側）にアウトソーシングするコンタクトセンタ３１を備えている。

すなわち、クラウド向け統合運用サービスシステム３は、環境Ａにおいて運用されているＩＴ基盤／ＩＴシステムおよび環境Ｂにおいて運用されているＩＴ基盤／ＩＴシステムにおける各種サービス、例えば、ＢＰＯサービス（一般業務の問い合せ、業務代行）、ＩＴシステムサービス（窓口一元化、ワンストップ対応化）、監視サービス（２４時間、３６５日対応）、などを運用する機能を有する。

コンタクトセンタ３１は、ＣＯＰＣ（Customer Operations Performance Center）に準拠し、例えば、サーバからなる。
そして、業務ＢＰＯサービス、ＩＴシステムサービス、運用監視サービス、の各サービスを提供するアウトソリューション機能を有する。

コンタクトセンタ３１は、ＩＴ系の業務は勿論、ヘルプデスク、バックオフィス業務といったＩＴ以外（非ＩＴ系）の業務を含めて、トータルでアウトソーシングサービス（業務代行）を提供する。

また、コンタクトセンタ３１は、複数の拠点に配置され、システム提供者側２からの運用などの委託を受け、クラウド向け統合運用サービスシステム３側にて蓄積した豊富なサポート経験を基に、ベンダーが行うソフトウェア／ハードウェア製品の、サービス利用者（一般消費者）に対するサポートサービス業務を代行する。

業務ＢＰＯサービスとは、例えば、顧客へのヒアリングに基づいた運用業務の設計構築からＩＴ業務代行、一連の業務プロセスを顧客に代わって遂行し、また、一般業務の問い合わせ（非ＩＴ業務代行）などを実行するサービスである。つまり、ヘルプデスクサービスなどを含むバックオフィスＢＰＯを実行する。

ＩＴ業務代行とは、システム提供者側２のＩＴ業務を代行するものであり、非ＩＴ業務代行とは、システム提供者側２の非ＩＴ業務を代行するものである。

ここで、ＩＴ業務とは、ソフトウェア、ネットワークなどコンピュータに関する技術力が必要な業務を意味し、例えば、WindowsやVMware（コンピュータを仮想化するソフトウェア）に関するサポート業務などが該当する。
非ＩＴ業務とは、ＩＴ業務以外の業務を意味し、例えば、「花屋」や「ファンクラブ」などの受付窓口業務などが該当する。

ＩＴシステムサービスとは、ＩＴサービス、例えば、ヘルプデスク（Help desk）サービスの窓口の一元化、ワンストップ対応などのＩＴシステムサービスを実行するサービスである。そして、コンタクトセンタ３１と連携し、各製品をサポートする製品サポート機能（各製品のサポートを実行するソリューション）有する。製品サポート機能とは、システム提供者側２におけるＩＴ基盤／ＩＴシステムに使用されている各製品に障害などが発生したとき、当該各製品の障害原因を解消すべく、障害の原因特定から対策までを対応するサービスである。また、対策においては保守センタの保守員などに通知し、その対応を実行する場合も含まれる。

ヘルプデスクサービスとは、サービス利用者、例えば、企業（顧客）におけるシステムを利用する利用者からのシステムやＩＴ機器に関する質問や問い合わせ、要望、不具合などの対処要請をＩＴサポート受付窓口にて受け付け、当該対処要請に対応するヘルプデスク業務などのヘルプデスクサービスを支援するソリューションである。

運用監視サービスとは、ＩＴ基盤／ＩＴシステムの運用を、例えば、２４時間、３６５日対応で監視するサービスである。

コンタクトセンタ／サーバ３１は、上述した各サービスを実行する演算装置／制御装置を含む情報処理装置／コンピュータを有する。

情報処理装置／コンピュータは、ビジネス・プロセス・アウトソーシング（ＢＰＯ：Business Process Outsourcing）ソリューション機能を含む。

情報処理装置／コンピュータにおけるアウトソーシングソリューション機能とは、例えば、業務ＢＰＯサービス、ＩＴシステムサービス、運用監視サービス、をサービス利用者に提供するものである。また、これらのサービスに対するサービス利用者の抱える問題・課題を解決したり、要望・要求を満たすものである。

また、コンタクトセンタ／サーバ３１は、情報処理装置／コンピュータ、の他、システム提供者側２およびサービス利用者側１との間で通信を行うインターフェース部を含む通信装置、必要なデータを蓄積するデータ蓄積部を含む記憶装置、データの入出力を行う入出力装置を備えている。

情報処理装置／コンピュータは、業務ＢＰＯサービスを提供する業務ＢＰＯサービス部、ＩＴシステムサービスを提供するＩＴシステムサービス部、監視サービスを提供する運用監視サービス部、を有する。

業務ＢＰＯサービス部におけるバックオフィスＢＰＯとは、例えば、企業などの組織において、事務・管理業務などを担当し、顧客に直接対応するフロントオフィスを支援し、ＩＴインフラ（ＩＴシステム）、ファシリティ（facility）、の運用をクラウドと併せて代行し、エンドユーザ（利用者、一般消費者）側に提供するサービス利用者側１のビジネスをサポートするものである。

ＩＴ基盤・ＩＴシステムサポート部におけるＩＴシステムサービスとは、ＩＴシステムを支援する機能である。

ＩＴ基盤・ＩＴシステムサポート部は、各製品をサポートする製品サポート部、ミドルウェアサービス部、各種ＯＳサービス部、を含む。

運用監視サービス部における運用監視サービスとは、ＩＴ基盤／ＩＴシステムの運用監視サービスである。

図２は、クラウド向け統合運用サービスシステム３における監視サービスを実行する統合監視運用システム３１０の一例を示す図である。

統合監視運用システム３１０は、環境Ａ対応の監視運用システム３１３、環境Ｂ対応の監視運用システム３１４を有する。

環境Ａ対応の監視運用システム３１３は、環境Ａにおける運用状況を監視し、運用状況に障害が発生した場合、その障害に関する各種情報を取得し、管理する機能を有する。環境Ｂの監視運用システム３１４は、環境Ｂにおける運用状況を監視し、運用状況に障害が発生した場合、その障害に関する各種情報を取得し、管理する機能を有する。
監視運用システム３１３および監視運用システム３１４は、例えば、障害の検知範囲が異なる監視ソフトを利用するとよい。これにより、例えば、環境Ａから得た教師データを元にした機械学習だけでは判定できない障害を、環境Ｂから得た教師データも含めることで、機械学習で判定できる可能性が広がる。

図３は、監視運用システム３１３、３１４を構成するサーバの構成例を示す機能ブロック図である。監視運用システム３１３、３１４は、同様な構成となっているの、監視運用システム３１３を例にその構成について説明する。

監視運用システム（サーバ）３１３は、インターフェース装置３１３１、機械学習装置３１３２、記憶装置３１３３、演算装置３１３４、を有する。

インターフェース装置３１３１は、各環境Ａ、Ｂにて運用されているシステム提供者側２の各システムやシステムサービス利用者側の利用者側端末との間で各種データの送受信を行う機能を有する。
機械学習装置３１３２は、運用分析ソフトウェアからなる機械学習部を有する。

記憶装置３１３３は、各環境における監視運用システムで共有化される教師データを格納するデータベース（ＤＢ）を有する。

演算装置３１３４は、運用状況監視部３１３４１、データ取得部３１３４２、データ分析部３１３４３、データ格納部３１３４５、障害区分判定部３１３４６、通報部３１３４７、を有する。
演算装置３１３４は、機械学習装置３１３２と連携し、内部に格納されたプログラムに従って上記の各部の動作を制御する。

運用状況監視部３１３４１は、各環境Ａ、Ｂにおける運用状況を監視し、システムに障害が発生した場合、機密情報を含んでいない障害、つまり障害情報（障害の種類）を検知する。障害情報（障害の種類）は、例えば、図５に示すようにＷＥＢサイトアクセス不可、ＷＥＢサイト応答遅延、などである。

データ取得部３１３４２は、各障害情報（障害の種類）に対応し、機密情報を含んでいるデータを取得する。この取得するデータは、例えば、図５に示すようにパフォーマンス（サービスＣＰＵの使用率、サービスメモリの使用量、サービスデータ書込み数、ネットワーク帯域、システム書込み数）やログ（サービスログ、システムログ）、などの各データである。

データ分析部３１３４３は、教師データにおける障害情報（障害の種類）、取得したデータ、を分析する。そして、障害情報（障害の種類）、取得したデータ、分析結果をもとに機密情報を含んでいない障害区分、つまり、障害の原因を特定するに足りる障害区分を決定する。障害区分は、例えば、図５に示すようにポート競合、ネットワーク障害、サーバリソース不足、アクセス集中、正常、ネットワーク遅延、Ｄｉｓｋ応答遅延、などである。

ここで、データ分析部におけるデータ分析には、機械学習装置３１３２（運用分析ソフトウェア）における機械学習技術を利用する。
機械学習（machine learning）とは、人間が自然に行っている学習能力と同様の機能をコンピュータで実現しようとする技術・手法のことであって、データから反復的に学習し、そこに潜むパターンを見つけ出すことであり、そして学習した結果を新たなデータにあてはめることで、パターンにしたがって将来を予測することができる。これは予測分析におけるモデル構築の自動化につながり、データサイエンティストの人材不足を補うものになると、大きく期待されている。機械学習、そのものは、周知なので、その詳細説明は省略する。

本例では、障害情報（障害の種類）、取得したデータ、分析結果をもとに機密情報を含んでいない障害区分、つまり、障害の原因を特定するに足りる障害区分（ポート競合、ネットワーク障害、サーバリソース不足、アクセス集中、正常、ネットワーク遅延、Ｄｉｓｋ応答遅延、など）を決定し、当該障害区分を機会学習の学習用のデータ、いわゆる教師データを元に識別モデルを作成し、新たに発生した障害時における取得した未知のデータから障害の原因を機械学習により判定するものである。

例えば、検知した障害が「ＷＥＢサイトアクセス不可」であって、サービスＣＰＵ使用率が「２」、サービスメモリ使用量が「１０」、サービスデータ書き込みが「３」、ネットワーク帯域が「５０」、サービスログが「×××」、システムログが「Ｘｘｘ」、システム書き込みが「１００」である場合は、障害区分が「ポート競合である過去の運用状況ログデータと障害区分を教師データとして蓄積しておく。そして、各環境における監視運用システム間において、機密情報を含む教師データを共有できるようにする。

障害区分判定部３１３４６は、新たに障害が発生した際、新たに検知した障害における取得データとＤＢにおける教師データを元に作成した識別モデルから、パターン化した障害区分を判定し、障害の原因を決定する。
取得データと機械学習から得られる結果（判定）は、機密情報が含まれていない障害区分の判定結果のみであるため、機密情報が漏洩することはない。また、ログに含まれているＩＰアドレスやサーバ名などを、削除／置換するなどの処理工数も不要である。

通報部３１３４７は、障害を検知し、通報が必要な場合、インターフェース装置３１３１を介して監視運用関係者側に障害検知を通報する。

図４は、教師データの構成例を示すテーブルである。教師データは、記憶装置３１３３のＤＢに登録され、障害情報（障害の種類）３１３３１、取得データ（各種ログなど）３１３３２、障害区分３１３３３、などを含む。

監視運用システム３１３にて検知した障害情報（機密情報含まず）３１３３１は、例えば、ＷＥＢサイトアクセス不可、ＷＥＢサイト応答遅延などであり、取得したデータ３１３３２（機密情報含む）は、パフォーマンス情報（サービスＣＰＵ使用率、サービスメモリ使用量、サービスデータ書込み数、ネットワーク帯域、システム書込み数）や各種ログ情報（サービスログ、システムログ）、などであり、障害区分（機密情報含まず）３１３３３は、障害の原因を特定するためのデータ（ポート競合、ネットワーク障害、サーバリソース不足、アクセス集中、正常、ネットワーク遅延、Ｄｉｓｋ応答遅延）、などである。
取得したデータ３１３３２の、例えば、サービスログ×××には、ＩＰアドレス（192．18．0．102など）、会社名（Ａ−Corp）やホスト名（host 10）、ユーザＩＤ（33445566）などの機密情報が含まれている場合がある。
本例では、これらの取得データを元に機会学習機能を利用して機密情報が含まない障害区分、を含む教師データを作成し、蓄積する。

図５は、障害を検知した際における障害区分を判定するフローチャートである。図５のフローチャートに示す動作は以下のとおりである。

ステップＳ６０１：演算装置３１３４は、障害検知有無を判定する。当該ステップにて障害を検知した場合（ＹＥＳ）は、ステップＳ６０２に進み、障害を検知しなかった場合（ＮＯ）は、処理を終了する。
ステップＳ６０２：演算装置３１３４は、取得したデータ３１３３２の中から、パフォーマンスやログデータを取得する。
ステップＳ６０３：演算装置３１３４は、機械学習部の機械学習技術を利用しで判定する。つまり、ステップＳ６０２にて取得した障害時の取得データを機械学習により障害区分を判定する。
ステップＳ６０４：演算装置３１３４は、監視運用関係者側に通知を必要とするか否かの判定を行う。当該ステップに通報が必要でない場合（ＮＯ）は、終了し、通知が必要である場合（ＹＥＳ）は、ステップＳ６０５に進む。
ステップＳ６０５：演算装置３１３４は、監視運用関係者側に障害検知を通報した上で終了する。

図６は、障害検知の有無にかかわらず定期的に障害区分を判定するフローチャートである。図６のフローチャートに示す動作は以下のとおりである。

ステップＳ７０１：演算装置３１３４は、取得したデータの中から、パフォーマンスやログデータを取得する。
ステップＳ７０２：演算装置３１３４は、機械学習により障害区分を判定する。つまり、ステップＳ７０１にて取得した障害時の取得データと機械学習により障害区分を判定する。
ステップＳ７０４：演算装置３１３４は、監視運用関係者側に通知を必要とするか否かの判定を行う。当該ステップに通報が必要でない場合（ＮＯ）は、終了し、通知が必要である場合（ＹＥＳ）は、ステップＳ７０５に進む。
ステップＳ７０５：演算装置３１３４は、監視運用関係者側に障害検知を通報した上で終了する。

図７は、本発明の監視運用システム３１３、３１４をサポートシステム３２０と連携した場合における監視運用システム（サーバ）とサポートシステムの構成例を示す機能ブロック図である。

本実施例は、実施例１における監視運用システム（サーバ）３１３／３１４をサポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０と連携し、サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０における障害対策データを考慮して教師データを作成するものである。実施例１と同一部分には同一番号を付与し、その説明は省略し、相違する点のみについて説明する。

監視運用システム（サーバ）３１３／３１４は、さらに、障害対策データ取得部３１３４８、障害対策実行部３１３４９、を有する。障害対策データ取得部３１３４８は、サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０にネットワークを介して接続され、当該サポートシステム３２０にて作成された障害対策データを取得する。障害対策実行部３１３４９は、障害の対策を実行する。

製品サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０は、障害対策調査用データ取得部３２０１、障害対策調査実行・データ分析部３２０２、障害対策データ作成部３２０３、障害対策データ格納部（ＤＢ）３２０４、機械学習部３２０５、を有する。

障害対策調査用データ取得部３２０１は、監視運用システム３１３、３１４から障害の対策に必要とされる障害対策調査用データを取得する。

障害対策調査実行・データ分析部３２０２は、障害対策調査用データの調査を実行し、分析する。

障害対策データ作成部３２０３は、障害対策調査実行・データ分析部３２０２にて分析した分析データを元に障害を解消して回復する上で有効な障害対策データを作成する。
つまり、製品サポートシステムにおける機械学習部３２０５は、監視運用システム３１３、３１４における教師データ３１３３０から障害対策データを含む識別モデルを作成する。更に機械学習部３２０５は、障害発生時の障害区分／障害対策の判定も行う。
障害対策データ格納部（ＤＢ）３２０４は、障害対策データを格納する。

図８は、図７の実施例における教師データの構成例を示すテーブルである。
本例では、教師データとして、検知した障害３１３３１、取得データ３１３３２、障害区分３１３３３に加えて障害対策３１３３４が含まれる。

障害対策３１３３４は、例えば、競合プロセス確認ポート変更、通信ツーと変更部、不足リソース算出・リソース追加、サーバ追加、ミラーサイト作成、ストレージ高速化、などである。

図９は、図７の実施例２における処理手順を説明するフローチャートである。図９のフローチャートに基づく動作は以下のとおりである。

ステップＳ１００１：演算装置３１３４は、障害検知有無を判定する。当該ステップにて障害を検知した場合（ＹＥＳ）は、ステップＳ１００２に進み、障害を検知しなかった場合（ＮＯ）は、処理を終了する。
ステップＳ１００２：演算装置３１３４は、取得したデータの中から、パフォーマンスやログデータを取得する。
ステップＳ１００３：演算装置３１３４は、取得したデータを機械学習により障害区分／障害対策を判定する。つまり、ステップＳ１００２にて取得した障害時の取得データと機械学習区分により障害区分および障害対策を判定する。
ステップＳ１００４：演算装置３１３４は、ステップＳ１００３における結果を受けて、障害区分有無を判定する。当該ステップにて障害区分有り（ＹＥＳ）の場合は、ステップＳ１００５に進み、無い場合（ＮＯ）は、ステップＳ１０１０に進む。
ステップＳ１００５：演算装置３１３４は、障害対策有無を判定する。当該ステップにて障害対策有り（ＹＥＳ）の場合は、ステップＳ１００６に進み、障害対策無い場合（ＮＯ）は、ステップＳ１０１０に進む。
ステップＳ１００６：演算装置３１３４は、ステップＳ１００５にて、障害対策が有るとき、製品の障害を解消すべき障害対策処理を実行する。
ステップＳ１００７：演算装置３１３４は、ステップＳ１００６にて実行した障害対策により障害が回復したか否かを判定する。当該ステップにて、障害回復の場合（ＹＥＳ）は、処理を終了し、障害回復できない場合（ＮＯ）には、ステップＳ１０１０に進む。
ステップＳ１０１０：製品サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０は、製品のサポートフロー（図１１参照）を実行する。

図１０は、図９におけるサポートフローの処理手順を説明するフローチャート。図１０のフローに基づく動作は以下のとおりである。

ステップＳ１０１０１：製品サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０は、各監視運用システム３１３、３１４から障害対策調査用データ収集、つまり障害発生環境の機密情報込みデータを取得する。
ステップＳ１０１０２：製品サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０は、障害対策調査実行し、調査内容／判定結果を当該システムのデータベース（ＤＢ）に登録する。
ステップＳ１０１０３：製品サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０は、障害対策を実行する。
ステップＳ１０１０４：製品サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０は、ステップＳ１０１０３における障害対策の実行により障害が回復したか否かを判定し、障害が回復している場合（ＹＥＳ）は、次のステップＳ１０１０５に進み、回復していない場合（ＮＯ）は、ステップＳ１０１０１に戻り、上記各ステップを繰り返す。
ステップＳ１０１０５：製品サポートシステム（製品Ｃサポートシステム、製品Ｄサポートシステム）３２０は、各監視運用システム３１３、３１４にて監視して得た障害に対する障害対策データ作成を作成し、当該障害対策データを当該システムのデータベース（ＤＢ）に登録する。

図１１は、実施例２における障害検知の有無にかかわらず定期的に障害区分を判定するフローチャートである。図１１のフローに基づく動作は、図９におけるステップＳ１００１がない点であるので、同一ステップには同一符号を付与して説明を省略する。

図１２は、障害区分／障害対策判定を説明する図である。
実施例１では、例えば、ポート競合によるＷＥＢサイトアクセス不可の場合における障害区分（ポート競合が発生していること）は把握できる。しかし、その対策が決まっていない状況にある場合、実施例２に示すようにサポートシステム３２０（図９のステップＳ１０１０におけるサポートフロー）と連携し、当該フローにより作成される障害対策データと各監視運用システムからのデータを元に教師データを作成することにより、より精度の高い障害区分／対策を判定することが可能となる。

例えば、障害の種類３１３３１が、図１２に示すようにポート競合によるＷＥＢサイトアクセス不可の現象である場合、取得したデータのサービス内容が同様な数値であっても、サービスログ、システムログによっては、障害区分におけるポート競合は、ポート競合（ＴＣＰ８０番）と、ポート競合（ＴＣＰ１３９９番）の２通りに細分化される。また、障害区分に併せて、その対策も異なり重複機能ＷＥＢサービスのポート変更と、ＡＢＣ．ｅｘｅプロセス停止の２通りに細分化される。
このようにサポートフローにより、蓄積された障害区分／障害対策も含むデータを教師データとすることで、教師データ作成のための工数が不要となるだけでなく、精度の高い障害区分／対策を判定できるようになる。

図１３は、図１における環境Ａの監視運用システム３１３および図７におけるサポートシステム（製品Ｃサポートシステム）３２０から環境Ｂの監視運用システム３１４へリソース、サポートシステム３２０（製品Ｃサポートシステム３２１）からサポートシステム３２０（製品Ｄサポートシステム）３２２へのリソースを貸与する様子を模式的に示した図である。また、障害発生時における対策処理を説明する図でもある。

統合監視運用システム３１０とサポートシステム３２０間でリソース（含サーバ）の貸与が可能とすることにより、統合監視運用システム３１０とサポートシステム３２０で使用しているリソースを効率的に活用できる。
本例では、環境Ａの監視運用システム３１３のリソースと製品Ｃサポートシステム３２１のリソースを環境Ｂの監視運用システム３１４に貸与し、また、製品Ｃサポートシステム３２１のリソースを製品Ｄサポートシステム３２２に貸与したものである。

このように障害が発生した場合、当該障害の対策に必要とするリソースが十分でない各システムがあれば、他のシステムのリソースを貸与することにより、システム全体として効率に活用できる。

ここで、各環境Ａ、Ｂに対応する監視運用システム３１３，３１４は、それぞれ製品サポート対応の情報（含機密情報）を格納している。製品サポート対応の情報には、障害区分３１３３３だけでなく、その発生した障害の対策方法３１３３４も含まれている場合がある。つまり、製品の障害判定結果とその判定での対策方法（パターン１、２）を共有することができる（図９参照）。
これにより、各監視運用システム３１３、３１４は、障害判定結果に基づく対策を実施することができる。ここで、対策ができない場合、つまり、製品サポートシステム３２０（製品Ｃサポートシステム３２１）への連絡（通報）が必要と判定した場合には、製品サポートシステム３２０（製品Ｃサポートシステム３２１）へ直接通報し、サポートフローを実行することも可能である。
すなわち、監視運用システム３１３，３１４は、それぞれ、各環境における製品に障害が発生した場合、当該障害の判定結果に応じた以下のようなパターン１、２の対応処理を実行する機能を有する。

パターン１：
例えば、環境Ｂの監視運用システム３１４にて、製品Ｃの障害を検知し、その判定結果、製品Ｃサポートシステム３２１への問合せが必要と判定した場合、製品Ｃサポートシステム３２１へ調査依頼をメール等により通報（連絡）する。
当該通報（調査依頼）を受けた製品Ｃサポートシステム３２１は、監視運用システム３１４における製品サポート情報を使って調査を開始する。このときの調査データは、環境Ｂのデータ群から必要なデータのみを取得する。この取得したデータには、機密情報があっても問題ない。
このように監視運用システムとサポートシステムを連携することにより、障害の検知から、障害分析（原因特定）／障害対策実施までを自動化する。

パターン２：
また、環境Ｂの監視運用システム３１４にて、製品Ｃの障害を検知し、その判定結果、判定に対策ありの場合には、当該監視運用システム３１４において、その対策方法に含まれる情報に基づく対策を実施する。

上述した実施例によれば、以下のような効果が期待できる。
（１）複数の環境から取得した情報をもとに教師データ（共有データ）を作成することで、様々な状況の教師データを短期間に作成することができる。
（２）共有データの作成にあたり、機密情報に対する情報漏洩の対策が必要ないため、対策コストを抑えられる。
（３）障害区分判定を定期的に行えば、監視運用システムが障害を検知していない障害を予測できる場合がある。そのため、監視ソフトが異なるなどの理由により、他の環境より検知できる障害が少ない場合でも、本システムにより障害予測できる場合がある。
（４）本システムによる監視運用を開始した新規の環境では、導入後すぐに分析(障害区分の判定)を利用できる。通常は、教師データを作成するまでは、機械学習による判定はできないが、本システムでは、すでに作成済の他環境の教師データを利用することで、機械学習による判定が可能となり、その期間を必要としない。
（５）本システムでは機密情報を含む情報を、特別な情報漏洩対策（削除／置換）することなく教師データ（共有データ）から障害区分を判定することができるため、商品別の売上予測など監視システム以外の利用も可能である。例えば、複数の異なるスーパーマーケットの在庫管理を行う場合、商品別の売上予測などを行える。また、予測結果など判定した結果には、機密情報を含まないので、競合他社の売り上げ情報を相互に利用することもできる。
（６）機密情報を含む情報を情報漏洩なく情報を共有化することで、リソースの使用状況を比較し、場合によっては別環境の監視運用システムへのリソースの貸し出しや借り入れを行うことができる (貸し借りをしているだけで、監視システム全体の規模は変わっていない)。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。

１ サービス利用者側
２ システム提供者側
３ クラウド向け統合運用サービスシステム
３１ コンタクトセンタ／サーバ
３１３、３１４ 監視運用システム／サーバ
３１３１ インターフェース装置
３１３２ 機械学習装置
３１３３ 記憶装置
３１３４ 演算装置
３１３４１ 運用状況監視部
３１３４２ データ取得部
３１３４３ データ分析部
３１３４４、３１３４４’ データ作成部
３１３４５ データ格納部
３１３４７ 通報部
３２０ サポートシステム（製品サポートシステム）
３２０１ 障害対策調査用データ取得部
３２０２ 障害対策調査実行・データ分析部
３２０３ 障害対策データ作成部
３２０４ 障害対策データ格納部

Claims (6)

1. 第１環境対応の第１監視運用システムと、第２環境対応の第２監視運用システムと、を備え、
   データを共有できない環境にある前記第１環境対応の第１監視運用システムおよび前記第２環境対応の第２監視運用システムは、
   各環境にある監視運用システムから取得した取得データと、障害の原因を特定するに足りる障害区分を含む教師データを記憶する記憶装置と、前記取得データは、機密情報を含み、前記障害区分は、機密情報を含んでいないものであり、
   前記記憶装置における教師データを元に識別モデルを作成し、新たに発生した障害時における取得した前記取得データと前記教師データを元に作成した識別モデルから障害区分の判定、障害の原因の決定を機械学習機能により可能とする機械学習装置と、
   前記記憶装置と前記機械学習装置に接続された演算装置を備え、
   前記教師データは、各環境における第１監視運用システムおよび前記第２監視運用システムにおいて共有される機械学習用のデータであり、
   前記演算装置は、
   各環境における第１監視運用システムおよび前記第２監視運用システムの運用状況を監視し、システムに障害が発生した場合、障害情報を検知する運用状況監視部と、
   前記運用状況監視部にて障害情報を検知した場合、当該障害情報に対応し、前記機密情報を含んでいるデータを取得するデータ取得部と、
   前記教師データにおける障害情報、前記データ取得部にて取得した取得データを分析するデータ分析部と、
   新たな障害が発生した場合、新たに検知した障害における取得データと前記記憶装置における教師データを元に作成された識別モデルから、前記新たな障害が発生した取得データの、パターン化した障害区分を判定し、障害の原因を決定する障害区分判定部と、
   を有し、
   データを共有できない環境にある前記第１監視運用システムおよび前記第２監視運用システムにおいて、各環境における前記第１監視運用システムおよび前記第２監視運用システムで共有化される前記障害区分を含む教師データを使用して各環境における前記第１監視運用システムおよび前記第２監視運用システムにて収集したデータの障害の原因を機械学習機能により判定可能と
   することを特徴とする統合監視運用システム。
2. 請求項１に記載された統合監視運用システムにおいて、
   前記教師データは、障害の種類、前記取得データ、前記障害区分、を含む、
   統合監視運用システム。
3. 請求項１に記載された統合監視運用システムにおいて、
   前記第１環境対応の第１監視運用システムおよび前記第２環境対応の第２監視運用システムは、障害が発生した場合、当該障害の対策データを作成するサービスシステムと連携する
   ことを特徴とする統合監視運用システム。
4. 請求項３に記載された統合監視運用システムにおいて、
   前記教師データは、前記障害の種類、前記取得データ、前記障害区分、障害対策データを含む、
   統合監視運用システム。
5. 第１環境対応の第１監視運用システムと、第２環境対応の第２監視運用システムと、を備え、
   データを共有できない環境にある前記第１環境対応の第１監視運用システムおよび前記第２環境対応の第２監視運用システムは、
   各環境にある監視運用システムから取得した取得データと、障害の原因を特定するに足りる障害区分を含む教師データを記憶する記憶装置と、前記取得データは、機密情報を含み、前記障害区分は、機密情報を含んでいないものであり、
   前記記憶装置における教師データを元に識別モデルを作成し、新たに発生した障害時における取得したデータと教師データを元に作成した識別モデルから障害区分の判定、障害の原因の決定を機械学習機能により可能とする機械学習装置と、
   前記記憶装置と前記機械学習装置に接続された演算装置を備え、
   前記教師データは、各環境における第１監視運用システムおよび前記第２監視運用システムにおいて共有される機械学習用のデータであり、
   前記演算装置は、
   各環境における第１監視運用システムおよび前記第２監視運用システムの運用状況を監視し、システムに障害が発生した場合、障害情報を検知するステップと、
   前記障害情報を検知するステップにて障害情報を検知した場合、当該障害情報に対応し、機密情報を含んでいるデータを取得するステップと、
   前記教師データにおける障害情報、前記データを取得するステップにて取得した取得データを分析するステップと、
   新たな障害が発生した場合、新たに検知した障害における取得データと前記記憶装置における教師データを元に作成された識別モデルから、前記新たな障害が発生した取得データの、パターン化した障害区分を判定し、障害の原因を決定するステップと、を有し、
   データを共有できない環境にある前記第１監視運用システムおよび前記第２監視運用システムにおいて、各環境における前記第１監視運用システムおよび前記第２監視運用システムで共有化される前記障害区分を含む教師データを使用して各環境における前記第１監視運用システムおよび前記第２監視運用システムにて収集したデータの障害の原因を機械学習機能により判定可能とすることを特徴とする統合監視運用方法。
6. 第１環境対応の第１監視運用システムと、第２環境対応の第２監視運用システムと、障害の対策データを作成するサービスシステム、を備え、
   データを共有できない環境にある前記第１環境対応の第１監視運用システムおよび前記第２環境対応の第２監視運用システムは、前記障害の対策データを作成するサービスシステムと連携し、
   各環境にある監視運用システムから取得した取得データと、障害の原因を特定するに足りる障害区分および障害対策を含む教師データを記憶する記憶装置と、前記取得データは、機密情報を含み、前記障害区分および前記障害対策は、機密情報を含んでいないものであり、
   前記記憶装置における教師データを元に識別モデルを作成し、新たに発生した障害時における取得した取得データと教師データを元に作成した識別モデルから障害区分を判定し、障害の原因を決定する機械学習機能を有する機械学習装置と、
   前記記憶装置と前記機械学習装置に接続された演算装置を備え、
   前記教師データは、各環境における第１監視運用システムおよび前記第２監視運用システムにおいて共有される機械学習用のデータであり、
   前記演算装置は、
   障害検知有無を判定するステップと、
   前記障害検知有無を判定するステップにて障害を検知した場合、取得したデータの中から、パフォーマンスやログデータを取得するステップと、
   検知障害種類、取得データである各パフォーマンスやログデータ、前記障害区分、を含む前記教師データから前記取得したデータの、パターン化した障害区分／障害対策を判定するステップと、
   前記障害区分／障害対策を判定するステップにおける結果を受けて、障害区分有りか否かを判定するステップと、
   前記障害区分有りか否かを判定するステップにて障害区分有りの場合、前記障害の対策を実行および障害の回復を行うステップと、
   前記障害区分有りか否かを判定するステップにて障害区分が無い場合、前記障害の対策データを作成するサポートフローを実行するステップと、
   前記障害の対策を実行および障害の回復を行うステップにて、障害が回復できなかった場合、前記障害区分に対策無を設定するステップと、を有する
   ことを特徴とする統合監視運用方法。

Images