監視ツールは導入しているものの、サーバーやソフトウェアの構成管理は、手作業でExcel台帳に転記し管理している。これが、多くの運用管理の現場における実態です。
不測の事態のために、構成情報のこまめな管理が必要なことは理解しつつも、問題が発生しないと重要性が認識されないため、これまで、IT投資における優先順位は高いとはいえませんでした。
しかし、ようやく状況が変わりつつあります。昨年以降、構成情報管理の自動化に着手する企業が増えてきたのです。

１．何故、今、構成情報の管理が求められているのか？

まず、『継続的かつ安定的にITサービスを提供』することの重要性が今まで以上に高まってきたためです。
ITシステムに障害が発生した場合には、その影響度や範囲をすばやく特定し、関連する部門や担当者への通知が必要になります。確認のために時間がかかっていては、被害が拡大するばかりか、最悪、企業としての社会的な責任が問われかねません。
最近の大手通信キャリアにおける大規模通信障害の例を見ても、影響度や範囲の早期特定が重要であり、そのためには最新の構成情報が必須であることがわかります。

また、近年大きな問題となっているサイバーセキュリティ対策もその一因です。
内閣サイバーセキュリティセンター（NISC）では、重要インフラ14分野を特定し、経営層を巻き込んでの対策強化を行ってきました。そして、対策の不備が発見された場合には、経営層への責任を明確化することになりました。
このため、どこにどんなデバイスがあるのか、どんなソフトウェアを利用しているのか、バージョンは何か、最新のパッチが当たっているか、などの管理状況が、可視化できるようなしくみが必要になってきました。
企業における構成情報管理の目的を整理してみると、図1のようになります。

構成情報を管理することは、IT予算を計画的に立案するためにも必要なことです。
例えば、EOS/EOL対策があります。サーバーOSはバージョンがどんどん新しくなり、古いOSはやがてサポートの終了（EOL）を迎えます。EOLとなったOSにはセキュリティ対策のパッチも提供されなくなり、継続して利用することは危険になります。このため、EOLが到来する前に、新しいOSに移行する必要があります。
しかし、それだけではありません。OSのバージョンが上がれば、必要となるCPUのパワーやメモリ、ディスクの必要量も大きくなりがちです。よって、より強力なサーバーを購入しなければならなくなるかもしれません。
予算を考えるためには、OSバージョンだけでなくサーバー・ハードウェアの情報も併せて把握しておく必要があります。このため、計画的に予算を確保し、移行していく必要があります。
また、最近の傾向であるオンプレミスからクラウドへの移行にあたっても、現状のリソース利用状況を正しく把握しておかないと、移行時にどれくらいのクラウドリソースを確保しなければならないか判断できず、移行後にかかる費用の試算を行うことが困難になります。

このように、障害対応、セキュリティ対策に加え、計画的な予算の確保にも構成情報は必要です。

２．構成情報が活用されていなかった理由は？

何故、構成情報がこれまで活用されていなかったのでしょうか。
構成情報の収集は手作業でもできるので、特にお金をかける必要はないという認識があったようです。このため、構成情報の収集は人ができる範囲に限られていました。
勿論、10台、20台程度のサーバーの型番やIPアドレスやホスト名、OSバージョン程度の情報であればExcelで管理することは可能でしょう。しかし、収集しなければならない情報が増え、一方で日々の作業が山積みのため、構成情報の収集は後回しになりがちでした。結果として、更新タイミングは、毎週が毎月になり、隔月になり、という具合に延び延びになっていきます。
しかし、構成情報は常に最新のものを取得しておくのが望ましいです。古い情報では、正しい判断が難しいためです。実際に手作業で台帳を作成している企業の例では、その情報がいつ更新されたのかわからない、その情報が本当に正しいのか疑わしい、という声がありました。
このため、情報はあるにはあるものの、使えない情報になっていたのです。

