CMDBデータ品質の運用設計：所有者1.2%から立て直す
CMDBはCIを登録した時点では終わりません。登録した後にどう保守するかで、現場での使い勝手が大きく変わります。壊れたサーバーの担当者が分からず、障害の影響範囲も追えない状態に陥ります。現場は止まった状態です。こうした事態の多くは、CIの登録漏れではなく、責任者や関係の情報が空欄のまま放置されていることが原因です。
この記事では、まずCMDBが公式ドキュメント上でどう定義されているかを確認したうえで、PDIの実機画面でCI 2,786件の現状を確かめます。責任者・所属・鮮度・関係という4つの切り口で空欄率を測り、そこから「どこから手を付けるか」「どう埋めていくか」「どう維持するか」という運用設計まで踏み込みます。CMDBを引き継いだものの手の付けどころが分からない方、改善計画をこれから立てる方に向けた内容です。
この記事で分かること
公式ドキュメントが定義する、CIの所有者・支援グループ・Discovery・CSDMサービス階層の役割
実機画面で確認した、責任者フィールドの充填率とクラス別の偏り
鮮度・関係情報の薄さがIncident対応の遅れにつながる仕組み
誰が所有者になるか・支援グループをどう設計するか・鮮度と関係をどう保つかという運用設計の骨子
検証環境はServiceNowのPDI（Personal Developer Instance）Zurichリリースです。CMDBのデータはデモ環境に入っていたものです。数値は環境や運用年数によって変わります。
CMDBが管理するもの
CMDB（Configuration Management Database）は、構成アイテム（CI）とその関係を一元管理する仕組みです。対象にはサーバーやネットワーク機器、ソフトウェア、サービスなど多様な種類が含まれます。公式ドキュメントの「Configuration Management Database (CMDB)」は、CMDBを組織のIT資産とサービスの記録源と位置づけています。英語ではsystem of recordと呼ばれる考え方です。ハードウェアからクラウドリソースまで、多様なCIクラスを扱える点が特徴です。
CMDBのテーブル構造は「CMDB tables descriptions」にまとまっています。基底となるConfiguration Item [cmdb_ci] テーブルを、ComputerやServer、Serviceといったクラスが継承する形で拡張していく構造です。今回の実機確認でも、この継承構造がそのままクラス別の内訳として現れます。
CIの所有者と支援グループの役割
CIには、誰が責任を持ち、誰が対応するかを記録するためのフィールドが用意されています。owned_byとmanaged_byはUser [sys_user] テーブルへの参照で、個人を指す設計です。support_groupはGroup [sys_user_group] テーブルへの参照で、グループを指す設計になっています。個人が持つ情報とグループが持つ情報は、そもそも入力する主体が違います。
役割の目安は次の通りです。owned_byは、CIの予算や廃棄判断に責任を持つ所有者を指します。managed_byが指すのは、日常の運用管理を担う技術担当です。support_groupは、障害発生時に一次対応するグループを表します。3つとも空欄のまま運用されているCMDBでは、壊れたときに誰へ連絡すればよいかという最も基本的な問いに答えられません。
Discoveryとlast_discoveredの関係
last_discoveredは、Discoveryが最後にそのCIを検出した日時を記録するフィールドです。公式ドキュメント「Exploring Discovery」によると、Discoveryはネットワークをスキャンし、ハードウェアやソフトウェアの存在や稼働状況を自動で検出します。検出結果は、CMDBのレコード更新に使われます。
裏を返すと、Discoveryの対象になっていないCIや、手入力のまま一度もスキャンされていないCIは、last_discoveredが空のままになります。空欄そのものはエラーではなく、自動検出の対象になっていないという事実を示す値です。
CSDMが定義するサービス階層
CSDM（Common Service Data Model）は、CIとサービスの関係を標準化するためのServiceNowのデータモデルです。公式ドキュメントの「Life cycle standard values」は、CIのライフサイクルに関する標準値を定義しています。「Manage Technical Services domain of the CSDM framework」は、サービスの階層構造を定義しています。上位からBusiness Application・Application Service・Service Offeringという3階層です。
「Application services」が扱うのは、この階層のうちCIをサービスとして束ねる部分です。CIが個別に登録されているだけでは、どのサービスに影響するかが見えません。CSDMの階層に沿ってサービスとオファリングを整備して初めて、障害の影響範囲を追跡できるようになります。
実機で確かめる現状
ここからは、公式ドキュメントの定義を踏まえたうえで、PDIの実機画面でCMDBの現状を確かめます。母数はCMDBに登録されたCI 2,786件です。
責任者・所属フィールドの充填率
最初に見るのは、責任者・所属に関わる7つのフィールドの充填状況です。
7項目のうち、owned_by・support_group・managed_byの3つが特に低い水準にとどまっています。companyやlocationはまだ3割前後埋まっていますが、これは会社情報や拠点情報が導入時に一括投入されやすい項目だからだと考えられます。個別のCIごとに人が判断して入れるフィールドほど、空欄率が高くなる傾向でした。
owned_by 1.2%、support_group 1.3%という数字は、単に入力が面倒だった以上の意味を持ちます。障害対応の現場では、影響を受けたCIから担当者を逆引きできることが前提です。逆引きできなければ、結局は人の記憶や別の台帳に頼ることになり、CMDBを見る意味が薄れます。
クラス別の内訳を画面で見る
Configuration Itemsの一覧をクラスでグループ化すると、全体2,786件の内訳が見えてきます。
Computerクラスだけで815件、Databaseクラスが13件というように、クラスごとに件数の規模が大きく異なります。件数の多いクラスをどう扱うかが、責任者情報を埋める順序を考えるうえでの起点になります。
所有者が空のCIを一覧で見る
Owned byで絞り込むと、空欄のCIだけを一覧できます。
一覧にはComputerクラスのCIが並び、ManufacturerやLocationは入力されているのに、Owned byだけが空欄のまま登録されています。これが実態です。物理的な情報は登録できていても、責任者情報だけが抜け落ちているという状態が、この一覧から見て取れます。
CI登録フォームで気づくこと
新規CIを登録する画面も確認しておきます。
標準のフォームに並ぶのは、Name・Asset tag・Assigned to・Category・Fault count・Installed・Install Statusです。責任者系の項目はありません。Owned byやSupport groupは、この初期フォームには含まれていません。登録する担当者の目に触れる場所に項目がなければ、入力されないのは自然な結果とも言えます。フォームの設計自体が、責任者情報の埋まりにくさに関わっている可能性があります。
💰 ━━━━━ ここから先は有料エリア（¥300）━━━━━
