この記事では、ServiceNow CSAで問われるCMDBを中心とした記事です。
CMDBと聞くと、サーバーやPCを登録するデータベースを想像しがちですが、単なる登録作業ではありません。
実際、運用保守業務においてはCMDBにCIを登録時、どのCMDBに入れるべきか、重複CIをどう防ぐか、エラー発生時、周辺機器の影響をどう把握するかなど問われます。
その為、CSAではCI、CSDM、関係性だけでなく、IRE、CMDB Health、Data Manager、権限などデータベースマネジメントやプラットフォームセキュリティが試験範囲に含まれています。
それ故、CSAに出てくるCMDBを理解したい場合、「この画面でCIを登録する」と覚えるだけでは足りず、問題文に出てくる課題を見て、CI、CMDB、CSDM、IRE、Reconciliation、CMDB Health、Data Schema、Application/Access Control、Importing Dataなどのどれを使うべきか判断できる状態を目指します。
初心者はこの順番で読むと迷いにくい
しかし上記のようにCMDBには沢山の用語があり、これを正しく判別する事が出来ず、この分野を苦手とする人が多くおり、まず初心者は以下の3の分けて覚えた方が良い。
1. CI/CMDB/CSDMの違いを押さえる
まず、CIは「管理対象の構成要素」、CMDBは「CIと関係性を管理する場所」、CSDMは「ServiceNow上でサービス、アプリ、CIをどこに置くか整理する考え方」と分けてください。この3つが混ざると、問題文を見たときに何を聞かれているのか判断しづらくなります。
2. 重複・欠損・古いCIをどう防ぐかを見る
次に見るのは、CMDBを壊さず保つ仕組みです。同じCIが複数できるならIREやIdentification rule、どのデータソースを信じるかならReconciliation rule、欠損や重複や古いCIを見たいならCMDB HealthやCMDB Data Managerが候補になります。
3. 問題文のキーワードから使う概念を選ぶ
最後は、問題文の言葉と機能を結びつけます。duplicate CIsならIRE、authoritative sourceならReconciliation、impact analysisならCI Relationship、completenessやcorrectnessならCMDB Health、stale CIやattestationならCMDB Data Managerというように、課題から概念を選ぶ練習をします。
例えば、こんな問題が出たらどう考えるか。
「複数のデータソースから同じサーバー情報が取り込まれ、同じCIが複数作成されている。どの仕組みで重複を防ぐべきか」と問われた場合、単にImport Setで取り込む話ではありません。既存CIか新規CIかを識別する必要があるため、IREやIdentification ruleを選ぶ方向で考えます。
このように、CSAのCMDB問題は「用語を知っているか」よりも、「その場面でどの概念を使うべきか」を見られていると考えると読みやすくなります。
CMDBの基本概念
CIとは、運用判断に使う構成要素
CIはConfiguration Itemの略で、CMDBで管理する構成要素です。サーバー、PC、ネットワーク機器、データベース、アプリケーション、サービスなどが対象になります。
ただし、CSAでは「CIは資産っぽいもの」と覚えるだけでは弱いです。CIはIncidentやChangeで参照され、障害時の影響調査や変更時のリスク確認に使われるものだと考えてください。
CMDBと資産管理は、目的が違う
| 観点 | CMDB | 資産管理 |
|---|---|---|
| 主な目的 | サービス影響、変更影響、障害調査 | 購入、契約、棚卸し、廃棄 |
| 見る対象 | CIとCIの関係性 | 資産の所有・利用・ライフサイクル |
| 試験での見方 | 構成情報として信頼できるか | 購入や所有情報として管理できるか |
CSDMは、サービス・アプリ・CIの置き場所を整理する考え方
CSDMはCommon Service Data Modelの略です。ServiceNow上で、Business Application、Application Service、Technical Service、CIなどをどのように整理し、関係づけるかを考える標準モデルです。
CSAでは、CSDMの細かい実装手順よりも「サービス、アプリ、CIを標準的なデータモデルに沿って整理する考え方」と押さえると解きやすくなります。
試験で迷いやすいCMDBの重要機能
CI Relationship：影響範囲をたどるための関係性
CMDBが単なる台帳と違うのは、CI同士の関係を持てる点です。たとえばアプリケーションがDBに依存し、そのDBが特定のサーバー上で動いているなら、障害時にどの業務サービスへ影響するかを追いやすくなります。
IRE：重複CIを防ぐための入口
IREはIdentification and Reconciliation Engineの略です。Discovery、CSV、外部ツール、クラウド連携など、複数ソースから入ってくるCI情報をCMDBへ入れる前に、識別と調整を行います。
同じサーバーがDiscoveryとCSVから別々に入ると、何もしなければ重複CIができます。CSAでは「duplicate CIs」という言葉が出たら、IREを思い出してください。
Identification rule：既存CIか新規CIかを判断する
Identification ruleは、受信データが既存CIに該当するのか、新規CIとして作るべきなのかを判断するルールです。nameだけでサーバーを識別すると弱いため、serial number、FQDN、cloud resource IDなど、一意性の高い属性を使う発想が重要です。
Reconciliation rule：どのデータソースを信じるか決める
Reconciliation ruleは、複数のデータソースが同じCIの属性を更新しようとしたときに、どちらを優先するかを決める考え方です。
| 属性 | 信頼しやすいソース例 | 理由 |
|---|---|---|
| OS、IP、ホスト名 | Discovery | 実機から検出できるため |
| 購入日、契約、コストセンター | ITAM、ERP、資産管理 | 購買・会計側の情報が正になりやすいため |
| クラウドリソースID | AWS、Azure、GCP連携 | クラウド側の識別子が正になりやすいため |
| サービス関係 | Service Mapping、アプリオーナー確認 | 技術検出と業務確認の両方が必要なため |
CMDB Health：CMDBが使える状態かを測る
CMDBは登録して終わりではありません。放置すると、ownerが空欄のCI、関係性のないCI、更新されていないCI、重複CIが増えていきます。これを測るのがCMDB Healthです。
| KPI | 意味 | 実務で見る例 |
|---|---|---|
| Completeness | 必要な項目が埋まっているか | Owner、Support group、Locationが空ではないか |
| Correctness | データとして正しい状態か | 重複CI、孤立CI、古いCIがないか |
| Compliance | 定めたルールに準拠しているか | 監査・証明ルールに合っているか |
| Relationships | 関係性が健全か | 孤立・重複した関係や不適切な関係がないか |
CMDB Data Manager：古いCIを残し続けないための仕組み
クラウドやコンテナを含む環境では、CIは増えるだけでなく消えていきます。CMDB Data Managerは、退役、アーカイブ、削除、証明などのライフサイクル操作をポリシーで管理する機能です。
Access ControlとCMDBロール：誰が触れるかを分ける
CMDBは誰でも編集できる状態にすると信頼性が落ちます。読み取り、編集、管理を分けることが重要です。たとえば、sn_cmdb_userは参照、sn_cmdb_editorはCIの編集、sn_cmdb_adminはCMDB全体の管理というように、役割を分けて考えます。
Baseline CMDB：以前から何が変わったかを見る
Baseline CMDBは、CIのスナップショットを作り、前回以降にどの属性や関係が変わったかを確認するために使います。変更管理や監査、障害後の差分確認と相性がよい機能です。
問題文キーワードから判断する対応表
ここが模試で一番使う部分です。
問題文に出る言葉から、どの概念を選ぶかを素早く判断できるようにしてください。
| 問題文に出やすい表現 | 選ぶ概念 | 理由 |
|---|---|---|
| duplicate CIs、同じCIが複数できる | IRE / Identification rule | 既存CIか新規CIかを識別するため |
| authoritative source、信頼できるデータソース | Reconciliation rule | どのソースの値を優先するか決めるため |
| data quality、health score | CMDB Health | 品質をKPIで確認するため |
| completeness、correctness、compliance | CMDB Health KPI | CMDB品質評価の主要観点だから |
| stale CI、old CI、attestation | CMDB Data Manager | 古いCIや確認対象をポリシーで管理するため |
| dependencies、impact analysis | CI Relationship | 障害や変更の影響範囲を追うため |
| snapshot、baseline、差分 | Baseline CMDB | CIの変更差分を確認するため |
| who can edit、read only、role | CMDB roles / ACL | 参照・編集・管理を分けるため |
| Business Application、Application Service | CSDM | サービスやアプリを標準モデルに沿って整理するため |
実務ケースで理解する：販売管理システムのCMDB
悪いCMDB：登録はあるが、判断に使えない
- サーバー名だけが登録されている
- DBやアプリとの関係がない
- CSV取込とDiscoveryで重複している
- ownerやsupport groupが空欄
- 障害時にどの業務へ影響するか分からない
- 変更対象CIが正しいか判断できない
- 古いCIが残り、現場が信用しなくなる
- 誰でも編集できてデータが崩れる
よいCMDB：影響範囲・品質・権限まで管理できる
よいCMDBでは、販売管理システムをApplication Serviceとして見えるようにし、その下にWeb、AP、DB、サーバー、ネットワークなどの関係を持たせます。DiscoveryやConnectorから入るデータはIREを通し、Reconciliationで信頼ソースを決めます。CMDB Healthで欠損や重複を監視し、古いCIはData Managerで退役やアーカイブの対象にします。
実務イメージ
販売管理システム → Application Service → Web/AP/DB → Server/Network/Storage のように関係をたどれる状態にする。これにより、Incidentでは影響範囲、Changeでは変更リスク、監査では構成変更の証跡を確認しやすくなります。
PDIで触って理解するなら
最初は画面を覚えるより、見る場所を決める
実際に理解を深めるなら、PDIや検証環境で次の流れを触ると、試験問題の言葉が読みやすくなります。
- CI Class Managerでクラス階層を見る
- サンプルCIを開き、関連リストやCI relationshipを確認する
- Relationship EditorやUnified Mapで関係性を確認する
- Import SetとTransform Mapの考え方を確認する
- IRE、Identification rule、Reconciliation ruleの役割を読む
- CMDB HealthのCompleteness、Correctness、Complianceを見る
- CMDB roleの違いを確認する
操作手順より、何を解決する機能なのかを見る
CSAでは「この画面のこのボタンを押す」というより、「この課題を解決するにはどの機能か」が問われやすいです。画面を触るときも、操作手順だけでなく、何を解決するための機能なのかを意識してください。
まとめ：CSAのCMDBは、壊れない構成管理を理解する範囲
最後に覚えるべきこと
- CMDBはCIと関係性を管理する基盤
- CSDMはServiceNowでサービス・アプリ・CIを整理する標準モデル
- IREは重複CIを防ぎ、信頼できるデータソースによる更新を制御する
- CMDB HealthはCompleteness、Correctness、Complianceなどで品質を見る
- Data Managerは古いCIや確認対象をポリシーで管理する
- CMDBの権限は読み取り、編集、管理で分ける
- Baseline CMDBはCIのスナップショットと変更差分を確認する
模試で確認する
CMDBの用語を読んだだけで終わらせず、問題文のキーワードから判断できるかを確認してください。
関連練習：ServiceNow CSA CMDB集中特訓では、CI、CSDM、関係性、CMDB Healthなど、CMDB領域だけを集中して確認できます。
