2. 值班台服务画像定义

服务画像是 SRE 值班台对生产服务进行标准化描述的元数据集合。它把分散在 CMDB、监控系统、工单平台和工程师头脑中的服务信息，提炼为一组结构化的关键属性，使值班人员能在 30 秒内理解“这个服务是什么、它有多重要、出问题该找谁、它依赖谁”。

2.1 服务画像概念

服务画像（Service Profile）是对一个生产服务在值班场景下的完整描述，包含其身份标识、可靠性承诺、运维责任人和上下游依赖关系。它与传统 CMDB 配置项的区别在于：

在值班台场景中，服务画像必须满足“三可”原则：可搜索（值班人员能通过服务名或别名快速定位）、可理解（非该服务开发人员也能看懂 SLO 和依赖）、可行动（画像中直接包含应急联系人和恢复步骤）。

2.2 关键属性详解

一个完整的服务画像包含以下四个核心属性，缺一不可：

1. 服务名（Service Name）：全局唯一的服务标识，通常采用“业务域-子系统-模块”三级命名规范，例如 payment-gateway-core。必须包含别名列表，因为不同团队可能使用不同的名称指代同一服务。
2. SLO（Service Level Objective）：服务等级目标，是值班台判断服务是否健康的基准线。至少包含三个维度：可用性（如 99.95%）、延迟（如 p99 < 200ms）、错误率（如 < 0.1%）。SLO 必须附带测量窗口（如 28 天滚动）和排除条件（如计划内维护不计入）。
3. 负责人（Owner）：包含开发团队、值班联系人、技术经理和备份联系人。每个角色必须提供即时通讯工具 ID 和电话，且至少有一个 7×24 可触达的应急联系人。
4. 依赖关系（Dependencies）：该服务正常运行所依赖的其他服务、中间件或基础设施。分为强依赖（服务不可用则本服务直接故障）和弱依赖（服务降级但可用）。依赖关系必须标注方向（上游/下游）和协议（HTTP/gRPC/消息队列等）。

2.3 画像在值班中的作用

服务画像在值班台的实际运作中承担三个关键角色：

• 告警上下文注入：当告警触发时，值班台自动将告警消息与对应服务的画像绑定，在告警卡片中直接展示 SLO 当前状态、负责人和依赖关系，减少值班人员“查背景”的时间。
• 事件优先级判定：根据画像中的 SLO 和依赖关系，自动计算告警的影响范围。例如：一个核心支付服务的 p99 延迟告警，其优先级自动高于一个内部工具服务的完全不可用告警。
• 应急响应导航：画像中预置的依赖关系图可以直接生成“故障树”，值班人员按图索骥，从受影响服务出发，逐层排查上游依赖，快速定位根因。

2.4 服务画像的依赖关系建模

依赖关系是服务画像中最复杂也最有价值的部分。一个服务通常有 5~20 个直接依赖，而间接依赖可能多达上百个。值班台需要的是“可执行的依赖拓扑”，而非完整的架构图。推荐使用以下方式建模：

2.5 服务画像的自动化维护

服务画像不能靠人工维护，必须通过自动化手段保持实时性。推荐以下数据采集方式：

• 服务注册中心：从 Consul/Nacos/Eureka 等注册中心自动同步服务名、实例数和健康状态。
• 调用链系统：从 Jaeger/Zipkin/SkyWalking 中提取服务间的调用关系和依赖方向。
• 监控系统：从 Prometheus/Grafana 中获取 SLO 指标的当前值和历史趋势。
• CMDB/工单系统：同步负责人、团队信息和变更记录。

自动化采集的频率建议：服务名和依赖关系每 5 分钟同步一次，SLO 指标实时更新（1 分钟粒度），负责人信息每日从 CMDB 同步。当检测到画像数据与采集源不一致时，自动触发告警通知画像维护团队。