そして、もう１つは組織の問題です。
例えばインフラとアプリケーションが別々の組織で管理されている場合、それぞれに台帳があり、サーバー・ハードウェアやOSはインフラチーム、ミドルウェアやアプリケーションはアプリケーションチームなどといったように管理されています。このような場合、組織の縦割りによって情報の分断が起こりがちです。
部門毎に閉じているため情報の交流は少なくなり、その結果サーバー情報とアプリケーション情報は１つの構成情報ではなく、別々の構成情報になり、一元管理とは程遠くなってしまいます。
しかし、サーバーの移行やアプリケーションのバージョンアップ、障害発生のような機会には、プロジェクトとして情報の突き合わせを行い、一時的に対応していたため大きな問題になることは無かったのです。

３．構成情報で何を管理する必要があるのか

基本的な考え方は、その情報を何に使うのか、から始めることです。
利用する目的を実現するために必要な情報に絞って収集します。このため、各企業で構成管理に必要とされる情報は異なります。これだけ集めれば大丈夫、ということではありません。
例えば、次のような目的が挙げられます。

• 障害発生時の対応
• 脆弱性問題への対応
• 保守契約の更新
• ソフトウェア・ライセンスの管理　など

構成情報と似た言葉で、「資産管理」というものがあります。
構成管理はITサービスの継続性や安定性に必要な情報の管理であるのに対して、資産管理は経理的な目的で必要な情報の管理になります。
情報的には被る部分が多いため、収集を検討するにあたっては、双方の必要情報を考慮したほうが良いでしょう。
表１に管理対象の構成情報を示します。

＜表1＞　管理対象の構成情報

No	対象	構成情報
1	ハードウェア	各機器や周辺機器の製品名やベンダー名、型番、シリアル番号、スペックなど
2	ソフトウェア	OSやミドルウェア、アプリケーションの名称やバージョン、パッチ適用状況。必要により設定情報
3	付帯情報	ロケーション、ラック位置、管理者、保守契約期間、問い合わせ先、マニュアル保管場所など

４．どうやって、構成情報を収集するのか

前述のように、手作業で構成情報をこまめに収集するのは無理があります。
よって、ツールを利用することを前提に、収集のしかたで情報を表２に示すように３つに分類します。
まず、ツールの基本機能として収集できる情報です。
各ツールによって、標準で収集できる情報は異なりますが、ハードウェアやソフトウェア、各種設定情報など標準機能で収集できる情報です。
次に、標準機能で収集できない情報は、コマンドやスクリプトを送り込んで強制的に収集します。簡単に収集できる情報から、少々手の込んだスクリプトで収集する情報などさまざまですが、多くはこの方法で情報の収集が可能です。
最後は、デバイスごとに後から付加しなければならない情報です。
サーバーが置かれているロケーションやラック位置、保守期間や管理番号、連絡先のように、デバイスに付帯する形で管理に必要な情報が相当します。このような情報は、ハードウェアやソフトウェアからは自動で収集できないため、追加情報としてデバイスに紐づけて手で入力しておき、管理します。

＜表2＞　構成情報の収集方法

ステージ	構成情報の収集対象	収集方法
1	ツールの基本機能として収集できる情報	標準機能でできるだけ多くの情報を収集 ※エージェントレスで収集できる情報/エージェントで収集できる情報の識別
2	標準機能では収集できない情報	コマンドやスクリプトを送り込んで強制的に収集
3	デバイスごとに後から付加する情報	デバイスに紐づいた情報の登録で管理 ロケーションや保守期間や問い合わせ先など

５．どのように構成情報を管理するのがよいのか

ツールですとスケジューリング機能を利用すれば、決められたタイミングで確実に情報の収集が行なえます。
基本は毎日、最新情報を収集しますが、情報によっては週次や月次で収集しても良いものもあるので、必要に応じて収集タイミングを定義します。
収集した情報は一覧表として、Excelなどの表計算ソフトで一元管理するか、基幹システムのデータベースなどにアップロードして情報の更新を行っていきます。
表２で示したように、情報の収集方法が異なるものについては、個別に収集した情報を逐次台帳上で更新していくことになります。
必要な情報を出力するためには、台帳で管理される構成情報を画面上で表示し、検索機能や並べ替え機能などを利用して目的に合った情報の出力を行います。
OSバージョンによる一覧表や、特定のアプリケーションやミドルウェアを利用している一覧表。OSとホスト名、サーバー・ハードウェア情報含んだ一覧表など、目的に応じてすばやく表示することが可能です。

