背景
1）背景诉求
现网发布改变对运维开发工程师来说是最繁重的作业。发布改变的概念、节奏等现已是陈词滥调。但在ToB时代到来后，云上事务的诉求是功用/缺陷修复尽快上线、版别宣布问题快速回退，防止客户事务受损。
在整个需求上线环节中，CD部分由运维施行。怎么让版别更快的交付上线是中心使命。
2）目标存储COS
腾讯云近几年开端大力发展，目标存储COS架构也经历了一次存储引擎晋级YottaStore的大迭代。目标存储COS从用户接入到数据落地，要经历三个中心子渠道：逻辑接入层、索引存储层、数据存储层。每个子渠道内部还有数十个模块相互配合供给服务，任何一个链路呈现反常都或许对数据PUT、GET、LIST、HEAD等接口形成可用性影响，COS节点数更是突破了10W+。
前史的存储引擎(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%。
2）灰度自测才能
为下降人工check等待时刻，COS在单机改变模版引进改变的自检进程。
榜首，灰度机器加回现网之前，扫描日志初始化，进而承认程序初始化成功。第二，灰度机器加回现网之前，引进主动化回滚。这里需继续丰厚测验用例，打通测验渠道树立完好测验流程。
3）优化并发战略
改变系统供给人工控制入口，布置编列中的一切使命能够人工承认后直接启动，速度直线提高。
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发布场景整理
结合COS事务特性进行发布场景整理与逻辑整理，咱们分别从正常布置、正常回滚、装备发布、扩缩容、紧迫逃生、混部后的发布下手，结合现网改变中遇到的一切问题承认一切场景。
别的回退对云事务来说是预案。当和发布有相关，应该榜首时刻回退。若不是回退问题，其实咱们希望让回滚流通成正向发布以继续改变。
-
调查点整理—质量岗哨
整理COS发布前后的调查点，便于了解改变行为然后设置“岗哨”。包括基础的进程是否拉起、日志是否有过错、coredump、正常/反常返回码是否正常、延迟成功率事务恳求是否变化。
每次改变软件负责人供给的额外注意事项，改变后的功用点更新的验证。以及是否可回滚，不行回滚改变的预案处理办法；
要重视改变期间的事情（不仅仅是改变模块的告警，而是需求重视全体的告警）和用户投诉、集群反常事情的发生等。
2）逐项霸占处理
-
装备文件办理晋级为装备模板+装备变量的办理形式，关于全体运营上的提高有巨大协助
榜首，开区辨认装备模版与装备变量，OSS支撑主动化开区，独立客户单使用创立；第二，OSS辨认装备变量，关于每一个装备变量能够承认功用，明确变量运用场景，做到装备修正和下发的预案模型，取代sed；第三，办理装备模版后，全局装备一致，不需求忧虑任何一个区域的装备文件再存在特异性问题；第四，差异装备模版、装备变量后，能够逐步根据状况减缩装备变量，让通用性更强，运营复杂度下降；第五，装备变量对应的文件能够独立抽出来后，便利的做装备中心办理等更高档的下发晋级；第六，实例问题——OSS建造，实例接口化晋级（耗时半年）。
-
接口实例化晋级
首要，接口化便于指定发布、日志、监控系统的一致办理（oss只保护接口，一切渠道支撑监听接口主动更新）；其次，实例接口化后一致接入部分产品树和产品下的集群树，规范化集群和LZ（逻辑区域），本源上根绝IP改变；此外，根据标签化的装备效果域办理，经过树立标签映射联系的东西支撑，能够下降许多运维的渠道迁移作业。
-
改变进程改造
榜首，固化发布流程。因为腾讯云是经过区域售卖区域办理，COS归于Region级产品，所以依照Region来作为内部发布渠道的笼统使命，内部差异实践不同功用特性的集群。可是一切软件的发布办法本来都各式各样，没办法确保每个人来发布都能不出问题。所以咱们的计划是，下降发布爆破半径且固化：区域发布次序唯一且固化，设置可最大程度下降发布爆破半径的流程编列并验证（如第二部分COS的直观提效第4点的发布流程优化图），而且一切的规范都经过智研渠道规范化落地，一个使用，一个流程，现代化晋级和固化发布流程，东西化落地批阅、double check、强制回滚，预发布流程等，根绝人为失误，为主动化改变打好基础。具体的点还包括：
每列分为一个完好的云特点概念，确保不同特点优先级次序，不同列之间引进暂停承认；将LZ(逻辑区域)的概念落为编列单元（图中的每一个使命）；LZ内完结set化办理，确保区域内针对不同云上客户优先级编列发布次序；新开区场景会主动辨认到流水线模板，确保每次新增/削减集群都会加入到改变流水线上，确保发布全网覆盖。
第二，固化发布战略确保了发布流程，当然还要确保发布进程（发布战略）。失利可暂停，改变必灰度，改变形式一致；一致的改变战略：程序改变一致最大失利数，组内/组间并发度；一致的灰度战略：一切改变依照【1-承认-10%-承认-100%】的灰度节奏，强确保改变影响面和人工调查承认；一致的单机改变模板：正常状况程序改变和装备改变的单机改变模板各有一个，其他按各场景各自唯一；一致的发布时刻：落地部分改变规范时刻，改变时刻往后发布单主动中止。
其他改变进程如下：
-
改造后的收益
3）处理存储事务混部场景
架平许多服务需求极致压榨硬件性能，与存储设备混部。该场景差异于在离线混部，归于在线和在线混部，每个服务都需求确保可用性。故需求考虑发布中此类场景的容灾设计。
需求根绝的状况：榜首，软件A数量>>软件B，软件A灰度10%触发机器死机导致软件B100%服务反常；第二，软件B类三副本cell模型（参考索引存储、块存储等完结），软件A机器改变影响软件B成对反常也会导致部分数据不行用的场景。
处理计划是引进通用了解的容灾分组，确保上述流程落地后规范并发布。
4）完善改变系统
发布问题，处理的要害不仅仅是发布。COS关于改变额外还提出了许多本身运营上的的要求。
全体来说，发布概念、发布流程把控的规范化处理了在大部分发布流程上人工误操作或许引起的问题。足够规范化带来的收益便是全面规范化外包化发布，经过运维和开发配合继续下降发布改变的人力投入。而且要害的是：版别发布未再呈现由人为操作引起的毛病case。
-
COS的改变改造总结
继续衡量，继续优化
假如一切发布正向环节都考虑完备，能将功率与质量都进行提高。但这是否就足够呢？答案是NO。还需求良好的可衡量系统，才能确保各项环节有数据反馈，继续调优。
好的衡量具有两个特征：一是能够答复一个实质问题，另一个是能够引导出正确的行为，两者缺一不行。
1）审计负反馈
目前来看，COS依照每一项发布的目标做行为上的数据审计。能够参考以下几点：
榜首，成熟度指标系统：比方达到了某些标志性的数据后，能够直观地标识成熟度等级（但等级低或许是包括了各种前史和事务原因的）。
第二，发布功率提高：比方从履行日志找到单机类功率低的点，比方从整个发布环节中找到时刻delay比较多而且可优化的点。
第三，发布行为考量：比方整个发布环节究竟占了多少人力，一次变成成功率是否高？因为人为环节或系统因素导致频频发布失利，发布结单是有数据的，从这些数据能够负反馈给到用户是否该好好整理下当时的发布问题及怎么提高（是否环境污染、装备填错、模板不幂等）。因为计算后发现30%的人力消耗都在发布后，咱们关于发布的调优才变的非常重要。
第四，发布进程事情相关：经过不同问题类型触发的毛病影响，给各个问题做贡献度系数，终究能够做改变质检的打分系统。
第五，发布软件原因：从程序上下手，能够从程序问题的原因分类来做计算，比方相同软件常常出BUG，相同渠道频频出BUG，BUG均匀影响线上时长等等反馈研发团队的可改善计划。
第六，审计负反馈经过部分某渠道汇总展示：定时邮件到一切产品的发布状况，引导各项环节完善办理。
2）成熟度系统
根据腾讯云上发布的了解，COS将发布成熟度差异为以下5级，终究目标为全主动发布。树立规范和成熟度模型，数据化牵引改善发布改变各环节的成熟度，迈向主动化。
未来：向更智能的发布形式演进
首要是改变质检。区域告警相关区域改变，事情总线建造（相关事情相关），毛病快速定位建造。用质检和打分系统替代灰度与全量&区域与区域之间的每一个暂停承认点，把流程主动化起来。
其次，用事情相关改变、一致的质检看板与结果分析、软件可回滚的前置条件下，把主动回滚才能也同步建造到位。
根据主干开发，引进城际快车发布形式，承继其带来的优点。每个人都非常清楚各个时刻点、每个人都感觉到特性进展、速度不断提高、更加聚焦于生产质量。
最终，结合云事务特性与devops中的改变看板：一致把控发布与发布评定（好像一区域最多一起发多少单等等），让每个人都有紧迫感的一起，也不会漏发要害功用版别。
腾讯工程师技能干货直达：
1、算法工程师深度解构ChatGPT技能
2、10分钟！从架构视角读懂K8s
3、探秘微信事务优化：DDD从入门到实践
4、耗时减半？腾讯云OCR只做了3件事
阅读原文
