别再把平台当“工具人”：Platform as a Product 的指标、旅程与团队 KPI 怎么设计才不跑偏？

大家好，我是 Echo_Wish。

这几年我在做运维、DevOps 和平台工程的过程中，发现一个特别有意思的现象：

很多公司喊着“平台化”“内部 PaaS”“自服务平台”，
结果平台团队活得像救火队。

• 业务方觉得你是“支持部门”
• 领导觉得你是“成本中心”
• 团队自己也不知道成功标准是什么

问题出在哪？

你把平台当系统在建设，而不是当产品在运营。

今天我们就聊聊：
Platform as a Product：指标怎么定？用户旅程怎么设计？团队 KPI 怎么不背锅？

一、Platform as a Product，本质不是技术升级，而是思维升级

传统运维视角是：

“我们把基础设施搭好，业务来用就行。”

产品视角是：

“谁是我的用户？他们痛在哪？我怎么降低他们的认知成本？”

这两种思维的差别巨大。

平台的“用户”是谁？

• 开发工程师
• 测试工程师
• SRE
• 数据团队
• AI 团队

如果他们用得痛苦，那平台再“技术先进”都没用。

二、指标怎么定？别只盯 SLA

很多平台团队 KPI 是：

• 可用性 99.99%
• 故障次数 < 3 次
• CPU 利用率 70%

这些重要，但远远不够。

如果你真的把平台当产品，你的指标应该分三层：

第一层：可靠性指标（基础健康）

• SLA / SLO
• MTTR
• 资源利用率
• 故障恢复时间

例如，基于 Prometheus 做 SLO 计算：

# 计算 5 分钟窗口内成功率
import requests

query = """
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
"""

resp = requests.get(
    "http://prometheus:9090/api/v1/query",
    params={
   "query": query}
)

print(resp.json())

但这只是底线。

第二层：用户体验指标（核心指标）

你要问：

• 新服务从创建到上线多久？
• 开发自助部署成功率多少？
• 一个新同学上手平台要几天？

这才是真正的平台价值。

举个例子，统计“从 Git push 到生产可用”的平均时长：

import pandas as pd

df = pd.read_csv("deploy_logs.csv")

df["duration"] = pd.to_datetime(df["prod_ready_time"]) - \
                 pd.to_datetime(df["git_push_time"])

print("平均交付时长：", df["duration"].mean())

如果平均 3 天，你的平台其实是在拖业务后腿。

平台真正的价值是：

缩短交付周期，而不是堆高可用性。

第三层：产品增长指标（容易被忽略）

如果平台是产品，那也应该有“增长指标”：

• 平台使用率
• 自助部署比例
• 模板使用覆盖率
• 标准化流水线覆盖率

比如：

# 统计使用标准流水线的项目占比
total_projects = 120
standard_pipeline_projects = 85

adoption_rate = standard_pipeline_projects / total_projects
print("标准化流水线覆盖率：", adoption_rate)

如果 adoption 只有 30%，说明什么？

说明业务在“绕开你”。

三、用户旅程：平台也有“漏斗模型”

我们可以把开发者使用平台的路径拆成旅程：

1️⃣ 发现平台
2️⃣ 创建服务
3️⃣ 配置 CI/CD
4️⃣ 部署测试
5️⃣ 发布生产
6️⃣ 运维监控

每一步都可能“流失”。

比如：

• 创建服务太复杂
• YAML 配置太难
• 权限申请要三天

那用户自然回到“手工 + 人肉运维”。

一个简单的分析方式：

journey = {
   
    "create_service": 100,
    "config_pipeline": 80,
    "test_deploy": 60,
    "prod_release": 55
}

for step, count in journey.items():
    print(step, "转化率:", count / 100)

如果转化率在第二步掉得厉害，
问题不是 SLA，而是产品设计。

平台团队要像产品经理一样思考：

哪一步体验最差？哪里是“卡点”？

四、团队 KPI 怎么设计才不背锅？

很多平台团队 KPI 是：

• 故障零容忍
• 事故必须为 0
• 变更必须审批

结果就是：

• 团队保守
• 不敢创新
• 推不动自动化

我个人更倾向的 KPI 设计是三块：

1️⃣ 稳定性 KPI（保底）

• SLO 达标率
• P1 事故数量
• MTTR

2️⃣ 效率 KPI（对业务负责）

• 交付周期缩短比例
• 人均运维服务数
• 自动化率提升

例如：

baseline = 5.0  # 之前平均交付 5 天
current = 2.8   # 当前 2.8 天

improvement = (baseline - current) / baseline
print("交付效率提升：", improvement)

3️⃣ 平台产品 KPI（对未来负责）

• 平台 NPS（内部满意度）
• 自助化比例
• 工单数量下降率

平台团队不能只对“事故负责”，
还要对“效率和体验负责”。

否则你永远是“高级运维”。

五、一个现实问题：平台是成本中心还是增长引擎？

说句真心话。

如果平台只保证稳定，那它永远是成本中心。

但如果平台能做到：

• 让业务 1 天上线
• 让 AI 团队 10 分钟拉起训练环境
• 让测试自动化覆盖率翻倍

那它就是增长引擎。

Platform as a Product 的终极目标不是：

把机器管好。

而是：

让组织更快。

六、我的一点感受

这些年做平台，我最大的体会是：

平台最大的敌人不是技术难度，
而是“自嗨”。

我们很容易沉迷：

• 架构优雅
• Kubernetes 多集群
• Service Mesh
• GitOps

但用户只关心一件事：

我能不能更快交付？

如果不能，那你做的只是“技术作品”，不是“产品”。

七、总结一句话

Platform as a Product，不是换个名字。

它要求你：

• 用产品思维看待内部平台
• 用用户旅程设计体验
• 用增长指标衡量价值
• 用效率 KPI 证明意义