そもそも構成管理データベース、CMDBとはどんなデータベースなんでしょうか。
CMDBが一般的な資産管理台帳やインベントリと大きく違う点は、構成要素同士の関係性を管理する機能を持っていることです。
これは個々のIT資産の情報だけでなく、サービスを構成する要素間のつながりを記録する機能を持っているということです。関係性とは、例えばサーバーA上でアプリXのインスタンスが実行されている、とか、サーバーAはストレージBに依存しているとか言う関係性に加えて、あるサービスがどのアプリとどのアプリの組み合わせで実現されていて、それぞれがどのサーバーで実行されているといった情報も含みます。
サービスがどう実現されているのかが記録されていることは、ITサービスの提供に不可欠な要素になります。
例えば、あるサーバーの障害がどのサービスに影響するのかといった影響度分析、サービスの不具合がどのコンポーネントの障害によるものなのかといった根本原因分析、パッチ適用やプログラムの変更がどのサービスに影響するのかといった変更リスクの評価といったいわゆるITサービス管理を円滑で効率よく正確に実施する事が出来るようになります。
このような構成アイテムの属性情報とCI間の関係性がきちんとCMDBに記録されていることで、ITサービス管理と一般にイメージするもの以外にも利用することが出来ます。
例えば脆弱性があるアプリケーションに見付かった場合を考えてみましょう。そのアプリケーションがどれぐらいのサーバーにインストールされているか、あたりまでは単なる資産台帳でもよくデータモデルができたものであればわかるかも知れませんが、それが一体どのサービスで利用されているものなのかまでCMDBでは追えます。そのサービスがどこ向けに利用されているのかやサービスのビジネス上の重要度から対応優先度を考えたり、実際の対応としてパッチを当てるのであればサービスへの影響を加味した適用計画が練られます。
またIT運用において一つの障害に起因して複数のエラーが誘発される事は高頻度であることですが、CMDBで関係性が記録されていることによって正確にグルーピングし、必要な対応に迅速に行き着くことができるようになります。構成アイテムには過去発生したインシデントや変更、ナレッジといった物を紐付ける事ができますので、復旧までの時間も短縮できますし、なにより対応する方々のストレスが大幅に軽減できます。
このように、正確で最新の状態を保ったCMDBは、構成アイテムの属性情報とそれぞれの関係性が記録されているため、IT部門だけが救われるだけでなく、実際にサービスを使っていたり販売している方々、問題を報告する義務のある方々、当然ながらそれらを管轄するマネージメント層にも価値を出すことができるものです。ですので、ビジネス上の目標に対してより具体的なユースケースを想定し、それにどうCMDBが役立つのかという文脈で他の部門にも役に立つという説得力を持たせることでCMDBをIT部門だけが価値を享受するもの以上の存在とし、IT部門だけが被るべきコストという存在から脱却させることが重要でしょう。
ところで、今のところIT資産の財務的な観点や契約的な観点には一切触れてきていませんでした。
ITILでも構成管理とIT資産管理は目的と焦点が異なる、密接に関連した別々のプロセスとして扱われています。ですので、一見同じ物を指しているから構成アイテムにIT資産管理に使用されるようなサポート期限やコストといった情報を付加してしまうと、整合性が微妙にとれなくなって破綻していきます。
ここでようやくServiceNowという名前を出しますが、ServiceNowのCMDBを含むデータプラットフォームServiceGraphでは、CMDBとIT資産管理で使われるアセットテーブルは、密接に関連する別のテーブルとして実装されています。例えばサーバー機器などでは、構成アイテムが変更されれば対応するアセットテーブルの資産情報も変更が入るように実装されていますし、逆のこと例えば購入して資産として登録するとそれに対応した構成アイテムもできあがるといった具合です。こうして構成管理とIT資産管理が密接に関わることで、各IT機器にインストールされているソフトウェアと契約情報を突合してライセンス利用状況を把握したり、あるサービスで使用しているアプリケーションや機器のサポート期限切れに併せたサービス刷新計画を練ったりといったことも可能になります。
このように密接に関わるテーブルも一緒に導入出来るような構成になっていれば、利用用途はさらに広がることでしょう。
過去の記事
