2. 核心概念：服务画像的定义、组成要素

服务画像是平台工程与 SRE 值班台之间的“语义桥梁”。它并非简单的 CMDB 快照，而是一组可观测、可查询、可关联的运行时元数据集合，用于在值班场景中快速回答“这个服务是什么、依赖谁、现在是否健康、过去发生了什么”。

2.1 服务画像的组成要素

五类要素构成服务画像的完整骨架，每类要素解决值班台的一个核心问题：

2.2 要素详解与落地示例

2.2.1 元数据（Metadata）

元数据是服务画像的“身份证”，提供值班台第一层上下文。关键字段包括：

• 服务标识：service_id、service_name、namespace
• 负责人信息：oncall_team、oncall_rotation、escalation_path
• SLO 定义：latency_p99_target、error_budget、availability_target
• 部署信息：cluster、region、deployment_strategy、artifact_version
• 关联文档：runbook_url、dashboard_url、design_doc

# 服务元数据示例（YAML 格式）
service:
  id: "payment-gateway"
  name: "支付网关"
  team: "payment-sre"
  slo:
    availability: "99.99%"
    latency_p99: "200ms"
  deployment:
    cluster: "prod-aws-ap-southeast-1"
    strategy: "blue-green"
  links:
    runbook: "https://runbook.internal/payment-gateway"
    dashboard: "https://grafana.internal/d/payment-gateway"

2.2.2 依赖（Dependencies）

依赖要素构建服务的拓扑关系图，是值班台进行根因定位和影响面分析的基础。依赖分为三类：

• 上游依赖：服务调用的外部 API、数据库、缓存、消息队列
• 下游依赖：调用该服务的其他服务或客户端
• 基础设施依赖：计算资源、网络、存储、DNS、证书

2.2.3 指标（Metrics）

指标是服务画像的“生命体征”，值班台通过指标判断服务是否处于健康状态。核心指标遵循 USE 方法论（利用率、饱和度、错误率）和 RED 方法论（速率、错误、延迟）：

• 黄金信号：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）
• 业务指标：请求量、成功率、响应时间分位数（p50/p90/p99）
• 资源指标：CPU 使用率、内存使用率、磁盘 IO、网络带宽

# Prometheus 指标示例（服务画像指标采集）
# 请求延迟直方图
http_request_duration_seconds_bucket{service="payment-gateway", le="0.1"} 1024
http_request_duration_seconds_bucket{service="payment-gateway", le="0.5"} 2048
http_request_duration_seconds_bucket{service="payment-gateway", le="1.0"} 3072

# 错误率
http_requests_total{service="payment-gateway", status="5xx"} 12

# 饱和度
container_memory_working_set_bytes{container="payment-gateway"} 524288000

2.2.4 日志（Logs）

日志是服务画像的“黑匣子”，提供故障发生时的详细上下文。值班台需要从日志中快速提取：

• 错误模式：异常堆栈、错误码、超时记录
• 关键事件：启动/停止、配置变更、限流触发、熔断开启
• 审计信息：操作人、操作时间、操作内容

# 结构化日志示例（JSON 格式）
{
  "timestamp": "2025-03-21T14:32:15.123Z",
  "level": "ERROR",
  "service": "payment-gateway",
  "trace_id": "abc123def456",
  "message": "上游用户服务超时",
  "context": {
    "upstream": "user-service",
    "latency_ms": 3500,
    "timeout_ms": 2000,
    "retry_count": 3
  }
}

2.2.5 事件（Events）

事件是服务画像的“历史档案”，记录服务生命周期中的所有重要变更和异常。值班台通过事件要素判断当前告警是否为已知问题：

• 告警事件：触发时间、级别、规则名称、持续时间
• 变更事件：发布、配置变更、扩缩容、数据库迁移
• 故障事件：故障开始/结束时间、影响范围、根因、处理人

# 事件记录示例
events:
  - type: "deployment"
    timestamp: "2025-03-21T10:00:00Z"
    version: "v2.3.1"
    status: "success"
    changed_files: 12

  - type: "alert"
    timestamp: "2025-03-21T14:30:00Z"
    severity: "critical"
    rule: "HighErrorRate"
    value: "5.2%"
    threshold: "1%"

2.3 五要素的关联关系

五类要素并非孤立存在，值班台的价值在于将它们关联查询。例如：

• 告警事件（事件）→ 关联服务元数据（Owner、Runbook）→ 查看当前指标（是否仍在异常）→ 查询日志（错误详情）→ 分析依赖拓扑（影响面）
• 变更事件（事件）→ 关联指标变化（延迟突增）→ 查看日志（变更后错误日志）→ 确认是否为变更引入故障

2.4 服务画像的存储与查询

服务画像数据通常存储在图数据库（如 Neo4j）或时序+文档混合存储中，以支持高效的关联查询。推荐的数据模型：