서비스 카탈로그: 조직의 인벤토리
Un 서비스 카탈로그 모든 서비스에 대한 중앙집중적이고 권위 있는 등록, 조직의 소프트웨어 구성 요소 및 리소스. 이는 기술 환경의 "지도"를 나타냅니다. 기업: 누가 무엇을 소유하는지, 서비스가 어떻게 상호 연결되는지, 어떤 SLA가 보장되는지, 각 구성 요소의 상태는 어떻습니까?
서비스 카탈로그가 없으면 성장하는 조직은 어려움을 겪습니다. 섀도우 IT: 아무도 모르는 서비스, 문서화되지 않은 종속성, 모호한 소유권(예: 누구에게 연락해야 할지 모르기 때문에 해결하는 데 몇 시간이 걸리는 사고. 서비스 카탈로그 전체 소프트웨어 생태계에 대한 단일 정보 소스를 제공하여 이러한 문제를 해결합니다.
무엇을 배울 것인가
- 서비스 카탈로그 모델링 방법: 엔터티, 관계, 메타데이터
- 서비스 소유권: 팀, 대기 중, 에스컬레이션 경로
- SLA 추적: RTO, RPO, 가용성 목표 및 규정 준수
- CMDB(Configuration Management Database): 구성 항목 및 변경 사항 추적
- 종속성 매핑: 종속성 그래프 및 영향 분석
- 자동 검색: 카탈로그 자동 채우기
서비스 카탈로그 모델링
효과적인 서비스 카탈로그는 다음을 기반으로 합니다. 데이터 모델 잘 디자인되어 캡처 생태계의 각 구성 요소에 대한 필수 정보입니다. 주요 엔터티는 다음과 같습니다.
- 서비스: 비즈니스 기능을 수행하는 마이크로서비스, 애플리케이션 또는 시스템
- 아피스: 서비스(REST, gRPC, GraphQL, Kafka 이벤트)에서 노출되거나 사용되는 인터페이스
- 자원: 인프라 리소스(데이터베이스, 캐시, 메시지 큐, 스토리지)
- 도서관: 여러 서비스에서 사용되는 공유 라이브러리
- Team: 하나 이상의 서비스를 유지, 운영하는 업무를 담당하는 그룹
# 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 서비스 소유권 서비스 카탈로그의 가장 중요한 개념 중 하나입니다. 각 서비스에는 책임이 있는 소유자로 명확하게 식별된 팀이 있어야 합니다. 개발, 유지 관리, 대기 중 및 사고 대응을 위해 정의되었습니다.
효과적인 소유권의 원칙은 다음과 같습니다.
- 명확한 소유권: 각 서비스에는 정확히 한 명의 팀 소유자가 있습니다. 서비스 없음 및 "고아"
- 전체 수명주기: 서비스 설계부터 폐기까지 팀 오너가 책임진다
- 통화 중 순환: 각 팀에는 명확한 에스컬레이션 경로와 함께 정의된 대기 순환이 있습니다.
- 지식 공유: 문서가 업데이트되고 액세스 가능해 버스 요소가 줄어듭니다.
고아 서비스 문제
중간 규모 조직의 서비스 중 30~40%에는 분명히 소유자가 없습니다. 확인되었습니다. 이것들 고아 서비스 사고의 주요 원인 중 하나입니다 장기화: 문제가 발생하면 누구에게 연락해야 할지, 어떻게 개입해야 할지 아무도 모릅니다. 서비스 카탈로그는 소유권을 명시적이고 가시적으로 만들어 이 문제를 제거합니다.
CMDB: 구성 관리 데이터베이스
Il CMDB(구성 관리 데이터베이스) 및 서비스 카탈로그 구성 요소 나를 추적하는 것 구성 항목(CI): 모든 리소스, 구성 및 관계 IT 인프라를 구성하는 것입니다. 서비스 카탈로그는 다음에 대한 정보에 중점을 두고 있습니다. 비즈니스(소유권, SLA, 종속성)에 대해 CMDB는 구성에 대한 자세한 보기를 제공합니다. 기술.
- 구성 항목: 서버, 컨테이너, 데이터베이스, 로드 밸런서, 인증서, DNS 레코드
- 관계: 구성 항목 간 "runs-on", "dependent-on", "connected-to"
- 변경 내용 추적: 각 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"
종속성 매핑 및 영향 분석
서비스 카탈로그의 가장 중요한 기능 중 하나는 데이터를 매핑하는 기능입니다. 중독 서비스 간 및 실행 영향 분석. 언제 서비스에 문제가 있는 경우 종속성 맵을 통해 어떤 서비스에 문제가 있는지 즉시 이해할 수 있습니다. 다른 서비스도 영향을 받으며 담당 팀에 알립니다.
- 하드 종속성: 서비스는 이 종속성 없이 작동할 수 없습니다(예: 데이터베이스)
- 소프트 종속성: 서비스는 이러한 종속성 없이 성능이 저하된 방식으로 작동합니다(예: 알림 서비스).
- 업스트림 종속성: 내가 의존하는 서비스
- 다운스트림 종속성: 나에게 달려있는 서비스
영향 분석은 다음과 같은 경우에 특히 유용합니다. 창 변경: 이전 구성 요소에 대한 유지 관리를 수행하면 팀이 전체 생태계에 미치는 영향을 확인할 수 있습니다. 필요한 알림 및 롤백을 예약합니다.
자동 검색 및 동기화
수동 업데이트가 필요한 서비스 카탈로그는 빠르게 쓸모 없게 됩니다. 이런 이유로, 현대 IDP는 다음과 같은 메커니즘을 구현합니다. 자동 검색 채우고 업데이트하는 것 카탈로그가 자동으로:
- 쿠버네티스 발견: 네임스페이스 및 배포를 스캔하여 활성 서비스 식별
- 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, 할당된 소유자, 현재 문서)을 준수하는지 확인합니다.
- 보안 검토: 취약한 종속성, 안전하지 않은 구성 또는 만료되는 인증서가 있는 서비스 식별
- 비용 할당: 완전한 가시성을 위해 인프라 비용을 팀 및 서비스와 연관시킵니다.
- 감사 추적: 서비스 및 구성에 대한 모든 변경 사항에 대한 전체 기록을 유지합니다.
잘 관리되는 서비스 카탈로그는 관료적이고 반응적인 프로세스에서 거버넌스를 변화시킵니다. 속도 저하 없이 지속적인 규정 준수를 보장하는 자동화된 사전 예방적 시스템으로 개발.