发布变更又快又稳？腾讯运维工程师经验首发 世界热讯
1）背景诉求
(相关资料图)
2）对象存储COS
历史的存储引擎(TFS、LAVADB等)在变更中需要小set内串行，或将数据迁走然后变更。这类变更耗时是显而易见的（从耗时过长会引发意想不到的变更方式：按照版本组合来变更，按照各区域版本自治完全没有统一概念等）。这类型的变更最多做到流程标准化。它可以set之间并发或批量迁走数据再变更，但解决不了本质问题。
YottaStore相比传统TFS模式或LAVADB模式而言，好在将小set模式的变更方式升级为集群百分比变更，打破理解set变更的模式，每个节点剔除加回也不需要等待数据迁移。这本质上提高了存储变更效率上限。
COS关键提效手段1）管理区域MZ适配发布YottaStore在上线的时候就对节点标签引入了MZ（Management Zone）的概念：同集群内跨MZ不能同时变更，减小误操作爆炸半径。例如，模块上线后使用20个MZ，跨MZ屏蔽节点会失败（保障现网最大5%的机器可以并发变更）。当然，在更核心服务配置时MZ应该设置的更多。优化前，基于MZ的概念变更节奏为：单机灰度：随机一个MZ变更1台；灰度：所有MZ随机变更1台；全量：MZ内全量并发，MZ之间串行，并且开始时智研平台并发度受限在100以内。
优化后：考虑集群内节点同服务角色，将灰度节奏调整为随机一个MZ全量，减少跨MZ带来的耗时，同时智研平台支持将最大并发调整为500+（单集群节点数/mz数量目前小于500，故相当于实现了MZ内全量并发）。
基于区域MZ适配发布优化的策略，主要是通过COS对MZ编排做了适配，同时智研平台把并发度支持从100并发调整到500并发，对于单机模板执行效率也做了优化。这整体优化了平台并发能力和发布流转效率，全园区覆盖效率提升100%。
第一，灰度机器加回现网之前，扫描日志初始化，进而确认程序初始化成功。第二，灰度机器加回现网之前，引入自动化回滚。这里需持续丰富测试用例，打通测试平台建立完整测试流程。
COS发布分离线计算，自研云集群、公有云海外、公有云国内（每个云属性下有多个集群）、同云属性集群都可以在灰度健康的情况下开启并发。正常的版本发布耗时大约在1周工作日内完成。
4）优化流转时间将发布流程放大并将每一环可能产生的问题明确，我们可以看到不必要的浪费和可节约的时间。COS当前采用研发提单（仅提供提单权限）。系统群内推送给到开发leader审批，预发布环境发布，再到运维leader审批现网发布的方式。其中流转通过自动群推送的方式减少人频繁@时间，与知会时间。
现网发布时，由于云上是区分客户等级的，所以在发布区域上用唯一流水线固化发布顺序来降低区域选择和流转时间。（流水线覆盖权限，且支持发布中临时调整）。其实固化对于质量的提升更多，后面来说。
上述点优化后，变更耗时从15天变更1w+设备，到4天变更4W+设备。
5）关注提效的更多探索某次大规模故障复盘当晚，我们对于快速故障处理时的发布提出了思考：回滚或者紧急的发布能否支持更快完成？软件发布是否还有提效的空间？答案是肯定的。为了从细节出发，我们对每一次单机变更做了记录。最终发现关键软件由于程序包太大，下载耗时就占了40%。该下发方案是，多台机器同时从变更系统拉取程序包。这使我们一下子就联想到了客户集中下载COS单对象的场景，该场景最优的解决方案，就是引入CDN的特性与优势：预热！
在实现上，我们用了两种方案：
第一，缓存接入点就近分发。机器触发新包拉取的时候存一份到缓存接入点。后续机器拉包去到就进的缓存接入点拉取，减少拉包时间。缺点是需要尽可能多的缓存接入点；COS地域较多，会导致耗成本。
第二，预拉取。变更系统知晓发布单的所有行为，所以在任务启动的时候后台就开始（比如以200台的并发度）将包往机器上分发。后面执行的机器在单机变更模版基础上加一步：判断是否已经分发过。当标志位是已分发时，则会跳过分发包直接开始变更步骤。（COS使用该方案，节省了缓存接入点，降低带宽与本机器成本）方案上线后，单机执行效率提升40%。
6）只考虑提效带来的问题云上2B业务规模量庞大，叠加对象存储COS内部模块数超20个，节点数超10万，对于版本迭代中的质量必须提出极高要求。
质量对于效率是非直观的，但是始终会影响真实的交付效率。
总的来说：现网发布中，效率是诉求，但发布质量是痛点，若质量问题不解决，单纯提效并不完善。
发布要提效，质量是痛点COS对于发布中引入的质量问题优化是艰难的。年维度的时间迭代，期间包含了COS运营模式改造、存储架构升级、变更体系完善、变更系统适配改造等多项措施。解决质量问题时不仅解决了效率痛点、规范了变更流程、保障变更质量的同时还降低变更人力，多方面助力发布提效。下面讲下COS如何做发布质量的提升，希望能给你一些思路。
1）明确质量痛点COS自身的问题第一，OSS不完善，无实例管理。由于前期没有统一的OSS，部署/开区都通过拷包完成。OSS缺失导致发布中的状态感知及各种发布中的问题排查都是低效的。三级模块管理很容易出错。因此，实例接口化升级是必要途径。第二，配置包区域化，模版不一致。每个区域都有自己独特的配置，而独立性并不是需要的。修改一次全网特性需要去每一个区域包里面改配置，确认时也一样。差异化配置众多，改造统一配置文件是重中之重。
第三，发布流程随意，发布成功率靠运维能力保障。原发布变更系统是没有顺序概念的，只有通用的编排比如串行/并行指着ip发布。
变更过程的问题从历史中能看到，问题最多的原发布变更系统。业务发展初期，典型的情况是只考虑变更效率的极致提升，无考虑管控不足带来的质量风险。所以在系统选型上，需要按照自身业务的管控需求来做。管控不足主要分为以下六点：结合COS业务特性进行发布场景梳理与逻辑梳理，我们分别从正常部署、正常回滚、配置发布、扩缩容、紧急逃生、混部后的发布入手，结合现网变更中遇到的所有问题确定所有场景。
另外回退对云业务来说是预案。当和发布有关联，应该第一时间回退。若不是回退问题，其实我们期望让回滚流转成正向发布以继续变更。
每次变更软件负责人提供的额外注意事项，变更后的功能点更新的验证。以及是否可回滚，不可回滚变更的预案处理方法；
要关注变更期间的事件（不仅仅是变更模块的告警，而是需要关注整体的告警）和用户投诉、集群异常事件的产生等。2）逐项攻克解决配置文件管理升级为配置模板+配置变量的管理模式，对于整体运营上的提升有巨大帮助
第一，开区识别配置模版与配置变量，OSS支持自动化开区，独立客户单应用创建；第二，OSS识别配置变量，对于每一个配置变量可以确定功能，明确变量使用场景，做到配置修改和下发的预案模型，取代sed；第三，管理配置模版后，全局配置统一，不需要担心任何一个区域的配置文件再存在特异性问题；第四，区分配置模版、配置变量后，可以逐渐根据情况缩减配置变量，让通用性更强，运营复杂度降低；第五，配置变量对应的文件可以独立抽出来后，方便的做配置中心管理等更高级的下发升级；第六，实例问题——OSS建设，实例接口化升级（耗时半年）。
接口实例化升级首先，接口化便于指定发布、日志、监控系统的统一管理（oss只维护接口，所有平台支持监听接口自动更新）；其次，实例接口化后统一接入部门产品树和产品下的集群树，规范化集群和LZ（逻辑区域），根源上杜绝IP变更；此外，基于标签化的配置作用域管理，通过建立标签映射关系的工具支持，可以降低很多运维的平台迁移工作。变更过程改造第一，固化发布流程。因为腾讯云是通过区域售卖区域管理，COS属于Region级产品，所以按照Region来作为内部发布平台的抽象任务，内部区分实际不同功能特性的集群。但是所有软件的发布方式原本都各式各样，没办法保障每个人来发布都能不出问题。所以我们的方案是，降低发布爆炸半径且固化：区域发布顺序唯一且固化，设置可最大程度降低发布爆炸半径的流程编排并验证（如第二部分COS的直观提效第4点的发布流程优化图），并且所有的规范都通过智研平台标准化落地，一个应用，一个流程，现代化升级和固化发布流程，工具化落地审批、double check、强制回滚，预发布流程等，杜绝人为失误，为自动化变更打好基础。详细的点还包含：
每列分为一个完整的云属性概念，保障不同属性优先级顺序，不同列之间引入暂停确认；将LZ(逻辑区域)的概念落为编排单元（图中的每一个任务）；LZ内实现set化管理，保障区域内针对不同云上客户优先级编排发布顺序；新开区场景会自动识别到流水线模板，保障每次新增/减少集群都会加入到变更流水线上，保障发布全网覆盖。
第二，固化发布策略保障了发布流程，当然还要保障发布过程（发布策略）。失败可暂停，变更必灰度，变更模式统一；统一的变更策略：程序变更统一最大失败数，组内/组间并发度；统一的灰度策略：所有变更按照【1-确认-10%-确认-100%】的灰度节奏，强保障变更影响面和人工观察确认；统一的单机变更模板：正常情况程序变更和配置变更的单机变更模板各有一个，其他按各场景各自唯一；统一的发布时间：落地部门变更标准时间，变更时间过后发布单自动停止。
其他变更过程如下：
改造后的收益架平很多服务需要极致压榨硬件性能，与存储设备混部。该场景区别于在离线混部，属于在线和在线混部，每个服务都需要保障可用性。故需要考虑发布中此类场景的容灾设计。
需要杜绝的情况：第一，软件A数量>>软件B，软件A灰度10%触发机器死机导致软件B100%服务异常；第二，软件B类三副本cell模型（参考索引存储、块存储等实现），软件A机器变更影响软件B成对异常也会导致部分数据不可用的场景。
解决方案是引入通用理解的容灾分组，保证上述流程落地后规范并发布。
发布问题，解决的要点不仅仅是发布。COS对于变更额外还提出了很多自身运营上的的要求。
整体来说，发布概念、发布流程把控的标准化解决了在大部分发布流程上人工误操作可能引起的问题。足够标准化带来的收益就是全面标准化外包化发布，通过运维和开发配合持续降低发布变更的人力投入。并且关键的是：版本发布未再出现由人为操作引起的故障case。
COS的变更改造总结持续度量，持续优化
如果所有发布正向环节都考虑完备，能将效率与质量都进行提升。但这是否就足够呢？答案是NO。还需要良好的可度量体系，才能保障各项环节有数据反馈，持续调优。
好的度量具有两个特征：一是能够回答一个本质问题，另一个是能够引导出正确的行为，两者缺一不可。
目前来看，COS按照每一项发布的目标做行为上的数据审计。可以参考以下几点：
第一，成熟度指标体系：比如达到了某些标志性的数据后，可以直观地标识成熟度等级（但等级低可能是包含了各种历史和业务原因的）。
第二，发布效率提升：比如从执行日志找到单机类效率低的点，比如从整个发布环节中找到时间delay比较多并且可优化的点。
第三，发布行为考量：比如整个发布环节究竟占了多少人力，一次变成成功率是否高？由于人为环节或系统因素导致频繁发布失败，发布结单是有数据的，从这些数据可以负反馈给到用户是否该好好梳理下当前的发布问题及如何提升（是否环境污染、配置填错、模板不幂等）。因为统计后发现30%的人力消耗都在发布后，我们对于发布的调优才变的非常重要。
第四，发布过程事件关联：通过不同问题类型触发的故障影响，给各个问题做贡献度系数，最终可以做变更质检的打分体系。
第五，发布软件原因：从程序上入手，可以从程序问题的原因分类来做统计，比如相同软件经常出BUG，相同平台频繁出BUG，BUG平均影响线上时长等等反馈研发团队的可改进方案。
第六，审计负反馈通过部门某平台汇总展示：定期邮件到所有产品的发布情况，引导各项环节完善管理。
基于腾讯云上发布的理解，COS将发布成熟度区分为以下5级，最终目标为全自动发布。建立标准和成熟度模型，数据化牵引改进发布变更各环节的成熟度，迈向自动化。
首先是变更质检。区域告警关联区域变更，事件总线建设（相关事件关联），故障快速定位建设。用质检和打分体系代替灰度与全量&区域与区域之间的每一个暂停确认点，把流程自动化起来。
其次，用事件关联变更、统一的质检看板与结果分析、软件可回滚的前置条件下，把自动回滚能力也同步建设到位。
基于主干开发，引入城际快车发布模式，继承其带来的好处。每个人都非常清楚各个时间点、每个人都感觉到特性进展、速度不断提升、更加聚焦于生产质量。
最后，结合云业务特性与devops中的变更看板：统一把控发布与发布评审（如同一区域最多同时发多少单等等），让每个人都有紧迫感的同时，也不会漏发关键功能版本。
腾讯工程师技术干货直达：1、算法工程师深度解构ChatGPT技术
2、10分钟！从架构视角读懂K8s
3、探秘微信业务优化：DDD从入门到实践
4、耗时减半？腾讯云OCR只做了3件事
