第9章：高度なCMDB活用：Service Mapping

9.1 Service Mappingとは何か、その価値

Service Mappingは、ITインフラストラクチャコンポーネント（サーバー、アプリケーション、データベース、ネットワークデバイスなど – CMDB内のCI）と、それらが集合的にサポートするビジネスサービスとの間の論理的な接続と依存関係を自動的に発見し、マッピングするServiceNowの機能です。

📌 標準的なDiscovery（インフラ中心、第4章参照）とは異なり、Service Mappingは「サービス視点」でITコンポーネント間の連携を可視化します。（例：「オンラインバンキングサービス」がどのサーバー、どのアプリケーション、どのデータベースで構成され、それらがどのように連携してサービスを提供しているか）

💡 Service Mappingの主な価値：

• 👍 サービスアウェアネス (Service Awareness): ITコンポーネントが特定のビジネスサービスにどう貢献しているかを視覚的なマップ（サービスマップ）で提供し、ITインフラとビジネス成果の連携を明確にします。これにより、IT部門は技術的な視点だけでなく、ビジネスの視点からもIT環境を理解できるようになります。
• 👍 正確な影響分析 (Accurate Impact Analysis): CIの障害発生時や変更計画時に、そのCIの停止や変更がどのビジネスサービスに影響を与えるかを即座に、かつ正確に示すことができます。これにより、ビジネスインパクトの迅速な評価、インシデント対応や変更作業の適切な優先順位付け、関係者への効果的なコミュニケーションが可能になります。
• 👍 迅速な根本原因分析 (Faster Root Cause Analysis): ビジネスサービス内で障害が発生した場合、サービスマップ上の依存関係をたどることで、問題の原因となっている可能性のあるCIを効率的に特定できます。影響範囲をサービスコンテキストで把握できるため、根本原因の特定と解決までの時間を短縮できます。
• 👍 コミュニケーション改善 (Improved Communication): ITチーム内部（例：アプリチームとインフラチーム間）だけでなく、IT部門とビジネス部門の関係者の間で、重要なビジネスサービスを支えるIT構成に関する共通の理解を促進します。サービスマップは、複雑なIT環境を誰にでも分かりやすく伝えるための共通言語となります。
• 👍 変更計画の改善 (Better Change Planning): 変更を実施する前に、サービスマップを利用して、変更対象のCIに関連する全てのコンポーネント（上流・下流）を特定できます。これにより、変更がサービス全体に与える潜在的な影響をより包括的に評価し、リスクを低減した計画立案を支援します。
• 👍 信頼できるCMDB活用の促進 (Enhanced CMDB Value): Service Mappingは、基盤となるCMDBデータ（CI、属性、関係性）の正確性と完全性を利用し、またその過程で検証も行います。質の高いサービスマップを作成・維持するためには、正確なCMDBが不可欠であるという認識が高まり、CMDBデータの品質維持への動機付けとなります。
• 👍 ITOMの基盤 (Foundation for ITOM): Service Mappingによって生成されるサービスマップ（ServiceNowのService Graphの一部を構成）は、Event Management（イベント情報とビジネスサービスの相関付けによる障害検知の高度化）、Operational Intelligence（AIを活用した異常検知や予測分析）など、他のITOM（IT Operations Management）機能の重要な基盤として活用されます。

9.2 Service Mappingの仕組み

9.2.1 Service Mappingの基本的な仕組み：

Service Mappingは、ビジネスサービスの エントリーポイント （ユーザーや他のサービスがそのサービスにアクセスする際の最初の接点）からマッピングを開始します。そして、ServiceNow Discoveryでも利用される パターン （特定の技術やアプリケーションの構成情報や接続情報を識別・収集するためのロジック）を使用して、エントリーポイントから接続をたどり、サービスを構成するITコンポーネント（CI）とその依存関係を段階的に発見・マッピングしていきます。

• エントリーポイント (Entry Point):
  • サービスディスカバリーを開始するための起点となるCIまたはアクセスポイントです。
  • 通常、外部からアクセス可能なコンポーネントがエントリーポイントとして定義されます。
  • 例：WebアプリケーションのURL、ロードバランサーの仮想IPアドレス（VIP）、APIエンドポイント、特定のTCPポートなど。
  • サービスごとに一つまたは複数のエントリーポイントを定義できます。
