構成管理データベース (CMDB) ガイド

CMDB の特徴

ここまで、CMDBの仕組み、構成管理におけるその役割、アセット管理との関わりと違いについてご説明しました。しかし、CMDB の機能はより実用的なレベルでどのように見えるのでしょうか?

CMDB の主な機能特性は次のとおりです。

CI メトリックと分析機能を備えたシームレスなダッシュボードにより、CI の健全性、それらの関係、変更による影響、インシデントや問題につながるパターン、組織内の各サービスの構築と保守にかかるコスト (金額とリソース) を簡単に追跡できるようになります。

コンプライアンス機能により、CI の現在の状態だけでなく、履歴変更、チェック アンド バランス、インシデントなどについて、監査人の詳細な記録と可視性が提供されます。

CI の作成とそのデータのタイムリーな入力が、手動入力、統合 (API 駆動、SCCM)、検出ツール (組織のネットワークですべての IP アドレスの自動スキャンを実行してソフトウェアおよびハードウェア情報を収集し、企業の各物理デバイスおよび仮想デバイスのインベントリを効果的に収集する) の、3 つの異なる方法でサポートされています。

連合データ セット (CI とそのデータの正規化と調整を含む)。

IT サービスのマッピング (一般的に、関係と依存関係のグラフィカルな図)。

アクセス制御により、必要に応じてさまざまなユーザーまたはチームに異なるアクセス レベルを付与し、質問またはインシデントが発生した場合に各自のソースにさかのぼって変更を追跡できます。

CMDB のメリット

CMDB が対処する主な問題は、サイロ化されたデータと古い情報です。CMDB を実装する前に、ほとんどの組織ではさまざまな所有者が存在するさまざまなシステムにデータが分散しているため、すべての CI とその相互依存関係を俯瞰することが難しく、最新の情報と最新でない情報の把握がさらに困難になっています。

これにより、チームは意思決定を行う際に重要なコンテキストを理解できなくなります。これは、リスクの評価と報告に影響を与え意思決定を妨げ、課題解決を遅らせて、最終的には財務と評判の両面でビジネスに負担がかかる可能性があります。

たとえば、CI A のデータがある部門に保管され、CI B のデータが別の部門に保管されているとします。CI B は、適切に機能するために CI A に依存しています。しかし、CI A の部門が保守のためにオフラインにすることを決定した場合、CI B に与える影響を把握できません。

これによって、最良の場合でもチーム間の混乱が生じる可能性があります。最悪の場合、これは重大なインシデントになる可能性があります。このシナリオを回避するために必要なのは、優れた CMDB だけです。

Forrester は、CMDB が今日非常に重要である次の 3 つのユース ケースを特定しています。

計画

テクノロジー マネージャーは、エンタープライズ アーキテクチャおよびポートフォリオ管理による俯瞰的なレベルと、アセットおよびキャパシティ管理による詳細なレベルの両方で計画する CMDB データを必要としています。

会計

IT 財務では、請求書を割り当てて企業財務を適切に管理するために、アプリケーションまたはサービス コードの記録が必要です。

操作

CMDB は、変更管理、インシデント管理、問題管理など、ITSM の多くのコア プラクティスを改善します。

変更管理では、CMDB はどのユーザー、システム、その他の CI が影響を受ける可能性があるかを予測することにより、リスク評価を改善できます。規制のある業界では、コンプライアンスを支援してチームがコントロールを管理し、明確な監査証跡を提供するのにも役立ちます。

インシデント管理では、CMDB はインシデントにつながった変更を特定して、より迅速に解決するのに役立ちます。インシデント レコードは、関連する CI に関連付けられ、チームが影響を与えるアセットとともにインシデントを経時的に追跡するのに役立ちます。

問題管理では、CMDB は根本原因の分析を支援して、チームをすばやく問題の核心に導けます。また、サービス コストと計画外のダウンタイムを削減するためにアップグレードが必要なアセットをチームが特定できるようにすることで、事前に積極的な問題管理をサポートできます。

最終的に、CMDB は複雑さを軽減してエラーを防ぎ、セキュリティを強化して、変更やインシデント管理などの ITSM プラクティスをスムーズに実行できるようにします。

CMDB の課題

業界の統計によると、CMDB への投資から有意義な価値を得るのは、組織の 25% だけであると報告されています。このような高い失敗率は、テクノロジーにかなり問題のある評判を残しています。

良い点は、失敗の理由が予防可能であり、6 つの予測可能なカテゴリに分類される傾向があることです。

文化 (Culture)

