3. 服务画像定义：什么是服务画像、画像的构成要素

在分布式系统故障复盘中，我们常常面临“数据太多、信息太少”的困境：成千上万条 span、数十个服务节点、海量的指标曲线，却难以在 5 分钟内定位根因。服务画像正是为解决这一矛盾而提出的核心抽象——它将一个服务在特定时间窗口内的静态拓扑关系、动态依赖行为、性能基线特征和已知错误模式提炼为一组结构化元数据，使得 MTTR 复盘可以从“大海捞针”变为“按图索骥”。

3.1 什么是服务画像

服务画像（Service Profile）是对一个微服务在正常运行态与异常运行态下的多维特征描述。它不是静态的配置文件，而是由分布式追踪数据、指标数据和日志数据实时计算出的动态快照。每一份服务画像都包含四个核心维度：

3.2 画像的构成要素详解

3.2.1 拓扑（Topology）

拓扑维度描述服务在分布式调用链中的位置与连接关系。它回答三个问题：

• 上游是谁？——哪些服务调用当前服务（caller）
• 下游是谁？——当前服务调用了哪些服务（callee）
• 调用频率与协议？——gRPC、HTTP、消息队列还是数据库直连

在 MTTR 复盘中，拓扑画像帮助团队快速绘制故障影响面：当某个服务出现延迟飙升时，拓扑画像可以立即展示其所有下游服务是否同步受损。

3.2.2 依赖（Dependency）

依赖维度比拓扑更细粒度，它记录服务所依赖的具体资源：

• 中间件依赖：Redis 集群地址、Kafka Topic、MySQL 实例
• 外部 API 依赖：第三方支付网关、认证服务、CDN
• 基础设施依赖：DNS 解析、负载均衡器、Sidecar 代理

依赖画像的关键价值在于故障隔离：当 Redis 集群出现慢查询时，依赖画像可以立即列出所有受影响的微服务，避免逐个排查。

3.2.3 性能基线（Performance Baseline）

性能基线是服务画像中最具量化价值的维度。它通常包含以下统计量：

3.2.4 错误模式（Error Pattern）

错误模式维度是 MTTR 复盘的加速器。它通过聚类分析将历史故障中的错误特征归纳为可复用的模式：

• 错误码分布：HTTP 500、503、504 的比例；gRPC UNAVAILABLE、DEADLINE_EXCEEDED 的占比
• 异常堆栈指纹：对 Java 异常栈、Go panic 栈进行哈希聚类，相同指纹归为一类
• 错误传播路径：错误从哪个服务开始，经过哪些服务被放大或转化

当新故障发生时，服务画像的错误模式维度会与当前 trace 数据进行相似度匹配，如果匹配到已知模式，可以直接给出根因建议，将 MTTR 从小时级压缩到分钟级。

3.3 服务画像的生成流程

服务画像不是人工维护的，而是由追踪系统自动构建的。以下是一个典型的画像生成流水线：

1. 数据采集层：通过 OpenTelemetry SDK 采集 trace、metrics、logs，统一输出到 OTLP 协议
2. 拓扑发现：从 trace 的 span.parent_span_id 和 span.attributes["net.peer.name"] 构建服务依赖图
3. 基线计算：使用滑动窗口算法（如 t-digest）计算 P50/P90/P99 延迟基线，存储到时序数据库
4. 错误聚类：对 span.status.code = ERROR 的 span 提取异常堆栈，使用 MinHash 算法进行相似度聚类
5. 画像存储：将四维数据合并为 JSON 文档，写入 Elasticsearch 或 ClickHouse，按 service_name + time_bucket 索引

3.4 服务画像在 MTTR 复盘中的角色

服务画像不是孤立的概念，它是整个 MTTR 复盘流程的数据底座。在后续章节中，我们将看到服务画像如何驱动以下关键环节：

• 异常检测：将实时 trace 数据与画像中的性能基线对比，自动标记异常 span
• 根因定位：通过拓扑画像缩小排查范围，通过错误模式匹配已知故障指纹
• 影响评估：利用依赖画像列出所有受影响的下游服务和业务线
• 复盘报告：将画像的快照对比作为复盘的核心证据，量化故障前后的性能变化