ServiceNow Discovery Scheduleの設計｜IP Range・MID割当・実行時間の判断ガイド

ServiceNow Discovery Scheduleは、単なる実行時刻の設定ではありません。Horizontal Discoveryで「何を探すか」「いつ動かすか」「どのMID Serverで実行するか」を結び付ける制御点です。この記事では、IP Rangeの切り方、Global Exclude、MID Serverの選択、実行頻度、最大実行時間、Run Historyの読み方を、範囲 → 実行経路 → 時間 → 結果の順に整理します。

Discovery Scheduleが決める3つのこと

ServiceNow公式ドキュメントは、Discovery ScheduleがHorizontal Discoveryの検索対象、実行時刻、使用するMID Serverを決めると説明しています。Scheduleを開いたときは、Activeや時刻だけでなく、IP範囲とMID選択が同じ意図で設計されているか確認します。

IP Rangeは「大きく一括」より運用境界で分ける

IP Rangeを大きく1本にまとめると作成は簡単ですが、失敗時にどの拠点・セグメントで詰まったか切り分けにくくなります。公式ドキュメントでは、IP address list、IP address range、IP network等を使って対象を定義でき、不要なネットワークや機器を探索しないよう範囲を限定することが推奨されています。

Rangeを分ける判断軸

• ネットワーク到達性：MID Serverから同じ経路で到達できる範囲か
• 管理責任：拠点、環境、システム所有者が同じか
• 探索時間：同じ時間帯・頻度で実行してよいか
• 資格情報：同じCredential Aliasや管理ドメインを使えるか
• 障害時の再実行：その範囲だけ止めて再実行できる単位か

公式のIP address configurationには、IP Rangeは含まれる全アドレスを走査し、プライベート・ブロードキャストアドレスを自動判別しないこと、性能問題を避けるためScheduleの範囲を最大/16程度に制限する注意があります。これは「常に/16で分ければよい」という意味ではありません。実際には、拠点やVLAN、MID到達性、実行時間でさらに小さく分けます。

Global Excludeで「どのScheduleでも触らない範囲」を守る

機密性の高い機器、ネットワーク機器の管理アドレス、他社管理区画など、どのScheduleからも探索してはいけない対象はGlobal IP Exclusionへ登録します。Scheduleごとの除外だけでは、新しいScheduleを作ったときに漏れる可能性があります。公式ドキュメントでは、ActiveなGlobal Excludeに含まれるIPはScheduled DiscoveryでもQuick Discoveryでもスキップされます。

MID Serverは到達性と負荷で選ぶ

MID Server選択は「一番近い名前のMID」を選ぶ作業ではありません。対象IPへ到達でき、必要なCapabilityを持ち、UpかつValidatedで、実行負荷を受けられることが前提です。Discovery Admin Workspaceでは、特定MID、MID Cluster、Auto-selectなどの選択肢があります。

MID Server自身がDownならScheduleを直しても動きません。Status、Validated、ECC Queue、プロキシ、サービス起動はMID Server接続・エラー切り分けで確認してください。ここでは、Scheduleから対象へ到達できるMID Serverを選べているかを確認します。

実行時間は重ねず、終了条件まで決める

ScheduleにはOn demand、指定時刻、別Scheduleの完了後などの実行方法があります。単に深夜を選ぶのではなく、対象機器のバックアップ、パッチ、脆弱性スキャン、他のDiscovery Schedule、MID Serverの処理量と重ならないようにします。

実行設計のチェックリスト

• 対象数と過去の所要時間から、次回開始までに終わるか
• 同じMID Serverへ複数の大規模Scheduleが集中しないか
• ネットワーク・機器のメンテナンス時間と衝突しないか
• Maximum runtimeを超えた場合にCancelするか
• 途中失敗時にどのRangeだけ再実行するか
• 頻度がCIの変化速度と業務用途に合っているか

頻繁に変わるクラウドや仮想環境と、ほとんど変化しないネットワーク機器を同じ頻度で探索する必要はありません。Changeの影響分析で必要な鮮度を基準にし、クラスや範囲ごとに頻度を変えます。

Run HistoryとDiscovery Statusで設計を検証する

Scheduleを保存できたことは成功ではありません。実行後にDiscovery Statusを開き、開始・終了、起動したProbe数、完了数、Error、識別されたデバイス、Anomalyを確認します。失敗が多い場合は、対象範囲、到達性、Credential、Patternのどの層かを分類します。

症状からScheduleの問題を切り分ける

実務で起きる失敗を4ビートで覚える

全拠点を1つのRangeへまとめたケース

事故：1拠点のネットワーク障害でSchedule全体の実行が長引きます。放置：どの範囲が未探索か分からず、全体を再実行します。設定：到達経路・拠点・実行時間でRangeとScheduleを分けます。改善：失敗範囲だけ再実行でき、Run Historyも比較できます。

複数Scheduleが同じMIDへ集中したケース

事故：深夜にECC Queueが滞留し、朝までにDiscoveryが終わりません。放置：CMDBの鮮度が落ちます。設定：実行時間をずらし、必要に応じてMID ClusterやBehaviorを設計します。改善：負荷と所要時間を予測しやすくなります。

除外対象を新しいScheduleが走査したケース

事故：監視対象外機器にアクセスし、セキュリティアラートが発生します。放置：Schedule追加のたびに同じリスクが再発します。設定：組織共通の対象外はGlobal IP Exclusionへ登録します。改善：Quick Discoveryを含む横断的なガードになります。

CIS-Discovery試験での判断軸

理解確認

3拠点のIP Rangeを同じMID Serverで同時実行したところ、毎回最大実行時間を超えました。最初の改善として最も適切なのはどれですか。

1. IP Rangeだけを拠点単位へ分け、3本を同じ開始時刻・同じMIDで実行する
2. Rangeと実行時間を拠点単位で分け、MIDの到達性・負荷を測る
3. Scheduleは分けず、Maximum runtimeだけを十分長くする
4. Scheduleは分けず、Auto-selectへ変えて実行MIDの状態を確認しない

正解：B。問題はScheduleの対象・実行経路・時間設計です。まず失敗範囲を分離し、実測できる単位にします。

よくある質問

IP Rangeは大きいほど管理しやすいですか

登録件数は減りますが、失敗範囲、実行時間、MID負荷の切り分けが難しくなります。公式の上限注意に加え、拠点・経路・責任・頻度で運用可能な単位へ分けてください。

Quick Discoveryが成功すればScheduleも必ず成功しますか

必ずではありません。単一IPの到達性・認証確認には有効ですが、ScheduleではRange、MID選択、同時負荷、実行時間、Excludeなど追加条件があります。

Auto-select MID Serverを選べば設計は不要ですか

不要にはなりません。候補MIDのIP Range capability、状態、検証、到達性が正しく構成されている必要があります。実行結果から期待MIDが選ばれたか確認します。

IPv6をIP Rangeへ登録できますか

公式の現行Discovery IP address configurationでは、IP address rangeまたはIP networkでIPv6はサポートされないと記載されています。利用するリリースの最新仕様を確認してください。

まとめ

Discovery Scheduleは、対象IP、実行MID、時間を結ぶ運用設計です。Rangeを到達性と管理境界で分け、共通の禁止範囲はGlobal Excludeで守り、MID負荷と所要時間から頻度を調整し、Discovery Statusの指標で検証してください。

Discovery全体の流れはServiceNow Discoveryの仕組み、MID接続はMID Server判断ガイド、認証はDiscovery Credential設計で確認できます。理解確認にはCIS-Discovery無料模試、学習順はCIS-Discovery対策ハブを利用してください。