内向基金完成首轮募资
06-17
介绍|如何快速在线修复功能缺陷？出现版本问题时如何快速回滚？效率提高后质量却落后了？为了解决这些经常让运维工程师头疼的问题，本专栏特别邀请了来自腾讯的知名运维工程师袁旭东，讲述对象存储 COS 的发布和演进过程，并提供开发人员拥有业务通用的高效、高质量的变更方法。该业务通过提升灰度自检能力、优化传输时间和并发策略来实现效率提升。
同时，提出了保证质量的措施，并建立了可衡量的体系来确保持续监控和优化，最终导致发布变更达到新的水平。步骤。
?????背景1）背景需求在现网发布变更是运维开发工程师最艰巨的任务。发布变更的概念、节奏等都是陈词滥调。
但ToB时代到来后，云业务的诉求是功能/缺陷修复能够尽快上线，版本问题能够快速回滚，防止客户业务受损。整个需求上线流程中，CD部分是由运维来实现的。
如何更快地在线交付版本是核心任务。 2）对象存储COS 腾讯云近年来开始大力发展，对象存储COS架构也经历了存储引擎升级YottaStore的大迭代。
对象存储 COS 从用户访问到数据实现经历了三个核心子平台：逻辑访问层、索引存储层、数据存储层。每个子平台内有数十个模块，相互配合提供服务。
任何一个链路的异常都可能影响数据PUT、GET、LIST、HEAD等接口的可用性。 COS 节点数量已超过 10W+。
历史存储引擎（TFS、LAVADB等）在变更时需要在一个小集合中序列化，或者必须移动数据然后再更改。这类变更的耗时性是显而易见的（太长的耗时过程可能会导致意想不到的变更：基于版本组合的变更、各地区没有统一的版本自治概念等）。
这种类型的变更可以最好地标准化流程。它可以在集合之间或批量地并发移动数据然后更改它，但它不能解决本质问题。
与传统的TFS模式或LAVADB模式相比，YottaStore的优势在于将小集模式的变化方式升级为集群百分比变化，打破了理解集变化的模式。每个节点的删除和添加无需等待数据迁移。
这本质上提高了存储变更效率的上限。 COS 效率提升关键措施 1）管理专区 MZ 适配发布 YottaStore 上线时在节点标签中引入了 MZ（管理专区）的概念：同一个集群内的跨 MZ 不能同时更改，减少了爆炸半径误操作。
例如，模块上线后使用20个MZ，则跨MZ屏蔽节点会失败（保证现网最多5%的机器可并发更换）。当然，配置更多核心服务时，MZ应该设置得更多。
优化前，基于MZ的概念变化节奏为：单机灰度：一个MZ随机变化1；灰度：所有MZ随机改变1；全量：MZ内全量并发，MZ之间序列化，智言一开始平台并发是有限的。优化后：考虑到集群中节点的服务角色相同，灰度节奏调整为随机MZ，减少跨MZ的耗时。
同时，智言平台支持将最大并发调整为+（单集群节点数/mz数量目前小于，所以相当于实现了MZ内的全并发）。基于区域MZ适配发布优化的策略主要是通过COS适配MZ编排，同时智言平台将并发支持从并发调整为并发，同时也优化了单机模板的执行效率。
这整体优化了平台的并发能力和发布流通效率，将整个园区的覆盖效率提升了%。 2）灰度自检能力 为了减少人工检查的等待时间，COS 在单机变更模板中引入了变更自检流程。
首先，在灰度机加回现网之前，初始化扫描日志，以确认程序初始化成功。其次，在将灰度机器添加回现有网络之前引入自动回滚。
这里我们需要不断丰富测试用例，开放测试平台，建立完整的测试流程。 3）优化并发策略变更系统，提供手动控制入口。
部署和编排中的所有任务都可以在手动确认后直接启动，速度线性提升。 COS 发布了单独的线路计算。
自研云集群、海外公有云、国内公有云（每个云属性下有多个集群）、同一云属性的集群都可以在灰度健康的情况下开启并发。普通版本发布大约需要一周时间才能完成。
4）优化流通时间。通过放大发布流程，明确各个环节可能出现的问题，我们可以看到不必要的浪费和可以节省的时间。
COS目前使用R&D提单（仅提供提单授权）。在系统组内推送给开发负责人审批，发布到预发布环境，再交给运维负责人审批，进行现网发布。
其中，流通是通过自动群推送来减少频繁@的时间和通知的时间。现网发布时，由于云端区分客户级别，因此采用独特的管道，固化发布区域的发布顺序，减少区域选择和传输时间。
（管道覆盖权限，支持发布期间临时调整）。事实上，固化更能提高质量，这将在后面讨论。
经过以上几点优化后，更换10000+设备所需的时间从15天增加到更换4000+设备的4天。 5）注重更多效率提升探索。
在大规模故障审核当晚，我们对快速故障处理时的发布产生了一些思考：回滚或紧急发布能否更快完成？软件发布效率还有提升空间吗？答案是肯定的。为了从细节入手，我们记录了每一个机器的变化。
最终发现关键软件下载耗时40%，原因是程序包太大。交付方案是多台机器同时从变更系统拉取程序包。
这立刻让我们想起了客户集中下载 COS 单个对象的场景。这种场景的最优解决方案就是介绍CDN的特性和优势：预热！在实现上，我们采用了两种解决方案：第一，缓存访问点就近分布。
当机器触发新的数据包拉取时，它会将副本保存到缓存访问点。后续机器将数据包拉取到拉取数据包的缓存访问点，减少拉取数据包所需的时间。
缺点是需要尽可能多的缓存访问点； COS 区域较多，成本较高。第二，预取。
变更系统知道发布订单的所有行为，因此当任务启动时，后台启动（例如根据平台的并发度）将包分发到机器上。后面执行的机器会在单机变更模板上增加一个步骤：判断是否已经下发。
当flag分发时，将跳过分发包，直接开始更改步骤。 （COS采用该方案可以节省缓存访问点，降低带宽和机器成本。
）该方案上线后，单机执行效率提升40%。 6）只考虑效率提升带来的问题。
云上2B业务规模巨大。叠加对象存储 COS 内部模块数量超过 20 个，节点数量超过 10 万个。
对版本迭代的质量必须提出极高的要求。质量与效率并不直观，但总是影响真实的交付效率。
总的来讲：当前的网络发布，效率是诉求，但发布质量是痛点。如果质量问题不解决，单纯提高效率是不够完美的。
提高出版效率，质量是一个痛点。 COS 很难优化出版过程中引入的质量问题。
年度维度的时间迭代包括COS运营模式改造、存储架构升级、变更系统改进、变更系统适配改造等多项措施，在解决质量问题时，不仅解决效率痛点，规范变更流程，并且保证了变更的质量，同时也减少了变更人力，多方面有助于提高发布效率。下面我们就来说说 COS 如何提高出版质量。
我希望它能给你一些想法。 1）明确COS本身的质量痛点。
首先，OSS不完善，没有实例管理。由于前期没有统一的OSS，部署/Zone开发都是通过复制包的方式完成的。
缺乏OSS会导致版本中的状态感知和各种版本中的故障排除效率低下。三级模块管理容易出错。
因此，实例接口升级是一个必要的途径。其次，配置包区域化，模板不一致。
每个区域都有自己独特的配置，不需要独立性。修改一次全网特性，需要去各个区域包更改配置，确认时也是如此。
差异化的配置有很多，改造统一的配置文件是重中之重。第三，发布过程任意，发布成功率由运维能力保证。
原来的版本变更系统没有顺序的概念，只有通用的编排比如串行/并行指向ip发布。变更流程的问题从历史中就可以看出，而原来的发布变更系统问题最多。
在业务发展初期，典型的情况是只考虑变革效率的最终提升，而不考虑因管控不足而带来的质量风险。因此，系统选型需要根据自身业务的管控需求而定。
管控缺陷主要分为以下六点： COS 发布场景梳理和基于 COS 业务特征的逻辑梳理。我们从正常部署、正常回滚、配置发布、扩缩容、紧急逃生、混合部署后发布开始。
首先根据现有网络变更过程中遇到的所有问题确定所有场景。另外，回滚也是针对云业务的一个计划。
当涉及到发布时，应该尽快回滚。如果不是回滚问题，我们其实希望将回滚流程变成前向发布来继续变更。
观察点梳理——质量哨兵对 COS 发布前后的观察点进行梳理，更容易了解变更行为并设置“哨兵”。包括基本流程是否启动，日志、coredump是否有错误，正常/异常返回码是否正常，业务请求延迟成功率是否变化。
?软件负责人对每次变更提供的额外注意事项，以及变更后更新的功能点的验证。以及变更是否可以回滚，以及计划如何处理；关注变更过程中的事件（不仅仅是变更模块的告警，而是整体的告警）以及用户投诉、集群异常事件等。
2）克服配置文件管理，升级为配置模板+配置变量的管理模式一一进行，对于整体运营的提升有很大的帮助。首先，确定区域开发的配置模板和配置变量。
OSS 支持自动化区域开发??和独立客户。单一应用程序创建；其次，OSS识别配置变量，可以确定每个配置变量的作用，明确变量使用场景，实现配置修改和分发的计划模型，替代sed；第三，管理配置模板后，全局配置统一，无需担心任何区域配置文件的特殊性；第四，区分配置模板和配置变量后，可以根据情况逐步减少配置变量，使得通用性更强，降低操作复杂度；第五，配置变量对应的文件可以独立提取，方便配置中心管理等更高级的分发和升级；第六，实例问题——OSS建设，实例接口升级（需要半年时间）。
接口实例化升级。第一，接口方便对指定的发布、日志、监控系统进行统一管理（oss只维护接口，所有平台都支持监控接口自动更新）；其次，实例接口统一后，可以连接到部门产品树和集群树下的产品，标准化集群和LZ（逻辑区域）从根源上防止IP变化；另外，基于标签的配置范围管理，通过建立标签映射关系的工具支持，可以减少大量运维平台的迁移工作。
改革变更流程的第一步是固化发布流程。由于腾讯云是通过区域销售和区域进行管理的，而 COS 是 Region 级别的产品，Region 作为内部发布平台的抽象任务，内部区分不同功能特性的集群。
然而，所有软件的发布方式多种多样，没有办法保证每个人都能毫无问题地发布。所以我们的方案是缩小释放爆炸半径并固化：区域释放序列唯一并固化，并建立可以最小化释放爆炸半径的流程安排和验证（比如第二部分中COS的直观改进）以及第4)点的发布流程优化。
图），所有规范均通过智研平台标准化，一申请一流程、现代化升级固化发布流程、工具化实施审批、双重检查、强制回滚、预发布流程等，消除人为错误，提供为自动化变更奠定基础。详细点还包括：每一列划分为一个完整的云属性概念，保证不同属性优先级顺序，不同列之间引入暂停确认；将LZ（逻辑区域）的概念简化为编排单元（图中的各个Task）； LZ内实行集合管理，保证根据区域内不同云客户的优先级安排发布顺序；新的区域场景将自动识别管道模板，确保每个新的/减少的集群都将添加到更改管道中。
确保网络全覆盖。其次，固化的发布策略保证了发布过程，当然也保证了发布过程（发布策略）。
故障可以暂停，变化必须灰度，变化方式统一；统一变更策略：统一程序变更最大失败次数、组内/组间并发；统一灰度策略：所有变更遵循[1-确认-10%-确认-%]灰度节奏，有力保障变更影响区域和人工观察确认；统一的单机变更模板：正常的程序变更和配置变更有一个单机变更模板，其他根据场景而不同；统一发布时间：落地部门更改标准时间，更改时间后自动停止发布订单。其他变革过程如下： 转型后的收获 3）解决存储业务共部署场景，建立很多需要极度挤压硬件性能并与存储设备共部署的业务。
这种场景与离线主机托管不同。属于线上、线上主机托管。
每项服务都需要确保可用性。因此，发布时需要考虑针对此类场景的容灾设计。
需要避免的情况：一是软件A的数量>>软件B，软件A的10%灰度触发机器死机，导致软件B%的服务异常；第二，软件B的三副本单元模型（指索引存储、块存储等实现），软件A的机器变更影响软件B的配对异常场景，也会导致部分数据不可用。解决方案是引入大家普遍理解的容灾分组，保证上述流程实施后标准化并发布。
4）改善变更系统发布问题，解决的重点不仅仅是发布。COS 还针对变更提出了许多额外的操作要求。
总体而言，发布理念和发布流程控制的标准化解决了大多数发布流程中可能因人为误操作而导致的问题。充分标准化带来的好处是全面标准化外包发布，通过运维、开发合作不断减少发布变更的人力投入。
而且关键是：版本发布中不再出现人为操作导致的故障案例。 COS 的变化和转型总结是不断衡量、不断优化的。
如果充分考虑发布的所有积极方面，效率和质量都可以提高。但这就足够了吗？答案是否定的。
还需要一个良好的可衡量体系来保证各方面的数据反馈和持续优化。好的测量有两个特点：一是能够回答本质问题，二是能够指导正确的行为。
两者缺一不可。 1）审核负面反馈 目前，COS 根据每个公布的目标进行行为数据审核。
可以参考以下几点： 第一，成熟度指标体系：比如达到某些标志性数据后，可以直观地识别成熟度水平（但水平较低可能包括各种历史和业务原因）。 ?第二，提高发布效率：比如从执行日志中找到单机效率低的点，比如找到整个发布过程中延时较大、可以优化的点。
?第三，考虑发布行为：比如整个发布过程占用了多少人力，一次性转化的成功率高吗？由于人为链接或系统因素，频繁出现发布失败的情况。发布报表包含数据。
这些数据可以作为给用户的负面反馈，以确定是否应该梳理当前的发布问题以及如何改进（是否是环境污染、配置错误、模板等而不是幂等）。因为经过统计，我们发现30%的人力消耗发生在发布之后，所以我们对发布的优化就变得非常重要。
第四，发布过程事件关联：通过不同问题类型引发的故障影响，对每个问题做出贡献系数，最终建立变更质量检查的评分体系。 ?五、发布软件的原因：从程序出发，可以对程序问题的原因进行分类统计。
比如同一个软件经常有BUG、同一个平台经常有BUG、受BUG影响的平均在线时间等等。反馈给研发团队是可行的。
改进计划。 ?六、审核负面反馈通过部门一定平台汇总展示：定期向所有产品的发布状态发送邮件，指导各个环节完善管理。
?2）成熟度体系是基于对腾讯云发布的理解。 COS 将发布成熟度分为以下五个级别，最终目标是全自动发布。
建立标准和成熟度模型，用数据驱动和提高发布变更各环节的成熟度，走向自动化。未来：向更智能的发布模型的演进从变更质量检查开始。
区域报警相关区域变化、事件总线构建（相关事件关联）、故障快速定位构建。使用质量检测和评分系统来取代灰度和全量&面积与面积之间的每一个停顿和确认点，实现流程的自动化。
其次，在事件相关变更、统一质检仪表板和结果分析、软件回滚的前提下，自动回滚能力也同时具备。在骨干发展的基础上，引入城际快车发布模式，继承其带来的效益。
每个时间点每个人都非常清楚，每个人都感觉到功能在进步，速度在增加，并且重点更多地集中在生产质量上。最后，将云业务特性与devops中的变更仪表板结合起来：统一控制发布和发布审核（比如同一个区域同时下发订单的最大数量等），让大家有一种感觉紧迫性和关键功能不会被错过。
版本。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-17
06-17
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用