このブログでは、IBM Cloud Pak for AIOps (AIOps) を既存の IBM Netcool (Netcool) 環境に導入および統合するために必要な導入アーキテクチャ、移行戦略、および重要な考慮事項について説明します。
一般的に、AIOps は既存の Netcool デプロイメントと一緒にデプロイされ、2 つが統合されます。このコンテキストでは、Netcool は現在提供している機能の大部分を引き続き提供し、AIOps は幅広い新機能を提供します。ただし、相関、ユーザー ツール、一部の自動化など、Netcool によって提供される機能の一部は AIOps によって置き換えられます。
展開の過程で、特定の Netcool コンポーネントを廃止することができ、それによってハードウェアが解放され、他の用途に使用できるようになります。おそらく、AIOps のコンピューティング リソースとして再利用される可能性もあります。下の図 1 は、一般的な AIOps/Netcool 展開アーキテクチャを示しています。
注意点:
- AIOps Netcool Connector インスタンスは、Aggregation Netcool/OMNIbus ObjectServer の各ペアに接続します。
- AIOps Netcool/Impact Connector インスタンスは各 Netcool/Impact クラスターに接続します。
- 存在する各 ITNM NCIM データベースに対して AIOps ITNM Observer ジョブが作成され、トポロジ データを取得します。
- 既存の Netcool/Impact サードパーティ統合のほとんど (すべてではないにしても) は変更されずに残ります。
- その他のデータ統合は、さまざまなコネクタと統合を介して AIOps に直接実装できます。
- イベントのアーカイブは、Netcool/OMNIbus から引き続き実行することも、AIOps に移行することも、あるいはその両方を行うこともできます。
以下のセクションでは、AIOps と Netcool の統合、および最終的にユーザーを Netcool UI から AIOps に移行するための一般的なアプローチについて説明します。これらのセクションで概説されているアクティビティはすべてを網羅したものではなく、その過程でさらに多くのタスクや考慮事項が必要になる可能性があることに注意してください。
注:このブログで概説した概念は、IBM Cloud Pak for AIOps 4 ベスト プラクティス ガイドでさらに詳しく説明されています 。
Netcoolのカスタムフィールドを確認し、必要なものだけをマップする
Netcool から AIOps への移行におけるイベント データの主なソースは、Netcool/OMNIbus です。これは、AIOps が提供する Netcool Connector を介して行うのが最適です。この統合の一環として、AIOps レイヤーでカスタム Netcool/OMNIbus フィールドの選択が必要になる可能性があります。Netcool/OMNIbus のカスタム フィールドを確認し、実際に必要なものだけを AIOps に複製することが重要です。これには、ユーザーが表示する必要があるものや、自動化やツールに必要なものが含まれます。効率性の観点から、AIOps に追加されたフィールドは追加のコンピューティング コストとストレージ コストを伴うことを念頭に置くことが重要です。そのため、必要なものだけを複製し、すべてを複製しないようにすることが賢明です。また、パフォーマンスを最大化するために、コンポーネントが可能な限り効率的に構成されるようにすることが、長年にわたる Netcool のベスト プラクティスです。
次のコネクタ マッピングの例が提供され、カスタム データ項目のリストを属性のサブ属性として配置する正しい場所が示されていますdetails。この例では、 と の 2 つのフィールドがマップされており、appIdそれぞれregionNetcool イベント フィールドと から値を取得し@AppIDます@Region。
他の統合ソースを特定する
Netcool/OMNIbus とその広範なプローブ カタログは、通常、AIOps のイベント資産の大部分を占めます。同様に、Netcool/Impact は通常、エンリッチメント用のデータベースやインシデント発生用のチケット システムなど、サードパーティ システムへの統合を提供します。AIOps には、他の種類のデータの統合を含む、多数の新しいイベント統合オプションが用意されています。AIOps 統合の完全なリストについては、こちらを参照してください。
大まかに言えば、AIOps は次の追加の統合タイプを提供します。
- Netcool/Impact (AIOps Netcool/Impact コネクタを使用)
- トポロジデータ
- メトリックデータ
- ログデータ
- チケットデータおよびその他のチケット機能（Github または ServiceNow）
- ChatOps 機能 (MS Teams または Slack)
- 電子メール統合
- 自動化（Ansible または SSH）
AIOps 展開に必要な新しいデータ ソースまたは統合を特定し、それに応じて計画を立てます。
イベントのハウスキーピング体制と暴風雨対策を評価し、計画する
イベント ハウスキーピングとイベント ストーム保護は、Netcool デプロイメントに重要な負荷保護を提供する関連するベスト プラクティス コンセプトです。これらは両方ともベスト プラクティス コンセプトであり、通常はすべての実稼働環境に実装されます。そのため、これらの自動化はそのまま維持され、現在と同じ保護を提供し続けることができます。イベント ハウスキーピングやイベント ストーム保護のオプションを含む Netcool/OMNIbus ベスト プラクティスの詳細については、IBM Netcool/OMNIbus 8.1 ベスト プラクティス ガイドを参照してください。
イベントハウスキーピング
システム内のイベントが関連性があり最新のものであることを保証するために、古いイベントをクリアすることが重要です。また、システムを合理化し、パフォーマンスを維持するのにも役立ちます。これらの理由から、イベント数を最適化し続けるために、包括的なイベント ハウスキーピング自動化を確実に実施することが、重要なベスト プラクティスです。
上記の Netcool Connector マッピングの例では、@ExpireTimeNetcool/OMNIbus のフィールドがexpirySecondsAIOps の属性にマッピングされます。イベントが最後に発生したのがこれより前である場合に AIOps のイベントをクリアする内部 AIOps オートメーションがあります。これはNetcool/OMNIbus のトリガーexpirySecondsと同等であることに注意してください。通常、フィールドはプローブ内または何らかのイベント ハウスキーピング オートメーションを介して Netcool/OMNIbus に設定されます。これを設定すると、Netcool/OMNIbus からのイベントは自動的にハウスキーピングされます。expire@ExpireTime
Netcool/OMNIbus で発生しないイベント (AIOps コネクタ経由で AIOps に流入するイベントなど) の場合は、同等のイベント ハウスキーピング自動化の実装を検討する必要があります。この目的には Netcool/Impact を使用することをお勧めします。推奨される実装は次のとおりです。
expirySeconds合意されたイベント有効期限ポリシーに従って設定する Netcool/Impact ポリシーを作成します。expirySeconds = 0すべての新しいイベントをNetcool/Impact ハウスキーピング ポリシーに送信する AIOps ポリシーを作成します。- 内部の AIOps 自動化により、現在の時刻が経過する各イベントが自動的にクリアされます
(lastOccurrenceTime + expirySeconds)。
expirySecondsこの演習の最終的な目標は、AIOps のすべてのイベントがゼロ以外の値に設定されていることを確認することです。
Netcool/Impact ハウスキーピング ポリシーの例を以下に示します。
イベント暴風雨対策
イベント ハウスキーピングと同様に、本番環境の Netcool/OMNIbus 展開では通常、何らかのイベント ストーム保護を採用します。これは、プローブ ルール、ObjectServer 自動化、アーキテクチャ設計 (コレクション レイヤーの組み込みなど)、またはこれらの組み合わせによって行われます。これらの既存のプロセスは、イベント ストームに対する重要かつ効果的な保護を提供するため、AIOps 展開シナリオではそのままにしておくことをお勧めします。
ユーザーツール、ビュー、フィルターを評価し、計画する
AIOps をデプロイメントに追加すると、ユーザーは最終的に Netcool/WebGUI から新しい AIOps UI に移行します。そのため、すべてのイベント ビューアーツールは、ビューとフィルターとともに AIOps 内で再実装する必要があります。AIOps の新機能は、トポロジの右クリック ツールも定義できる点です。これにより、UI からさらにユーザー オプションが提供されます。トポロジ ツールは、アラート ツールと同様のタスクを実行でき、同様に条件を適用して、特定の種類のリソースでのみ使用できるようにします。トポロジ ツールは、作成することが理にかなっている場所で作成する必要があります。
既存のイベント相関を評価する - Netcool で無効にし、AIOps で再実装する
Netcool/OMNIbus は通常、親子関係でイベントを別のイベントにリンクすることで相関関係を実装します。これには、合成親イベントの作成と管理、または一連のイベントを別のイベントにリンクして事実上の親にするだけの処理が含まれます。AIOps では、追加のイベントを作成する必要がなくなり、実際のイベントを使用する代わりに、アラート ビューアーで仮想イベントがレンダリングされます。イベントをリンクするために必要なメタデータは、イベント自体の中にエンコードされます。つまり、イベント ストアには実際のイベントのみが保持されるため、効率が向上します。
ただし、イベントのグループ化方法のこの変更は、AIOps が追加され、ユーザーが代わりに AIOps UI を使用する展開に影響を及ぼします。AIOps ではイベントのグループ化の実装が異なるため、基本的に AIOps レイヤーでグループ化を再実装する必要があります。次の点が主なタスクの概要です。
- Netcool/OMNIbus では、スコープベースのグループ化トリガー グループを無効にする必要があります。
- フィールドを設定する Netcool の関数は
@ScopeIDそのまま残すことができます。@ScopeIDその後、フィールドを AIOps の属性にマッピングするとresource.scopeId、スコープベースのグループ化が AIOps によって内部自動化によって自動的に適用されます。上記のマッピングの例は、Netcool コネクタでのこのマッピングの例を示していることに注意してください。
- Netcool 以外のイベント ソースに必要なスコープベースのグループ化ポリシーは、AIOps ポリシーとして実装できます。AIOps では、イベントは複数のスコープベースのグループのメンバーになることができます。Netcool ではそうではありません。イベントは、単一のスコープベースのグループにのみ属することができます。
- Netcool Operations Insight の一時イベント相関機能はすべて無効にし、代わりに一時グループ化AI 自動化を構成、トレーニング、および有効にする必要があります。これにより、同等の機能が提供されます。
- トポロジ データが AIOps に取り込まれ、マージされた後、どのようなトポロジ グループ化の機会が存在するかを検討する必要があります。これは視覚化に役立つだけでなく、追加のイベント相関の機会も提供します。 トポロジ テンプレートとグループの作成に関する詳細なガイダンスについては、トポロジのドキュメントまたはAIOps ベスト プラクティス ガイドを参照してください。
- Netcool/OMNIbus または Netcool/Impact に実装されたカスタム相関関係、または ITNM の根本原因分析 (RCA) エンジンによって生成された相関関係を含むその他の相関関係では、ローカル カスタム フィールドとカスタム自動化の組み合わせを使用し、AIOps レイヤーでスコープベースのグループ化メカニズムを活用してグループ化を実行する必要があります。たとえば、カスタム フィールドを
@RCACorrelationNetcool に作成して、@ServerName + @ServerSerial根本原因イベントを含めることができます。ローカル自動化では、このフィールド値を根本原因イベント自体と、その関連するすべての子イベントに設定できます。その後、このフィールドを Netcool Connector 経由で AIOps にマップできます。最後に、AIOps スコープベースのグループ化ポリシーを作成して、この属性でイベントをグループ化できます。その結果、根本原因イベントとその症状のある子でグループ化が形成されます。
すべてのカスタマイズを確認し、最適な実装ポイントを決定します
すべての Netcool および AIOps の導入には、統合、自動化、その他の構成などのカスタマイズが含まれます。既存の Netcool 環境に AIOps を追加する場合は、各カスタマイズを確認して、Netcool 内にそのまま残すか、AIOps に移動するかを判断するのが賢明です。ほとんどの場合、そのまま残す方がシンプルで簡単です。ただし、場合によっては、AIOps レイヤーで再実装することが理にかなっていることがあります。たとえば、ServiceNow チケット統合用の Netcool/Gateway を AIOps ServiceNow Connector に移動すると合理的です。同等のチケット作成機能を利用できるだけでなく、類似チケット分析とトポロジ データの収集という追加の利点も得られます。さらに、AIOps ServiceNow Connector インスタンスは、UI を介して数分でセットアップできます。
イベントのアーカイブを評価および計画する（REPORTER データベース）
ほとんどの Netcool デプロイメントでは、イベントをイベント アーカイブにアーカイブするために Netcool/Gateway for JCBC (または別のタイプのゲートウェイ) を採用しています。このデータは長期保存され、レポート、法令遵守、その他の目的に使用されます。ほとんどの場合、これはそのままにしておくことができます。Netcool 以外のイベント ソースの場合、Netcool/Impact ポリシーを呼び出す AIOps ポリシーを使用して、イベントをイベント アーカイブに書き込むことができます。REPORTER スキーマへのマッピングが正しく行われていれば、Netcool Gateway と同じイベント アーカイブに書き込むように安全に構成できます。
ユーザーの移行、WebGUI サーバーの廃止
上記のすべてのタスクが実行され、新しい AIOps システムのテスト、検証、および妥当性確認が完了したら、ユーザーは新しい AIOps UI への移行を開始できます。すべてのユーザーが移行し、新しい環境が使用可能になり、運用に必要なレベルの機能が提供されていると判断されるまで、一定期間、AIOps を既存の Netcool/WebGUI システムと並行して実行することをお勧めします。
すべてのユーザーが AIOps に移行したら、Netcool/WebGUI サーバーをシャットダウンできます。例外的な状況で緊急ロールバックが必要になった場合に備えて、これらのサーバーを完全に廃止する前に、しばらくそのままにしておくことをお勧めします。
表示レイヤーのNetcool/OMNIbus ObjectServerの廃止
既存の Netcool 環境への AIOps の導入が成功すると、すべてのユーザーが AIOps にログインし、Netcool/WebGUI は廃止されます。Netcool コネクタは集約層の ObjectServer に接続するため、アーキテクチャ内で Display ObjectServer は冗長になります。Display ObjectServer が特定の目的を果たすために使用されている特殊なケースもありますが、一般的には廃止できます。
まとめ
このブログでは、既存の Netcool 環境に AIOps を導入する際に考慮すべき主な事項と手順について概説しています。AIOps には、ここでは取り上げていない Runbook Automation などの機能が多数あり、これらを使用することでさらに価値を高めることができます。AIOps が提供する多くの新しい強力な機能も、使用を検討する必要があります。IBM Cloud Pak for AIOps ベスト プラクティス ガイドでは、 AIOps の計画、導入、実装についてさらに詳しく説明しており、導入前に確認する必要があります。
本記事はこちらの記事を参考に日本語化したものです。