脆弱性対策であれば、各OSへのパッチの適用状況。OpenSSLのバージョン表示というような絞り込みも可能になります。
サーバーセキュリティ対策では、このような機動的な対応ができることが重要な要因となるのです。

6．POLESTAR Automationで構成情報の収集を行う

ITインフラ運用自動化ツールのPOLESTAR Automationは、構成情報の管理とジョブスケジューラの機能を兼ね備えたツールです。
特徴はユーザビリティに優れたグラフィカルなインターフェースで、基本的な操作はマウスだけで行えるため、誰でもストレスなく操作が可能です。
標準で構成情報を収集する機能があり、定期的に情報のアップデートを行います。
POLESTAR Automationは、管理対象のサーバーにエージェントを導入して利用する方法と、エージェントレスで利用する方法の両方に対応（併存も可能）しています。エージェントを利用したほうが、標準機能でエージェントレスよりも収集できる情報が多くなりますが、エージェントレスの標準機能で収集できない情報は、ジョブを作成することで同等の情報を収集することも可能です。
POLESTAR Automationでは1,100種類以上のサンプルジョブが用意されており、その中には多くの情報収集ジョブがあります。
ロケーションや保守期間などの付加情報は、各デバイスに紐づくプロパティ項目を追加して、格納することができます。

このようにして、POLESTAR Automationは表３に示すように、構成管理に必要となる多様な情報を収集、登録することができます。

＜表3＞　POLESTAR Automationにおける構成情報収集自動化

ステージ	構成情報の収集内容	POLESTAR Automationでの収集
1	自動化ツールとしての基本機能の範囲で収集できる情報	システム情報、ディレクトリ情報、アカウント情報、アプリケーション情報、レジストリ情報*、Windowsサービス情報*、Windowsアップデート情報* Packages + *Windowsサーバーのみ　+Linux/UNIXのみ
2	標準機能では収集できない情報	1,100種類のサンプルジョブを利用して情報収集ニーズをカバー　ユーザーが個別に作成も可能
3	デバイスごとに後から付加する情報	デバイスに紐づくプロパティに情報項目を追加し、管理

そして、格納されている情報は、表４に示すようなさまざまな方法で出力することができます。
まず、ダッシュボードやシステム情報などの画面での表示。そして、表示されている画面のExcel出力（POLESTAR Automationでは、いたるところにExcel出力ボタンがあります）。さらに、標準のレポーティングツールを利用した、定形レポート出力。最後に、別ツールとの連携のための、API経由での情報提供。
このように、利用目的に合わせて最適な出力手段をお選びいただけます。

＜表4＞　POLESTAR Automationにおける構成情報出力機能

No	出力ニーズ	特徴
1	各デバイスの構成情報表示	ダッシュボード上に表示。表示された内容をExcelで出力可能
2	一時的にデバイスと構成アイテムの一覧表を作成	画面上に一覧表を表示 表示された内容をExcelで出力可能
3	定形レポートの作成	レポーティングツールのテンプレートを利用して画面表示が可能 Excel、Word、PDF等で出力可能 メールに添付して定期的に報告が可能
4	API連携で構成情報を提供	API経由で構成情報の提供可能 ※ServiceNowのCMDBとの連携実績あり

POLESTAR Automationでは、強力なジョブ作成機能と標準の構成情報収集機能で、さまざまな構成情報管理ニーズにお応えすることができます。
図1に示した構成情報の管理を行う目的は、図４に示すようにPOLESTAR Automationの機能を利用することですばやく、確実に実現が可能です。

• 標準の構成情報収集：標準機能として、主な構成情報を決められた時間に収集
• スクリプトジョブ：ウィザード画面を用い、スクリプトを送り込むためのジョブを簡単に作成。７種類のスクリプト言語を利用可能
• 点検ジョブ：点検ポリシーに設定した条件（範囲内、設定チェック、特定キーワード・フィルタリング等）に基づき遵守、違反で結果を表示　該当ソフトウェアの存在確認やパッチ適用確認などに利用
• ライブオブジェクト照会：デバイスと構成情報、プロパティ情報の一覧表を作成
• 報告書：標準レポーティングツールを利用し、テンプレートにあわせて情報を収集し出力

以上