• パターン (Patterns):
  • Discoveryパターン（第4章参照）と同様に、特定の技術コンポーネント（例：Apache Web Server, Tomcat Application Server, Oracle Databaseなど）を識別し、その構成情報、実行中のプロセス、リスニングポート、他のコンポーネントへの接続情報（例：設定ファイル内のデータベース接続文字列）などを収集するための一連の手順を定義したものです。
  • 📌 Service Mappingで使用されるパターンは、特にコンポーネント間の「接続」と「依存関係」を特定し、その接続をたどって次のコンポーネントを発見できるように設計されています。例えば、Webサーバーのパターンは、それが通信するアプリケーションサーバーを特定し、アプリケーションサーバーのパターンは、それが利用するデータベースを特定するといった具合です。

9.2.2 概念的なフロー:

Service Mappingの発見・マッピングプロセスは、以下のような概念的なフローで進みます。

1. 定義: マッピング対象とするビジネスサービスと、そのサービスへのアクセス起点となるエントリーポイントをServiceNowに定義します。
2. 開始: Service Mappingは、定義されたエントリーポイントからディスカバリーを開始します。
3. 識別と情報収集: エントリーポイントに到達すると、関連付けられたパターンが実行され、そのコンポーネントの技術タイプ（例：Apache Web Server）を識別し、主要な属性情報や実行中のプロセス、設定ファイルなどを収集します。
4. 接続の特定: パターンは、そのコンポーネントが他のITコンポーネントとどのように通信しているか（例：特定のポートで別のサーバーのIPアドレスに接続している、設定ファイルにデータベースの接続情報が記載されているなど）を特定します。
5. 接続の追跡と繰り返し: Service Mappingは、特定された接続情報をたどり、次の関連コンポーネントを発見します。そして、その新しいコンポーネントに対しても同様にパターンを実行し、識別、情報収集、さらなる接続の特定を行います。
6. マップ生成: このプロセスをサービス全体にわたって繰り返すことで、エントリーポイントから始まり、サービスを構成する全ての主要なITコンポーネントとその間の依存関係が繋がり、最終的にビジネスサービスの完全な依存関係マップ（サービスマップ）が自動的に生成されます。

[図表プレースホルダー: Service Mappingの概念フロー図。エントリーポイントから始まり、パターンを使ってCIを次々に発見し、サービスマップを構築していく様子を視覚的に示す。]

9.3 Service Mappingの実装

📌 Service Mappingの成功には計画的な実装プロセスが必要です。 ビジネスサービスを正確にマッピングするための主要なステップは以下の通りです。一足飛びに全てのサービスをマッピングしようとするのではなく、段階的なアプローチが推奨されます。

1. ビジネスサービスの特定と優先順位付け:

   組織にとってビジネス上の重要度が高く、かつService Mappingによる可視化のメリットが大きいビジネスサービスを特定し、マッピングの優先順位を決定します（第2章のCMDBスコープ定義や、CSDMにおけるサービス定義と連携）。最初は、比較的単純な構造のサービスや、障害発生時の影響が大きいクリティカルなサービスから着手するのが一般的です。

2. サービスアーキテクチャの理解と情報収集:

   マッピング対象とする各ビジネスサービスについて、アプリケーションオーナー、開発チーム、インフラ担当者など、関連するステークホルダーと協力し、サービスの構成要素（主要なサーバー、アプリケーション、データベース、ミドルウェア、ロードバランサーなど）、それらの間の主要な通信経路や依存関係、そしてユーザーがサービスにアクセスするためのエントリーポイント（URL、IPアドレス、ポート番号など）を事前に可能な限り詳細に把握します。既存の設計書、構成図、ネットワーク図なども重要な情報源となります。

3. エントリーポイントの定義:

   収集した情報に基づき、各ビジネスサービスについて、Service Mappingがディスカバリーを開始するための起点となるエントリーポイントをServiceNowに正確に設定します。エントリーポイントは、MIDサーバーからネットワーク的に到達可能である必要があります。

