06 - Service Catalog e CMDB: Gestione e Governance dei Servizi

Service Catalog: L'Inventario dell'Organizzazione

Un Service Catalog e il registro centralizzato e autoritativo di tutti i servizi, componenti e risorse software di un'organizzazione. Rappresenta la "mappa" del panorama tecnologico aziendale: chi possiede cosa, come i servizi sono interconnessi, quali SLA sono garantiti e qual è lo stato di salute di ogni componente.

Senza un service catalog, le organizzazioni in crescita soffrono di shadow IT: servizi di cui nessuno conosce l'esistenza, dipendenze non documentate, ownership ambigua e incidenti che richiedono ore per essere risolti perchè nessuno sa chi contattare. Il service catalog risolve questi problemi fornendo una single source of truth per l'intero ecosistema software.

Modellare il Service Catalog

Un service catalog efficace si basa su un modello dati ben progettato che cattura le informazioni essenziali su ogni componente dell'ecosistema. Le entità principali sono:

• Service: un microservizio, un'applicazione o un sistema che esegue una funzione di business
• API: un'interfaccia esposta o consumata da un servizio (REST, gRPC, GraphQL, eventi Kafka)
• Resource: una risorsa infrastrutturale (database, cache, message queue, storage)
• Library: una libreria condivisa usata da più servizi
• Team: il gruppo responsabile della manutenzione e dell'operazione di uno o più servizi

# 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
      

Service Ownership e Accountability

La service ownership e uno dei concetti più importanti del service catalog. Ogni servizio deve avere un team chiaramente identificato come proprietario, con responsabilità definite per sviluppo, manutenzione, on-call e incident response.

I principi di una ownership efficace sono:

• Clear ownership: ogni servizio ha esattamente un team owner. Nessun servizio e "orfano"
• Full lifecycle: il team owner e responsabile dalla progettazione alla dismissione del servizio
• On-call rotation: ogni team ha una rotazione on-call definita con escalation paths chiari
• Knowledge sharing: la documentazione e aggiornata e accessibile, riducendo il bus factor

CMDB: Configuration Management Database

Il CMDB (Configuration Management Database) e un componente del service catalog che traccia i Configuration Items (CI): ogni risorsa, configurazione e relazione che compone l'infrastruttura IT. Mentre il service catalog si focalizza sulle informazioni di business (ownership, SLA, dipendenze), il CMDB fornisce una vista dettagliata della configurazione tecnica.

• Configuration Items: server, container, database, load balancer, certificati, DNS records
• Relationships: "runs-on", "depends-on", "connected-to" tra configuration items
• Change tracking: storico di tutte le modifiche a ogni CI, con chi, quando e perchè
• Compliance: verifica che i CI rispettino le policy organizzative (versioni, patch, configurazioni)

# 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"
      

Dependency Mapping e Impact Analysis

Una delle funzionalità più preziose del service catalog e la capacità di mappare le dipendenze tra servizi e eseguire impact analysis. Quando un servizio ha un problema, la mappa delle dipendenze permette di capire immediatamente quali altri servizi sono impattati e di notificare i team responsabili.

• Hard dependencies: il servizio non può funzionare senza questa dipendenza (es. database)
• Soft dependencies: il servizio funziona in modo degradato senza questa dipendenza (es. servizio di notifiche)
• Upstream dependencies: servizi da cui dipendo
• Downstream dependencies: servizi che dipendono da me

L'impact analysis e particolarmente utile durante le change windows: prima di eseguire una manutenzione su un componente, il team può verificare l'impatto su tutto l'ecosistema e pianificare le notifiche e i rollback necessari.

Auto-Discovery e Sincronizzazione

Un service catalog che richiede aggiornamento manuale diventa rapidamente obsoleto. Per questo, le IDP moderne implementano meccanismi di auto-discovery che popolano e aggiornano automaticamente il catalogo:

• Kubernetes discovery: scansione dei namespace e dei deployment per identificare servizi attivi
• GitHub/GitLab discovery: scansione dei repository per trovare file catalog-info.yaml
• Cloud provider discovery: interrogazione delle API cloud per inventariare risorse (RDS, S3, Lambda)
• Network discovery: analisi del traffico di rete per identificare dipendenze non documentate

# 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
      

Governance e Audit

Il service catalog e un componente fondamentale per la governance IT dell'organizzazione. Permette di implementare:

• Compliance checks: verificare che tutti i servizi rispettino le policy organizzative (SLA definiti, owner assegnato, documentazione presente)
• Security reviews: identificare servizi con dipendenze vulnerabili, configurazioni non sicure o certificati in scadenza
• Cost allocation: associare i costi infrastrutturali ai team e ai servizi per una visibility completa
• Audit trails: mantenere uno storico completo di tutte le modifiche a servizi e configurazioni

Un service catalog ben gestito trasforma la governance da un processo burocratico e reattivo a un sistema automatizzato e proattivo che garantisce compliance continua senza rallentare lo sviluppo.