2、服务画像基础概念

2.1 服务画像定义

服务画像（Service Profile）是对一个微服务或应用系统在运行态的结构化数字描述。它通过一组可观测性指标、元数据、依赖关系和历史行为记录，将服务的“身份”、“行为模式”和“健康基线”固化为可查询、可对比、可复用的知识对象。

服务画像不是静态的架构文档，而是持续演进的运行时快照，包含以下核心维度：

2.2 服务画像在故障复盘中的作用

在MTTR复盘流程中，服务画像扮演“基线锚点”和“差异探测器”的双重角色。具体作用体现在以下四个阶段：

1. 故障发现阶段：画像提供的健康基线（如P99延迟<200ms、错误率<0.1%）使异常检测不再依赖人工阈值，而是基于历史画像的统计偏离。
2. 故障定位阶段：画像中的依赖拓扑和变更历史可以快速缩小排查范围。例如：如果画像显示服务A在10分钟前刚发布v2.3.1，且依赖的Redis集群出现慢查询，则根因范围可迅速收敛。
3. 故障恢复阶段：画像记录的历史恢复动作（如“上次同类故障通过回滚v2.3.0解决”）可直接推荐给值班SRE，缩短决策时间。
4. 复盘改进阶段：通过对比故障前后画像差异，量化故障影响面（如“QPS下降40%”、“错误率上升至5%”），并识别出画像中缺失的监控盲区。

2.3 服务画像与可观测性的关系

服务画像与可观测性（Observability）是“数据”与“知识”的关系。可观测性提供原始数据流（Metrics、Logs、Traces），而服务画像是对这些数据的结构化提炼与持久化。

下图展示了服务画像在可观测性体系中的位置：

从架构图中可以清晰看到：可观测性平台是服务画像的数据底座，而服务画像引擎则是对这些数据进行二次加工与知识沉淀的中间层。两者之间的关键差异如下：

2.4 服务画像的典型数据模型

在实际工程落地中，服务画像通常以JSON Schema的形式定义。以下是一个简化示例：

{
  "service_profile": {
    "meta": {
      "service_name": "order-service",
      "version": "2.3.1",
      "team": "commerce-platform",
      "git_repo": "git@github.com:company/order-service.git",
      "environment": "production"
    },
    "resource_baseline": {
      "cpu_usage_p50": 35.2,
      "cpu_usage_p99": 78.5,
      "memory_mb_p50": 512,
      "memory_mb_p99": 1024,
      "gc_pause_ms_p99": 50
    },
    "traffic_baseline": {
      "qps_avg": 2500,
      "latency_p50_ms": 45,
      "latency_p99_ms": 180,
      "error_rate_pct": 0.05,
      "request_size_kb_p50": 4.2
    },
    "dependencies": {
      "upstream": ["api-gateway", "user-service"],
      "downstream": ["payment-service", "inventory-service"],
      "middleware": ["redis-cluster-orders", "kafka-orders-topic"],
      "database": ["mysql-orders-primary"]
    },
    "change_history": [
      {"timestamp": "2025-03-10T14:30:00Z", "type": "deploy", "version": "2.3.1", "changed_files": 12},
      {"timestamp": "2025-03-08T09:15:00Z", "type": "config", "key": "jvm.gc", "old_value": "CMS", "new_value": "G1"}
    ],
    "incident_archive": [
      {"incident_id": "INC-20250308", "severity": "P1", "root_cause": "G1GC参数配置不当",
       "mttr_minutes": 28, "recovery_action": "回滚JVM配置至CMS"}
    ]
  }
}