4. MIDサーバーの設定と検証:

   Service Mappingが対象コンポーネントと通信するために、適切なMIDサーバーが構成され、必要なネットワークゾーン（例：本番環境セグメント、DMZ）に配置され、ServiceNowインスタンスと正常に通信できる状態であることを確認します（第4章のMIDサーバー設定参照）。Service Mapping用のケイパビリティ（例：「ServiceMapping」）がMIDサーバーに割り当てられていることも確認します。

5. 認証情報の設定と検証:

   サービスを構成する可能性のある全てのコンポーネント（サーバー、データベース、ネットワーク機器など）に対して、Discovery（第4章参照）と同様に、適切な認証情報（例：SSH、WMI、SNMP、JMXなど）がServiceNowに登録され、MIDサーバー経由で利用可能であり、かつ必要な権限を持っていることを確認・検証します。

6. Service Mapping Discoveryの実行:

   定義したビジネスサービスとエントリーポイントに基づき、ServiceNow上でService Mappingのディスカバリージョブ（スケジュール実行または手動実行）を開始します。実行中は、Discoveryステータスやログを監視し、エラーや警告が発生していないかを確認します。

7. サービスマップの検証と調整:

   ディスカバリージョブが完了したら、生成されたサービスマップを詳細にレビューします。事前に収集したサービスアーキテクチャ情報や、アプリケーションオーナーなどの専門家の知見と照らし合わせ、マップが実際のサービスの構成や依存関係を正確に反映しているか、重要なコンポーネントの欠落や誤った接続がないかなどを検証します。📌 この検証プロセスには、アプリケーションオーナーや開発者、インフラ担当者など、サービスに詳しい関係者の積極的な協力が不可欠です。

8. マッピングエラーのトラブルシューティング:

   サービスマップが不完全であったり、不正確な情報を含んでいたりする場合（例：CIが正しく識別されない、期待される接続が見つからない、パターン実行エラーなど）、Service Mappingのログ、Discoveryログ、ECCキューなどを調査し、原因を特定します。一般的な原因としては、認証情報の不足や権限エラー、ネットワーク接続の問題、ファイアウォールによるブロック、標準パターンで対応できないカスタムアプリケーションや特殊な構成、パターンのバグや設定ミスなどが考えられます。原因に応じて、認証情報の修正、ネットワーク設定の見直し、パターンの調整やカスタムパターンの開発（第4.6章参照）、あるいはCI識別ルールの見直し（第6章参照）など、適切な対処を行います。

9. 手動マップ調整の検討（限定的に）:

   非常に複雑な構成や、自動検出が困難な特定の依存関係については、場合によってはサービスマップ生成後に手動でCIや関係性を追加・修正するといった調整が必要になることもあります。しかし、Service Mappingの主な利点は自動化による継続的な最新化であるため、手動での調整は最小限に留め、可能な限りパターンやDiscovery設定の改善によって自動的に正確なマップが生成されることを目指すべきです。

[図表プレースホルダー: Service Mapping実装の主要ステップを順番に示したフローチャートまたはチェックリスト。各ステップのポイントも簡潔に記載。]

9.4 IT運用とITSMにおけるService Mappingの活用

📌 Service MappingはITSMプロセスをサービス視点で強化します。 サービスコンテキストを提供することで、CMDBデータとITSMプロセスの価値を大幅に向上させます。

Service Mappingによって生成されたサービスマップは、単にIT構成を可視化するだけでなく、日々のIT運用や主要なITSMプロセスにおいて実用的な価値を提供します。

• 👍 サービスアウェアなインシデント管理:
  • インシデント対応者は、影響を受けているCIがどのビジネスサービスに影響を与えているかをサービスマップで即座に確認できます。
  • これにより、ビジネスインパクトの迅速な評価と、サービスの重要度に基づいた優先順位付けが可能になります。例えば、同じサーバー障害でも、それがクリティカルな顧客向けサービスを支えているのか、社内向けの低優先度サービスを支えているのかで、対応の緊急度が変わってきます。
  • サービスマップ上で、障害CIの周辺の依存関係を確認することで、障害の波及範囲や、他に影響を受けている可能性のあるコンポーネントを迅速に特定できます。
