Amazon Principal：怎样衡量一个平台是否成功？

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 来源Org-level Impact明确问怎样衡量平台成功；平台类型和实际结果没给，以下为内部数据平台训练例。
• 用户是消费团队，目标是更快可靠地完成其业务工作；调用量/团队数量为采用信号而非最终成功本身。
• 不把平台改造前后差异自动归因于平台，需要选择可比较基线并核产品/团队变化。

解题路线

1. 先定关键消费旅程，例如新数据源接入到首个可信产物、业务发布到安全可观测、故障到恢复。逐旅程定义成功条件与分母，再设可靠性/延迟目标，不从平台CPU/请求数反推用户满意。
2. 结果指标可用time-to-first-value、发布成功率、数据新鲜度/正确率与关键旅程可用性；同时有活跃/留存消费团队、无需人工支持完成比例、单位业务工作成本。错误自动重试把请求翻倍不能被记成增长成功。
3. 分层按团队规模/数据量/新老用户看分布，平均接入时间可能掩盖慢团队。成本按成功任务或有效数据单位计，并包括平台维护、支持与迁移负担，不能只报云账单下降却把人工成本转给用户。
4. 指标配guardrails：标准化提高速度不能让数据越权，压成本不能破坏恢复目标。SLO/错误预算作为优先级输入，不用红绿灯替代消费者体验；公开SLI/SLO参考https://sre.google/sre-book/service-level-objectives/。
5. 变更用试点组/阶段推广收集证据，比较前后相同旅程与相似用户，并记录干扰因素。低采用可能是文档/接入成本，也可能平台没有解决真实问题，不先用强制迁移把指标抬起来。
6. 复盘把指标对应动作：接入慢改善self-service；成功率低查正确性/依赖；单位成本高核冗余与热点；留存低访谈退出团队。季度目标聚焦一两项实际瓶颈，避免几十个指标无人负责。

手动走一遍

假设接入时间中位数10天→2天，但只有20%的新团队进入统计，因为其余卡在审批前；若分母只算完成者会误称成功。应同时报全申请cohort的完成率/时间分布与卡住阶段。调用量增加3倍若由失败重试推动，还要看成功产物与用户旅程错误。

规模与取舍

测量采样/日志需控开销与隐私，按旅程关联ID而非全量payload。团队cohort样本小需报告不确定性；不用一个百分比推整个组织ROI，收益扣支持/迁移/运营成本。

易错点与追问

容易失分的边界

• 调用量等于价值。
• 分母排掉卡住用户。
• 均值掩盖长尾团队。
• 云账单不含人工迁移成本。
• 强制采用当满意度。

继续深挖

• 没有随机实验怎样构建可信基线？
• 失败重试如何避免计为活跃使用？
• 小团队与大团队指标怎样分层？
• 平台成功与团队健康如何分开？