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.
Cosa Imparerai
- Come modellare un service catalog: entità, relazioni, metadati
- Service ownership: team, on-call, escalation paths
- SLA tracking: RTO, RPO, availability targets e compliance
- CMDB (Configuration Management Database): configuration items e change tracking
- Dependency mapping: grafi di dipendenze e impact analysis
- Auto-discovery: popolamento automatico del catalogo
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
Il Problema dei Servizi Orfani
Il 30-40% dei servizi nelle organizzazioni di medie dimensioni non ha un owner chiaramente identificato. Questi servizi orfani sono una delle principali cause di incidenti prolungati: quando qualcosa va storto, nessuno sa chi contattare o come intervenire. Il service catalog elimina questo problema rendendo l'ownership esplicita e visibile.
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
Best Practice per il Service Catalog
Il service catalog deve essere la single source of truth per tutte le informazioni sui servizi dell'organizzazione. Ogni tool (monitoring, incident management, CI/CD) deve leggere le informazioni dal catalogo invece di mantenere copie separate. Questo elimina la duplicazione e garantisce la coerenza dei dati.
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.