• 👍 サービスアウェアな変更管理:
  • 変更担当者や承認者（CABメンバーなど）は、サービスマップを使用して、変更対象CIの上流（依存しているサービス）および下流（依存されているコンポーネント）の依存関係を視覚的に把握できます。
  • これにより、提案された変更がビジネスサービスや他の連携システムに与える潜在的な影響をより正確に評価でき、変更のリスク評価と変更計画の質が向上します。
  • 変更の衝突検出においても、サービスコンテキストを考慮することで、より重要な競合を優先的に特定できます。
• 👍 サービス健全性監視とイベント管理の高度化:
  • Service Mappingは、サービス全体の健全性監視の基盤となります。ITOM Event Managementと連携することで、個々のインフラコンポーネントから上がってくる大量のイベントを、サービスマップに基づいて関連付け、ビジネスサービスレベルでの真の障害や影響を特定できます。
  • サービスマップ内の各CIのステータスやCMDB Healthメトリクス（第7章参照）を集約し、ビジネスサービスの全体的な健全性としてダッシュボードに表示できます。
  • これにより、IT運用チームは、個々のコンポーネントの死活監視から、ビジネスサービスの可用性とパフォーマンスの管理へと視点を移行できます。
• 👍 問題管理における根本原因分析の支援:
  • サービスマップは、問題分析者が、繰り返し発生するインシデントの背後にある複雑な依存関係を理解し、根本原因となっている可能性のあるCIや構成上の問題を特定するのを支援します。
  • 特定のサービスでパフォーマンス劣化が頻発している場合、サービスマップを分析することで、ボトルネックとなっている共通のコンポーネントや、予期せぬ依存関係を発見する手がかりが得られることがあります。

[図表プレースホルダー: インシデントレコードからサービスマップが表示され、障害CIと影響ビジネスサービスがハイライトされているイメージ。または、変更要求フォームから関連サービスマップが表示され、変更対象CIと依存CIが示されているイメージ。]

9.5 サービスマップの維持

📌 サービスマップの正確性維持には継続的な保守が不可欠です。 IT環境は常に変化するため、一度生成したサービスマップも時間とともに陳腐化します。マップを信頼できる情報源として活用し続けるためには、IT環境の変更に合わせてマップを最新の状態に保つ必要があります。

💡 主な維持方法:

• スケジュールされたDiscovery (定期的な再マッピング):

  マッピング対象として定義されたビジネスサービスに対して、定期的に（例：日次、週次、月次など、サービスの変更頻度や重要度に応じて）Service Mappingのディスカバリージョブをスケジュール実行します。これにより、IT環境内の構成変更（新しいCIの追加、既存CIの廃止、接続関係の変更など）を自動的に検出し、サービスマップに反映させます。

• 変更起因の更新 (Change-Triggered Updates):

  重要な変更管理（第8章参照）が計画され、承認・実装された際に、その変更が関連するビジネスサービスのService Mappingディスカバリーを自動的または手動でトリガーする仕組みを導入します。👍 これにより、大きな構成変更があった場合に、その内容を迅速にサービスマップへ反映させ、マップの鮮度を高く保つことができます。

• マップ健全性の監視と修正:

  Service Mappingが提供する健全性レポートやダッシュボード（例：マッピングされなかったCI、接続エラー、パターン実行の失敗などを示す情報）を定期的に確認します。発見された問題（例：エントリーポイントの変更、認証情報のエラー、パターンの不備など）の原因を調査し、設定修正やパターン調整など、適切な対処を行います。

• パターンの保守と更新:

  サービス内で使用されている技術コンポーネント（OS、ミドルウェア、データベースなど）のバージョンがアップグレードされた場合や、新しい技術が導入された場合は、必要に応じて既存のDiscoveryパターンを更新したり、新しいカスタムパターンを開発したりする必要があります（第4.6章参照）。ServiceNowが提供するパターンのアップデートも定期的に確認し、適用します。

• 検証プロセスとフィードバックループ:

  定期的に（例：四半期ごと、半期ごと）、アプリケーションオーナーやサービスの専門家と共に、生成されたサービスマップの内容をレビューし、実際のサービス構成との間に乖離がないかを確認します。検証で見つかった不正確な点や改善点は、Service Mappingの設定やパターン、あるいは基盤となるCMDBデータ自体へのフィードバックとして活用し、継続的な改善サイクルを回します。

