
CIのつながりは親→種類→子(cmdb_rel_ci)
ServiceNow の CMDB を調べていくと、サーバやサービスといった個々の CI(構成アイテム)だけが見えるわけではありません。「このサービスはどのサーバに依存しているか」「このサーバが止まると何に波及するか」という CI どうしのつながり も見えてきます。このつながりを1件ずつ保存しているのが CI 関連(CI Relationship)、テーブル名で言うと cmdb_rel_ci です。
この記事は、CMDB の中心テーブル cmdb_ci は見たことがある管理者・開発者を想定しています。CI 同士の関連がどんなテーブルに、どんな形で保存され、依存マップや影響分析にどうつながるのかを確認したい人向けです。PDI(Zurich / OOTB)で cmdb_rel_ci と cmdb_rel_type を実際に開きます。1行=parent→type→child の有向トリプルであること、関連の「向き」と呼称を決める cmdb_rel_type を確認します。PDI 実機での件数分布、そして Email を起点にした依存チェーンの実例も確認します。
この記事で分かること
CI 関連は cmdb_rel_ci の1行=parent(親 CI)→ type(種類)→ child(子 CI) という有向トリプルで保存されること
cmdb_rel_ci が cmdb_ci のサブクラスではなく、独立したルート基底テーブルであること
関連の向きと呼称を決めるのが cmdb_rel_type(sys_metadata 継承)であること
parent_descriptor / child_descriptor の2つで1行を両方向から読めること
PDI 実機の 238件中136件(約57%)が Depends on::Used by で、依存関係が関連の主役であること
connection_strength(Always / Infrequent / Occasional / Cluster)や percent_outage が影響分析の材料になること
Email を中継点にした依存チェーンが、障害の影響波及(impact)をどう表すか
この記事の内容は ServiceNow の PDI(Personal Developer Instance)Zurich(ズーリッヒ)リリースの OOTB(初期設定)で確認した個人メモです。本番環境やカスタマイズ済み環境では、フィールド・選択肢・関連の内容が異なる場合があります。
CI 関連(CI Relationship)とは
CI 関連とは、ある CI と別の CI のつながりを1件=1レコードで残したものです。たとえば「Electronic Messaging(メールの業務サービス)が Email(メールサービス)に依存している」というつながりがあります。これが cmdb_rel_ci の1行として保存されています。
ポイントは、関連が向きを持つことです。1行には必ず parent(親) と child(子)、そして type(種類) があり、「親が・どういう関係で・子につながっているか」を表します。下の実画面は、その1行をフォームで開いたものです。

このレコードは、Parent に Electronic Messaging、Child に Email、Type に Depends on::Used by が入っています。つまり「Electronic Messaging は Email に依存している(Depends on)」という1本の関連です。CI 本体(cmdb_ci)にこの情報を持たせるのではなく、関連だけを専門に保存するテーブルに1行ずつ積んでいく、という設計です。
PDI(Zurich / OOTB)の cmdb_rel_ci には、すでに 238件の関連が入っていました。
cmdb_rel_ci はどこに位置するテーブルか
名前が cmdb_rel_ci なので CMDB の CI クラス(cmdb_ci のサブクラス)に見えますが、継承元を確認すると違いました。

今回確認した PDI(Zurich / OOTB)では、cmdb_rel_ci の super_class(継承元)は空でした。cmdb_ci の子クラスではなく、独立したルート基底テーブルです。前回の cmdb_ci の記事で見た「cmdb_ci の下に多数の子クラスがぶら下がる」階層があります。このテーブルは、その階層には入っていません。
では cmdb_ci との関係は何かというと、継承ではなく参照です。cmdb_rel_ci は parent(Reference → cmdb_ci) と child(Reference → cmdb_ci) という2つの参照を持ちます。「どの CI と どの CI を結ぶか」をそこで指します。parent も child も cmdb_ci への参照なので、サーバ・アプリ・サービスなど、どのクラスの CI 同士でも結べるのが特徴です。
固有フィールドは12件で、関連の中身を決めるのは次の6つです。

parent・child・type の3つで「誰が・どんな関係で・誰に」が決まり、connection_strength と percent_outage は後述の影響分析の材料になります。フィールド一覧は次のURLで確認できます(先頭の <YourInstance> は自分のインスタンスに置き換えてください)。
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=cmdb_rel_ci^elementISNOTEMPTY
関連の「向き」と呼称を決める cmdb_rel_type
cmdb_rel_ci の type が指す先が cmdb_rel_type(CI Relationship Type) です。こちらは sys_metadata を継承するメタデータで、PDI 実機では 40種類ありました。1件を開くと、関連タイプの正体が分かります。

cmdb_rel_type が持つのは、おもに name・parent_descriptor・child_descriptor の3つです。descriptor(呼称)が親側と子側で別々に用意されている点がポイントです。

