許可されていない変更の要求

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：5分

    • 構成アイテム (CI) の不正な変更アクティビティがどのようにキャプチャおよび管理されているかを理解し、この変更をレビューしてタイムリーにアクションを実行できるようにします。

    ServiceNow® サービスマッピングと ServiceNow® ITSM の統合の一環として、許可されていない変更アクティビティが検出されたときに、変更管理アプリケーションはイベント通知を受け取ります。結果として、関連する CI に対して許可されていない緊急変更要求が作成されます。承認されていない変更を 変更管理 アプリケーションからレビューし、承認または却下できます。

    注:
    許可されていない変更の要求は、アプリケーションサービスの一部である CI に対してのみ作成されます。また、学習パターンを使用して誤検知を最小化する Flapper アルゴリズムもあります。

    ディスカバリープロセス (水平またはトップダウンの検出) では、定義による実際の変更ではない CI プロパティの変更が見つかることがあります。この識別は、測定誤差の場合や、大文字と小文字の区別など、同じ値の異なる表現が原因である可能性があります。緊急の変更要求は重要なアクションです。そのため、この学習パターンで、誤検知 (Flapper の変更) を識別しながら、再計算やタイムラインの更新をトリガーしないようにします。誤検出を回避し、実際の変更のみを報告する必要があります。

    学習パターンは、誤検知を次のように識別します。
    1. サービスに関連付けられている CI プロパティが変更されると、新しい値 (CI とフィールドのペア) が Flapper のデータテーブルに記録されます。
    2. システムは夜間ジョブを実行し、収集されたデータに対してさまざまなアルゴリズムを実行して、誤検出を示すパターンを特定します。
    3. 変更された CI フィールドの関連する戦略述語はすべて、90% を超える信頼度で実行されます。この手順により、すべての新しい値が誤検出かどうかが判断されます。すべての新しい値が false の場合、変更は無視され、モデルは更新されません。
      注:
      CI がアクティブな変更要求に関連付けられている場合、このステップはスキップされます。
    予定されていない CI 変更アクティビティが発生すると、許可されていない変更要求が作成され、次のチェックがトリガーされます。
    • システムは、CI が許可された CI クラスの一部かどうかを確認します。許可されている場合、システムはこの特定の CI で以前にフラグが付けられているかどうかを確認します。フラグが付けられていて、以前に作成された許可されていない変更が通知無視期間内の場合、それ以上のアクションは実行されません。フラグが付けられていない場合は、この CI がプロパティで指定された条件に一致する変更要求に関連付けられているかどうかがさらに確認されます。関連付けられていない場合は、検出された CI の変更は「許可されていない」としてフラグが付けられ、ci.change.unplanned イベントが発生します。
    • ci.change.unplanned イベントを受信すると、スクリプトは [イベント処理を有効にする (Enable event processing)] フィールドが true かどうかを確認します。true の場合、許可されていない変更の要求が作成されます。デフォルトでは、このプロパティは false です。

    生成された ci.change.unplanned イベントによって、緊急タイプの変更要求の作成が自動的にトリガーされます。

    フォームに事前入力されている次のような詳細情報を利用して、許可されていない変更を識別してレビューできます。
    • [許可されていない (Unauthorized)] オプションが選択されている。このオプションは、その変更が許可されていない変更であることを示します。
    • [アサイン先グループ] フィールドに [変更管理] が設定されている。
    • [構成アイテム] フィールドに、許可されていない変更が行われたアイテムが設定されている。
    • [説明] フィールドに、変更の要求の変更済みフィールドの情報が設定されている。

    許可されていない変更の要求フラグ

    レビューおよび承認のために、[アサイン先グループ]、[CI アイテム管理担当者]、[オーナー]、および [担当者] メンバーにメール通知が送信されます。ただし、CI 変更が多く、それらの CI を含めるためのオープンな変更の要求が作成されていない場合、システムはこれらの CI に対して、許可されていない変更の要求を作成します。このイベントが発生すると、メンバーは多数の許可されていない変更の通知メールを受信します。このような場合、これらの通知を無効にすることを選択できます。詳細については、「許可されていない変更の通知の無効化」を参照してください。
    注:
    メール通知は、アプリケーションサービス ([検出済み] または [手動サービス]) の一部である CI に予定されていない変更がある場合にのみ、送信されます。

    この変更の要求が承認されると、ステータスが [評価] に変更され、通常のプロセスに従って要求がクローズされます。

    実施後のレビューのアサイン

    承認なしで変更が実装された場合は、許可されていない変更のリスクと影響度を評価するために、実装後のレビューが必要になります。

    許可されていない変更が承認されると、[ステータス] フィールドが [レビュー] となっている変更タスクが作成されます。この変更タスクは、[簡単な説明] フィールドが [実施後のレビュー] に設定されている変更管理グループにアサインされます。通知を受信するアサインされたメンバーは、変更タスクをレビューしてクローズできます。

    許可されていない変更の設定の変更

    変更アドミニストレーターは、[許可されていない (Unauthorized)] チェックボックスをオフにして、許可されていない変更の要求を緊急の変更要求に変換できます。このチェックボックスをオフにした場合は、[作業メモ] フィールドに変更の理由を入力します。

    ITIL ユーザーが [許可されていない (Unauthorized)] チェックボックスをオフにするには、[タイプ] フィールドに [機能停止] が指定されたタスクレコードから機能停止を作成します。詳細については、「タスクからの機能停止の作成」を参照してください。

    注:
    機能停止レコードが関連付けられていない、許可されていない変更があると、状況フローは [許可] から [レビュー] になり、スケジュールまたは実装ステータスがスキップされます。この変更に対して実装が既に発生しているため、ステータスが変更されます。