変更管理 と ITOM ヴィジビリティ との統合
組織が ITOM ディスカバリー または ITOM ヴィジビリティ に登録されている場合、これらの ITOM 製品とのデータ連携が自動的に有効になります。このデータ連携を使用すると、変更要求プロセスの一部である IP アドレスを持つ構成アイテム (CI) を自動的に管理できます。変更要求の履行者は、CI の検出プロセスを手動で要求することもできます。
データ連携のアクティブ化
組織で購入したサブスクリプションに応じて、次のプラグインをインストールして設定する必要があります。
- ITOM ディスカバリー の場合 - Discovery プラグイン (com.snc.discovery)
- ITOM ヴィジビリティ の場合 - Discovery プラグイン (com.snc.discovery) および Service Mapping プラグイン (com.snc.service-mapping)
統合： ITOM ディスカバリー
がアクティブになると ディスカバリー 、 変更管理 プロパティの変更モジュール内の 3 つの新しいプロパティ ():
| プロパティ | 説明 |
|---|---|
| 影響を受ける CI に対する Discovery のトリガー方法 (自動、手動、またはオフ) を構成する | 影響を受ける CI に対する Discovery のトリガーを、自動で行うか、手動で行うか、その両方で行うか、あるいはまったく行わないかを決定します。 タイプ：選択リスト 値：オフ、両方、自動、手動 デフォルト値：オフ 注: 以下のプロパティが [両方 (Both)] に設定されており、手動で検出をトリガーした場合、その変更要求に対して自動検出はトリガーされません。 |
| Discovery を手動でトリガーできる変更要求ステータスのリスト (カンマ区切り形式) | Discovery を手動で開始できるように変更要求のステータス値を定義します。これらの定義されたステータス値については、[Discovery を開始] 関連リンクが利用可能です。 タイプ：文字列 デフォルト値：実装、レビュー 注: インスタンスで複数の言語が使用されている場合は、このプロパティをレビューの内部ステータス値に設定する必要があります。 |
| Discovery が自動的にトリガーされる変更要求ステータスのリスト (カンマ区切り形式)。例：変更要求ステータスが [レビュー] に変更された場合 | Discovery が自動的にトリガーされる変更要求ステータスを定義します。Discovery は、リストされたステータス値に移行するときに開始されます。 タイプ：文字列 デフォルト値：レビュー 注: インスタンスで複数の言語が使用されている場合は、このプロパティをレビューの内部ステータス値に設定する必要があります。 |
注:
上記の表にある末尾 2 件のプロパティに関して、インスタンスで複数の言語が使用されている場合は、そのプロパティをレビューの内部値、すなわち 0 に設定する必要があります。
新しいプロパティに加えて、[Discovery ステータス] および [検出の最終更新日] フィールドが [影響を受ける CI] 関連リストに追加されます。[Discovery ステータス] は、5 つのステータス値のいずれかと、そのステータスを反映するアイコンを提供します。
- 処理中
- 正常に完了
- 完了 (警告あり)
- 完了 (エラーあり)
- キャンセル
[Discovery ステータス] 値は、対応する ログファイルへのリンクとして表示されます。[検出の最終更新日] フィールドには、Discovery が実行された前回を示す日時スタンプが含まれます。
Discovery モジュールを手動で開始するか、手動および自動の両方の開始を選択した場合は、変更要求のステータスがプロパティに定義されているステータスのいずれかと一致すると、 セクションに [Discovery を開始] 関連リンクが表示されます。Discovery がトリガーされると、[Discovery ステータス] および [検出の最終更新日] フィールドが変更されます。図 : 1. Discovery との変更管理データ連携
統合： ITOM ヴィジビリティ
アプリケーションサービスのコンテキストで変更を表示できます。サービスマッピング で利用可能なサービスマップは、アプリケーションサービス全体、およびサービスを構成する個々の構成アイテム (CI) に加えられる変更を示します。
Now Platform が変更を検証するように構成されている場合は、すべての変更が評価され、有効または無効と表示されます。変更が有効な場合、アプリケーションサービスマップ上の変更レコードは承認済みとしてマークされます。変更の検証のためにプラットフォームを構成する方法の詳細については、「提案された変更の管理」を参照してください。
変更マークのタイプは、マークが表す変更の性質によって異なります。
- 明るいグレーのバルーン (
) - アプリケーションサービスの動作に影響を与えない未承認の変更。ネットワークパスの変更やクラスターへのノードの追加などです。
- 暗いグレーのバルーン (
) - アプリケーションサービスの動作を変更する未承認の変更。
- 緑のバルーン (
) - Now Platform が変更を検証するように構成されている展開での、承認済みの変更。
- 二重のバルーン (
) - 短時間に行われた複数の個別の変更。