江苏移动信息技术中心和华为BES团队在2018年正式启动业务支撑领域的DevOps转型，经过3个月的努力，DevOps核心能力之一的灰度发布正式应用于生产，版本升级"更稳定、更迅速、更灵活"。
架构、业务越来越复杂，响应速度、稳定性要求越来越高，CRM面对众多挑战
作为电信运营商三大支撑系统之一的业务支撑系统，承载了运营商全部的业务实现与运营。随着互联网时代各大热点的快速发展以及云化架构CRM的到来，用户量及业务受理量的不断增加，业务发展的多样性、复杂度不断提升，新功能快速上线的诉求，对承载运营商业务实现及运营的业务支撑系统的稳定性及故障处理时长有了更高的要求。
面对如此种种期望和困境，灰度发布提供了一种很好的解决思路。
看业界：互联网大咖如何玩转灰度发布
灰度发布也叫灰度放量，是对某一产品的发布逐步扩大使用群体范围，以保证整体系统的稳定，将正式版本在一定周期内平滑可控分阶段上线的过程。作为DevOps开发优秀工程实践，广泛用于互联网软件产品及云服务业务发布上线过程中。
灰度发布可以保证及早获得用户的意见反馈，完善产品功能，提升产品质量；
让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围；
可及时发现问题采取措施并修复，或者进行版本回滚，把问题的影响降到最低。
灰度发布的流程如下：
亚马逊灰度发布实践
· 亚马逊服务上线，为了减小服务出现问题后对用户的影响，一般的发布流程为：部署到Gamma环境 -> 部署到集群规模较小的Region -> 部署到集群规模较大的Region。
· 部署到Gamma环境：亚马逊的Gamma环境是生产环境的镜像，Gamma环境与生产环境共用一份数据，Gamma环境外部用户不可见，内部用户可以在Gamma环境上测试新版本。
· 部署到集群规模较小的Region：对于存在多Region部署的服务，上线新版本通常会选择先部署到集群规模较小的Region，出现问题后影响用户相对较少。
江苏移动CRM根据架构、业务特点选择适合的灰度方案
江苏移动CRM由4大生产中心组成，分别承载江苏的13个地市业务量。四个中心物理上独立，基于这种业务模型和系统架构以及要充分体验版本新功能的考虑，灰度的切换策略选型以地市单位进行实施。
江苏移动CRM借鉴亚马逊灰度发布经验，基于生产的系统架构，选用了物理灰度的架构，新建了一个可以承载一个地市业务量的独立灰度中心（相当于亚马逊的Gamma环境）。
制定以地市维度的灰度策略，选定灰度地市。针对营业厅渠道的业务，在操作员登录时通过地市操作员登录的负载地址到灰度负载进行切换分流；针对电子渠道的业务，发送灰度通知指令到能力开放平台，由能力开放平台切换地址来完成灰度的切换。新版本在灰度中心上测试通过后，逐步发布到其他业务中心。
因为和生产环境共用数据库，物理灰度版本就要求数据库必须向下兼容。如果灰度版本的数据库无法向下兼容，则不能同时在生产和灰度环境分别部署正常的版本和灰度版本。因此在设计灰度版本时将配置表增加了灰度标签和属性，或者直接新增单独的灰度配置表。
江苏移动CRM灰度发布具有以下设计属性：
· 在系统入口分流，实现全系统的灰度发布
· 灰度生产应用独立发布，实现白天无感知发布
· 一键自动切换和分钟级回滚
· 滚动升级，不中断服务
完善的发布流程与回退机制，助力灰度发布有效落地
灰度发布：应用版本灰度发布->数据库脚本执行->地市切换灰度（分流）->问题灰度暴露解决->灰度应用版本加问题补丁全量生产发布
灰度回退：得益于分布式架构的优势，应用无需回退，只需要将地市从灰度中心回切到原生产中心即可。如果数据影响了现有生产中心，数据库也需要回退到上个版本，包括物理库上SQL脚本的回退和DDS（分布式数据服务中间件）上DDL脚本的回退。
灰度成果：3个月试用，版本升级"更稳定、更迅速、更灵活"
1、多地市轮流切换灰度中心，上线的影响面受到了很好的控制，影响范围直接下降了92%。
2、上线次日问题数量月均下降80%。
3、灰度中心日常空置，灰度中心版本可以白天发布、白天测试，大大降低上线成本。
4、灰度中心有真实的用户数据、真实的网元，验证结果百分百准确。
5、灰度中心发布后，灰度地市验证发现的问题、新需求及功能发现的问题，可以利用正式发布前的时间完成修复，大大缩短了bug修复周期。
9-11月份，平均每个月实现一次全量版本的灰度发布，这在资源利用上是不足的，灰度中心在每月一次的全量发布之外仍然闲置，未来会结合江苏移动的DevOps发展之路，为快速版本迭代和问题解决提供发布支持。