たとえば type が Depends on::Used by のとき、
親 → 子 の向きで読むと「Electronic Messaging Depends on(依存する)Email」
子 → 親 の向きで読むと「Email Used by(使われる)Electronic Messaging」
というように、1行の関連を両方向の日本語(呼称)で読めるようになっています。だから CI のフォームを開くと、その CI が親になっている関連は「Depends on ◯◯」、子になっている関連は「Used by ◯◯」と、向きに応じた言葉で関連リストに出てきます。
cmdb_rel_type の構造と、関連の強さを表す connection_strength の選択肢は次の通りです。

40種のタイプ一覧は次のURLで確認できます。
https://<YourInstance>/cmdb_rel_type_list.do?sysparm_query=ORDERBYname
なお、IP Connection::IP Connection のように parent と child の呼称が同じ(対称な)タイプもあります。この場合は向きを意識せずに「IP 接続」とだけ読めます。
PDI 実機ではどの関連が多いか
cmdb_rel_ci を type でグループ化すると、どの関連が実際によく使われているかが分かります。


238件中136件(約57%)が Depends on::Used by でした。つまり CMDB の関連の半分以上は「依存関係」です。残りは Contains(包含)、Members(メンバー)、Runs on(〜の上で動く)が続きます。ほかに In Rack(ラック搭載)など、構成や物理配置を表すものもあります。
依存関係がこれだけ多いのは、CMDB の関連が 「何が止まると何に困るか」を表す影響分析(impact analysis) の土台になっているからです。Depends on::Used by をたどれば、ある CI の停止がどこまで波及するかを機械的に追えます。
connection_strength と percent_outage:影響の強さ
関連には「つながっている」という事実だけでなく、つながりの強さも持たせられます。それが connection_strength と percent_outage です。
connection_strength(Always / Infrequent / Occasional / Cluster)… その依存が常時なのか、たまになのかといった強さ。
percent_outage(0〜100の整数)… 親が止まったときに、子へどれだけの割合で影響が及ぶか。
これらは、依存マップ(Dependency Views)上で影響の見え方を変えたり、影響分析の計算材料になったりします。ただし、これらの値が可用性スコアや影響計算にどう重み付けされるか、その内部ロジックは今回の検証範囲外です。OOTB の多くの関連ではこれらが未設定(空)のままで、つながりの有無だけを表していました。
実例:Email を中継点にした依存チェーン
依存関係が「向きを持つ1行」であることの威力は、ひとつの CI を起点に関連を並べると見えてきます。Email(class=Service)を含む関連を実機で引くと、7件すべてが Depends on::Used by でした。

整理すると、Email は依存チェーンの中継点になっています。

Email を親に持つ側(上流):Electronic Messaging・Outlook Web Access・Blackberry・Windows Mobile です。それぞれ「Depends on Email」の関連を持ちます。つまりこれらの業務サービスは Email に依存しています。
Email を子に持つ側(下流):Email は「Depends on IronMail-SD-01 / IronMail-SD-02 / EXCHANGE-NY-02」。つまり Email はメール基盤に依存しています。
この並びがあるおかげで、影響の伝播を関連をたどって追えます。たとえば EXCHANGE-NY-02 が停止 → Email が影響 → Electronic Messaging / OWA / Blackberry へ波及、という具合です。これが ServiceNow の 依存マップ(Dependency Views) や影響分析の基本的な仕組みです。関連の考え方は ServiceNow 公式の CI relationships(Zurich) でも説明されています。
実機で確認するときに見るべきURL
最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます(<YourInstance> は置き換えてください)。
# 関連の一覧(種類でグループ化)
https://<YourInstance>/cmdb_rel_ci_list.do?sysparm_query=GROUPBYtype
# 関連タイプの一覧(40種)
https://<YourInstance>/cmdb_rel_type_list.do?sysparm_query=ORDERBYname
# cmdb_rel_ci のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=cmdb_rel_ci^elementISNOTEMPTYまとめ
CI 関連は cmdb_rel_ci の1行=parent → type → child の有向トリプルで保存される。
cmdb_rel_ci は cmdb_ci のサブクラスではなく、独立したルート基底テーブル。parent / child はどちらも cmdb_ci 参照で、任意のクラスの CI 同士を結べる。
関連の向きと呼称は cmdb_rel_type が決める。parent_descriptor / child_descriptor の2つで、1行を両方向から読める。
PDI 実機では 238件中136件(約57%)が Depends on::Used by。依存関係が関連の主役で、影響分析・依存マップの土台になる。
connection_strength・percent_outage で関連の強さを持たせられるが、可用性・影響計算への重み付けロジックは検証範囲外。
CMDB の関連が分かると、cmdb_ci(CI 本体)・同定と調整(IRE)・サービス系テーブル(CSDM)・CI 停止記録(Outage)という CMDB シリーズが、「CI・つながり・サービス・停止」という形でひとつにつながって見えてきます。
関連記事
ServiceNowのCMDBは何がどこに入っている? CI・関係・サービスを実機で数える — cmdb_rel_ci が支える CI・関係・サービスの全体件数を実機で確認できます。