Business & Tech Metric

解决什么问题：让团队同时看清"业务在跑"和"系统在跑"—— 只看技术 = 系统活着但业务已死； 只看业务 = 业务好但不知道为什么； 两者结合 = 真正的运营视角。

它是什么

业务指标（Business Metric） 衡量业务目标达成度—— 订单量、GMV、用户活跃、转化率、留存率。

技术指标（Tech Metric） 衡量系统运行状态—— QPS、延迟、错误率、CPU、内存、可用率。

两者必须配合使用——业务指标告诉你"效果如何"，技术指标 告诉你"为什么是这个效果 / 下次能不能更好"。

                  ┌──────────────┐
                  │  业务目标     │ ← 业务指标（订单 / GMV）
                  └──────┬───────┘
                         │
                         ↓
                  ┌──────────────┐
                  │  系统行为     │ ← 技术指标（QPS / 延迟）
                  └──────┬───────┘
                         │
                         ↓
                  ┌──────────────┐
                  │  调节决策     │ ← 看两者差值
                  └──────────────┘

SE@G Ch 7： "Engineering productivity is not just about lines of code. It is about how engineering work translates to business outcomes. You need both engineering metrics and business metrics to know if you are succeeding."

V2 视角（V2 B5）：业务指标 + 技术指标 = 反馈环的两个轴—— 只用一个轴 = 视野受限、决策片面；两个轴交叉验证 = 看清全貌。

关键属性

属性	业务指标	技术指标
衡量对象	业务结果（用户 / 收入 / 价值）	系统状态（资源 / 性能 / 稳定）
时间尺度	天 / 周 / 月	秒 / 分钟 / 小时
数据源	业务事件、订单、行为	监控埋点、日志、链路
责任方	业务 / 产品 / 运营	工程 / SRE / 运维
变化速度	慢（业务演进）	快（系统波动）
解释成本	高（需因果分析）	低（直接反映）
易失真	易（业务定义常变）	较难（指标定义稳定）
易获取	难（依赖事件流）	容易（系统自带）

怎么用

场景 1：双指标仪表盘

┌─────────────────┬─────────────────┐
│  业务指标（周）  │  技术指标（实时）│
├─────────────────┼─────────────────┤
│ DAU: 100w       │ QPS: 5000       │
│ GMV: 5000w      │ P99: 180ms      │
│ 转化率: 3.2%    │ 错误率: 0.05%   │
│ 留存率: 65%     │ 可用率: 99.97%  │
└─────────────────┴─────────────────┘
         │                  │
         └────────┬─────────┘
                  ↓
         联合解读：技术没退化但业务下滑？
         → 不是技术问题，是市场 / 产品问题

关键：业务指标异常时，第一反应不是查技术指标—— 但要用技术指标排除"是不是系统故障影响了业务"。

场景 2：用技术指标反推业务根因

现象：GMV 下降 10%
  │
  ├─ 检查技术指标：可用率 99.95%（正常）
  ├─ 检查业务指标：转化率下降 8%
  │     │
  │     ↓
  │   检查行为指标：加购率正常，支付率下降
  │     │
  │     ↓
  │   根因：支付成功率从 95% → 88%
  │     │
  │     ↓
  │   进一步检查：支付服务 P99 从 200ms → 800ms
  │     │
  │     ↓
  │   结论：支付服务慢 → 用户放弃 → GMV 下降
  │
  └─ 如果只看 GMV，永远不知道为什么

场景 3：技术指标好但业务差——假象识别

场景：双 11 大促当天
  - 技术指标：QPS 涨 5 倍、P99 涨 1 倍、错误率稳定
  - 业务指标：GMV 涨 2 倍（小于去年 3 倍）

表面看：系统稳、业绩好。
实际看：转化率从 8% → 5%，用户放弃率上升。

→ 业务增长低于系统能力 = 业务侧问题
   （流量来源、用户画像、活动设计等）

原则：技术指标稳 = 必要条件，不是充分条件—— 系统稳了业务未必好，反过来业务好了系统未必稳。

场景 4：业务驱动的技术指标设计

业务诉求：用户下单后 5 秒内看到确认页
  │
  ↓
拆解到技术指标：
  - 下单 API P99 < 1s
  - 支付回调 P99 < 500ms
  - 确认页渲染 P99 < 500ms
  - 数据库写入 P99 < 200ms

  │
  ↓
形成 SLO 链路：
  端到端 P99 < 5s（业务 SLO）
    = 各环节 SLO 之和（技术 SLO）

IDDD Ch 8：业务事件 = 各 BC 技术事件的聚合

常见误区

1. "只看技术指标就够了"——错。技术活着 ≠ 业务活着—— 系统正常但转化率 0 = 仍然是失败的运营
2. "业务指标 = 唯一真相"——错。业务指标有"归因模糊"问题—— GMV 下降可能由 10 个因素造成，技术指标能定位到具体环节
3. "指标越多越好"——错。指标泛滥 = 没人看——核心 3-5 个指标要看，其余存档
4. "业务指标和技术指标分开管理"——错。必须同一个人 / 同一份仪表盘看， 否则两边割裂，决策失真
5. "指标定义一次写好"——错。业务演化 = 指标定义演化—— "订单"定义变了，指标算法必须跟着变（V2 B7）

关键洞察

业务指标 = 目的，技术指标 = 手段；两者必须同时看。

只看技术 = 在完美地做没用的事； 只看业务 = 不知道为什么有用 / 没用； 业务 + 技术 = 既看清方向，又看清路径。

相关链接

• SLO——指标的承诺形式
• 告警——指标超阈值的响应
• 闭环反馈——指标是闭环的输入
• 数据驱动——指标驱动决策
• [V3 涌现作为] · 反馈——指标的 V2 定位
• [V3 涌现之时] · 演化——指标定义随业务演化