2. 服务画像基础概念：定义、核心维度（业务、技术、运维、团队）

服务画像是将微服务或应用视为一个可观测、可度量的实体，通过一组结构化的元数据与运行时指标，对其业务属性、技术架构、运维状态和团队协作进行多维度建模的产物。它是连接原始可观测数据与上层决策（如 DORA 指标评估、告警降噪策略）的语义桥梁。

2.1 服务画像的定义

服务画像（Service Profile）是一份动态更新的结构化文档，它聚合了以下三类信息：

• 静态元数据： 服务名称、Owner 团队、Git 仓库地址、技术栈、部署环境。
• 动态运行时特征： 平均响应时间、错误率、流量模式、依赖拓扑。
• 治理与契约： SLA/SLO 目标、变更频率、告警规则、On-Call 轮值表。

在 SRE 实践中，服务画像通常以 YAML 或 Protobuf 格式存储在配置中心，由 CICD 流水线或可观测平台自动维护。

# 服务画像示例（简化 YAML）
service:
  name: "payment-gateway"
  owner: "team-payment"
  tech_stack: "Go 1.21, PostgreSQL 15, Redis 7"
  criticality: "P0"                    # 业务关键性
  slo:
    latency_p99: "200ms"
    availability: "99.99%"
  dependencies:
    - "account-service"
    - "fraud-detection"
  deployment:
    strategy: "rolling-update"
    frequency: "daily"

2.2 核心维度总览

服务画像由四个核心维度构成，每个维度对应一组可观测数据与治理动作。下表总结了各维度的关注点与典型指标：

2.3 业务维度

业务维度回答“这个服务有多重要？”。它通过服务关键性分级和业务影响分析来量化：

• P0 ~ P3 分级： P0 服务中断直接导致收入损失或合规风险；P3 服务故障可容忍较长时间。
• SLA / SLO： 业务承诺的可用性与性能目标，是告警阈值设定的最高依据。
• 流量与交易量： 每秒请求数（RPS）、订单量、支付金额等，用于判断异常是否影响核心链路。

2.4 技术维度

技术维度描述服务的内部构造与外部依赖。它是告警降噪中“根因定位”的关键上下文：

• 技术栈： 编程语言、框架版本、数据库、消息队列。
• 依赖拓扑： 上游调用方与下游依赖服务，用于构建服务依赖图。
• 部署架构： 单体、微服务、Serverless；部署策略（蓝绿、金丝雀）。

2.5 运维维度

运维维度聚焦服务的可观测性与运行健康度，直接为 DORA 指标提供数据源：

• 部署频率： 每日/每周部署次数，反映交付速度。
• 变更失败率： 部署后导致故障的比例。
• 错误预算： SLO 允许的故障时间窗口，用于告警抑制。
• 资源利用率： CPU、内存、磁盘、网络 I/O，用于容量规划。

2.6 团队维度

团队维度将人纳入画像，因为 DORA 指标最终由团队行为驱动：

• Owner 与 On-Call： 明确责任归属，缩短 MTTR。
• 代码审查覆盖率： 影响变更质量。
• 知识分布： 是否存在单点故障（Bus Factor）。

2.7 服务画像四维度关系图

下图展示了四个维度如何共同构成服务画像，并驱动 DORA 指标评估与告警降噪策略：

2.8 服务画像与 DORA 指标的映射

服务画像的每个维度都直接或间接影响 DORA 四大指标。下表展示了映射关系：