题干与适用场景
你维护跨语言的可观测性规范，多个 SDK、采集器、查询面板和告警依赖同一组属性。团队希望把约定从 development 升级为 stable，以便下游放心依赖；平台团队担心字段含义尚未收敛，升级会产生双写与高基数成本。假设已有三个月的真实遥测样本和两个试点服务。
面试官考察点
面试官考察你能否把“稳定”解释为兼容性承诺，而不是文档完成度。强回答会检查命名、类型、单位、必需级别、枚举和隐私边界，量化采用率、查询正确性、基数与迁移成本，并为不兼容变化保留过渡路径。
回答前需要澄清的问题
- 哪些下游已经把字段写入告警、计费或合规报表？依赖越多，稳定承诺越慎重。
- 约定覆盖哪些信号和语言？跨 SDK 的默认行为必须一致。
- 当前属性是否出现高基数、敏感数据或歧义枚举？这些问题应在升级前解决。
- 需要兼容多久？若存在旧采集器，必须设计双版本或 opt-in 过渡。
- 成功标准是采用率、查询可复用性，还是减少自定义字段？不同目标会改变试点指标。
30 秒回答框架
“我不会因字段数量达到某个值就升级。先审计语义、类型、单位、必需级别、枚举、隐私和跨 SDK 一致性，再用真实查询验证下游。只有试点服务采用稳定版本后，兼容性测试通过、基数和成本在护栏内、迁移与弃用路径明确，才进入 stable；否则保持 development 或 alpha，并记录下一次决策条件。”
分步骤深入解答
- 定义承诺。 OpenTelemetry 约定有 development、alpha、beta、release candidate、stable 等稳定级别；stable 意味着下游可依赖其兼容性保证。
- 审计语义。 检查名称、值类型、单位、要求级别、枚举和示例是否互相一致；把“看起来有用但没有明确用例”的属性退回讨论。
- 验证真实使用。 从三个月数据抽样，检查仪表盘、告警、日志关联和跨语言查询是否得到相同结果，记录缺失率与未知值。
- 控制成本和隐私。 测量新增属性带来的基数、存储和查询成本，禁止把用户标识、原始内容或秘密写入属性；必要时用哈希或受控分类。
- 设计版本路径。 对已有实验约定保留 development 命名空间；稳定化时提供版本选择或 opt-in，双写期间比较新旧结果，再定义弃用日期。
- 设置门槛与回滚。 两个试点服务连续两个发布周期满足兼容测试、查询正确率 99.9%、属性缺失率低于 1%、基数增幅低于 20%，才提交稳定化；任一护栏越界就回到 opt-in。
替代方案包括先发布 beta、只稳定一组核心属性、为不同信号分开版本，或通过转换处理器在采集端映射旧字段。稳定化不应被用来掩盖未解决的采样、权限或数据质量问题。
高质量示范回答
“我把 stable 看作兼容性产品承诺。先盘点依赖该约定的告警、报表、采集器和 SDK，审计名称、类型、单位、要求级别、枚举与隐私边界。然后从三个月真实遥测中重放关键查询，在两个语言不同的服务上比较缺失率、未知值、基数和成本。只有连续两个发布周期查询正确率达到 99.9%、缺失率低于 1%、基数增幅低于 20%，且已有稳定版本的弃用日期、双写和回滚方案，我才升级为 stable；如果字段含义仍有争议，就保持 development 或 beta，并写清下一次评审的证据门槛。”
常见错误
- 错误表现： 用采用率或字段数量直接证明稳定 → 失败原因： 稳定级别是兼容性承诺 → 修正方法： 增加跨 SDK、查询和迁移测试。
- 错误表现： 把所有业务字段都纳入规范 → 失败原因： 高基数与隐私风险会扩大 → 修正方法： 只保留有明确用例且可控成本的属性。
- 错误表现： 立即替换旧字段 → 失败原因： 下游查询会静默失真 → 修正方法： 版本选择、双写、对比和弃用日期齐备后再切换。
- 错误表现： 忽略未知和缺失值 → 失败原因： 面板看似完整但结论不可靠 → 修正方法： 把数据质量指标列为稳定化门槛。
追问及应对
一个核心字段需要改名，stable 还能保留吗？
若改名改变下游查询语义，应保留旧字段并新增版本，提供映射和弃用周期；只有证明语义等价且迁移成本可控时，才考虑兼容别名。
如何处理不同语言 SDK 的默认差异？
建立跨语言契约测试，使用同一组输入验证字段名、类型、单位和要求级别；默认行为未一致前不要扩大 stable 范围。
基数增加但业务查询更准确，是否接受？
把准确性收益与存储、查询延迟和成本上限一起评估；可先对高价值服务 opt-in，并设置采样、聚合或降维方案。
什么时候应停止稳定化？
当语义争议未解决、缺失率或基数超过护栏、隐私审查失败，或试点查询无法复现时，应停止并回到 development/beta，记录证据缺口。