技术运营-变更管理案例介绍

变更管理是运营管理者在推进生产线管理流程的切入点，或是最早实施的流程之一。这不仅是因为变更管理流程的逻辑简单、成果明显，同时也是因为通过管理流程的实施，可以很快的发现关联的管理或技术的问题，并加以改进，也就是达到“提纲挈领”的效果。这里的案例就是讨论通过变更管理，发现和改进生产线的发布流程和环境一致性的问题。

01背景介绍

A公司是一家提供SaaS产品运营公司，公司主要经营国内外中小企业视频会议、电话会议业务。运维团队以及生产线管理流程已经初步建立。其中，变更流程的设置如下：

第一步，变更的申请

研发通过上线变更平台，在产品上线发布前的1-3个工作日内提出变更申请。主要目的是尽早协调运维团队的资源，和检查上线申请的软硬资源配置准备工作。如果在这个准备过程中发现问题，则及时沟通解决。

在发布的前24小时，研发再次修订上线变更申请。这次主要是提交测试报告，和确认变更的时间及资源。运维与测试人员再次确认测试报告，确认无误后则运维总监批复该流程，变更流程的申请部分到此结束。

第二步，变更的执行

在指定的发布时间，发布工程师执行发布动作，完成线上的软件或硬件的安装和配置。发布之后由测试人员进行测试验证，有问题时决策是否回滚，测试通过后发布结束。

变更管理在流程本身上并没有太大的问题，但在流程的执行中，会触发各种隐含的问题。在管理流程的实施中，挖掘和暴露相关的问题，从而进行改进，也是管理流程的核心目标之一。这个案例主要讲的是A公司在变更管理在实施过程中所发现的问题，以及后续是如何改进的。

02研发与运营的冲突

A公司在一次应用程序的模块的接口升级中遇到困境。在整个发布过程中，研发的QA在测试环境完成整体的业务接口模块的测试，并提交代码和变更申请。运维团队在变更审核中没有发现问题，给予通过。随后在指定的时间内执行正常的变更上线。

生产线的发布时间为晚上21:00-00:00的3个小时时间段进行。时间很有限。在实际上线过程中，碰到的问题是：软件在线上由运维团队更新完成后，QA执行变更测试，发现接口测试不通过，通过与开发人员问题排查，发现有一个连接其他相关联的接口的网络策略不通，这是因为两个业务接口是分别两个独立的子网，逻辑上是隔离的，而在QA测试环境中，所有的网络段之间的路由策略是开放的，所以，这个问题在QA测试环境里面没有测试出来。

生产线服务是7x24运行的。要在生产线线上临时开通网略策略，这是个未知情况而且风险很大。加之A公司刚刚经历过网络上的一些安全问题，针对网络策略的调整，运维部门的网络工程师非常谨慎。如果网络策略不开通，就需要研发可以通过改代码来规避网络策略风险，但是改动的代码又比较多，所以，线上的发布陷入僵持阶段。

这次发布问题被升级到更高的管理层。负责生产线运营的VP被半夜call-in来决策。VP在电话会议上问研发和运营团队，如果临时开通网络策略，有谁可以签名保证不会出现安全事故。结果是没有人出面保证。最后，这个变更被临时取消，发布被回退。发布被安排在第二天的白天做紧急的测试，在第二天的晚上做线上实施。

A公司的决策是对的，新的软件发布出现问题，临时要做的补救动作影响大又没有做过QA，所以，一定要做回滚操作。但同时，由于新的软件上线的延迟，用户的体验和业务的推广都受到了影响。要规避这种困境，只能从管理流程和技术环境上去优化。

SaaS产品运营的核心竞争力就是服务的稳定性及可持续性，变更管理在产品运营中起到的作用是至关重要的，直接会影响到用户的体验。因此，建议一套符合A公司业务运营变更流程及发布体系是当前最迫在眉睫的任务。运营部牵头梳理变更发布中存在的问题主要有两个：

（1） 变更中受影响的客户规模大小无法控制

（2） 测试与生产环境不一致。

03解决方案：变更管理与用户管理、发布管理的结合

针对这两个问题，A公司主要从发布管理体系的建立和结合入手。切入点有3个：