組織のあらゆるものと同様に、文化とチームのコミットメントは、新しいテクノロジーとプロセスが成功するかどうかを左右する、最も重要な要素の 1 つです。Harvard Business Review による最近の調査では、エグゼクティブの 93% が、データ主導のデジタル トランスフォーメーションにおける最大の課題は人とプロセスであると述べています。これは、CMDB プロジェクトにも当てはまります。

関連性

CMDB は、多くの場合、「信頼できる唯一の情報源」と呼ばれ、組織がニーズに関連するユース ケースを検討せずに、すべてのデータを 1 つにまとめようとする場合があります。

他のデータ リポジトリと同様に、CMDB には、変更管理などの内部プロセスをサポートする、焦点を絞った有用なデータが含まれている必要があります。CMDB に、価値目標、所有者、データを更新してすべての変更を反映する方法が、明確に定義されていることを確認してください。

一元化

CMDB がアセット データを表示するための一元化された場所であると言っても、すべてのアセット データが CMDB にのみ存在する必要があるという意味ではありません。このよくある誤解により、チームがすべてのデータをこの「信頼できる唯一の情報源」に移動しようとするため、多くの作業が発生する可能性があります。ここでの実際のベスト プラクティスは、各ユース ケースのサポートに最適なツールを使用するように、他のツールからのデータをフェデレーションすることです。

たとえば、財務データを IT 財務管理 (ITFM) ツールに保持し、ソフトウェア アセット管理 (SAM) ツールを使用してソフトウェア ライセンス情報を保持する方が理にかなっていることがよくあります。データは、プライマリ ストレージ スペースでなくても、CMDB にインポートしてミラーリングできます。

正確さ

多くの組織は、正確な CMDB の開発と維持に苦労しています。最も一般的な課題は、検出ツールの実行頻度が低すぎる、自動化ルールがない、または手動入力に依存していることです。これらの課題に対する典型的な答えは、従来のボトムアップ型の検出を強化するイベント駆動型の検出です。

これらの用語に慣れていない場合、ボトムアップ型の検出は、アセットがインフラストラクチャから始まり、顧客向けの CI に分岐してマッピングされるときです。イベント駆動型の検出は、システム内のイベントや問題など、システムが相互に通信する原因となる何かが発生したときです。その後そのイベントに基づいて、関連する CI とその関係がマッピングされます。

さて、すべての CI を検出できるわけではありません。たとえば、チームがモニターを CMDB にマッピングしたい場合があります。モニターは、自動システムでは検出できないため、スプレッドシート (または同様の方法) を使用して手動で入力する必要があります。

正確さの鍵は、ボトムアップ型の検出とイベント駆動型の検出の両方の力を活用して、アセットとその関係を最も明確に把握することです。

プロセス

一部の組織では、CMDB は、クラウドおよびソフトウェア定義のインフラストラクチャの新しいスタックと、それらでホストされている最新のワークフローではなく、従来のインフラストラクチャとソフトウェアをモデル化するためのものであるという認識があります。

ここでの真実は、セマンティクについての議論が、技術的なエコシステムを俯瞰できるツールで CI (従来と最新) を追跡する真価を追求することを妨げてはならないということです。

ツール

上記の不満足な失敗統計を回避したい場合は、適切なツールを選択することが最も重要です。一部の CMDB ツールは、データ構造が従来の物理インフラストラクチャ上に固定され、変更に対する検出ツールの反応が遅いアセット リポジトリにすぎません。CMDB で成功するには、新しいタイプのアセットを考慮し、迅速な変更が可能なツールが必要です。

CMDB で管理内容を選択する

CMDB 内でどの CI を管理すべきかについて、すべてに適した答えはありません。各組織のユース ケースと目標によって、CMDB の設定に適した幅と深さのレベルを決定する必要があります。一般的に、大まかに開始してサービスを使いこなしてから、組織の目標を達成するために必要な場所にのみさらに広く、また深く究めることが合理的です。

つまり、CI は、技術的エンティティまたは非技術的エンティティとして大まかにグループ化できます。

技術的エンティティには、ビジネス サービス、テクニカル サービス、アプリケーション、ソフトウェア、データベース、コンテナー、仮想マシン、オペレーティング システム、ハードウェア、ネットワーク、ポートなどがあります。

非技術的エンティティには、IT サービス マッピングで他のアセットに依存している、または他のアセットの影響を受けるものとして表す必要がある場合は、CMDB でモデル化することもできます。非技術エンティティには、ユーザー、顧客、組織、場所、サービス契約、ドキュメントなどがあります。

最後に、CMDB モデルの設計では、クラウド サービスを考慮する必要があります。SaaS サービス (Google アプリ、Dropbox、Salesforce など) と IaaS サービス (DigitalOcean、Linode、Rackspace、Amazon Web Services など) の両方は、必要に応じて CI として表せます。