1. 服务画像概述
1.1 服务画像的定义
服务画像是对单个服务在运行态所有可观测维度的结构化数字快照。它把散落在监控、日志、调用链、CMDB、变更系统、事件平台中的原始数据，按统一元模型聚合为服务级特征向量，使每个服务都拥有一份可量化、可对比、可预测的“数字身份”。
核心公式： 服务画像 = 静态元数据 + 动态运行时指标 + 历史行为模式 + 依赖拓扑
服务画像不是静态的 CMDB 属性表，而是随时间推移不断自更新的时序特征集合。它覆盖以下维度：
| 维度 | 典型字段 | 数据来源 |
|---|---|---|
| 基础元数据 | 服务名称、Owner、Git 仓库、语言栈、框架版本 | CMDB / 代码扫描 |
| 运行时指标 | QPS、P99 延迟、错误率、CPU/内存水位 | 监控系统（Prometheus / Datadog） |
| 依赖拓扑 | 上游调用方、下游依赖、中间件、DB、缓存 | 调用链 / 服务网格 |
| 变更特征 | 发布频率、回滚率、配置变更次数 | CI/CD 平台 / 变更管理 |
| 事件历史 | MTBF、MTTR、告警收敛比、故障类型分布 | 事件管理平台（PagerDuty / Opsgenie） |
| 容量特征 | 资源规格、利用率峰值、扩缩容记录、限流触发次数 | 容器平台 / 容量管理系统 |
1.2 核心价值
服务画像在 SRE 日常工作中提供四个关键价值：
- 标准化认知 — 消除团队对同一服务的理解偏差，所有 SRE 和研发看到同一份“服务身份证”。
- 异常快速定位 — 当告警触发时，画像提供基线对比，一眼识别是“正常波动”还是“画像漂移”。
- 容量预测基础 — 只有建立服务级资源画像，才能基于历史趋势做精准的容量预测与资源规划。
- 自动化决策输入 — 弹性伸缩、故障自愈、混沌实验等自动化动作依赖画像作为输入特征。
实践建议： 服务画像的初始版本不必追求全维度覆盖。建议从“运行时指标 + 依赖拓扑”两个维度起步，每两周迭代一个维度，3 个月内完成全维度覆盖。
1.3 在 SRE 体系中的定位
服务画像处于 SRE 数据中台的核心枢纽位置，向上支撑稳定性治理，向下整合可观测数据。下图展示了服务画像在 SRE 体系中的定位：
从图中可以看出，服务画像处于数据采集层与业务价值层之间的桥梁位置。它不直接产生稳定性，但所有稳定性能力——异常检测、容量预测、故障定位、自动化决策——都依赖画像提供标准化输入。
1.4 服务画像与相关概念的关系
| 概念 | 与服务画像的关系 | 区别 |
|---|---|---|
| CMDB | CMDB 是画像的静态数据源之一 | CMDB 偏资产配置，画像包含运行时动态特征 |
| 资源画像 | 资源画像是服务画像的子集，聚焦 CPU/内存/存储 | 服务画像更全面，包含业务指标、依赖、变更等 |
| 应用拓扑 | 拓扑是画像的依赖维度 | 拓扑只描述连接关系，画像包含时序指标与行为 |
| SLI/SLO | SLI 是画像的黄金指标维度 | SLO 是目标，画像是实际运行状态的记录 |
常见误区： 不要把服务画像做成“大而全的 CMDB”。画像的核心价值在于动态基线和趋势分析，而非静态属性堆砌。如果画像数据超过 24 小时未更新，它就已经开始贬值。
1.5 服务画像的成熟度模型
根据业界实践，服务画像的建设可分为四个成熟度阶段：
- L1 — 手工台账： 依赖人工维护 Excel 或 Wiki，数据滞后、不完整、不可信。
- L2 — 自动化采集： 从监控、CMDB 自动拉取数据，但各维度独立存储，缺乏关联分析。
- L3 — 统一画像引擎： 建立画像元模型，多维度数据归一聚合，支持基线对比与趋势分析。
- L4 — 智能画像自治： 画像自动发现新服务、自动更新依赖、自动识别画像漂移并触发修复流程。
课程目标： 本课程将帮助团队从 L2 向 L3 跨越，建立可落地的服务画像引擎，并基于画像开展资源画像、MTTR 复盘与容量预测工作。