灰度发布
灰度发布让部分流量先进入新版本，再逐步放量。本文负责分组、指标比较和停止条件。
1. 面试核心
先记住这几条，再读正文- 部署与发布。 部署准备新进程，发布决定哪些请求使用新版本。
- 稳定分组。 用户或租户哈希分桶可保持灰度组稳定。卡 · 综合题
- 灰度评估。 灰度比较同时关注业务结果、样本量和实例负载。
- 无结论时暂停。 监控缺失或分析无结论时，应暂停自动放量。卡 · 分析结果与暂停
- 回退范围。 路由回退停止后续流量，已有副作用需单独修复。
2. 部署与发布
部署先启动新版本，并通过 readiness。发布通过网关或 service mesh 调整流量归属。
功能开关还可控制代码内的功能启用。开关需有负责人、到期时间和清理任务。长期保留会增加测试组合。
3. 稳定分组
需要用户体验稳定时，按用户或租户 ID 哈希分桶。分桶规则和盐值在同一实验阶段保持稳定。改变规则会让用户跨组迁移。
入口可生成可信的发布标签。下游代理按标签选择版本，并由应用传播到后续调用。Trace context 本身用于追踪，路由标签需要独立约定。
外部客户端提交的标签需清除或校验。标签传递同时覆盖 RPC 和异步消息边界。
4. 观察指标与停止条件
每阶段预设成功、暂停和回退条件。比较相同时间窗口、区域和业务类型的流量。
- 技术指标覆盖错误、超时和延迟分位数。
- 资源指标覆盖线程池、连接池和下游调用量。
- 业务指标覆盖订单成功率、金额差异和数据状态。
最小样本量与观察时间需同时达标。短时间零错误只说明已观察样本未出错。
5. 流量比例与实例容量
请求比例与实例比例分别控制。10% 请求落到 1% 实例时，新实例会承受更高负载。
长连接和会话黏性也会造成分布偏斜。比较版本性能时，需同时核对单实例负载。放量前确认新版本容量和业务键分布。
6. 数据库变更
新旧版本共存需要兼容的数据读写。扩展、回填与收缩步骤见架构迁移。
发布检查需覆盖旧代码读取新数据的情况。消息消费者和定时任务也列入兼容矩阵。
7. 回滚的范围
回退将后续请求切回已验证版本。已写数据、已发消息和外部调用需单独对账。
新格式若超出旧代码能力，应关闭风险入口并向前修复。上线前验证旧版本读写，确定可回退的时间边界。
8. 影子流量
影子请求复制到新版本，响应留作对照。查询比较与副作用隔离见架构迁移。
灰度分析需将影子指标和真实用户指标分开。复制流量的负载也应计入容量计划。
9. 发布后清理
全量完成后，确认旧实例已排空。随后删除临时路由与标签，并清理到期功能开关。
更新监控基线并保存实际放量记录。失败发布保留时间线、阈值和修复结果。
10. 分析结果与暂停
放量判断需要成功、失败与无结论三种结果。监控查询失败、空结果和样本不足需单独处理。缺失数据按成功处理，会绕过发布门槛。
Argo Rollouts 的 Inconclusive 会暂停当前步骤。操作人随后决定继续或终止。空值、NaN 和查询错误则按分析配置处理。它们并非自动等价于 Inconclusive。
配置分析规则时，应显式约定无数据与错误处理。成功率计算还需检查分母和请求覆盖范围。
11. 常见问题
11.1 小流量的覆盖范围
1% 流量会漏掉低频租户、长尾数据和容量拐点。后台任务也需独立验证。代表性分组与压力测试共同补足覆盖。
11.2 蓝绿与灰度
蓝绿使用两套环境完成切换。灰度逐批切换流量，两者可以组合。数据兼容和连接排空适用于两种方式。
12 · 面试题卡片
12.1 如何设计一次可以安全回滚的灰度发布
出现公司：Shopee
题型：综合题
考察重点
- 理解稳定分桶、标签传播和实际容量。
- 理解技术指标、业务指标与停止条件。
- 理解数据兼容、不可逆副作用和回滚边界。
参考回答
安全回滚依靠稳定分组、明确门槛和数据兼容。
新版本就绪后按用户或租户分批接流量。每批核对样本量、错误、延迟与业务结果。实际实例负载也需与旧版本比较。
数据读写保持兼容，回退路径在发布前验证。路由回退后，对已有副作用执行对账或补偿。监控缺失或结论不足时暂停放量。
12.2 灰度监控没有数据，可以按零错误继续放量吗？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：样本覆盖、无结论与发布门槛。
相关内容：分析结果与暂停。
参考回答
应暂停放量，先确认流量覆盖和监控是否正常。
空结果缺少错误率分母，无法判断版本安全。Argo Rollouts 的 Inconclusive 会暂停步骤。查询错误和空值需在分析配置中单独定义处理。