現状の課題
インシデント管理、問題管理、変更管理、リリース管理を行う上で、ITインフラに関する正確な構成情報を把握しておくことは不可欠である。構成情報を管理すべき対象となる構成アイテム（CI）や管理項目、粒度などは、各IT組織の管理ポリシーや業務内容により異なることから、汎用的な構成管理DBを構築し維持していくことは一般にかなり困難である。
構成管理DBは、物理的に単一のデータベースである必要はないが、あらゆる関係者が、必要な時に必要な情報を、容易にアクセスできる必要がある。また、構成アイテムの種類により管理すべき属性は異なるので、構成アイテムごとに管理項目を任意に設定できる必要がある。
例えば、サーバーに関するインシデントが発生した場合、対象サーバーのハード構成情報（機種、型番、IPアドレス、ホスト名など）やOS構成情報（OS種別、バージョン、適用パッチなど）、アプリケーション構成情報（導入アプリケーションのバージョン）などは、調査や1次切り分けを行う上で、最低限必要な情報といえる。
この場合、ITインフラ環境の情報を最新に保つ必要がある。ただし、必要となるITインフラ環境の情報は多岐にわたる上、日々変更が行われていることから、人手で構成管理DB
を最新状態にアップデートしていくのは現実的とはいえない。また、ベンダーが提供するパッケージ型の構成管理DBの場合、高度な機能を備えている半面、使いこなすには専門知識が要求され、サービスデスク担当者が活用できていないといったケースもある。
解決策
構成情報を最新に保つには、情報を自動的に収集する仕組みが必要である。これらの構成情報は、対象サーバーにエージェントなどを導入することなく、標準的なプロトコル（WMI， ssh， SNMPなど）で取得できることが望ましい。収集した構成情報を、構成管理DBに自動的に登録・更新され、更新頻度は、任意に設定できることが望ましい（1日1回など）。また、本番環境の変更作業時など、任意のタイミングで構成管理DBへ反映する仕組みも必要である。
構成管理DBには、運用マニュアルやSLAなどのドキュメントの他、保守契約情報も格納する必要があるので、手動での登録・更新も必要である。また、同一の構成アイテムであっても、属性によって自動で更新されるものと手動で更新するものを選択できる必要がある。
また、情報の信頼性を確保するため、定期的に構成管理DBに格納された構成アイテムの情報と、実環境の構成情報を比較し、差異がないかチェックする仕組みが必要となる。
Senju Familyでの実践方法
Senju Service Managerでは、インシデント管理や変更管理などと同様の統一されたユーザーインタフェースで構成情報を管理する。構成アイテムごとに一覧表示され、任意の属性で検索することができる。構成アイテム同士のリンクで親子関係を持たせることにより、子の構成アイテムが保持する情報を親に伝播させることができる。具体的には、「ラック単位でのサーバー電源容量」といった管理もできる。また、将来予定されている構成変更を予約することができ、指定日時には申請内容が自動的に構成アイテムに反映される。これにより、変更後の構成がシミュレーションでき、さらに、反映漏れを防止することができる。
最新構成情報はSenju DevOperation Conductorのコンフィグレーション機能により、自動的に収集する。ハード機種名、型番、ホスト名、IPアドレス、OSのバージョン、インストールアプリケーションなどの一般的な属性情報は、標準のテンプレートを用いて収集できる。機器やアプリケーション固有の構成情報は、コマンド、テキストファイル、SNMP、WMIなどの標準的なインタフェースにより取得する。
収集した構成情報は、インポートコマンドを用いて構成管理DBに自動的に登録・更新すること。また、ジョブスケジュール機能を用いることで、任意の頻度（毎日1:00など）での更新を自動化できる。更新に失敗した場合は、アラートメッセージを出力し、対応を促すことが可能である。
構成管理DBは自動だけでなく、手動での登録・更新が可能である。自動収集される属性項目（ホスト名、IPアドレスなど）と手動で設定する属性項目（保守連絡先、保守契約内容など）が混在する場合でも、一つの画面フォームで統一して管理することができる。また、自動収集される属性項目は、読み取り専用に設定することで、不用意な変更を防ぐことができる。
蓄積された情報は、構成アイテムの種類ごとにCSV形式やExcel形式で一覧出力できる。収集した構成情報と構成管理DBから出力された構成アイテムの一覧情報を比較し、差異がないか確認することで構成管理DBの信頼性を確保することができる。