9.6 Service MappingとCMDBおよびCSDMの連携

📌 Service MappingはCMDB/CSDMと密接に連携します。 Service MappingはCMDBデータを活用し、CSDMの概念に基づいてサービスをマッピングします。Service Mappingの成功は、質の高いCMDBと、CSDMに準拠したデータモデル設計に大きく依存します。

• 基盤としてのCMDB:

  Service Mappingは、ServiceNow Discovery（第4章）やその他のデータソース（第5章）によって収集され、IRE（第6章）によって正規化・調整されたCMDB内のCI（構成アイテム）とその属性、そしてCI間の技術的な関係性を基盤として利用し、サービスマップを構築します。

  📌 したがって、CMDBに登録されているデータの精度、完全性、そして鮮度が、そのままサービスマップの品質に直結します。不正確または古いCMDBデータに基づいて生成されたサービスマップは、信頼性が低く、誤った意思決定を招く可能性があります。

• CSDM（共通サービスデータモデル）との整合:

  Service Mappingは、CSDM（第3章参照）のフレームワーク、特にサービス関連のCIクラスと整合するように設計されています。

  主に、CSDMの アプリケーションサービス (Application Service) CI（サービスの技術的な構成や提供インスタンスを示す）をマッピング対象とし、それを支える技術レイヤーのCI（サーバー、データベース、ネットワーク機器など）との依存関係を明らかにします。

  さらに、マッピングされたアプリケーションサービスは、CSDMの ビジネスサービス (Business Service) CI（ビジネスユーザーが認識するサービスの価値や機能を示す）にリンクされることで、技術的な構成とビジネス上の成果との繋がりが明確になります。

  📌 効果的なService Mappingを実施するためには、CSDMに基づいたCMDBの基盤構築、特にビジネスサービス、アプリケーションサービスといったサービス関連CIクラスの適切な定義と実装が前提となります。

  💡 第3章で触れたCMDB Foundation Dashboardは、このCSDM準拠の基盤構築の進捗状況を確認し、Service Mappingの準備状況を評価するのに役立ちます。

[図表プレースホルダー: CSDMの階層構造（ビジネスサービス、アプリケーションサービス、技術CI）と、Service Mappingが主にどのレイヤー間の関係性をマッピングするかを示した図。CMDBがその全ての基盤となっていることを強調する。]

9.7 本章のまとめ

📌 Service Mappingは、ITインフラとそれが支えるビジネスサービス間の依存関係を可視化するServiceNowの高度な機能です。

本章では、Service Mappingが単なる技術的な構成図ではなく、IT運用とビジネスの連携を強化し、サービス中心のIT管理を実現するための戦略的なツールであることを学びました。

• 👍 Service Mappingの価値: サービスアウェアネスの向上、影響分析・根本原因分析の迅速化と精度向上、変更計画の改善、コミュニケーションの促進、そしてITOM運用の基盤強化など、多岐にわたるメリットをもたらします。
• 📌 仕組みと実装: エントリーポイントから開始し、パターンを用いてコンポーネント間の接続をたどり、サービス全体の依存関係マップを自動生成します。その実装には、ビジネスサービスの特定、アーキテクチャの理解、MIDサーバーと認証情報の設定、実行後の検証とトラブルシューティングといった計画的なアプローチが必要です。
• 📌 継続的な維持: 生成されたサービスマップの価値を維持するためには、定期的な自動再マッピング、変更管理プロセスとの連携、マップの健全性監視、パターンの保守、そして関係者による定期的なレビューといった継続的な努力が不可欠です。
• 👍 CMDB/CSDMとの不可分な関係: Service Mappingは、正確で完全なCMDBデータを基盤とし、CSDMフレームワーク（特にビジネスサービスとアプリケーションサービスの階層）と整合して機能します。質の高いCMDBとCSDMの実装が、効果的なService Mappingの前提条件となります。

Service Mappingを導入し、適切に運用することで、組織は自社のITインフラストラクチャがビジネスサービスにどのように貢献しているかについての深い洞察を得ることができ、IT運用の効率性、サービスの可用性、そしてビジネス全体の回復力を大幅に改善することが可能になります。