![技術語り-Tech Blog[JP]](https://blogger.googleusercontent.com/img/a/AVvXsEiYsL2e14T1O3H3pP9BUj4BxNQQDgWUK-pNhtt6X8syLNp1zvyRWOG_UEv_Gcanv4Nix1_-8MCZL02odSwi69Cbmp6WJeoNDX8f7GQSPH25NUW3dtNTkcGdKhA0sRemc7CD46aj4pMhd8WzzKViOuxBpGmZ5DaFru2sTTv9Jie9aXa98EppzJj1P3lUvyY=s175)
CMDB-fundamentals①
Introduction to CMDB
概要
資産構成管理のデータベースです。
- IT課題
- 可視性を提供するCMDB
- NowPlatform上での活用
解決課題
ハードウェア、ソフトウェア、アプライアンス、仮想マシン、クラウド サービス、モバイル デバイス、コンテナー テクノロジ、オーケストレーターの普及これにより、インフラストラクチャの可視性が常に移動するターゲットになります。IT は、可視性を得るために、複雑なデータの統合、維持、理解という課題に直面しています。
---
CMDB の統合と維持に対する追加の課題は、未知の CI、不整合なデータ品質、および不明確な関係をキャプチャすることです。一般に、CMDB プロジェクトは、失敗した開始、長時間の実装、継続的なメンテナンスの課題に対して定評があり、ビジネス価値が限られ、報われない作業が多く生じます。
---
監査シナリオは、組織が通常の要求を解決しようとする貴重なリソースを失う方法の一例に過ぎません。データセンターでの計画外の停止を考慮すると、わずか数時間で数百万の費用がかかる可能性があります。しかし、現在でも多くの組織は、ワード文書とスプレッドシートのみを使用してインフラストラクチャを理解しています。堅牢な構成管理機能により、IT は計画外の停止コストを削減し、ビジネス成果を直接向上させることができます。
---
ビジネスオーナーとの成熟度と信頼を確立する戦略計画と、適切に構成された構成管理データベース (CMDB) を使用すると、継続的な IT 活動に関して組織を最大 40% 節約できます*しかし、IT 部門は信頼できる CMDB の価値を認識していることが多いのに、多くの組織は CMDB の実装、維持、および価値の引き出しに苦労しています。
---
CMDBの概要
適切に実装され、維持された CMDB は、物理サーバーおよび仮想サーバー、コンピューター、ルーター、スイッチ、アプリケーション、クラウド インスタンスなどの信頼性の高い構成データを含む、企業インフラストラクチャを完全に可視化します。
---
CMDBは、構成管理プロセスによって管理され、サービス管理、資産管理、運用管理などのすべての構成管理プロセスの基盤として機能します。
--
IT プロフェッショナルは ServiceNow CMDB を使用して IT 環境を可視化するため、事実に基づく意思決定を行い、企業に電力を供給するビジネスクリティカルな IT サービスを提供することに重点を置くことができます。
--
CMDBは、IT環境を理解する組織の不可欠な部分であり、あらゆるレベルの活動で意思決定をサポートするための巨大な価値提案を提供することができます。
--
標準化
ServiceNow CMDB は、共通のプロセスを持つ単一のデータモデルを利用し、
分類、および事前交渉されたセマンティクス、形式、および品質基準
交換されたデータ。
単一記録システム
その結果、Now Platform 上に構築されたすべてのテーブル、ビュー、およびアプリケーションは、統合された単一の記録システムを活用します。
拡張
このデータ モデルも簡単に拡張できます: 基本システム テーブルとビューを簡単に拡張できます。他のテーブルのフィールドは、ワークフローを駆動するために参照および使用することができます。データ検証と正規化ルールにより、信頼されたデータをあらゆるアプリケーション、フォーム、またはワークフローで活用できます
CMDB の変更
CMDBデータに対するすべての変更は完全にトレース可能で、日付と時刻、ServiceNowディスカバリー、SCCM、ユーザーなどの変更のソースによって記録され、新しい値と以前の値が含まれています。
CI とサービス履歴のタイムラインは、CI とアラートに対する計画的な変更と計画外の変更を時系列で視覚化します。
CMDB クエリ ビルダ
CMDB クエリビルダー機能は、サービスマップを含む複数の CMDB テーブル間で CMDB に対して、CMDB に対する API と関係を照会するシンプルで直感的な方法を提供します。ユーザー インターフェイスはドラッグ アンド ドロップで、コードを記述せずに CMDB データに複雑なクエリを作成および実行できます。クエリは、保存、スケジュール設定、および複数のファイル形式にエクスポートできます。
CMDB ダッシュボード
正常性ダッシュボードは、CMDB データの品質を全体的に把握できます。完全性、正確性、およびコンプライアンススコアを使用して、CMDB、CIクラス、およびCIレベルでのデータ品質の単一のビューを提供します。
ServiceNow用語
サービスナウ CMDB を理解するには、CMDB について話すときに使用できる言語の知識が必要です。次に進む前に、各用語を確認してください。- Configration Items
- Attributes
- Relationship type
- Class
- Configration Management System
- Configration Management Database
- Base table
- CI Reclassfication
- CI class upgrade
- CI class downgrade
- CI class switch
- Parent and child class
- Assets vs CI
- AssetsDB vs CMDB
- CMDB vs Autoritative Sources
- Common Service Data Model
- Application Service
- Application
- Devops
CI ...管理対象アイテム
製品やサービスを提供するために管理する必要があり、現在、または間もなく構成管理を行うインフラストラクチャの物理コンポーネントと論理コンポーネント。 たとえば、ネットワーク デバイス、サーバー、アプリケーション、配送トラック、サービスなどです。
Attributes...CIの情報
CI の名前、シリアル番号、製造元、オペレーティング システムなど、さらに説明する情報。
Relationship type...DBのリレーション
構成項目間の関係を含めます。たとえば、Web アプリケーションは特定のデータベースからデータを読み取り、その結果、基になるハードウェアに依存する場合があります。
Class...DBクラス
Windows サーバー、Linux サーバー、プリンター、仮想マシン、車両、動物などの共通の属性を共有する特定の種類または CI のグループを含み、表を表すテーブルについて説明します。
Configration Management System...管理ツール
組織の構成データを管理するために使用されるツールとデータベースのセット。
Configration Management Database...管理データベース
ライフサイクル全体にわたって構成レコードを保存するために使用されるデータベース。構成管理システムは 1 つ以上の CMDB を保持し、各 CMDB は、C の属性と他の C との関係を格納します。
Base table... [cmdb_ci] テーブル
すべての CI の基本属性を格納するコア構成項目 [cmdb_ci] テーブル。すべての構成項目クラスは、すべてのハードウェアとアプリケーションを含むこのテーブルから拡張されます。
CI Reclassfication...オーバーライドしたテーブル
クラスがアップグレード、ダウングレード、または切り替えられている CI です。アップグレードされた CI の例としては、サーバー [cmdb_ci_server] クラスから Windows Server [cmdb_ci_win_server] クラスにアップグレードされたサーバー レコードがあります。
CI class upgrade...特化クラス
CI クラスはクラス階層内のあまりジェネリックではないクラスに更新され、新しく割り当てられたクラスには追加の属性があります。たとえば、CI がサーバー [cmdb_ci_server] クラスから Windows サーバー [cmdb_ci_win_server] クラスに移動した場合にアップグレードが行われます。
CI class downgrade...汎化クラス
CI クラスは、クラス階層内のより汎用的なクラスに更新され、新しく割り当てられたクラスの属性が少なくなります。たとえば、WINDOWS Server [cmdb_ci_win_server] クラスからサーバー [cmdb_ci_server] クラスに CI が移動されると、ダウングレードが発生します。
CI class switch...
CI クラスは、クラス階層内の別のブランチにあり、現在のクラスとは異なる属性セットを持ちます。たとえば、Linux サーバー [cmdb_ci_linux_server] クラスから Windows サーバー [cmdb_ci_win_server] クラスに CI を再分類します。
Parent and child class...親子クラス
別のテーブルを拡張するテーブルは子クラスと呼ばれ、拡張されるテーブルは親クラスです。テーブルは、他のテーブルの拡張と拡張の両方を親クラスと子クラスの両方にできます。たとえば、サーバー テーブルは [コンピュータ] テーブルを拡張し、Windows サーバー テーブルはサーバー テーブルを拡張するため、サーバー テーブルは親クラスと子クラスの両方になります。
Assets vs CI...
Now プラットフォームでは、ハードウェア資産を作成するときに、対応する CI が自動的に作成されるか、CI が初めて検出されて CMDB に挿入されると、対応する資産レコードが自動的に作成されます。アセットと CI は CI/アセットのライフサイクルを通じて接続されます。
資産：
多くの場合、調達プロセス中に開始されますが、検出ツールが CI を初めて検出したときに作成される場合があります。
財務ライフサイクルの一部である
構成
アイテム(CI):
多くの場合、検出ツールが CI を初めて検出したときに開始されますが、調達プロセス中に作成される場合があります。
技術業務の一部である
AssetsDB vs CMDB...
資産 DB は在庫 + 財務データ
CMDB はインベントリ + リレーションシップ
CMDB vs Autoritative Sources...
CMDB は、いくつかの情報の権限のあるソースです。
サポートグループ
連絡先
所有者
CMDB は、すべての情報の権限のあるソースではありません。
すべてのサーバーおよびアプリケーション構成ファイルの内容
サーバー ログ ファイル
Common Service Data Model...
CMDB 内のサービス モデリングに関する規範的なガイダンスを提供しながら、真のサービス レベル レポートを有効にし、サポートする、製品およびプラットフォーム全体にわたる標準および共有サービス関連定義を表します。これらのサービス関連の定義は、サービスナウ®製品ポートフォリオと今すぐプラットフォーム®にまたがっています。
Application Service...
組織にサービスを提供するように構成された、相互接続されたアプリケーションとホストのセット。アプリケーション サービスは、組織の電子メール システムや顧客向けの組織 Web サイトのように内部にできます。
Application...
アプリケーション サービスを構成項目 (CI) として構成するデバイスとアプリケーション。アプリケーション サービスを構成するさまざまな API とそれらの間の関係は、CMDB に格納されます。(すなわち、トムキャット、アパッチ、マイクロソフトSQL、オラクル、IIS)。
Devops...
アプリケーションを構築する開発者と、アプリケーションを企業内に展開および保守する運用グループで構成されます。DevOps 環境では、これら 2 つのグループを 1 つに統合して、サービス提供の迅速化と向上のために、より効果的に連携します。
構成管理機能
ServiceNow CMDBのメリットは、NOWプラットフォーム全体に及び、サービス管理、資産管理、運用管理、セキュリティ管理、クラウドオペレーション、イベント管理、コンプライアンスなどの構成管理機能を強化します。
CMDB が日常のプロセスで重要な役割を果たす方法については、以下のユース ケースを確認してください。
ユース ケース 1
–
ITサービスデスクは、インシデント管理プロセス中にCMDBを使用して、ネットワークユーザーの機器とソフトウェアをよりよく理解することができます
ユース ケース 2
–
オペレーション 管理者は、ネットワーク上のサーバー、アプリケーション、ネットワーク デバイス (それらの関係など) を把握できます。
データの作成
CMDBは、以下を通じて正確なデータ取得を可能にします。
- 既知および未知の C のエージェントレス自動検出
- サード・パーティー・データ・ソースへの既存の統合
- Web サービスまたはその他の方法を使用した追加統合
組み込みのデータ調整機能と正規化機能により、常に正確で有用なデータを確保できます。
ServiceNow ディスカバリを実装すると、CMDB で常に再検出および更新される CI データを使用して、CMDB を簡単かつ正確に設定および維持できます。完全に統合され、エージェントレスの ServiceNow Discovery は、連携している CI の種類を自動的に特定し、そのデバイスに適した追加のプローブ、センサー、パターンを起動して、さらに詳しい情報と属性を収集します。
サービスマップは、既存のサービスマップにオーバーレイ
特定のサービスの基になる C を接続するための構成データを、CMDB
サービスを認識しています。
CMDB は、最も一般的なインフラストラクチャとも統合
VMware vCenter、マイクロソフト システム センター構成などのプラットフォーム
マネージャー、Google クラウド プラットフォーム、エンドポイント管理サービス。
さらに、データは、インポートセット、Webサービス、ダイレクトを通じてCMDBにインポートされる場合があります
データベース インポート、および Excel ファイル。変換マップ、ID と調整エンジン、およびビジネス ルールを使用すると、インバウンド データをターゲット テーブルおよびフィールドにマップし、変換、マージ、および結合できます。
CMDB は、ID と調整エンジン (IRE) やフィールドの正規化などの NOW プラットフォーム機能を利用して、CI の一意性を自動的にチェックします。これにより、許可されたデータ・ソースのみが特定の CI クラスを更新し、データを正規化し、データを CMDB にロードして、その CI の最新かつ正確なプロファイルを確保できます。
Maps provide visualization of CMDB relationships
Maps provide visualization of CMDB relationships
サービス対応 CMDB
ServiceNowのサービスマッピング技術は、複雑なITインフラストラクチャとサービス関係を明確にグラフィカルに把握し、提供します。IT プロフェッショナルは、サービス マップをクリックしてデータをフィルター処理し、特定の API に焦点を当て、インシデント、問題、変更要求などの機内操作アクティビティと共に影響とリスクを確認できます。
管理者、システム所有者、およびサービス所有者は、構成のドリフト、計画外の変更、インシデント履歴を迅速に特定して、その役割を担う CI の正常性、およびそれらの実行アクティビティが直接または間接的に影響を与えている場合に、その原因を把握できます。
共通サービス データ モデルの概要
共通サービス データ モデル (CSDM) は、ServiceNow 製品およびプラットフォーム全体にわたる、標準および共有サービス関連の定義のセットを表します。CSDM は、真のサービス レベル レポートを有効にし、サポートすると同時に、CMDB 内のサービス モデリングに関する規範的なガイダンスを提供します。これらのサービス関連の定義は、ServiceNow 製品ポートフォリオと現在のプラットフォームにまたがっています。
コース：CMDBの概要：設計
ドメイン共通サービスデータモデルは、3つのドメインに分かれています。最初のドメインはデザインです。このドメインでは、ビジネス機能、ビジネスアプリケーション、および新しい（ニューヨークリリース）情報オブジェクトに関連するテーブルを識別します。これらのテーブルはAPM製品ラインの一部として普及し、在庫とポートフォリオの観点からビジネスアプリケーションの控えめな表現に関連する機能を有効にします。ビジネスアプリケーションを機能の観点から見て、提供したい機能に関連して支出が多すぎたり少なすぎたりする場所を特定して合理化することができます。ビジネスアプリケーションを使用すると、ビジネスアプリケーションに関連する新しいテーブル情報オブジェクトを含む、アプリケーションに関するメタデータを識別できます。 PIIやPCIなど、コンプライアンス関連のデータがある場所を特定する必要がある領域の場合、その情報は、ビジネスアプリケーションに関連する情報オブジェクトテーブル内に出力されます。データが存在する場合、その情報オブジェクトをデータが存在する正確なデータベースインスタンスに関連付けることができます。
テクニカルサービスの管理[テクニカルサービスの管理]
領域内で、共通サービスデータモデルの最も重要な要素の1つであるアプリケーションサービスを特定します。アプリケーションサービスは、ビジネスアプリケーションの実装であると考えてください。アプリケーションサービスに出入りする多くの回線に気付くでしょう。この特定のテーブルは、共通サービスデータモデルの要素の多くを結び付ける接着剤になります。ビジネスアプリケーションまたはアプリケーションサービスの実装は、さまざまな方法で実行できます。 Dev、QA、Prodなどの環境ごとに分類できます。地域ごとに分類できます。北米製品とEMEA製品などです。これらは、実際に実装されているものを表したものになります。 ServiceNow Service Mappingのような製品をお持ちの場合、そのアプリケーションサービスの実装を構成するすべての構成アイテムを特定できます。 ServiceNow Discoveryは、サーバーとネットワーク機器、およびそこに存在するアプリケーションからすべての部品を識別できます。ここでは、CMDBにServiceNowの黎明期から存在していたアプリケーションテーブルが特定されています。これは、ホスト上で実行されているコード内にある検出可能な要素を対象としています。それらの名前は、特定のホストで検出および実行されている特定のコードに関連しているため、アプリケーションの名前、@記号、およびホストの名前に似ていることがよくあります。データベースインスタンスは、アプリケーションの一例です。次に、技術サービスと技術サービスの提供の表現が表示されます。これらは、企業が消費するために存在するこれらのテクノロジーを提供および管理するグループです。本質的に、技術サービスの管理は、ビジネスが消費できるように技術的な観点から提供されるものを識別する領域です。
オーディオクリップ：販売/消費
次のドメインは販売/消費です。技術サービスから提供されていると特定されたように、販売/消費は、技術の専門家が提供するものを消費するビジネスです。これらは、ビジネスがビジネスとして実行するために存在する正確な要素を識別し、ビジネスサービスの提供、ビジネスサービス、および（ニューヨークリリースの新機能）ビジネスサービスポートフォリオを含む複数のテーブルで識別されます。ビジネスサービスポートフォリオはCMDBCIテーブルではありませんが、サービス関連オブジェクトの階層を提供するために識別されます。また、ニューヨークのリリースでは、サービスの提供をリクエストカタログからリクエストする機能が新しく追加されました。
データモデルは、複数の構成戦略を可能にし、サポートする当社の製品およびプラットフォーム全体にわたるCMDBフレームワークです。CSDM には、基本システムテーブルとリレーションシップを使用したデータの適切なモデリングに関連するベスト プラクティスが含まれています。多くの ServiceNow 製品は、このデータ モデル内のデータに依存しています。
- 共通サービス: サービスレベルのレポートを有効にしてサポートする、製品およびプラットフォーム全体にわたる標準および共有サービス関連の定義。
- データモデル:複数の構成戦略を可能にし、サポートする当社の製品とプラットフォーム全体にわたるCMDBフレームワーク。
CSDM と ServiceNow が提供する内容をよりよく理解するには、それが何であるかと何がないのかを理解することが役立つことがあります。
CSDM は CMDB フレームワークです。
CSDM は次のとおりです。
- 標準用語と定義
- CMDB データモデリングとデータ管理のベストプラクティス
- 基本システム CMDB コアテーブル
- サービス モデリングに関するガイダンス
- 推奨されるマッピング
CSDM は最終的なソリューションではありません
CSDM は次のものではありません。
- ITSM、SPM、APM、EM、またはその他の製品のプロセスまたは実装ガイド
- 一連のレポート
- インストールするコード
- 当社が販売するSKUまたは製品
- 過去の実装のための自動修正
共通サービス データ モデルの詳細を知りたいですか?以下のドキュメントをダウンロードして、読み続けてください。
ステークホルダー
CMDBステークホルダー
CMDBの旅を始めると、堅牢で正確なCMDBから価値を実現できるステークホルダーが多く存在する可能性があります。各利害関係者は、CMDB の実装から実現したいさまざまな目標と成果を持つことになります。
構成管理の目標と目的に関する合意は、利害関係者が整合し、確立された優先順位に合意するために不可欠です。構成管理の取り組みは、組織の戦略的目標と IT 部門の戦術的目標に明確かつ明確に関連付ける必要があります。
前のセクションで説明したように、CMDB では、サービス依存関係マップを作成して、イベント、インシデント、問題、および変更の要求をサービスへの影響に関連付けることができます。これらの機能をサポートするために必要な特定の CI 情報を決定し、組織のバイインを構築するには、適切な関係者を関与する必要があります。この関係者グループには、プロセスの所有者、プロセス マネージャー、および各プロセスのその他の主題の専門家を含める必要があります。
実例
構成管理の旅における10の重要なマイルストーン
結論として、組織の構成管理を成功に導くため、取り組み、注意を向ける 10 のマイルストーンを次に示します。
- 構成マネージャーが主導する構成管理チームを持つ
- 構成項目をサービス指向ビューに揃えるか、または配置中である
- 指定したユースケースと目標をサポートするために選択したCIクラスを確認します。
- 必要な時間とエネルギーを投資して、CMDBチームからすべての関係者、およびすべてのステークホルダーのCMDBチームの両方に情報が流れるよう、コミュニケーションプロセスを効果的に設定します。
- すべての関係者がビジョンと目標を明確に理解できるように、トレーニングを優先的に実施
- CMDBへの情報の流れを、記載されたユースケースをサポートする頻度で可能な限り自動化する
- CMDB内のデータの完全性と完全性を継続的な改善につながる方法で監査するように設計されたワークフローを活用する
- 多くの場合、CMDBがすべての述べられたユースケースとサポートされているすべてのダウンストリームアクティビティの真実の単一のソースであることの重要性を伝えます
- 構成管理チームが追加の CI クラスおよび拡張されたユースケースの要求に適切に対応できるプロセスを配置する
- 影響を受けるサービスを見据えたインシデントおよび変更管理プロセスの継続的改善
ナレッジチェック
次の質問を読み、答えを選択してください。
Q.CMDB の実装と保守は困難な場合があります。組織が CMDB から実装を完了できなかったり、ビジネス価値を実現できなかった理由は何ですか。適用するすべてのものを選択します。
- 構成項目間の関係が不適切です
- データ品質の一貫性が一致しない
- IT 以外の構成項目が多すぎます
- 不明な構成項目
A.3以外が〇
Q.CMDB は、組織の IT 環境を一貫した完全なビューで表示する、単一のデータベースに対して、複数の CI を統合します。正常性ダッシュボードは、CMDB データの品質を全体的に把握できます。ダッシュボードにはどのようなスコアが表示されますか?適用するすべてのものを選択します。
- 完全
- コンプライアンス
- 正しさ
- つながり
A.1,2,3
Q.各利害関係者は、CMDB の実装から実現したいさまざまな目標と成果を持つことになります。 CMDBの実装と維持におけるステークホルダーの役割は何ですか?
- 名前、ソース、リレーションシップなどの CI データのインポート
- 機能をサポートするために必要な特定のCI情報を決定し、組織のバイインを構築する
- 構成管理責任のための進入戦略の作成
- 関連部門の CI 正常性を示す必要なレポートを特定する
A.2
用語を正しい説明と一致させる
用語:
- クラス
- リレーションシップの種類
- 構成管理データベース (CMDB)
- 属性
- 構成管理システム (CMS)
- 構成項目 (CI)
---
内容:
- 製品またはサービスの提供に必要なインフラストラクチャのコンポーネント
- CI に関する名前、シリアル番号、オペレーティング・システムなどの詳細な情報
- 構成アイテム間の関係
- ライフサイクル全体にわたって構成レコードを保存するために使用されるデータベース
- 共通属性を共有する特定のタイプまたは CI のグループを含む表
- 組織の構成データを管理するために使用されるツールとデータベースのセット
A.
5-6
6-1
4-2
2-3
3-4
1-5
この研修に参加していただきありがとうございます。
このコースでは、テクノロジーを活用した組織における IT の課題を垣間見ることができます。一般的な用語、構成管理機能、CMDB 実装に関わる主要な関係者など、ServiceNow CMDB に導入されました。
Design a Successful CMDB Implementation
ServiceNow 構成管理データベース(CMDB)は、構成管理をサポートするように明示的に設計された専用のデータベースです。構成管理は、必要な状態で必要な状態で製品またはサービスが確実に構築され、運用されるように努めるエンジニアリングおよび管理の分野です。
CMDB の導入が成功するたびに、構成管理機能の実装、設計、維持のための詳細な構成管理計画があります。
このコースでは、CMDBの旅程を開始する際に従う一連の推奨ステージを提供します。
目標
- CMDB 展開を正常に計画するためのステージを確認する
- ユース ケースにマップされた明確な目標を記述する
- チームを構築し、役割と責任を定義する
- CMDBが価値を提供することを保証する計画を設計する
- 以前に設定した目標と目標を結び付けて、他の関係者に価値を示す
CMDB を成功させるための計画
時間をかけて構成管理計画を作成すると、重要なサービスによって提供されるパフォーマンスが向上します。CMDB を設計する最初のステップを考える場合、CMDB は「プロジェクト」や「製品」ではなく、「ライブに行く」日付を持つということを理解することが重要です。プロジェクトには開始と終了があります。しかし、CMDBを実装し、世話し、育成することはありません。CMDB を維持するプロセスは実行しません。それは継続的な取り組みです。
CMDB を成功に導く実装は、他の ServiceNow 製品実装とは違います。
CMDBの導入が成功すれば、100%完璧になることはないでしょう。しかし、多くの大企業は、ServiceNow Discoveryなどの自動化ツールを配置し、よく考え抜かれたスケーラブルな変更管理プロセスを開発するにつれて、近づいています。
CMDBを成功に導く4つのステージ
CMDB を導入する場合、これら 4 つの段階に従って成功を収めます。各番号をクリックすると、ステージとテイクアウトの詳細が表示されます。
- 効果的なCMDB実装計画を作成するために、お客様が従う必要のある4つの段階があります。ステージ1では、明確な構成管理目標の目的と結果を使用して方向性を設定します。
- ステージ2では、チームとガバナンスモデルを構築し、経営幹部から早期に賛同を得ることでこれを実現します。これにより、長期的に構成管理プロセスの信頼性と信頼が構築されます。
- ステージ3では、構成計画を設計します。構成アイテムを使用してCMDBを設計するにつれて、最初は小さく、徐々に大きくなります。
- ステージ4では、CMDBの価値を他の部門に示し、ビジネスプロセスを統合して目標に結び付け、CMDBの変更について積極的にコミュニケーションを取ります。
これらの段階の終わりに、ServiceNowの顧客は次の能力を向上させます。
- サービスの健全性をこれまで以上に管理する
- 競争上の優位性を提供する独自の要件を表すサービスを決定する
- ターゲットを絞った方法で戦略的投資を推進する
- 標準化と簡素化によってコストを削減する
- 利益サービスを支えるテクノロジーに関する可視性
- 技術的な負債/サポートのリスクプロファイルを理解する
- 社内外の顧客が提供するサービスをどのように消費しているかを把握し、将来の消費を予測する
- 両方のサービスを提供するために使用されるネットワーキング、コンピューティング、およびデータインフラストラクチャを明確にするオンプレミスおよびクラウドベース
- 各サービスのコストを計算し、公開されたサービスレベルに基づいてサービスを提供する能力を測定する方法
顧客はこのベストプラクティスを徹底的に実行しました。その結果、彼らは何を奪うべきか、次のような価値を理解する必要があります。まず、組織が戦略的イニシアチブを達成するのに役立つように、目標を書くことで価値を理解する必要があります。お客様は、全員が目標に集中できるように、構造化されたチームと運営委員会を作成することの重要性を理解する必要があります。ビジネス主導の構成管理計画を維持しながら、お客様は、特定のユースケースに焦点を当てたCIの堅実なインベントリをCMDBに投入することから始めることを知っておく必要があります。顧客が目標やユースケースに結びつかないアイテムを入力していることに気付いた場合、顧客は自分たちが軌道に乗っていないことを知り、最終的にこのベストプラクティスを実行した結果、顧客は明確なコミュニケーションの重要性を理解します。構成管理計画の変更に関するビジネスの利害関係者への明確なコミュニケーションは、CMDBの長期的な健全性にとって素晴らしいことです。
Q.CMDB を設計する最初のステップを考えるとき、CMDB を理解することが重要です。
- 製品です
- プロジェクトです
- ゴーライブを持っています
- 継続的な取り組みです
Q.4 つのステージのそれぞれを、CMDB の成功を計画して、目的の結果に合わせる
- 方向を設定する_1
- チームとガバナンス モデルの構築_2
- 構成計画を設計する_3
- CMDBの価値を他の部門に表示する_4
方向を設定する
明確な構成管理の目標、目的、および成果は、CMDB を成功に導く優れた構成管理機能を設計するための鍵となります。
CMDB導入が成功している企業は、達成する内容、そのアプローチ、意図されたビジネス成果、およびそれらの成果の継続的な測定を常に明確にします。
適切に述べられた目標と目的を書く:
- 何を達成したいですか?
- 方法: アプローチ、制約、および前提を定義する
- 理由: CMDB がサポートするビジネス成果は何ですか?
- 対策:目的の結果を達成していることをどのように知っていますか?
CMDB 展開の成功を計画する - 方向を設定する
成功するCMDB展開の計画は、CMDBをオンにするだけではありません。このビデオでは、CMDB展開の明確な目標を特定する方法、管理と運用のチームを構築する方法、およびCMDBが価値を提供することを保証する計画を設計する方法について段階的に説明します。
ステージ1、方向性の設定、CMDBの展開を成功させるための最初のステップは、明確で明確な目標、目的、および結果を定義することです。目標に集中するのに役立つユースケースのリストを書き留めることから始めます。これらのユースケースは、テクノロジーの成果だけでなく、ビジネスの成果にも結びつく必要があります。
例を見てみましょう。監視ツールは、クラウドサービスの1つがパフォーマンスのしきい値の1つを超えていることを示しています。そのクラウドサービスのパフォーマンスがビジネスにとってどれほど緊急であるかを理解する必要があります。そのクラウドサービスが正しく動作していることに依存している従業員や顧客がいる可能性があります。 CMDBの展開には、ビジネスを混乱させる可能性のあるサービスの問題を監視、通信、および解決できるように、使用するクラウドサービスを正確にマッピングするという目標が必要です。あなたの会社はITインフラストラクチャに多額の費用を費やしており、コストを削減する必要があります。テクノロジーが展開されている場所と、テクノロジーがサポートするビジネスアプリケーションを理解して、コストを削減する場所を特定する必要があります。 CMDBの展開には、最も重要な資産をより適切に管理し、重要ではない資産を廃棄できるように、正確な資産マッピングを目標にする必要があります。
いくつかのユースケースを念頭に置いている場合は、いくつかの簡単な質問に答えて、目標を明確に定義してください。何を達成したいですか？おそらく、資産をより適切に管理したり、クラウドサービスの可用性を向上させたいと考えています。
次に、どのようなアプローチを取りますか。完全性と完全な正確さが必要ですか、それとも反復的ですか？どのくらい自動化できますか？最後に、これがどのような測定可能なビジネス成果をもたらすか。この明確さを前もって持っていない場合は、必要のない領域に労力を費やす可能性があり、パートナーの期待に応えることができない可能性があることを忘れないでください。
専門家のヒント、あなたの目標を達成するためのあなたの能力が必要とするものに関して結果を定義してください。 ITインフラストラクチャのコストを事前に節約することでそこに到達できます。つまり、新しいイニシアチブのための予算が増えることになります。
ユースケースを書くことから始める
まず、目標に焦点を当てるユースケースのリストを書きます。これらのユースケースは、会社の戦略的イニシアチブに直接結びつくべきです。Service今、顧客は多くの場合、次の方法から始めます。
CMDB の導入に時間を取ることは、特定のプロセス内でのデータの消費など、企業が念頭に置いている目的と目標を達成する必要があります。たとえば、インシデント、問題、変更、イベント、IT 運用管理などです。
顧客の例
この例を見て、ある顧客が目標を概説し、その主なビジネスの優先事項に重点を置いて、Why セクションを使用して説明します。
Q.適切なユース ケースを、目的のビジネス結果を右側にマップします。
- データセンターの移行
- 資産管理
- クラウド優先戦略
- 正確なインフラストラクチャ構成とサービスへの影響
- オンプレミスのインフラストラクチャと共にクラウド サービスをマップする
- インフラストラクチャとアプリケーションの正確な追跡
A.
1-3
2-1
3-2
明確な構成管理の目標と目的は、常に次のもので構成する必要がありますか。
- 何が、どのように、なぜ、測定
- 方法、理由、測定、時期
- 理由, 測定, 何, どこ
- 測定, 何, 方法, 誰
A.1
チームとガバナンス モデルの構築
構成管理チームとガバナンス構造を構築する場合、役員から早期に買収することで、構成管理プロセスに対する信頼性と信頼を長期的に生み出します。
チームは、日常のサポート機能に悩まされることなく、構成管理の責任を果たさなければならない。このチームは、日々の「ライトを点灯したままにする」サポート機能とは独立して動作する必要があります。
CMDBは、IT組織に影響を与えるさまざまな規制要件やガバナンス要件を満たす上で非常に強力なツールとなります。たとえば、サーバンズ・オクスリー法は、財務報告に影響を与えるプロセスの管理の証拠を必要とする連邦命令です。また、特定のCMDB要件を決定する多くの業界固有の規制があります(例えば、患者情報のHIPAAコントロール、欧州連合のデータ保護のためのGDPRコントロール)。
CMDB チームは、内部監査チーム、法律顧問、IT ガバナンスおよび規制管理を担当する IT 担当者など、適切なガバナンス関係者からこれらの特定の要件を収集する必要があります。
CMDBは、IT組織に影響を与えるさまざまな規制要件やガバナンス要件を満たす上で非常に強力なツールとなります。
いくつかの例を次に示します。
The GDPR impacts data usage across the world
- データが保存または処理される国に関係なく、欧州連合(EU)の個人のデータ保護を保証する一般データ保護規則(GDPR)。
- 財務報告に影響を与えるプロセスの管理の証拠を必要とする連邦命令であるサーバンズ・オクスリー法。
- 患者情報のHIPAA制御など、特定のCMDB要件を規定する業界固有の規制も多数あります。
CMDB チームは、内部監査チーム、法律顧問、IT ガバナンスおよび規制管理を担当する IT 担当者など、適切なガバナンス関係者からこれらの特定の要件を収集する必要があります。
役割と責任
チームを配置して、各メンバーの役割、責任、権限を定義します。次に、これらのことを文書化して、必要な変更を行う所有権とサポートを持っていることを確認します。
ServiceNow は、構成管理チームの役職と役割が会社ごとに異なっていることを認識しています。つまり、ServiceNow のお客様が適切に実装された CMDB を正常に展開して維持するために利用する多くの標準的な役割と責任の概要を示すため、次の表は役立ちます。
RACI モデルに精通している場合があります。
- Responsible
- Accountable
- Consulted
- Informed
各ユーザーとその役割の詳細については、RACI pdf をダウンロードしてください。
ステージ2：構成管理のためのガバナンスモデルでチームを構築することは、CMDBだけではなく、成功するためにガバナンスモデルの適切なチームに依存することを意味するプロセスです。ガバナンスモデルの最高のチームは、CMDBの展開が、ステージ1で定義した目標と目的に沿っていることを保証します。優れたガバナンスは、次のアクティビティ、プロセス計画、および設計で構成されます。ここで、計画を作成し、CMDBの構造と、それを設定するために使用するデータを定義します。構成IDは、CMDBで追跡する構成アイテムのタイプを指定する場所です。
構成制御これは、データが有効で最新であることを確認する場所です。これは、検証プロセスによってサポートされます。ステータスのアカウンティングとレポートの監査は、構成管理プロセスからレポートする内容を把握して、正常に機能していることを確認する場所です。構成管理チームは、これらの責任を管理する必要があります。これは通常、計画の展開を保証し、CMDBの管理の成功に責任を持つ構成管理プロセスの所有者、構成管理サービスの提供を管理し、操作手順を文書化する構成マネージャー、実行する構成管理システムアナリストのスペシャリストで構成されます。 CMDBの保守と構成管理プロセスに関連する日常のタスク。一部の組織では、構成管理チームが運営委員会によって監督されています。CCBの構成管理委員会は、依存する主要な戦略的イニシアチブに責任を持つリーダーシップチームメンバーで構成されています。それらをサポートするために、CCBは、海外の構成管理の実装を全社的に計画するエグゼクティブスポンサーが議長を務める必要があります。
専門家のヒント：構成管理チームを集中させ、他のサポートの問題にとらわれないようにします。これを確立するための優れた方法は、構成管理チームのメンバーが他のプロセスチームと比較してどのような役割を果たしているかを示すRACチャートを使用することです。サポート機能。
ガバナンスの実装
このチームの一員として、ServiceNow のお客様は構成制御ボード (CCB) を形成します。CCB は、構成管理計画および関連するすべての構成管理アクティビティーに対する指示アクションおよび変更を監督します。
CCBは、構成管理の取り組みに対して常に良い価値提案があることを確認するための運営委員会として機能します。CCBは不可欠であり、価値提案の観点から構成管理プロジェクトを軌道に乗せ、会社にとって有効であり続けるために存在します。
CCBの投票メンバーは、ビジネスの戦略的イニシアチブに直接責任を負い、使用事例を理解するための日々のインフラサポートチームの取り組みに十分近いリーダーシップチームメンバーであるべきです。
CCB レビューを引き起こす可能性のあるイベントの例を次に示します。
- 新しい CI クラスの許可
- CM プランに対する変更の承認
- 主な変更点
- アーキテクチャ、セキュリティ、プロジェクト管理、ビジネス継続性プランニング/災害復旧、内部監査など、他のプロセスとの関係の変化
- 構成管理目標の設定、その他の企業目標への調整・調整
- 構成管理のメトリックとスコアカードのレビュー
- 構成管理に関連するインシデントまたは問題のレビュー
Q.構成管理プロセスの信頼性と信頼を長期的に生み出すのに役立つ方法は、次のうちどれですか。
- 経営幹部から早期バイインを取得する
- CIクラスのオーナーに成功の概要を提供してもらいます
- 日常のサポート機能も担当するチームを作成する
- CMDBが実装され、価値があることが証明された後、経営幹部からバイインを取得します
A.1
構成計画の設計
構成項目を使用して CMDB を設計する際には、小規模で開始し、徐々に成長します。ステージ 1 で定義されたユース ケースに関連付ける、C と属性のみを追跡します。
経験則として、CI クラス、CI、または CI 属性がサポートされるか、報告されるか、またはガバナンスが追跡に必要かどうかを判断するのが適切です。そうでない場合は、追跡しないでください。
多くの場合、CMDBで見つかったデータは、「何をすべきか」ではなく、「何ができるか」に基づいています。関係者からのレポート要件は、効果的なリポジトリ内で「何をすべきか」を特定します。しかし、レポート要件は、CMDB設計と継続的な評価の重要な側面になります。
今日、どのデータが重要であるかを判断します。効果的な構成管理は、値ベースのレポートで構成されます。レポート要件は、CMDBのデータ検出および保存要件を促進します。利害関係者のニーズを理解することは、効果的な CMDB の重要なデータ要素を開発するのに役立ちます。
サービスナウ CMDB の機能
時間をかけて、ServiceNow CMDB とその機能 (CI クラス、CI クラスマネージャー、識別規則と調整ルールなど) について理解してください。
ServiceNow Discovery、サービス マッピング、クラウド検出、REST 統合、サードパーティの検出ツールなど、すべての包括的なシステムおよびデータ フィードの CMDB の設計オプションと、すべての包括的なエコシステムについて理解を深めます。
CMDB には、構成アイテム (API)、その属性、および CMDB を適切に管理するために分類する必要がある関係が設定されます。プロセスを開始する際には、小さく始めて徐々に成長することが重要であることを覚えておいてください。重複を生成しない、API の設定と更新のプロセスを構築します。ベースライン ServiceNow 識別規則はかなり堅牢で拡張性に優れていますが、特定のエンタープライズ インフラストラクチャとアプリケーション、および検出時に適切に収集される属性に基づいて調整が必要になる場合があります。識別ルールの仕組みをしっかりと把握し、収集されたデータと属性を理解することは、CMDBの重複を防ぐのに大いに役立ちます。
CI クラス
ServiceNow では、ベースライン インスタンスで既に定義されている CI クラスから始めることをお勧めします。これらの CI クラスは、何千もの ServiceNow のお客様によって審査されており、企業が必要とする属性のほとんどを含める必要があります( すべてではない場合)、ほとんどの属性を含める必要があります。
ServiceNow のお客様は、次の C を分類します。
- ウィンドウズサーバー
- Linux サーバー
- ファイアウォール
- ロード バランサー
- データベース
- ネットワーク ルーター
- スイッチネットワーク
- ストレージ
- アプリケーション サーバー
設計段階で質問をする必要があります。
cmdb クラスには、IT 部門、設備機能 C、または他の部門の C かどうかに関係なく、ServiceNow 内のすべての CI に適用される可能性のある属性があります。 cmdb_ciクラスは、IP アドレスや DNS ドメインなどの IT CI に固有の情報を追加することによって、基本クラス cmdb を拡張します。
CMDB調整エンジンを構成する特定のモジュールを確認する前に、CMDBで更新を実行するために、ハードウェアスキーマをしっかりと理解している必要があります。 CMDBがどのように設定されているかを理解する必要があります。これはCMDBのサンプルスキーマです。右端には、基本構成アイテムまたはCMDBと呼ばれるテーブルがあります。基本的に、これは、CMDBにあるすべてのレコードのベーステーブルと呼ばれるものです。そのテーブルから拡張されたのは、cmdb_ciと呼ばれるテーブルです。基本的に、ハードウェアまたはアプリケーションと見なされるものはすべて、このテーブルcmdb_ciから拡張されます。そこから、ハードウェアに焦点を当てたCMDBの別のスライスがあります。ハードウェアまたはルーターやスイッチなどのデバイス、Windows Serverはこれらすべてのタイプのものをプリンターしますが、これらすべてのタイプのデバイスをこのテーブル内に格納するわけではないため、拡張テーブルを作成し、右から左に移動すると次のようになります。独自のテーブルで特定のタイプのデバイスを定義できる拡張テーブルと呼ばれるもの。したがって、ハードウェアから、コンピュータと呼ばれる別のテーブルに拡張し、そこからサーバーと呼ばれる別のテーブルを拡張して、すべてのサーバーレコードを実際にそのテーブル内で定義できるようにします。さらに、左端にあるように、さらに拡張されたテーブルを定義することもできます。ネットウェアサーバーとして。これは、最近ではあまり目立たなかったNetwareを知っている人にとっては古代の表です。
ハードウェアスキーマを見ると、アプリケーションスキーマと呼ばれるものもあります。もう一度右端を見ると、前のスライドであるCMDBでおなじみの表が表示されています。それから拡張されて、cmdb_ci_applと呼ばれる、またはアプリケーションの略称であると考えることができる別個のスライスまたは別個のブランチがあります。
Cmdb_ci_applから拡張されるものはすべて、アプリケーション固有です。すべてが1つのテーブルに存在することを示すアプリケーションはありません。サーバー、ルーター、スイッチ、プリンターと同様に、cmdb_ci_applに常駐できる独自の拡張テーブルがあります。この例では、cmdb_ci_app_server、次にcmdb_ci_app_server_tomcatという別の拡張テーブルがあります。
それぞれがよりきめ細かくなり、アプリケーションを特定のクラスに制御またはスライスできるようになります。これも、右側のテーブルが左側にあるものの親テーブルであり、前述のように、単語テーブルがCIタイプまたはクラスと互換的に使用できます。したがって、ここで見ているのは、アプリケーションに関するCIタイプであるか、クラスと呼ばれることがあります。
CI クラスマネージャ
CI クラスごとに、サポートと維持に関心がある場合は、CMDB が正しく設定されていることを確認することが重要です。CI クラス・マネージャーを使用して、各 CI クラスの属性、識別規則、および関係を構成できます。さらに、CI クラス マネージャーは、CI クラスに関するすべての必要な情報を表示するワンストップ ショップを提供します。
CI クラスマネージャーに移動する方法、特定のクラスを検索する方法、および特定のクラスの詳細を表示する方法を理解するには、次の各タブをクリックします。
フィルター ナビゲータから CI クラス マネージャーを検索します。次に、[階層] をクリックして CI クラスを検索します。
「CI クラスの検索」フィールドに、CI クラスを入力します。
CI クラスを定義する際には、データのデータの設定方法と保守方法を計画する必要があります。ServiceNow は、CMDB でデータを収集、設定、マップ、および維持するための 2 つの自動化されたソリューションである探索とサービス マッピングを提供します。
サービスナウディスカバリー
企業が ServiceNow Discovery を使用して検出プロセスを自動化することを決定した場合、検出はすべてのロード バランサー、ネットワーク デバイス、サーバー、仮想デバイス、アプリケーション、およびリレーションシップを検出し、CMDB での CA の作成と自動メンテナンスを容易にします。
検出スケジュールを作成して、すべてのサーバ、ネットワーク デバイス、アプリケーションを自動的に再検出し、エンタープライズ環境でサポートされている最新の状態の CI を維持できます。
Example of CIs discovered by ServiceNow Discovery (Horizontal Discovery)
Discoveryは、ネットワーク上のアプリケーションとデバイス、およびオペレーティングシステム、ソフトウェア、メモリなどのそれらのデバイスの重要な属性を検出し、検出した情報で構成管理データベースまたはCMDBを更新します。ディスカバリーは、ネットワーク上のデバイスを検出するため、いわゆる水平ディスカバリーを提供しますが、特定のビジネスサービス（最近ではアプリケーションサービスとして知られている）の一部である構成アイテムまたはCI間の関係を描画しません。
サービスマッピング
サービスと依存関係のマップにより、CI が重要なサービスをサポートしている場合に、インシデント、問題、変更などのサービス管理プロセスをサポートするチーム メンバーが可視性を得られるようにします。
たとえば、ディスク ドライブの損失によりデータベース インスタンスがダウンし、HR 部門が新しい従業員の機器を注文するために使用する要求サービスに影響を与える場合があります。
ServiceNow サービス マッピングは、検出された API 間の関係と依存関係を検出してモデル化し、この情報を自動的に CMDB に取り込みます。
Example of CIs and their relationships discovered by ServiceNow Service Mapping (Top-down Discovery)
サービスマッピングは、ディスカバリーを補完する機能を提供します。トップダウンマッピングを使用して、電子メールサービスなどの組織内のサービスの一部であるCIを検索してマッピングします。この方法では、サービスの提供に使用されるすべてのCIを視覚化できます。
サービスナウディスカバリとサービスマッピング
水平検出とも呼ばれる ServiceNow ディスカバリと、トップダウン探索とも呼ばれるサービス マッピングは、次のように異なります。
サービスナウディスカバリには、次の機能があります。
- 役に立つかどうかにかかわらず、すべてを見つけます。
- IP アドレス範囲内にあるすべてのデバイスを識別し、資産管理イニシアチブのインベントリの観点からすべての IT デバイスに対応する上で非常に優れています。
- 有効なユース ケースには、インベントリ、ソフトウェア ライセンス、CMDB の作成、実際の状態データを提供する必要な状態の検証、インシデント、問題、および変更をサポートする依存関係 CI 関係マッピングが含まれます。
サービス マッピングには、次の機能があります。
- サービスを構成する API を検出し、それ以外のすべてを無視します。
- CMDB をサービスに対応させることができます。
- 有効な用途としては、アプリケーション サービス全体またはそのセグメントの移行の計画、変更が CI に与える影響の特定、高可用性と継続性に関するアプリケーション サービスの分析、影響を受けるサービスまたはダウンしたサービスのトラブルシューティングの合理化などが含まれます。
ナレッジチェック
Q.次の要件を満たす CI または CI 属性のみを追跡しますか?(該当するすべてのものを選択)
- サポートされます
- 報告されます
- いくつかのガバナンスのために追跡する必要があります
- 検出ツールで収集可能
A.1,2,3
次の例を見る:
- CIクラス
- CI クラスマネージャ
- 識別規則と調整ルール
- 発見
- サービスマッピング
---
- CMDB テーブル/クラスを管理および作成するための一元的な場所です。
- 共通の属性を共有する一連の C を表すテーブルについて説明します。
- 異なるデータからデータを識別し、調整するための一元化されたフレームワークを提供します。
- インフラストラクチャとアプリケーションの検出を自動化
- サービスを構成する、C とそれらの関係の検出を自動化します。
A.
1-2
2-1
3-3
4-4
5-5
サーバー クラスは、次のどれによって説明するのが最も良いですか。(該当するすべてのものを選択)
- ハードウェア クラスへの親クラス
- コンピュータ クラスから拡張
- Linux サーバー クラスの子クラス
- 親クラス->Windows サーバー クラス
A.2,4
ベースラインインスタンスで提供される CI クラスは、次のうちどれですか。(該当するすべてのものを選択)
- スイッチ
- ウィンドウズサーバー
- データベース
- ウェブサーバー
- Cisco 7604 ルータ
- Cisco ASA 5505 ファイアウォール
A.1,2,3,4
他のステークホルダーに価値を示す
構成管理は、サービス、アプリケーション、基盤となる IT インフラストラクチャ、および組織全体が活用できるその他の重要な資産クラスをモデル化する、単一の共通の表現を提供します。
CMDBを考える1つの方法は、組織全体の意思決定支援システムであり、戦略的、戦術的、状況的な意思決定を支援するためのデータを提供することです。
付加価値はITサービス管理をはるかに超える可能性があります。監査、コンプライアンス、顧客サービス、施設、法務、人事など、他の多くのビジネス分野に真の価値があります。製品やサービスの実行に関する洞察と、製品やサービスの設計、実装、および実行方法を説明する情報は、製品やサービスを管理および提供するための比類のないメカニズムを提供します。
多くの場合、優先順位についていくつかの異なる意見がありますが、これは一般的に最終的な目標に明確なアライメントによって克服されます。関係者が連携し、関与しなければ、構成管理の取り組みは苦戦し、最終的には失敗する可能性があります。文書化された将来の状態ロードマップは、構成管理機能の長期的なビジョンを伝え、実装への段階的なアプローチを社会化するのに役立つツールです。
多くの場合、優先順位についていくつかの異なる意見がありますが、これは一般的に最終的な目標に明確なアライメントによって克服されます。関係者が連携し、関与しなければ、構成管理の取り組みは苦戦し、最終的には失敗する可能性があります。文書化された将来の状態ロードマップは、構成管理機能の長期的なビジョンを伝え、実装への段階的なアプローチを社会化するのに役立つツールです。
ビジネス・プロセスを統合する場合は、常に元の目標に結び付け、CMDBへの変更について積極的にコミュニケーションを取るようにしてください。そうすることで、CMDBは組織全体にとって貴重な資産となります。
CMDBをビジネスプロセスと統合し、それがプロジェクトにどのように役立つかを示すことは、ビジネスの利害関係者からのサポートと賛同を得て、構成管理と連携するための重要な部分です。
通常、4つ、資産管理、プロジェクト管理、情報セキュリティ、およびインシデント管理があります。資産管理チームは、要求、承認、注文、および受領を追跡することにより、資産に関する正確な財務情報を保持します。 CMDBは、資産の場所とステータスを追跡することで、このチームに即座に価値を示すことができます。プロジェクト管理チームは、ITインフラストラクチャ資産の正確なアカウントを維持して、新しいプロジェクトを開始したり、資金を調達したりして、CMDBがデバイスのアプリケーションとサービス、およびそれらの使用率情報を明確に可視化することで価値を示すことができるようにしたいと考えています。セキュリティは、問題の発見と仲介に重点を置いています。 CMDBは、インシデントが発生した場合にこれらの脆弱性によって最も影響を受ける重要なサービスを特定するのに役立つことで、それらに価値を示すことができます。どのサービスがリスクにさらされているのか、優先度の高い修復作業をどこに向ける必要があるのかを正確に知ることができます。インシデント管理は、サービスデスクの準備を改善するよう努めています。これにより、サービスデスクチームはインシデントの根本原因をより効率的に見つけることができます。サービスへの影響を追跡し、解決策で修復することで、これらのビジネスプロセスからの変更要求を構成制御で簡単に管理できることを覚えておいてください。
ServiceNow CMDBダッシュボードは、CMDB全体の状態を、主要なビジネスプロセスに関与する組織のメンバーだけでなくすべての利害関係者に表示します。ステータスの更新を共有したり、SLAを追跡したり、継続的な改善を監視したり、データ品質を監視したりできます。 CMDBの状態を追跡する際に考慮すべき3つのメトリックがあります。完全性はCIクラスマネージャーに入力される必要のある推奨フィールドのステータスを測定し、コンプライアンスはCMDBの事前定義された証明書への準拠を測定し、正確性は識別のための事前定義されたデータルールの整合性を測定します、孤立、および古いCISにより、CMDBへの変更の追跡と伝達がより効率的になります。
ヘルスダッシュボードはこれらのメトリックを集約して、CMDBの全体的なパフォーマンスを示します。
専門家のヒント：構成管理と他のガバナンスメカニズムとの関係を文書化して、ビジネス目標でCMDBによって提供される価値の間に明確な見通しを提供するようにしてください。
以前に設定した目標と目標に戻って、組織内の他の部門に価値を示します。他の人への価値は、戦略的なビジネスドライバーから次の場所に提供される見通しの高さです。
- 顧客に提供されるサービス
- サービスの提供に使用されるテクノロジ
- 実際に使用される運用インフラストラクチャ
- サービスの総コスト
資産管理、インシデント管理などの主要なビジネス・プロセスとの統合から始めます。ServiceNow が内部的に他の組織に価値を示している方法の詳細については、Usman Sindhu - プロダクト マーケティング マネージャーに耳を傾ける時間を取ります。
基本的な構造が整ったので、今度は他の組織に価値を提供します。これは非常に重要です。構成管理のプラクティスを描くと、それらが制御できないシステムとビジネスプロセスであることがわかるため、貢献する必要のある上位のビジネスプロセスを実際に確認する必要があります。あなたに依存しています。多くの場合、顧客は、資産管理、プロジェクト管理、セキュリティ、インシデント管理などの強制的なテンプレートから始めることができます。これらは、お客様が最初に目にする一般的なものの一部です。次に、あなたが理解する必要があるのは、彼らが何を気にかけているのか、彼らの目的は何か、そしてあなたが彼らに提供できる価値は何かです。それでは、情報セキュリティの簡単な例を見てみましょう。セキュリティのために、彼らはデータ侵害の管理に関心を持っています。これは、侵害を防止し、技術的には侵害が発生した場合に、可能な限り最小限の損害でシステムを復旧させる方法を示しています。現在、システムで作業して元に戻すと、これらのシステムのタブである重要なサービスを可視化できない可能性があるため、CMDBは、影響を受ける重要なサービスについての情報を提供できる場所の1つです。セキュリティチームは、これらの重要なサービスシステムと重要でないサービスシステムで作業できます。これで、非常に迅速に情報セキュリティチームに価値を提供し、優れた関係を構築し、構成管理計画のCMDBを非常に信頼できるものにしました。
CMDBの利点
ServiceNow ITは、独自の世界クラスの製品を実装するだけでなく、実装する製品の価値を実現することで恩恵を受けています。NOW ON NOWのイニシアチブには、ServiceNowのディスカバリ、サービスマッピング、イベント管理と共にServiceNow CMDBの実装が含まれており、ServiceNow全体で他の多くの主要な利害関係者に迅速に価値をもたらしました。
ServiceNow は、すべての既知のアプリケーションとサービスがマップされ、最新の状態になっている 30 以上のグローバル IT サービスを CMDB にマッピングし、設定しました。
ServiceNowは、正確かつ認定されたCMDBを備え、グローバルエコシステムを正確に表現し、リクエスト、インシデント、問題、変更、可用性、コスト、特にサービスの中断など、あらゆる種類のチケットをサポートする機能を備えています。
そして、異なる視点と一連のユースケースについては、ここでは外観が異なります。したがって、誰もが行っているクラウド移行では、ディスカバリークラウドオーケストレーション通知を設定して、CMDBに通知し、CMDBを自動的に更新する外部クラウドサービスとインフラストラクチャを管理できます。クラウドの移行でできるもう1つの方法は、プロビジョニング時にアプリケーションサービスIDを要求し、クラウドでプロビジョニングされたリソースにこれらのIDをタグ付けすることです。サービスマップ上のタグを自動的にスキャンし、監視し、NOCで、サービス信頼性チームで監視イベントをCIに関連付け、イベント管理ダッシュボードと情報セキュリティを確認して、すべてのグローバルサービスユーザーにサービスを提供します。セキュリティチームはCMDBを使用して、ホームの脆弱性が存在する場所と、企業データを保護する必要がある場所を特定します。これらはすべて、顧客にサービスを提供するためにCMDBに依存しています
この研修に参加していただきありがとうございます。
このコースでは、ユースケースにマッピングされた明確な目標を記述する方法、チームを構築する方法、CMDBが価値を提供する計画を設計する方法、目標と目標を元に戻すことによって他の関係者に価値を示す方法など、CMDBの導入を成功させるための段階を確認しました。
----
CMDB の設定
CMDB の実装時に実証済みのツールとプロセスを活用することで、CMDB の整合性を維持できます。これらのツールの 1 つは CI クラス マネージャーで、基本クラス定義を作成または編集するための中心的なビューであり、識別、調整、CMDB Health のクラス設定です。
これらのプロセスの 1 つに、さまざまなデータ ソースのデータを識別および調整するための集中フレームワークを提供する識別と調整モジュールがあります。検出、インポート セット、サード パーティの検出ツールなどの複数のデータ ソースが CMDB を設定し、CI レコードを作成および更新する場合に CMDB の整合性を維持するのに役立ちます。
複数のソースを使用すると、重複レコードを介して不整合が発生するリスクが高くなります。識別と調整は、CI レコードの重複の防止、CI 属性の調整、CI の再分類、および権限のあるデータ・ソースのみが CMDB を更新するのを防ぐのに役立ちます。
このコースでは、CMDB の設定と実装に関するベスト プラクティスについて説明します。
目標
- ヘルススキャンの役割を含む、CMDB の設定と実装に関するベスト プラクティスを確認する
- CI クラス マネージャが CI クラスを作成および編集するための集中管理の場所を提供する方法を説明します。
- 異なるデータ ソースのデータを識別および調整するための識別および調整フレームワークを活用する
- 重複または過負荷の状態を避けるためにルールが必要な時期、および信頼できるデータ ソースを特定する
実装のベスト プラクティス
ヘルススキャンは、CMDB が最高の状態で実行されていることを確認します。この評価を実施することは、実装を成功させるための重要な部分です。
ServiceNow の Healthscan は、インスタンスの主要な領域を確認し、将来のアップグレード、ユーザー エクスペリエンス、パフォーマンス、セキュリティ、管理性を向上させる方法についての提案とガイダンスを提供する正常性の「全身」評価です。
HealthScan は、割り当てられた ServiceNow プロフェッショナル サービス チームと共に ServiceNow の実装中に使用して、実装がうまく行われるようにすることができます。
割り当てられたソリューションコンサルタントと協力して、インスタンスで HealthScan をリクエストできます。 HealthScan が提供する内容よりも詳細な情報が必要な場合は、プロフェッショナル サービスエグゼクティブまたはカスタマーサクセス チームを通じて ServiceNow 構成のレビューをリクエストできます。
HealthScan は、ServiceNow の開発チーム、サポート、プロフェッショナル サービス チームのベスト プラクティスに基づいて構築された定義と一致しない構成を検索してインスタンスをスキャンします。
HealthScan スコアカード結果ダッシュボードには、インスタンスの正常性に関するデータが表示され、高レベルの概要と傾向が提供されます。
パーセンテージは、主要な領域におけるインスタンスの正常性を示します。データは、プラットフォームの正常性を改善するために注意を集中する場所を示すために、製品スイートごとに分類されます。
ServiceNowプラットフォームは高度に構成可能であり、ビジネス目標に合わせてカスタマイズできます。最高のユーザーエクスペリエンスを提供し、プラットフォームを最大限に活用できるように、ServiceNowはServiceNowHealthscanと呼ばれる自動化ツールを開発しました。 ServiceNow Healthscanはインスタンスをすばやくスキャンし、プラットフォームの最適化と技術的負債の排除に関する推奨事項を提供します。今日私と一緒にいるのは、ツール製品マネージャーのマーティンウッドです。マーティン、ヘルススキャンについて教えてください。確かに、フランクに感謝します。 Healthscanには2つのステップがあります。まず、システムがインスタンスを分析します。何千もの展開からの経験で構築された何百ものベストプラクティスkpiのライブラリがあり、さらに多くが常に作成されています。スキャンは迅速で、完了するまでに約10分かかります。 2番目のステップは、自動化された洞察を提供するために、一連のスコアリングメカニズムを通じてそのデータを詳細に分析することです。 Healthscanスコアカード。この情報はダッシュボードに表示され、情報の概要がわかります。詳細が必要な場合は、ServiceNow構成レビューで、このスマートな自動チェックとヒューマンインテリジェンスを組み合わせて、完全に詳細なレポートを提供します。さて、Healthscanスコアカードに戻りましょう。これは、改善の余地がある場所を示しています。それで、それがどのように見えるかを私に見せてもらえますか？絶対に。スコアカードは、インスタンスの状態のビューを提供する主要なメトリックに焦点を当てています。必要に応じてクレジットスコア。パーセンテージは、インスタンスの状態を主要な領域に分類して示しています。ここでは、セキュリティ、使いやすさ、パフォーマンス、管理のしやすさ、およびアップグレードのしやすさのスコアを確認できます。これらは、これらの領域におけるServiceNowのベストプラクティスとの整合性を示しています。トップラインの数字は製品スイートごとに分類されており、どこに注意を向けるべきかがわかります。トレンドチャートには、時間の経過に伴うスコアが表示されます。悪化していると思います。ここでは、スコアは過去数か月にわたって安定しています。数字を改善する方法や、どこでうまくやっているのか知りたいですか？クリックして結果に関する具体的なフィードバックを取得し、どのアクションがスコアを向上させるかを理解できるようにします。ここには豊富なデータポイントがたくさんありますが、さらに詳細な情報が必要な場合はどうすればよいですか？彼らがそこで私を助けることができる何かがありますか？絶対に。 ServiceNow構成レビューは、ServiceNowHealthscanを利用しています。構成レビューは、自動チェックの速度と効率をServiceNowエキスパートコンサルタントのヒューマンインテリジェンスと組み合わせたインスタンスの詳細なレビューです。インスタンスのすべての部分の包括的なレビューを実行するように設計されており、潜在的な懸念事項を特定する詳細なレポートを提供します。このレビューは、インスタンスの技術的およびコードベースの部分であるだけでなく、ユーザーインターフェイスとユーザーが得られるエクスペリエンスでもあります。アップグレードの準備ができているだけでなく、プロセスのパフォーマンスを最適化するのに役立ちます。ここでは、レポート出力の詳細レベルを確認できます。 2は、インスタンスの状態の概要を示す高レベルのステータスの概要だけでなく、主要なベストプラクティスのkpiに関する情報も取得します。これは、インスタンスの状態を最適化するためのアクションアイテムを含む一連の詳細な推奨事項によってバックアップされます。それで、Healthscanにあるベストプラクティスの定義を使用して、実装を行うときに最初から役立つことができますか？絶対に。 ServiceNowのカスタマーサクセスチームとプロフェッショナルサービスチームは、Healthscanを使用して実装がうまくいくことを保証します。ここでは、一般的なミスステップを回避するために使用するツールの1つを確認できます。 Healthscanスプリントスキャンは、潜在的に懸念される領域の調査結果に関するものです。ここでは、各スキャンが以前の上位の数値とどのように比較できるかを確認できます。14の新しい結果と57が解決され、トレンドチャートを使用して時間の経過とともに状況がどのように行われているかを確認できます。顧客が最近行ったいくつかの良い仕事のためにトレンドが下がっていて、全体的にかなり良いです。この情報により、実装チームはベストプラクティスのラインに集中し、カスタマイズを減らすことができます。 Healthscanには、自動コードレビューなどの他の機能もあります。これにより、開発チームに直接、迅速で効果的なフィードバックが提供されます。毎日実行され、インスタンスの状態を改善するのに役立つ実用的な情報を電子メールで提供します。したがって、Healthscanには多くの優れた機能がありますが、これが顧客の推進に役立つ可能性のある最終的なビジネス結果を顧客に伝えることができるかもしれません。承知しました。私たちはこれを、より迅速にアップグレードするために技術的負債を削減している1人の顧客に使用しています。目標は、以前は6か月のアップグレードであったものを1つだけに変えることです。 1つだけ、それは速いです。では、お客様はHealthScanをどのように活用しているのでしょうか。最初のステップは、ソリューションコンサルタントと協力して、Healthscanスコアカードを使用してインスタンスを高レベルで分析することです。これはあなたに概要を与えます
次に、HealthScan によってレビューされた主要なベストプラクティスの一部を確認して、CMDB が最高の状態で実行されるようにしましょう。
CMDB の主要な実装のベスト プラクティス
CMDB ヘルスダッシュボードを有効にする
デフォルトでは、CMDB ヘルスダッシュボードジョブは無効になっています。CMDB の正常性の監視と維持は不可欠です。重複した CI、必須 CI フィールド、監査などの正常性インジケーターは、CMDB の全体的な正常性の計算に役立つ。
推奨事項: データを収集および集計する各 CMDB 正常性 KPI に対応するジョブを有効にして構成します。これらのジョブには、CMDB ヘルス ダッシュボード ジョブ タブからアクセスできます。 スケジュールされたジョブを定期的なスケジュールで実行するように構成することも、いつでも実行することもできます。
サービスに付属する CI クラスを可能な限り活用
ベースラインの経験をスムーズにするため、製品に付属する CI クラスを利用することをお勧めします。
推奨事項: ServiceNow でベースラインとして提供される CI クラスを利用します。 また、CMDB_CIを延長しないこともベスト プラクティスです。
CMDB 属性は適切なレベルに配置する必要があります。
属性は CMDB 階層内でできるだけ高く配置する必要があります。例えば、サーバークラスで属性を定義するのではなく、Windows、Linux、およびUnixクラスで3つの別々の「保証期間」属性を定義します。
推奨事項: 同じかそれ以下の別々のテーブルに定義された複数の属性は、階層の上位のテーブルで 1 回だけ定義する必要があります。この例では、この子クラスがこの属性を継承できるように、この属性を Server Class に追加するのが理にかなっています。
ツリー ピッカーは、選択する場所の値のフィルター処理されたリストを提供するために使用される特別な参照参照です。
推奨事項: エンド ユーザーが重複する可能性のある場所やスペルミスのある場所を入力するのではなく、ツリー ピッカーを使用します。
カスタム CMDB テーブルは 'u_cmdb_ci' で始まります
カスタム CMDB テーブルは、CMDB の一部として簡単に識別できるように、「u_cmdb_ci」で始まる必要があります。
推奨事項: 新しいクラスを作成する際に、テーブル名が 'u_cmdb_ci' で始まるようにしてください。
リレーションシップ エディタで [提案されたリレーションシップ] のみを表示する
リレーションシップ エディタでは、すべてのリレーションシップが既定で表示されます。これにより、ユーザーが間違った関係の種類を選択する可能性があるため、ユーザー エクスペリエンスに悪影響を及ぼす可能性があります。
推奨事項: sys_property glide.cmdb.suggested_relationship.enabled は 「false」に設定する必要があります。2 つのクラス間の有効なリレーションシップの種類がすべて [推奨されるリレーションシップ] として表示されていることを確認し、glide.cmdb.suggested_relationship.enabled = true を設定します。これにより、ユーザーがクラス間の無効な関係を作成することがなくなり、より信頼できる CMDB を作成できます。
提案された関係
提案された関係を定義すると、CMDB の信頼を維持するのに役立ちます。 ベスト プラクティスに従うには、次の手順を実行する必要があります。
1. sys_propertiesで glide.cmdb.suggested_relationship.enabled を 「true」に設定
2. 推奨されるリレーションシップ エディタを使用して、クラスの有効な関係を定義します。
システム プロパティを設定して CMDB レポートの結合の影響を制限する
推奨事項: データベース エンジンは、通常、複数の結合を非常に適切に処理します。リレーショナル モデルでは、結合が安価で効率的であると仮定しており、これは通常当てはまります。ただし、非常に大きな結合によってデータベースのパフォーマンスの問題が発生することはほとんどありません。
この潜在的な複雑さを軽減するには、次のプロパティを使用して結合の複雑さとサイズを制限します。
システム プロパティ システムに移動し、次の説明を含むプロパティを見つけます。
クエリごとのデータベース結合の最大数。
値が小さいほど、システムは複雑でないクエリの数を増やします。
値を大きくすると、クエリの数が減り、クエリごとに複雑さが増します。
関係を変更しないでください
リレーションシップ (テーブル cmdb_rel_type) は、常にベースラインまたは標準外の状態に保つ必要があります。変更すると、検出が中断され、エラーが発生する可能性があります。
インスタンスで定義された関係を表示するには、「cmdb_rel_type.list」に移動します。 CI リレーションシップタイプ テーブルが表示されます。
カスタマイズを避ける - 属性は、カスタム属性を使用して再作成するのではなく、ボックス外の属性を活用する必要があります。
属性は、ベースラインを再作成するのではなく、ベースラインを活用する必要があります。
アプリケーションには、ビジネス所有者が割り当てられている必要があります。
ビジネス所有者が各ビジネス アプリケーションに割り当てられていることを確認します。
左側の項目と右側の関連情報を一致させる
アプリケーションは常にこの定義を持つ必要があります
- カスタム属性を作成する代わりに基本システム属性を利用する必要がある
- 次の操作を行うことで、提案された関係のみを表示します。
- CMDB ヘルス ダッシュボード ジョブ
- 場所フィールドでツリー ピッカーを使用して、次の操作を行います。
- 別のテーブルで使用される属性は、どこに定義する必要がありますか?
- カスタム CMDB テーブルは、次の項目で始まる必要があります。
- 変更すると検出が中断され、エラーが発生する可能性があります。
- デフォルトでは 「無効」であり、「有効」である必要があります。
- 別のテーブルではなく階層の上位にあるテーブル
- 重複する場所やスペルミスを防ぐ
- u_cmdb_ci
- 設定sys_property glide.cmdb.suggested_relationship.enabled は 'false' に設定する必要があります
- 事業主
- ユーザーとグループ
- 関係
CI クラスマネージャ
ServiceNow は非常に柔軟性が高く、テーブル、識別ルール、リレーションシップ、および CMDB 正常性定義を構成する方法を提供する個々のモジュールを備えています。従来、管理者はこれらの各モジュールに個別にアクセスする必要がありましたが、これらの構成を行う場所を正確に覚えておくのは困難でした。
CI クラス マネージャは、これらすべてをまとめて、CMDB クラス階層をツリービュー形式で表示する一元的な場所を提供し、クラス定義とクラス設定を表示または編集して識別規則、調整ルール、CMDB Health を表示または編集します。
このレッスンでは、CI クラスマネージャのさまざまなセクションとタブとその機能について説明します。
CI クラスマネージャ
[基本情報] タブでは、表示名、テーブル名、拡張フラグの設定、クラスへのアイコンの関連付けなどの基本的な詳細を表示または構成する場所を提供します。
カスタム テーブルを作成すると、名前に自動的にプレフィックスが付き、u_cmdb_ci_の後に表示名が付きます。
例: u_cmdb_ci_my_custom_web_server_class
拡張可能フラグの選択は、クラスを別のクラスで拡張できるかどうかを示します。
以下は、Apache Web サーバー クラスの任意の ServiceNow インスタンス内のデフォルトテーブル availabe の例です。
[属性] タブでは、新しいクラス属性を表示または作成できます。
属性の起点を識別するための 3 つのフィルターがあります。
すべて(すべての属性 - 追加および派生)
派生 (親クラスから派生した属性)
追加 (このクラスに直接追加された属性)
属性の起点を識別するための 3 つのフィルターがあります。
すべて(すべての属性 - 追加および派生)
派生 (親クラスから派生した属性)
追加 (このクラスに直接追加された属性)
CIクラスマネージャーを見てみましょう。フィルタナビゲータに移動し、[構成]で[CIクラスマネージャ]と入力して、[CIクラスマネージャ]を選択します。 CIクラスマネージャーは、識別および調整ルールの関係とともに更新CIクラスを作成し、CMDBヘルス設定を構成するために使用されます。 [階層]ボタンを選択すると、CMDBクラス階層全体が読み込まれます。クラス定義を中央の場所に統合すると、[CIクラスの検索]ボックスを使用して、CIクラスをフィルター処理および検索できます。たとえば、WebサーバーのすべてのCIクラスを検索するWebサーバーCIクラスを検索できます。これらは、見つかった一致です。そうすると、先に進んでWebサーバーを選択します。すぐにわかるのは、トップレベルから開始することです。ルートノードは構成アイテムクラスであり、アプリケーションの子とインフラストラクチャサービスの子クラスがあります。 Webサーバーはインフラストラクチャサービスに分類されます。さまざまなクラスのそれぞれに加えて括弧内の数字を見ると、Webサーバーに関連付けられているCIの数がわかります。これは、19 CIとしてリストされています。つまり、Webサーバークラスまたはその子クラスの1つに19のCIがあります。 ApacheWebサーバーには3つのCIがあります。iPlanetWebサーバーには1つ、Microsoft IIS Webサーバーには6つのCIがあります。ApacheWebサーバークラスを選択すると、構成方法の詳細を表示できます。左側のペインには、基本的な情報属性、識別ルール、依存関係、調整ルール、推奨される関係、すべての関係ルール、ヘルス設定、およびApacheWebサーバーと子クラス内のすべてのCIを含むいくつかのタブが表示されます。表示名（この場合はApache Webサーバー）に入力する新しいクラスを作成するときの[基本情報]タブから始めて、テーブル名が自動的に入力されます。この場合、cmdb_ci_apache_web_serverがテーブル名の先頭に追加されます。この場合はWebサーバーです。これは、アイコンをクリックしてそのクラスに適切なアイコンを選択することにより、変更または修正できます。この場合、すでに選択されているWebサーバーで、拡張可能フィールドをチェックすると、クラスを拡張できることが示されます。つまり、子CIクラスはこのクラスから作成でき、このクラスから属性を継承します。 [属性]タブには、このCIクラスで使用できるすべての属性のリストが表示されます。 Allフィルタは、すべての親クラスからのすべての派生属性と、このクラスに直接追加された属性を表示します。Derivedフィルタは、親クラスから継承された属性のみを対象とし、次に追加されたものは、これに追加された属性のみを表示します。クラス。したがって、この場合、6つの属性があります。下部に新しい属性を追加する場合は、ダブルクリックして新しい行を挿入し、属性名または列名を入力します。この場合、Maxクライアントに入力します。列名は、「u」の下線で派生します。それはユーザー定義の属性だったと言います。型を型整数に変更し、最大長を40のままにします。
CI クラスマネージャ
各タブをクリックして、CI クラスマネージャーに含まれる詳細の一部を確認します。
識別規則と ID エントリは、識別および照合プロセスで使用され、一意に識別されます。
既定では、[識別規則] タブには、親クラスから派生した ID ルールと、定義済みの ID エントリが表示されます。
提供されている例では、識別規則は Apache Web サーバー クラスに固有であり、親クラスから派生したものでありません。 3 つの基準属性 (クラス、構成ファイル、バージョン) を含む 1 つの ID エントリが存在します。
既定では、[識別規則] タブには、親クラスから派生した ID ルールと、定義済みの ID エントリが表示されます。
提供されている例では、識別規則は Apache Web サーバー クラスに固有であり、親クラスから派生したものでありません。 3 つの基準属性 (クラス、構成ファイル、バージョン) を含む 1 つの ID エントリが存在します。
CI クラスのホスティングルールと包含化ルール (従属関係ルール) を作成して、ディスカバリおよびサービス・マッピング・プロセス中に依存 CI を正しく識別する際に役立ちます。
調整とは、CI テーブルおよび属性レベルで CMDB を更新する権限のあるデータソースのみを指定して CI 属性と CI 属性を調整するプロセスです。メモ 調整規則は、データ ソースによって CMDB レコードを作成できるため、レコードの作成には適用されません。調整ルールを設定すると、さまざまなデータ ソースのフリップ フロッピングによって、互いの値が更新され、構成マネージャーの制御が、どのデータ ソースが信頼できるソースであるかの制御を取得できなくなります。このプロセスは、調整ルールに依存します。
推奨されるリレーションシップは、定義するクラスのリレーションシップを構築するときに、どのリレーションシップが妥当かをユーザーが判断できるように構築されます。
たとえば、システムで次の関係タイプを考えてみます。
電源を供給する :: 電源を受け取る
で実行 :: ホスト
通常、ユーザーはこれらの関係を使用して、次のように 2 つの項目間の次の妥当な関係を定義します。
ラックは、サーバーに電力を供給します: ラックがサーバーに電力を供給したり、サーバーがラックから電力を受け取ったりすると、読み取ることができます。
データベースはサーバー上で実行されます: データベースがサーバー上で実行されている場合、またはサーバーがデータベースをホストしている間に読み取ることができます。
通常、次の定義はどちらも適切ではありません。
ラックはサーバー上で実行される
サーバーがデータベースで実行される
たとえば、システムで次の関係タイプを考えてみます。
電源を供給する :: 電源を受け取る
で実行 :: ホスト
通常、ユーザーはこれらの関係を使用して、次のように 2 つの項目間の次の妥当な関係を定義します。
ラックは、サーバーに電力を供給します: ラックがサーバーに電力を供給したり、サーバーがラックから電力を受け取ったりすると、読み取ることができます。
データベースはサーバー上で実行されます: データベースがサーバー上で実行されている場合、またはサーバーがデータベースをホストしている間に読み取ることができます。
通常、次の定義はどちらも適切ではありません。
ラックはサーバー上で実行される
サーバーがデータベースで実行される
次に、識別ルールを見てみましょう。識別ルールは、CMDB内のCIを一意に識別するために使用されます。識別ルールはCIクラスに適用され、単一のCI識別子と、特定の優先度を持つ一意の属性セットを定義する1つ以上の識別子エントリで構成されます。この例では、Apache Webサーバークラスに適用される識別ルールがあり、1つの識別子エントリがあります。識別子エントリを開くと、クラス、構成ファイル、バージョンの3つの基準属性で構成されていることがわかります。下部で、この選択で[null属性を許可する]が選択されていることに注目してください。基準属性の1つがヌルでない場合、一致を試みることができます。選択されていない場合、すべての属性に一致を試みる値が必要です。この場合、親ルールへのフォールバックを許可するも選択されています。これにより、この識別子エントリと一致するものが見つからない場合は、親CIクラス識別ルールに移動して、一致するものを見つけようとします。次に、依存関係を見てみましょう。依存関係ルールは、CMDB内の構成アイテム間の一貫性と有効性、およびモデリング関係を保証するために使用されます。これらのルールは、特定のCIタイプ間の関係タイプを防ぎます。 DiscoveryやServiceMappingなどのさまざまなアプリケーションは、Cis間の関係を作成します。各アプリケーションは、同じエンティティを表すために一貫性のない関係タイプを使用する可能性があり、その結果、同じCisの複数のビューが生成されます。依存関係ルールは、CIタイプのペア間の有効な関係タイプと有効な方向を定義し、CMDBで有効で一貫性のある関係を実現します。したがって、Apache Webサーバーの依存関係を見ると、Apache Webサーバーがハードウェア上で実行されており、これは親クラスのハードウェアから派生していることがわかります。それらの関係は、オーバーライドの依存関係をクリックすることで置き換えることができ、オーバーライドの依存関係内では、ルールタイプの2つの選択肢があります。 1つはホスティングルールです。ホスティングロールは1レベルの深さしかできないフラットなルールのセットであり、常に物理ハードウェアまたは仮想ハードウェアタイプのリソースが含まれます。ホスティングルールは、親CIタイプまたはhost：hostsなどの関係タイプと子CIタイプで構成されます。アプリケーションと呼ばれるCIタイプがハードウェアのCIタイプで実行されることを指定するホスティングルールを作成し、次にCIタイプの包含階層を表す包含ルールタイプを作成し、CIタイプに含めることができる有効なオブジェクトを記述することができます。 。サービス定義と、CIタイプに含めることができるオブジェクト。調整ルールを見てみましょう。調整ルールは、テーブルまたはCI属性のセットを更新することを許可されているデータソースを定義します。特定のテーブルに複数の調整ルールが定義されている可能性があることに注意してください。この場合、定義されている調整ルールは1つだけであり、それがデータソースサービスウォッチになります。これはこのクラスに適用されます。基本的に、これはデータソースが1つしかないことを意味します。このテーブルを更新します。ここでも、複数の調整ルールを設定できます。データ優先ルールは、複数の調整ルールが存在する場合に、テーブルの属性を更新するためにどのデータソースが優先されるかを定義するために使用されます。 2最後に、データ更新ルールは、データソースがCI属性を更新すると予想される頻度を定義します。CIが古くなっているか、データソースによって指定された頻度で更新されていない場合、優先度の低い承認済みデータソースがCI属性を更新できます。それでは、提案された関係を見てみましょう。推奨される関係は、CIの作成時にユーザーが選択できる適切または合理的な関係のリストを提供するために定義されます。提案された関係はCMDB、relタイプの提案されたテーブルに格納され、提案された関係アプリケーションを使用して、またはここでCIクラスマネージャーで構成できます。ここに表示されるのは、ApacheWebサーバーの推奨される関係です。ここにフィルターボタンがあり、画面に表示されるものを絞り込んで、インバウンドまたはアウトバウンドの関係を表示できます。また、関係の種類で絞り込むこともできるので、関係の実行だけを表示したい場合は、選択を解除できます。他の2つのタイプは、この特定の実行の関係を示しています。そこで、そのフィルターをクリアして、新しい提案された関係を作成することがいかに簡単であるかを示し、[新規]をクリックします。これから行うことは、ApacheWebサーバーがアプリケーションソフトウェアにエクスポートすることを指定することです。了解しました。提案された関係を定義しました。保存します。この関係がアプリケーションソフトウェアにエクスポートされるようになりました。
CI クラスマネージャ
各タブをクリックして、CI クラスマネージャーに含まれる詳細の一部を確認します。
各タブをクリックして、CI クラスマネージャーに含まれる詳細の一部を確認します。
[正常性] タブでは、CMDB の正常性の監視と維持に役立つ KPI とメトリックを構成できます。CI の重複、必須の CI フィールド、監査などの正常性メトリックは、特定の CI クラスまたは基本 CMDB レベルでの全体的な正常性スコアカードの計算に役立ちます。
CMDB データの正常性は、次の KPI について監視およびレポートされ、各 KPI はサブメトリックで構成されます。
完全性: 設定されていない必須フィールドと推奨フィールドについて、CI がテストされます。
コンプライアンス: CMDB データは、事前に定義された証明書に準拠しているかどうかが監査されます。
正確性: CI は、識別規則 (重複した CI を検出するため)、孤立した CI 規則、古い CI 規則などの事前定義されたデータ保全性ルールに対してテストされます。
さまざまな正常性インジケーターのテスト後、結果はクラス レベルで (完全性、コンプライアンス、および正確性) を使用して集計され、最終的には全体的な CMDB レベルで集計されます。
これらの KPI は CI クラス マネージャーのこのセクションで構成されます。
最後に、正常性包含ルール - 正常性計算に含まれる CI の範囲を絞り込みます。
CI リストには、選択したクラスに対して定義されているすべての CI が表示されます。
この例では、Apache Web サーバークラスに 3 つの API があります。
この例では、Apache Web サーバークラスに 3 つの API があります。
クラスの固定を使用すると、最も頻繁に使用するクラスに簡単に移動できます。 「ピン」をクリックすると、ピン留めされたクラスが表示されます。 表示されているクラスのいずれかをクリックすると、そのクラスの設定が表示されます。
個別のモジュールを使用した CMDB 設定
このセクションの概要で説明したように、テーブル、列、識別規則、リレーションシップ、および正常性ルールなどの CMDB への構成は、従来、それぞれのモジュールに移動して構成されていました。 このビデオでは、CI クラス マネージャーを使用しない場合にこれらの構成を行うナビゲートする場所を説明します。Q.次の説明を正しい項目に一致させる
オーバーロードされた CI: 重複する CI の逆の問題は、異なる CI が同じ CI として識別され、複数の CI を作成する必要がある場合に 1 つの CI が作成される場合です。
識別子を有効にするには、次の 2 つの条件を満たす必要があります。
調整定義とデータ ソース優先順位規則を正しく構成すると、プロセスの 90% を処理して、信頼されているデータ ソースと、特定のクラス、クラスのセット、CI 属性の最終的な信頼できるソースを制御できます。
- クラスにアイコンを割り当てるには、どこに行きますか?
- 正常性を決定するために集約されたインジケーター
- 頻繁にアクセスされるクラスに簡単に戻ることができます
- CI 属性の更新が許可されているデータ・ソースはどこで定義しますか?
- 一意に識別するルールを定義する場所は、どこに行きますか。
- 正常性計算に含まれる C の範囲を絞り込む
----
- [基本情報] タブ
- [調整ルール] タブ
- [ID ルール] タブ
- 固定されたクラス
- 正常性の包含ルール
- 完全性、コンプライアンス、および正確性
---
1-2
2-5
3-4
4-1
5-3
6-6
識別と調整フレームワークの概要
ID 照合エンジン (IRE) とも呼ばれる ID および調整フレームワークは、さまざまなデータ ソースからデータを識別および調整するための一元的な方法を提供します。
IRE は、3 種類の品質チェックを処理します。
IRE は、重複する CI を管理し、検出、サービス・マッピング、インポート・セット、REST 統合などの複数のデータ・ソースを使用して CI レコードを作成および更新する場合に CI の更新を制御することにより、CMDB の整合性を維持するのに役立ちます。
複数のデータ ソースを使用してデータをインポートすると、重複レコードを介して不整合が発生するリスクが高くなります。データベースの整合性を維持するには、CMDB に対して真に新しい C に対してのみ新しいレコードが作成されるように、C とサービスを正しく識別することが重要です。識別規則と調整ルールは、CI レコードの重複の防止、CI 属性の調整、CI の再分類、および権限のあるデータ・ソースのみが CMDB 内の CI レコードを更新することを可能にするのに役立ちます。
識別ルール
CMDB を作成する最も効率的な方法は、ServiceNow ディスカバリなどの自動検出ツールまたは SCCM などのサード パーティの検出ツールを使用することです。しかし、多くの CMDB は不正確なデータを持つことに苦しんでいます。エンタープライズ CMDB データが不正確な場合、CMDB に依存するレポートとプロセスが失敗し、組織が危険にさらされる可能性があります。
CMDB 識別プロセスは、CI ID とも呼ばれる識別ルールに依存して、CI を一意に識別します。識別規則は CI クラスに適用され、それぞれ異なる優先順位を持つ単一の CI ID と 1 つ以上の ID エントリーで構成されます。各識別子エントリは、特定の優先順位を持つ一意の属性セットを定義します。
既定の識別規則を超えて追加の規則を作成する必要がある場合は、最も強力な識別子エントリに対して最も高い優先順位で設定された、優れた規則を作成することをお勧めします。
よい識別子エントリ候補は、一意で、時間の経過と変わらない属性に基づく必要があります。例としては、ハードウェアのシリアル番号やアプリケーションの構成ディレクトリなどがあります。同じサーバーに 2 つの同様のアプリケーションがインストールされていて、同じ識別子エントリの選択肢になっている場合でも、構成ディレクトリは一意のままです。
よい識別子エントリ候補は、一意で、時間の経過と変わらない属性に基づく必要があります。例としては、ハードウェアのシリアル番号やアプリケーションの構成ディレクトリなどがあります。同じサーバーに 2 つの同様のアプリケーションがインストールされていて、同じ識別子エントリの選択肢になっている場合でも、構成ディレクトリは一意のままです。
CMDB の一般的な不正確さ
重複 CI: 1 つの CI を表す CMDB に重複する CI がある場合です。この状況は、CI の識別規則によって、各 CI が変更されない ID エントリで一意に表現されることを保証しない場合に発生することがあります。オーバーロードされた CI: 重複する CI の逆の問題は、異なる CI が同じ CI として識別され、複数の CI を作成する必要がある場合に 1 つの CI が作成される場合です。
これらの問題は、構成項目を識別するために使用される属性が CI の ID を適切に表していない場合に発生します。
識別ルールは、特定のハードウェアおよびアプリケーションルールを使用して、CMDBに挿入または更新されるすべてのハードウェアおよびアプリケーションを管理するのに役立ちます。
識別ルールは、特定のハードウェアおよびアプリケーションルールを使用して、CMDBに挿入または更新されるすべてのハードウェアおよびアプリケーションを管理するのに役立ちます。
これは、CMDB に対するすべてのハードウェアの挿入と更新を管理するために使用される既定の識別規則です。これには、ハードウェア テーブル [cmdb_ci_hardware] に挿入または更新された CI、またはサーバー テーブル [cmdb_ci_server] などの拡張テーブルが含まれます。
これは、拡張クラスに他の特定のルールが定義されていない場合に、CMDB 内のすべてのアプリケーションの挿入または更新を識別するために使用されるデフォルトのアプリケーション規則です。
正しい識別方法の選択
運転免許証やパスポートが他の人と区別されるドキュメントであるのと同様に、構成項目には独自の固有の識別子が必要です。識別子は、各構成項目の一部である属性で構成されます。識別子を有効にするには、次の 2 つの条件を満たす必要があります。
- 識別子は、その構成項目に固有である必要があります (シリアル番号、ホスト名、インストール ディレクトリ、構成ファイルのパスなど)。
- 構成項目の有効期間中、識別子は変更できません (つまり、IP アドレス、バージョンは、同じ CI の時間の経過と同時に変更される可能性があり、確かな選択肢とは見なされません)。
仮想コンピュータまたは物理コンピュータの一般的な識別子を考えてみましょう。ネットワークは、コンピュータを IP アドレスで識別します。IP アドレスは一意です。実際、あるコンピュータが別のコンピュータと同じ IP アドレスを持つネットワークに参加した場合、通常は警告が発行され、そのコンピュータはネットワークに参加できません。IP アドレスが一意の識別子として最適な選択であると考えるかもしれません。ただし、IP アドレスが簡単に変更できるため、CMDB の信頼できる一意識別子ではありません。
MAC アドレスはネットワーク カードに一意に割り当てられ、ハードウェアに焼き付くので、MAC (メディア アクセス制御) アドレスの方が良い選択です。しかし、仮想ハードウェアを使用すると、MAC アドレスをランダムに割り当てることができ、ネットワーク全体で複製できます。
MAC アドレスはネットワーク カードに一意に割り当てられ、ハードウェアに焼き付くので、MAC (メディア アクセス制御) アドレスの方が良い選択です。しかし、仮想ハードウェアを使用すると、MAC アドレスをランダムに割り当てることができ、ネットワーク全体で複製できます。
一般に、シリアル番号は、物理ハードウェアと仮想ハードウェアの固有 ID として生成され、構成項目の存続時間に応じて変更されない傾向があるため、はるかに優れた選択を行います。ServiceNow には、ハードウェア項目を識別するための既定の識別子エントリとしてシリアル番号を使用する既定のハードウェア識別規則があります。 ただし、選択したハードウェアではシリアル番号が使用できない可能性があります。したがって、ホスト名または IP/MAC アドレスの組み合わせが、シリアル番号が存在しない場合に使用できるフォールバック メカニズムが存在します。
良いアプリケーションと悪いアプリケーション識別規則の設定
ソフトウェア アプリケーションには、識別子として適用できる一意のシリアル番号が必ずしも含まれているわけではありません。 実行する個々のプロセスによって最もよく識別できます。ただし、多くのアプリケーションでは、複数のインスタンスのインスタンスを 1 台のマシンで実行できるため、同じアプリケーションの複数のインストールが同じ名前で実行されている場合があります。 したがって、インストール ディレクトリまたは構成ファイル パスによってアプリケーションを識別することをお勧めします。 同じソフトウェアの複数のインスタンスを同じホスト上の異なるディレクトリにインストールする必要があり、この属性は有効で効果的な識別方法になります。識別規則の選択が不適切である場合、次のシナリオを検討してください。
データセンターには 2 つの Linux サーバーがあります。 サーバー 1 は Tomcat Web サーバーの 2 つのインスタンスを実行しています。サーバー 2 は Tomcat の 1 つのインスタンスを実行しています。
CMDB に書き込まれると、Tomcat Web サーバーはアプリケーションの名前 (識別子エントリの一部として構成されている) によって識別されていると仮定します。2 台の Tomcat Web サーバーが存在するサーバー 1 では、名前は同じであるため、Tomcat アプリケーションが 2 つある場合でも、CMDB に作成されるエントリは 1 つだけです。オーバーロードされた CI とも呼ばれます。
Tomcat の最初のインスタンスが挿入され、Tomcat の 2 番目のインスタンスが Tomcat の最初のインスタンスを更新し、一致するものが名前に見つかります。
CMDB に書き込まれると、Tomcat Web サーバーはアプリケーションの名前 (識別子エントリの一部として構成されている) によって識別されていると仮定します。2 台の Tomcat Web サーバーが存在するサーバー 1 では、名前は同じであるため、Tomcat アプリケーションが 2 つある場合でも、CMDB に作成されるエントリは 1 つだけです。オーバーロードされた CI とも呼ばれます。
Tomcat の最初のインスタンスが挿入され、Tomcat の 2 番目のインスタンスが Tomcat の最初のインスタンスを更新し、一致するものが名前に見つかります。
取り除く: このシナリオを考えると、名前自体は Tomcat Web サーバーを識別するための識別規則として不適切な選択と見なされます。バージョンは、ソフトウェアがアップグレードされたときに時間の経過とともに変更される可能性もあるので、最良の選択とは見なされません。
識別ルールの選択を改善する次のシナリオを検討してください。
データセンターには 2 つの Linux サーバーがあります。 サーバー 1 は Tomcat Web サーバーの 2 つのインスタンスを実行しています。サーバー 2 は Tomcat の 1 つのインスタンスを実行しています。
CMDB に書き込まれると、Tomcat Web サーバーはアプリケーションの Cfg ファイル名 (識別子エントリの一部として構成されている) によって識別され、この場合はサーバー 1 上のすべての Tomcat インスタンスに対して一意であると仮定します。2 台の Tomcat Web サーバーが存在するサーバー 1 では、CFg ファイル名が異なるので、この場合は CMDB に 2 つのエントリが作成されます。
CMDB に書き込まれると、Tomcat Web サーバーはアプリケーションの Cfg ファイル名 (識別子エントリの一部として構成されている) によって識別され、この場合はサーバー 1 上のすべての Tomcat インスタンスに対して一意であると仮定します。2 台の Tomcat Web サーバーが存在するサーバー 1 では、CFg ファイル名が異なるので、この場合は CMDB に 2 つのエントリが作成されます。
取り除く: このシナリオを考えると、Cfg ファイル名は、Tomcat Web サーバーを識別するための識別規則として適していると考えられます。インストール ディレクトリまたは構成ファイルのパスも常に一意である場合も、さらに優れた選択肢があります。
概要
組織内の構成管理グループは、組織内の CI を最もよく識別するために、どの属性が一意で、時間の経過と共に変更される可能性が最も低いかを最もよく判断するために、ハードウェアとアプリケーションの属性に精通していることが重要です。識別規則は、CI クラス・マネージャーまたは CI ID モジュールを介して、単純なユーザー・インターフェースでクラスごとに構成されます。調整定義とデータ ソース優先順位ルール
CMDBデータの信頼を得る方法
CMDB データを更新するデータ ソースを理解し、制御することは、CMDB 内のデータを信頼するうえで重要です。調整定義とデータ ソース優先順位規則を正しく構成すると、プロセスの 90% を処理して、信頼されているデータ ソースと、特定のクラス、クラスのセット、CI 属性の最終的な信頼できるソースを制御できます。
調整ルール
調整ルールは、テーブルまたはテーブル属性のセットを更新できるデータ ソースを指定し、親クラスレベルまたは子クラス レベルで定義できます。CMDB 内の C を更新する権限を持つ各データ ソースに対して、調整規則が設定されていることを確認することをお勧めします。データ ソース優先順位ルール
複数のデータ ソースが CMDB 内の同じクラスまたは同じクラス属性を更新する権限を持っている場合、各データ ソースに対してデータ ソース優先順位ルールを設定して、特定のクラスまたはクラス属性に対して、どのデータ ソースが信頼できるソースと見なされるか、顧客が制御できるようにすることができます。データ ソースの優先順位規則がない場合、データ ソースは互いの変更を上書きできます。データ ソースの優先順位の例
この例では、Windows サーバー [cmdb_ci_win_server] テーブルの ServiceNow は、最も高い優先順位に相当する最低の順序の値で構成されています。すべてのデータ ソースは、Windows サーバー テーブルにレコードを作成する機能を持っていますが、ServiceNow が更新を実行するか、Windows サーバー レコードを作成した後、その [ソースの検出] フィールドはサービスナウとして表示されます。この時点では、インポートセットを使用したデータのインポートも、Altiris からの更新も許可されません。これは、インポート セットと Altiris データ ソースの両方の方が、高い順序の値または低い優先順位を持つためです。
この例では、Windows サーバー [cmdb_ci_win_server] テーブルの ServiceNow は、最も高い優先順位に相当する最低の順序の値で構成されています。すべてのデータ ソースは、Windows サーバー テーブルにレコードを作成する機能を持っていますが、ServiceNow が更新を実行するか、Windows サーバー レコードを作成した後、その [ソースの検出] フィールドはサービスナウとして表示されます。この時点では、インポートセットを使用したデータのインポートも、Altiris からの更新も許可されません。これは、インポート セットと Altiris データ ソースの両方の方が、高い順序の値または低い優先順位を持つためです。
CI クラス マネージャ内では、特定のクラス レベルに対して、データ更新ルールを定義するオプションの設定があります。この規則を使用すると、管理者は、優先順位の高いデータ ソースによってクラスを更新する必要がある時間間隔を構成できます。優先度の高いデータ ソースが指定された間隔内に更新を実行しない場合、ServiceNow は、優先度の低いデータ ソースが更新を実行できるようにします。
このコースでは、CMDB の設定と実装に関する一般的なベストプラクティスについて説明しました。CI クラス・マネージャーの使用方法を確認しました。最後に、ID、調整、およびデータ優先順位の規則を使用して作成し、重複を防止し、信頼できるソースからのデータのみを受け入れる方法を学習しました。
