4. 服务画像概念
在平台工程与 SRE 的融合实践中，服务画像是构建值班台可观测性与容量规划的基础数据模型。它并非简单的元数据清单，而是对服务全生命周期状态的结构化数字映射，为值班人员提供“一眼可知”的服务健康视图。
4.1 服务画像的定义
服务画像（Service Profile）是指：围绕一个业务服务，将其运行态所需的静态属性、动态指标、依赖关系、成本归属及可靠性目标进行结构化建模，形成一份可被平台自动采集、查询与更新的数字档案。在值班场景中，画像直接决定了告警聚合、故障定界、容量评估的准确性与效率。
核心观点： 没有服务画像的值班台，如同没有病历本的急诊室——每一次故障都需要从零开始排查。
4.2 服务画像的构成要素
一个完整的服务画像由四大要素构成：元数据、依赖、SLO、成本。四者缺一不可，共同支撑值班决策。
| 构成要素 | 定义 | 典型字段 | 值班场景价值 |
|---|---|---|---|
| 元数据 | 服务的静态身份与归属信息 | 服务名、Owner、Git仓库、部署环境、PaaS集群 | 快速定位负责人与部署位置 |
| 依赖 | 服务运行时上下游调用关系 | 上游API、下游DB/缓存/消息队列、外部SaaS | 故障影响面分析与根因链路追溯 |
| SLO | 服务承诺的可靠性量化目标 | 延迟P99、错误率、可用性SLI、燃烧率 | 告警分级与值班响应优先级判定 |
| 成本 | 服务消耗的基础设施与平台资源 | CPU/内存配额、Pod副本数、云资源月费 | 容量规划与资源扩缩容决策 |
4.3 服务画像的用途
服务画像在平台工程体系中承担着数据底座的角色，其核心用途可归纳为以下四个维度：
- 值班台上下文注入：当告警触发时，画像自动携带服务元数据、依赖拓扑与SLO状态，减少值班人员的信息拼图时间。
- 故障定界与影响分析：基于依赖关系图，快速判断故障是自身问题还是上游引发，并评估下游受影响的服务范围。
- 容量规划基线：画像中的成本与资源使用数据，为容量预测模型提供历史基线，支持“按服务画像”进行精细化扩缩容。
- 平台自服务门户：开发团队通过画像自助查询服务健康、成本归属与SLO达成情况，降低对SRE的依赖。
实践建议： 画像数据应存储在平台统一的CMDB或服务目录中，并通过API对外暴露。建议使用YAML或JSON Schema定义画像模板，确保各团队录入格式一致。
4.4 服务画像数据模型示例
以下是一个简化的服务画像YAML定义，展示了四大要素的字段结构：
service_profile:
metadata:
name: "order-service"
owner: "team-payment"
git_repo: "https://git.company.com/payment/order-service"
environment: "production"
cluster: "k8s-prod-01"
dependencies:
upstream:
- "user-service"
- "inventory-service"
downstream:
- "payment-db (MySQL)"
- "order-cache (Redis)"
- "notification-queue (Kafka)"
slo:
latency_p99_ms: 200
error_rate_percent: 0.1
availability_sli: 99.95
burn_rate_warning: 2.0
cost:
cpu_cores: 8
memory_gb: 32
pod_replicas: 6
monthly_cloud_cost_usd: 4500
4.5 服务画像与值班台的关系
下面的SVG图展示了服务画像在值班台中的核心位置——它作为数据枢纽，连接着可观测性采集、告警引擎与值班人员的决策界面。
4.6 画像驱动的容量规划闭环
服务画像中的成本要素与SLO要素共同构成了容量规划的输入输出闭环。下面的SVG图展示了这一闭环流程：
常见误区： 很多团队只维护元数据和依赖，忽略了SLO与成本要素。这会导致容量规划缺乏量化目标，值班台无法判断“资源是否够用”以及“扩容是否值得”。服务画像的四大要素必须同步维护，缺一不可。