o 用户管理：切分用户。从业务角度层面，将区分大客户、小客户做不同的体验池管理，也就是流量切分；

o 发布管理：分步发布。从技术角度上考虑蓝绿发布、灰度发布运用到发布管理中，做到无缝最小化的影响小客户体验的问题；

o 环境一致性：保持核心环境参数在线上的生产线系统与线下的开发测试系统的一致性，如将业务发布设计的关联关系拓扑实施动态的更新并展示，对每次发布的服务都有哪些依赖接口、影响哪些服务和主机，解决环境不一致及相关网络策略依赖问题。

其中，客户的切分采用篮子管理的思路：

A公司最终决策将SaaS产品分成三个篮子，每个篮子为不同的版本，比如三个篮子对应的产品分别为N.1、N.2、N.3，

o N.1版本对应的是小型客户企业，相对而言，他们对服务的新功能的要求快，相应稳定性要求少些、可以接受比较频繁的变更。

o N.2版本对应的是中型企业客户，变更周期相对短一些的；

o N.3版本对应的是大型企业客户，这些客户要求服务更稳定的、软件变化小；

在业务这一层将客户切分开来，发布问题其实也就解决了一大部分。比如在时间顺序上，新的版本发布，可以先给N.1客户，运行一段时间后，进入N.2，然后N.3。

发布管理主要体现蓝绿发布、灰度发布上，另外，解决环境一致性问题也是A公司当时最关注的点。

04蓝绿部署、灰度发布

（1）蓝绿部署

蓝绿部署（Blue Green Deployment）的目的是减少发布时的中断时间、能够快速撤回发布。

蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。

蓝色系统不对外提供服务，用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统。

切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

A公司改进后的发布具体场景如下：

相同版本的产品分布在六个节点上运行，逻辑上分为a和b两组，在发布时，首先把a组从负载均衡中摘除，执行a组的产品版本发布操作，b组仍然继续提供服务，如下图a组离线进行发布操作。

当a组升级完毕，负载均衡重新接入a组，再把b组从负载列表中摘除，进行新版本的发布。a组

重新提供服务，如下图b组联系进行发布操作。

最后，b组也升级完成，负载均衡重新接入b组，此时，a、b两组版本都已经升级完成，并且都对能外提供服务。

（2）灰度发布（Canary releases）

金丝雀发布（Canary）也是一种发布策略，和国内常说的灰度发布是同一类策略。

蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。

灰度发布，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本体验没有太多的问题，相对稳定了，再逐步扩大到其他版本的生产线升级，也就是说把版本升升级按照用户重要程度在一段周期内逐步平稳的都迁移到新版本上面来。

A公司结合用户的3个分类，将生产线相应分类为3个集群。在上面实施了灰度发布的策略。

发布的难点在于需要对a、b、c三类客户给与三个不同的身份标签来确认用户请求不同篮子的产品进行体验。标注a/b/c三类不同的客户属性通常需要研发在产品设计阶段完成，比如a/b/c客户标签分别为big、middle、small，那么客户进入生产线统一登录中心时，平台会对请求的URL进行解析，如果解析到big关键字，则会让该URL请求转发到大客户对应的业务集群中，因此，灰度发布的难点就是在研发设计初期就需要和产品共同考虑，并应对不同客户对业务持续性和连续性的需求。如下图为a/b/c不同客户集群在一个负载均衡器中，如果a客户需要升级版本，前提是b和c两种类型的客户已经升级完成，并运行了两周，则可以进入a客户的升级。

05环境一致性管理

环境一致性管理对开发环境、测试环境与生产环境所涉及到的业务关联关系及网络依赖关系的管理，这部分的管理难点在于生产环境属于用户实际使用的环境，是实际产生利润来源的环境，所以，生产线上的投入的成本相对较高，基础及应用设施大而全。而开发环境和测试环境基本是生产环境的缩小或者近似。

在实际变更中，上线发布失败的很大一部分原因是因为测试环境与生产环境不一致导致的测试不完整或测试不一致。这里，环境不一致管理的难点不在于基础设施本身，而是在于业务应用层。业务与业务之间的逻辑关联关系决定环境管理的复杂度。而随着业务版本迭代及业务的扩张，业务与业务的关联关系变得愈发复杂。

