一 点睛

灰度升级是在不升级和全部升级中的一个状态，把升级从一个短期的过程拉成一个长期的过程，让每一个状态的改变都是一个渐进的过程。

恢复升级策略分类：

• 按照用户身份执行灰度策略
• 按照号段执行灰度升级策略
• 按照命令行执行灰度升级
• 按照时间执行灰度升级

二 按照用户身份执行灰度策略

按照用户身份执行灰度策略是为了快速收集用户反馈，及早发现问题，一般适用于开发一个新项目，实现一种新玩法，在产品层面实现灰度升级的场景。不同身份的用户，对于新发布造成的 bug 的反映程度不同，反馈的热情也有差异。

三 按照号段执行灰度升级策略

按照号段进行灰度升级的主要原因有两个。

1 按照号段进行灰度升级在程序上容易实现，只需要两个变量就可以表示一个区间。

2 很多后台逻辑架构都是按照号段来部署的，如果按号段进行灰度升级，和切分的部分逻辑吻合，降低了灰度升级的复杂性。

可以按照号段，在一周内完成灰度升级 。

四 按照命令行执行灰度升级

有时我们可以让用户只使用部分功能。每个用户都被灰度，但每次只使用一小部分功能，逐步使用全部功能。

按照命令进行灰度升级一般用于后端系统重构、性能优化的场景——用户使用的功能变化不大，性能会有所提升。用户感知不大，开发人员只需要根据监控视图来评估灰度升级的效果。

五 按照时间执行灰度升级

对于一些常规需求的发布，特别是无状态的服务，采用按照时间灰度比较好，作为一个常规需求，我们按照时间灰度，保持一个周期完全发布的节奏，把灰度升级纳入日常发布规范中，可以有效控制服务质量。

有些互联网公司，把一周定为一个发布周期，一周发布四天，周一发布10%，周二发布20%，周三发布30%，周四发布40%。四天累计发布100%，周五不发布，防止周末发现问题来不及处理。

一周发布一个版本，中间发现有问题后及时回滚，保证每次发布都不会对 100% 的用户造成影响。经过四天的灰度发布，把发现周期拉长。

六 小结

由于灰度升级操作提高了发布的复杂性，所以要将发布流程规范化，让发布自动化，灰度配置化，只由人工触发，并且灰度升级后通知发布人员，观察灰度升级后发布的数据。监控和日志也要做到完善。

一般在发布后，至少观察十分钟的监控视图，还要亲自对线上起作用的业务进行实际验证。一般的监控指标有下面几个：服务器内存、CPU、磁盘、网卡的数据是否异常；新程序是否按照预期启动。新老服务的请求量是否在正常范围内，新增脚本或新增程序是否运行正常。

有时，灰度策略是几种策略的合并。

例如：

按用户灰度：先内部体验，然后再外部体验。

按号段灰度：针对不同的大区，按照用户人数从少到多的顺序进行灰度。

大区灰度的时间安排：按时间进行灰度，根据灰度结果控制灰度节奏。