ITサービスを提供するために必要なハードウェアやソフトウェアなどを、構成アイテム(CI:Configuration Item)と言います。構成管理とは、構成アイテム(CI)の情報と、構成アイテム間の依存関係を正確に管理する取り組みのことです。
構成アイテムには、主に物理資産と文書の2種類があります。
物理資産 |
ハードウェア ソフトウェア ネットワークコンポーネント など |
文書 |
契約書 ライセンス 運用マニュアル 仕様書 設計書 ベンダー情報 SLA など |
構成管理では、これらの構成アイテムの情報をCMDB (Configuration Management Database)に集約して管理します。
CMDBは、構成アイテムと、構成アイテム間の依存関係を管理するためのデータベースです。日本語では、構成管理データベースと言います。
CMDBは、構成管理だけではなく、サービスデスクの他のプロセスを運用する上でも使われます。たとえば変更管理では、変更依頼があった場合に、システムを変更した場合の影響範囲を特定する必要があります。このとき、最新のCI情報がCMDBにより可視化されることで、サービス提供によるシステムへの影響範囲を素早く特定できます。
CMDBはインシデント管理 、問題管理 、変更管理 、リリース管理 、展開管理などの主要プロセスの土台となるデータベースです。
「ハードウェア・ソフトウェアを管理する」と言えば、IT資産管理 を思い浮かべる方も多いでしょう。IT資産管理と構成管理の違いは、管理をする目的です。
資産管理では、財務・経理処理の最適化を目的にアイテムを管理します。一方、構成管理では、ITサービスの最適化を目的にアイテムを管理します。そのため、管理手法や管理対象に違いがあります。
|
CMDBによる構成管理 |
資産管理 |
---|---|---|
目的 |
ITサービスの最適化 |
財務・経理処理の最適化 |
管理単位 |
複数アイテムになる場合もある |
必ず1アイテムごとに管理 |
管理項目 |
一意の識別子 / CIタイプ/名前・説明/場所/提供日/ライセンス情報/オーナー/ステータス/サプライヤー情報/関連文書/関連ソフトウェア/監査証跡当のデータ/リレーション情報/ SLA など |
名称/資産区分/機器種別/ベンダー名/シリアルNo./使用者/使用部門/管理番号/管理者/管理部門/設置場所/スペック/購入日 など |
例えば、あなたの会社でデスクトップPCとモニターを10台ずつ購入したとします。
この場合、資産管理ではデスクトップPCとモニターをそれぞれ個体に識別して管理します。デスクトップPC 10台、モニター10台の合計20アイテムとなります。一つ一つに、資産管理番号を印字したシールを貼付して管理している企業も多いでしょう。減価償却など経理上の処理を最適化する資産管理では、すべてのIT資産は個別に識別して管理されます。
一方構成管理では、1つ1つのアイテムが個別に管理されるとは限りません。たとえば、「デスクトップPCとモニターをセットとして管理する」という規定があるとすれば、デスクトップPCとモニターの10セットを、1つのCIとして管理します。このようにCMDBによる構成管理では、2つ以上のIT資産を1つのCIとして管理することがあります。
ITILv3 / ITIL2011における構成管理は、「サービス資産および構成管理」としてサービストランジションの主要プロセスの1つに定義されています。
サービス戦略(Service Strategy) |
サービス設計(Service Design) |
サービス移行(Service Transition) |
サービス運用(Service Operation) |
継続的サービス改善(Continual Service Improvement) |
---|---|---|---|---|
財務管理 |
サービスカタログ管理 |
変更管理 |
イベント管理 |
7ステップ改善 |
需要管理 |
サービスレベル管理 |
サービス資産および構成管理 |
インシデント管理 |
サービス測定 |
サービスポートフォリオ管理 |
キャパシティ管理 |
ナレッジ管理 |
リクエスト対応 |
サービスレポート |
|
可用性管理 |
移行計画及び支援 |
アクセス管理 |
|
|
ITサービス継続性管理 |
リリース及びデプロイ管理 |
問題管理 |
|
|
情報セキュリティ管理 |
サービスバリデーション及びテスト |
サービスデスク |
|
|
サプライヤ管理 |
評価 |
技術管理 |
|
|
|
|
アプリケーション管理 |
|
|
|
|
ITオペレーション管理 |
|
ITILv4では、構成管理は「サービス構成管理」というプラクティスとして定義されています。
「プラクティス」は、ITIL v3/2011の「プロセス」に代わり、ITILv4から導入された新しい概念です。インシデント管理 / 問題管理 / ナレッジ管理などの「プロセス」と、サービスデスク などの「機能」が、ITILv4では「プラクティス」と表現されるようになりました。
ITILv4には34個のプラクティスがあります。ITILv4のプラクティス群は、「一般管理プラクティス」「サービス管理プラクティス」「技術管理プラクティス」の3種類に分類されています。その中でサービス構成管理は、「サービス管理プラクティス」に分類されます。
一般管理プラクティス(General Management Practices) |
サービス管理プラクティス.(Service Management Practices) |
技術管理プラクティス(Technical Management Practices) |
---|---|---|
アーキテクチャ管理 |
可用性管理 |
展開管理 |
継続的改善 |
事業分析 |
インフラストラクチャとプラットフォーム管理 |
情報セキュリティ管理 |
キャパシティとパフォーマンス管理 |
ソフトウェアの開発と管理 |
ナレッジ管理 |
変更コントロール |
|
測定とレポート |
インシデント管理 |
|
組織の変更管理 |
IT 資産管理 |
|
ポートフォリオ管理 |
モニタリングとイベント管理 |
|
プロジェクト管理 |
問題管理 |
|
関係管理 |
リリース管理 |
|
リスク管理 |
サービスカタログ管理 |
|
サービス財務管理 |
サービス構成管理 |
|
戦略管理 |
サービス評価とテスト |
|
サプライヤ管理 |
サービス継続性管理 |
|
人材管理 |
サービスデザイン |
|
|
サービスデスク |
|
|
サービスレベル管理 |
|
|
サービスリクエスト管理 |
|
情報システム部門担当者が手作業でCMDBを更新するのは限界があります。CMDB内のデータが古い状況が続くと、構成管理自体が形骸化します。
たとえば、変更管理では、実際にシステムへ変更を加える前に、システムへの影響範囲を評価するプロセス(変更の評価と計画)があります。このとき、CMDBの情報が古いままでは、変更のリスクや影響がある他のシステムを正しく特定できません。
構成管理は、他のプロセスの土台になる概念です。そのため、他のプロセスと連携してはじめてその真価が発揮されます。もし、他のプロセスと構成管理を連携する仕組みが無ければ、それぞれを管理するツール間を行き来することになってしまいます。
たとえば、ITILのインシデント管理では、システム障害に対応する前に、影響範囲の調査をする必要があります。しかしこの時、構成管理ツール(CMDB)とインシデント管理ツールが連携していないと、もしそのシステム障害によって他のシステムに影響があったとしても、構成管理ツール側には自動でアラートがあがりません。
構成管理の課題は、ITSMS(ITSMツール)がスマートに解決します。ITSMSはサービスデスクが提供するITサービスを効果的に管理するツールです。ほとんどのITSMSには構成管理をサポートする機能が備わっています。
ITSMSでは、ソフトウェアに備え付けられた自動探知機能により、自動的に構成情報をシステムへ登録することが可能です。情報システム担当者は、新しいデバイスを購入するたびにCMDBに登録したり、変更が行われた文章を手作業で更新したりする手間から開放されます。
ツールによってはインシデント管理や変更管理などのプロセスとCMDBの連携をサポートしています。情報システム担当者は、必要に応じて、迅速かつ正確に該当のCIと影響範囲を特定し、次のアクションにつなげることができます。
Freshserviceは、CI情報やCI間の依存情報を自動的に検知できます。ディスカバリプローブが自動で社内の全資産を特定し、新しいハードウェアとソフトウェアをスキャンします。また、スケジュールを設定し、資産情報を定期的に更新することも可能です。
Freshserviceは、インシデント管理、変更管理などのプロセスとCMDBを紐づけることができます。ITサービスを提供する際、システムの影響範囲をスムーズに特定することが可能です。
各プロセスの画面から、CMDBにより構築されたアイテム情報と、アイテム同士の依存関係を確認することも可能です。
Sorry, our deep-dive didn’t help. Please try a different search term.