基于变更管理流程中发现的问题，A公司经过不断的探索，在环境一致性的管理做了很大改进。切入点是逻辑拓扑的动态管理。

A公司提出业务动态管理拓扑的方法是这样：建立动态拓扑图，任何的业务接口或者模块的变更，动态拓扑都能清晰的看到他们之间的依赖，包括信息接口或者项目也能在动态拓扑上体现出来。业务关联关系的拓扑图如下：

上图中的每个节点是服务器(server)。每个服务器，如svr-1，会包含几个元素：主机名，IP地址，Port，接口名。与Srv1关联的节点有哪些，都属于哪些产品，哪些服务接口、模块、端口信息等也会展现在图上。每次变更后，拓扑图都会更新。拓扑程序发现有新的端口或者应用上线，图中的新组件则会显示红色，新增的与之关联的也会自动变成红色，待运维和研发人员确认后变成正常绿色状态。

这样，在变更申请中，通过拓扑图来了解新的变更会影响哪些业务，会需要开放哪些网络策略等，都比较清楚。

拓扑图的动态维护是个关键。为了解决上线后拓扑更新的问题，A公司采用自动发现程序。自动发现程序有两种方法实现，一个是在网络层，通过网络连接方式来动态实时获取各个资产连接端口信息，并与业务建立关联；另外一种是在应用层，就是通过APM的方式，对应用程序进行埋点，接口和接口相互调用信息可以通过埋点来获取，并形成前后数据流关系。通过这样的自动程序来发现上线后的服务连接的节点信息来实时更新拓扑，确保生产线的业务关联关系拓扑永远是最新的。

拓扑自动发现的程序设计的一个基础是依托CMDB（配置管理库）来定义资产（property）及其配置(configuration)，比如，每个资产运行哪些服务，每个节点运行哪些docker容器。同时，将变更管理的信息，包括配置改变（如网络设备的ACL策略变更）、变更时间、业务影响等比较完整的信息，与CMDB结合，这样就形成一个完整的闭环，得到一个全局的、完整的和实时的生产线运行信息。

06进一步的讨论

从A公司的变更管理流程实施的经历来看，我们可以学习到几个关键点：

（1）通过变更控制，可以有效的降低变更给7x24生产线带来的风险。

（2）通过变更管理，可以发现关联的技术和管理上的问题。

（3）通过关联的流程改进，如发布管理和环境一致性管理，可以有效的提高生产线变更的成功率。

A公司经过发布流程的改造，效率上有了很大的提升。客户管理的群体通过单元化拆分来区别对待，从前端大客户关系维护到后端的问题处理也变得顺畅很多，单次发布的影响面降到最低，客户基本无感知。发布过程中出现的问题也呈下降趋势，服务的上下线就不再组织一个庞大的评审会来集中讨论和整理业务的关联关系，极大降低了各部门的沟通成本。

但是随着A公司业务的成倍增长，发布管理及环境一致性管理变得越来也复杂，这直接体现在各服务产品模块之间的接口设计及其相互调用。相应的运营成本也大幅度上升。首先，需要更多的单元去管理不同版本的产品线，不同群体客户，这对成本上是一个挑战；再次，越来越多的版本迭代，关联关系拓扑的依赖关系变更复杂，经常出现同一个时间需要发布几十个产品升级，依赖面变得更广，关联拓扑的更新变得不够清晰化。后续需要引进AIOPS的算法来帮助维护复杂的运行中的生产线拓扑图。

以上内容皆节选自《云计算和数据服务》这本书，书中采用理论与实践相结合的形式，系统阐述云计算和大数据服务的具体实现。

云计算和大数据服务战略的落地，包括技术构建和运营管理、新兴的人工智能技术的应用，以及组织能力的建设。针对这一目标，全书分为七部分：云计算技术、大数据与数据智能、服务的技术运营、智能运营（AIOps）、安全技术与管理、服务质量管理和组织能力。写作本书的目的是帮助读者对云计算和大数据的重要专题从基本概念、发展思路到解决方案有一个系统认识。

本书具有非常强的可读性和实践指导意义，可作为云计算和大数据企业的高层管理人员和技术架构师的参考读物，也可作为高校相关专业师生的教学参考用书。