题干与适用场景
搜索团队完成了一个新排序算法，但上线方式未定。工程师希望用功能开关，增长团队希望做 A/B 实验，运营担心事故。请说明如何选择机制、定义成功指标、控制曝光，并在结果不佳时回滚。假设算法已经部署到生产，问题集中在“谁看到、如何比较、何时扩大”而非代码实现。
面试官考察点
- 能否区分目的：功能开关控制暴露，渐进发布控制风险，A/B 实验回答因果问题。
- 能否先定义用户、业务和系统护栏指标，再讨论流量比例。
- 能否说明稳定分桶、实验污染、回滚权限和默认值。
- 能否把旗标生命周期、负责人和清理计划纳入产品方案，而不是只谈上线按钮。
回答前需要澄清的问题
- 我们是在验证价值，还是只想安全发布？ 未知价值需要实验；价值已确定但风险高则渐进发布。
- 实验单位是什么？ 搜索算法通常按用户或账号稳定分桶；按请求随机会造成同一用户看到不同体验。
- 主要成功指标和不可接受的护栏是什么？ 点击率提升不能掩盖延迟、投诉、转化或错误率恶化。
- 是否存在跨端、跨地区或依赖服务？ 若曝光不能一致，实验结论会被污染，应缩小范围或先解决分配问题。
30 秒回答框架
“我先确认目标是学习、控风险还是两者兼有。若要比较排序价值，我会用用户级稳定分桶的 A/B 实验；若价值已确认但担心事故，就先小范围渐进发布，并保留一键关闭的功能开关。上线前定义一个北极星指标和延迟、错误率等护栏指标，记录变体 ID、曝光和结果。达到预设门槛才扩大，失败则暂停并回滚，实验结束后删除旗标和清理代码。”
分步骤深入解答
1. 先把三种机制放回问题类型
功能开关是运行时的控制面：可以让代码进入生产但不向所有用户暴露。渐进发布是暴露策略：从内部账号、少量客户到全量。A/B 实验是比较变体的测量设计：在可比群体中观察指标差异。三者可以叠加，但不能互相替代。
2. 选择实验单位与稳定分桶
Google Cloud 文档示例使用 userID 做 sticky bucketing，并以描述性变体 ID 记录结果。对于搜索排序，应按用户或账号哈希到 baseline/experimental，保证同一用户在实验期间不来回跳组。若按请求随机，缓存、学习行为和回访体验会互相污染。
3. 设计指标和停止规则
北极星指标应直接代表用户任务，例如有效搜索后的满意点击或完成率。护栏指标覆盖 P95 延迟、零结果率、错误率、投诉和商业损失。提前写出扩大、暂停和回滚门槛，避免看到短期点击上涨就忽略长期留存或系统健康。
4. 用渐进发布降低不可逆风险
Microsoft 的做法把部署与曝光分开，并从团队账号、选择客户到更广用户逐级开放。先让内部用户验证基本正确性，再按地区或客户段扩大。每一级都检查指标和日志；旗标的关闭路径必须独立于新算法，避免“回滚按钮本身依赖故障代码”。
5. 处理实验污染与变体审计
记录用户、变体、时间、版本、曝光事件和结果事件。Google Cloud 建议使用描述性变体名称，而不是只记录布尔值。若同一用户跨端分配不一致、实验组互相影响，先标注污染并暂停结论。指标分析必须能从结果追溯到当时的旗标规则。
6. 结束实验并治理旗标
Optimizely 区分实验和目标投放：实验用于回答“哪种方案更好”，确定答案后再用旗标发布胜者。Atlassian 和 Microsoft 都强调清理已全量发布的旧旗标，否则会积累分支、沟通和维护成本。每个旗标应有负责人、过期日期、默认值和删除任务。
高质量示范回答
我会先问团队要学习还是要控风险。排序算法的价值未知，所以第一阶段采用用户级稳定分桶的 A/B 实验；实验外层再套一个小流量渐进发布开关，任何护栏超阈值都能立即关闭。成功指标是有效搜索后的满意点击，护栏包括 P95 延迟、零结果率、错误率和投诉。
我会记录变体 ID、曝光和结果，不按请求随机分组，也不只看点击率。先在内部账号和一小组客户运行，确认日志、缓存和跨端分配一致，再按预设门槛扩大。结果确定后，把胜者切换为默认并删除实验分支、负责人和旗标配置；如果护栏恶化，先暂停实验、恢复 baseline，再调查原因。这样同时回答了学习、风险和长期治理。
常见错误
- 错误表现 → 把功能开关说成 A/B 实验。 失败原因：开关只控制暴露，未必产生可比测量。修正方法：明确实验需要分组、指标、暴露记录和分析计划。
- 错误表现 → 每次请求随机分流。 失败原因：同一用户体验抖动，缓存和行为被污染。修正方法：选择稳定实验单位并使用 sticky bucketing。
- 错误表现 → 只设一个增长指标。 失败原因：点击上涨可能伴随延迟、错误或投诉恶化。修正方法：同时定义北极星指标和系统、体验护栏。
- 错误表现 → 全量后保留旗标不清理。 失败原因：分支和规则持续增加，未来无法判断哪个路径有效。修正方法：在创建时登记负责人、到期日和删除任务。
追问及应对
如果实验组点击率高但延迟也高，你会选哪一个？
先检查护栏是否超过预设门槛。若超标，暂停扩大并恢复 baseline；再按用户价值分层判断是否需要优化算法或只对延迟敏感场景保留实验。不能用单一点击提升覆盖系统退化。
如果同一用户在网页和移动端被分到不同变体怎么办？
先定义实验单位。若问题要求跨端一致，就用账号级键并统一分配服务；无法统一时，缩小结论到单端，避免把跨端交互误当成实验效果。
什么时候不值得做 A/B 实验？
当风险主要来自正确性或合规、样本量不足以检测目标差异，或上线价值已经由外部约束决定时，直接使用小范围渐进发布和护栏监控更合适。实验成本应低于决策不确定性。
旗标服务不可用时默认什么？
为每个变体定义安全默认值，通常是已验证的 baseline，并在本地配置保留最后可用值。记录评估失败，避免把旗标服务故障放大成核心业务故障。