共计 5989 个字符，预计需要花费 15 分钟才能阅读完成。
导读 | 如何让性能缺点修复疾速上线？版本收回问题时怎么疾速回退？效率晋升后品质落伍？为解决这些常让运维工程师头疼的事件，本栏目特邀腾讯出名运维工程师袁旭东，讲述对象存储 COS 的公布演进过程，为各位开发者提供业务通用的高效高质变更办法。该业务通过晋升灰度自测能力、优化流转工夫和并发策略等办法实现提效，同时提出措施保障品质，并设置了一套可度量体系保障继续监控、调优，最终带动公布变更程度上新台阶。
背景
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 件事
