服务画像基础：定义与核心维度
服务画像是可观测性体系中对单个服务进行多维度特征提取与状态建模的产物。它并非静态的元数据登记表，而是融合了静态属性（技术栈、部署拓扑）与动态指标（流量水位、依赖健康）的运行时快照。在变更失败率协同场景中，服务画像为每一条变更记录提供“上下文锚点”，使风险预判从经验驱动转向数据驱动。
2.1 服务画像的定义
服务画像（Service Profile）是指：
通过采集服务在基础设施层、运行时层和业务层的关键特征，形成的一组结构化标签与量化指标集合。其核心价值在于：
- 差异化评估：不同画像的服务对应不同的变更风险基线。
- 异常定位：当变更失败率升高时，画像维度可快速缩小排查范围。
- 容量与依赖管理：画像中的流量与依赖数据直接关联变更回退策略。
关键原则：服务画像必须保持“可计算”与“可对比”。所有维度数据应能以数值或枚举形式输入到后续的 Metric Design 模型中，避免模糊描述。
2.2 核心维度总览
服务画像由四个核心维度构成，每个维度下包含若干可观测指标。下表列出各维度的定义与典型数据来源：
| 维度 | 定义 | 典型数据来源 | 变更失败率关联 |
|---|---|---|---|
| 技术栈 | 服务使用的编程语言、框架、中间件、运行时版本 | CMDB、容器镜像元数据、构建产物 | 不同技术栈的编译/部署失败模式差异显著 |
| 流量 | 服务接收的请求量、并发数、响应延迟、错误率 | APM、网关日志、服务网格指标 | 高流量服务变更失败后影响面更大，回退阈值更敏感 |
| 依赖 | 上游调用方、下游依赖服务、中间件、外部 API | 分布式追踪、服务拓扑图、依赖清单 | 依赖深度与变更失败传播速度正相关 |
| 健康度 | 服务当前及历史可用性、错误预算消耗、SLO 达成率 | 告警系统、SLO 仪表盘、事件管理平台 | 健康度低的服务变更失败容忍度更低 |
2.3 技术栈维度
技术栈维度是服务画像的“基因层”。同一变更流程在不同技术栈上的失败率可能相差数倍。需要采集的关键字段包括：
- 编程语言与版本：Java 17 vs Java 8、Go 1.21 vs 1.18，版本差异直接影响二进制兼容性。
- 框架与版本：Spring Boot 3.x vs 2.x、Express 4 vs 5，框架升级常引入破坏性变更。
- 运行时环境：JVM 参数、Node.js 内存模型、容器基础镜像（Alpine vs Ubuntu）。
- 构建与打包方式：Maven/Gradle、Docker 多阶段构建、原生编译 vs JIT。
实践建议：在 CMDB 或服务注册中心中为每个服务维护一个
tech_stack_hash 字段，将技术栈组合映射为固定哈希值。变更时对比前后哈希值，若不一致则自动标记为“高风险技术栈变更”。
2.4 流量维度
流量维度决定了变更的“爆炸半径”。核心指标分为三个层级：
| 层级 | 指标 | 采集粒度 | 变更失败率影响 |
|---|---|---|---|
| 入口流量 | QPS、TPS、并发连接数 | 分钟级 | 高 QPS 服务变更失败后流量快速堆积，触发级联超时 |
| 延迟分布 | P50/P95/P99 延迟、长尾请求占比 | 分钟级 | 延迟劣化是变更失败的早期信号，P99 比平均值更敏感 |
| 错误率 | HTTP 5xx、业务错误码、超时率 | 分钟级 | 错误率突增是变更失败的直接证据，需与基线对比 |
流量维度的关键设计原则是基线对比：不能只看值，必须与变更前 24 小时同一时间窗口的流量特征做对比，排除日常波动干扰。
2.5 依赖维度
依赖维度刻画服务的上下游关系与耦合程度。依赖越复杂，变更失败后“涟漪效应”越明显。依赖维度的核心建模要素包括：
- 依赖数量：直接下游服务数、间接下游服务数（深度）。
- 依赖类型：同步调用（HTTP/gRPC）、异步消息（Kafka/RabbitMQ）、数据存储（MySQL/Redis）。
- 依赖关键性：强依赖（调用失败则服务不可用） vs 弱依赖（可降级）。
- 依赖健康状态：下游服务的当前错误率、延迟、可用性。
常见陷阱：仅统计直接依赖而忽略间接依赖。例如服务 A 依赖 B，B 依赖 C，当 C 因变更失败宕机时，A 的失败率也会飙升。服务画像应至少记录 2 层依赖拓扑。
2.6 健康度维度
健康度维度是服务画像的“状态快照”，反映服务在变更前的运行质量。健康度低的服务对变更的容错能力更差。核心指标包括：
| 指标 | 计算方式 | 健康度阈值参考 |
|---|---|---|
| 可用性 | 1 - (错误请求数 / 总请求数) | > 99.9% 为健康，< 99.5% 为亚健康 |
| 错误预算消耗率 | 当前错误预算消耗 / 总错误预算 | < 50% 为安全，> 80% 为危险 |
| SLO 达成率 | 过去 28 天满足 SLO 的时间占比 | > 99.9% 为优秀，< 99% 需关注 |
| 告警密度 | 过去 1 小时内产生的 P0/P1 告警数量 | 0 为正常，> 3 为高风险 |
2.7 服务画像与变更失败率的协同关系
下图展示服务画像四个维度如何共同影响变更失败率的评估与决策：
2.8 画像数据的采集与更新策略
服务画像不是一次性建模，需要持续更新。推荐以下采集策略：
- 技术栈：每次 CI/CD 构建时自动采集，写入服务元数据库。
- 流量：实时流式采集（1 分钟粒度），保留 7 天滚动窗口用于基线计算。
- 依赖：每 5 分钟通过服务拓扑发现工具（如 Istio/Consul）刷新一次。
- 健康度：从 SLO 仪表盘和告警系统拉取，更新频率与告警评估周期一致（通常 1 分钟）。
画像版本化：每次变更前，系统自动生成当前服务画像的快照（profile_snapshot），与变更记录绑定。变更失败后，可直接对比变更前后的画像差异，快速定位根因。