サービスカタログ: 組織のインベントリ
Un サービスカタログ すべてのサービスの集中化された権限のある登録、 組織のソフトウェア コンポーネントとリソース。テクノロジーの展望を表す「地図」 企業: 誰が何を所有しているか、サービスがどのように相互接続されているか、どの SLA が保証されているか、 各コンポーネントの健全性はどのような状態ですか。
サービスカタログがなければ、成長を続ける組織は苦境に陥る シャドーIT: 誰も知らないサービス、文書化されていない依存関係、曖昧な所有権など 誰に連絡すればよいか誰も分からないため、解決までに何時間もかかるインシデント。サービスカタログ は、ソフトウェア エコシステム全体に信頼できる単一の情報源を提供することで、これらの問題を解決します。
何を学ぶか
- サービス カタログをモデル化する方法: エンティティ、関係、メタデータ
- サービスの所有権: チーム、オンコール、エスカレーション パス
- SLA 追跡: RTO、RPO、可用性目標およびコンプライアンス
- CMDB (構成管理データベース): 構成アイテムと変更の追跡
- 依存関係マッピング: 依存関係グラフと影響分析
- 自動検出: カタログの自動作成
サービスカタログのモデル化
効果的なサービス カタログは、 データモデル を捉える優れたデザイン エコシステムの各コンポーネントに関する重要な情報。主なエンティティは次のとおりです。
- サービス: ビジネス機能を実行するマイクロサービス、アプリケーション、またはシステム
- API: サービス (REST、gRPC、GraphQL、Kafka イベント) によって公開または消費されるインターフェイス
- リソース: インフラストラクチャ リソース (データベース、キャッシュ、メッセージ キュー、ストレージ)
- 図書館：複数のサービスで利用する共有ライブラリ
- チーム: 1 つ以上のサービスの保守と運用を担当するグループ
# Service Catalog: modello dati per un servizio
service:
metadata:
name: checkout-service
display_name: "Checkout Service"
description: "Gestisce il flusso di checkout e pagamenti"
created_at: "2024-03-15"
last_updated: "2026-01-20"
classification:
type: microservice
tier: tier-1 # Critico per il business
lifecycle: production # development | staging | production | deprecated
domain: e-commerce
subdomain: payments
ownership:
team: team-checkout
team_lead: "mario.rossi"
product_owner: "anna.bianchi"
on_call:
primary: "checkout-oncall-primary"
secondary: "checkout-oncall-secondary"
escalation: "engineering-manager"
slack_channel: "#team-checkout"
email: "team-checkout@company.io"
technical:
language: TypeScript
framework: NestJS
runtime: Node.js 20
repository: "github.com/company/checkout-service"
ci_cd: GitHub Actions
deployment: ArgoCD
container_image: "ghcr.io/company/checkout-service"
infrastructure:
kubernetes:
cluster: production-eu
namespace: checkout
replicas: 3
database:
type: PostgreSQL
instance: "checkout-db-prod"
version: "15.4"
cache:
type: Redis
instance: "checkout-redis-prod"
sla:
availability: "99.95%"
rto: "15 minutes" # Recovery Time Objective
rpo: "5 minutes" # Recovery Point Objective
response_time_p99: "200ms"
throughput: "1000 rps"
dependencies:
provides:
- api: checkout-api
type: REST
docs: "https://docs.company.io/checkout-api"
consumes:
- service: payment-gateway
api: payment-api
criticality: hard
- service: inventory-service
api: inventory-api
criticality: soft
- service: notification-service
api: notification-api
criticality: soft
サービスの所有権と説明責任
La サービスの所有権 これはサービス カタログの最も重要な概念の 1 つです。 各サービスには責任を持った所有者として明確に識別されたチームが必要です 開発、メンテナンス、オンコール、インシデント対応用に定義されています。
実効所有権の原則は次のとおりです。
- 明確な所有権: 各サービスには 1 人のチーム所有者がいます。サービスがなく「孤児」
- フルライフサイクル: チームオーナーはサービスの設計から廃止まで責任を負います
- オンコールローテーション: 各チームには、明確なエスカレーション パスを備えた定義済みのオンコール ローテーションがあります。
- 知識の共有: ドキュメントが更新されてアクセス可能になり、バス係数が減少します。
孤立したサービスの問題
中規模組織のサービスの 30 ～ 40% には明らかに所有者がいません 特定された。これら 孤立したサービス それらは事故の主な原因の一つです 長期化する: 何か問題が発生したとき、誰に連絡すればよいのか、どのように介入すればよいのか誰もわかりません。 サービス カタログは、所有権を明示的かつ可視にすることで、この問題を解決します。
CMDB: 構成管理データベース
Il CMDB (構成管理データベース) およびサービス カタログ コンポーネント 私を追跡するもの 構成アイテム (CI): すべてのリソース、構成、関係 ITインフラを構成するものです。サービス カタログは次の情報に重点を置いていますが、 ビジネス (所有権、SLA、依存関係) の場合、CMDB は構成の詳細なビューを提供します。 テクニック。
- 設定項目: サーバー、コンテナ、データベース、ロードバランサ、証明書、DNS レコード
- 人間関係: 構成アイテム間の「実行」、「依存」、「接続」
- 変更の追跡: 各 CI に対するすべての変更履歴、誰が、いつ、なぜ変更したか
- コンプライアンス: CI が組織のポリシー (バージョン、パッチ、構成) に準拠していることを確認します。
# CMDB: Configuration Items e relazioni
configuration_items:
- id: ci-checkout-pod-01
type: kubernetes_pod
name: "checkout-service-7d8f9b6c4d-xk2mn"
status: running
properties:
image: "ghcr.io/company/checkout:v2.3.1"
cpu_request: "500m"
memory_request: "512Mi"
node: "worker-node-03"
relationships:
- type: runs-in
target: ci-checkout-namespace
- type: connects-to
target: ci-checkout-db
- type: connects-to
target: ci-checkout-redis
- id: ci-checkout-db
type: rds_instance
name: "checkout-db-prod"
status: available
properties:
engine: "postgres 15.4"
instance_class: "db.r6g.large"
storage: "50GB"
encrypted: true
multi_az: true
backup_retention: 30
relationships:
- type: used-by
target: ci-checkout-pod-01
- type: backed-up-to
target: ci-checkout-db-snapshots
- id: ci-checkout-redis
type: elasticache_cluster
name: "checkout-redis-prod"
status: available
properties:
engine: "redis 7.0"
node_type: "cache.r6g.large"
encryption_at_rest: true
encryption_in_transit: true
change_history:
- ci_id: ci-checkout-db
timestamp: "2026-01-15T14:30:00Z"
change_type: "configuration_update"
description: "Upgraded from db.r6g.medium to db.r6g.large"
performed_by: "platform-team"
ticket: "INFRA-4521"
approved_by: "tech-lead"
依存関係マッピングと影響分析
サービス カタログの最も価値のある機能の 1 つは、データをマップする機能です。 依存症 サービス間で実行する 影響分析。とき サービスに問題がある場合、依存関係マップを使用すると、どのサービスに問題があるのかをすぐに理解できます。 他のサービスが影響を受ける場合は、担当チームに通知する必要があります。
- ハード依存関係: サービスはこの依存関係なしでは動作できません (例: データベース)
- ソフト依存関係: サービスは、この依存関係がないと機能が低下して動作します (通知サービスなど)。
- 上流の依存関係: 私が依存しているサービス
- 下流の依存関係: 私に依存するサービス
影響分析は、次のような場合に特に役立ちます。 ウィンドウを変更する: 前 コンポーネントのメンテナンスを実行すると、チームはエコシステム全体への影響を検証できます 必要な通知とロールバックをスケジュールします。
自動検出と同期
手動更新が必要なサービス カタログは、すぐに廃止されます。このため、 現代の IDP は、次のメカニズムを実装しています。 自動検出 入力および更新される カタログが自動的に作成されます。
- Kubernetes の検出: ネームスペースとデプロイメントをスキャンしてアクティブなサービスを特定します
- GitHub/GitLab の検出: リポジトリをスキャンして、catalog-info.yaml ファイルを見つけます。
- クラウドプロバイダーの発見: クラウド API をクエリしてリソース (RDS、S3、Lambda) をインベントリに追加する
- ネットワークディスカバリ: 文書化されていない依存関係を特定するためのネットワーク トラフィックの分析
# Auto-discovery: configurazione per Backstage entity provider
catalog:
providers:
# Discovery da GitHub: cerca catalog-info.yaml in tutti i repo
github:
company:
organization: "company"
catalogPath: "/catalog-info.yaml"
filters:
branch: "main"
repository: ".*" # Tutti i repository
schedule:
frequency: { minutes: 30 }
timeout: { minutes: 3 }
# Discovery da Kubernetes: importa workloads come entità
kubernetes:
production:
cluster: production-eu
processor:
namespaceOverride: false
defaultOwner: platform-team
schedule:
frequency: { minutes: 15 }
# Discovery da AWS: importa risorse cloud
awsS3:
production:
region: eu-west-1
schedule:
frequency: { hours: 1 }
rules:
- allow:
- Component
- API
- Resource
- System
- Domain
- Group
- User
サービス カタログのベスト プラクティス
サービスカタログが存在する必要があります 唯一の真実の情報源 すべての情報について 組織のサービスについて。すべてのツール (モニタリング、インシデント管理、CI/CD) は次のことを読む必要があります。 個別のコピーを保持するのではなく、カタログから情報を取得します。これにより重複が排除されます データの一貫性を確保します。
ガバナンスと監査
サービス カタログは、 ITガバナンス 組織の。 これにより、以下を実装できるようになります。
- コンプライアンスチェック: すべてのサービスが組織のポリシー (定義された SLA、割り当てられた所有者、現在のドキュメント) に準拠していることを確認します。
- セキュリティレビュー: 脆弱な依存関係、安全でない構成、または期限切れの証明書を持つサービスを特定します。
- コスト配分: インフラストラクチャのコストをチームおよびサービスに関連付けて完全に可視化します
- 監査証跡: サービスと構成に対するすべての変更の完全な履歴を維持します。
適切に管理されたサービス カタログは、ガバナンスを官僚的で事後的なプロセスから変革します。 速度を落とすことなく継続的なコンプライアンスを確保する、自動化されたプロアクティブなシステムへの移行 開発。