1、 SRESRE 实践白皮书实践白皮书 v1.0.4v1.0.4 2024年9月 SRE-E 修 订 记 录修 订 记 录 1.0.4 修订记录：第三章第 2 节研发保障结构进行了优化，并增加了 某大型游戏全球研发保障实践等合共 2 个案例，新增2.7 万字。第三章第 5 节故障应急结构进行了优化，依据2024 年 6 月 22 日 北京小米站沙龙更新并增加了小米故障应急响应经验分享等合共 5 个案例，新增 4.5 万字。1.0.3 修订记录：第三章第 4 节变更管理依据 2024 年 4 月 13 日上海 B 站沙龙更新约 4 万字，包括 6 篇不同类型的企业案例 1.0.2 修订记录：增加了

2、版权声明 为 CC BY-ND 4.0 修正了目录没有 3.1.1 的问题 修改了页眉的时间点 修正了部分错别字 目 录目 录 第一章 SRE 整体介绍.1 1.1 前言.1 1.2 SRE 发展历程.2 1.3 SRE 的目标.4 第二章 SRE 的组织架构.6 第三章 SRE 的职能.10 1 可靠性架构设计.10 1.1 应用韧性架构.11 1.1.1 分布式设计.11 1.1.2 解耦设计.11 1.1.3 冗余设计.11 1.1.4 熔断设计.12 1.1.5 限流设计.12 1.1.6 降级设计.13 1.1.7 可观测设计.13 1.2 基础设施保障.14 1.2.1 机房多活.

3、14 1.2.2 网络容灾.14 1.3 数据灾备.14 1.3.1 数据备份.14 1.3.2 数据回滚.14 2 研发保障.15 2.1 研发保障体系设计.16 2.1.1 代码可靠性.16 2.1.1.1 代码缺陷.17 2.1.1.2 代码规范.19 2.1.1.3 代码安全.21 2.1.1.4 代码圈复杂度.23 2.1.1.5 代码重复.24 2.1.1.6 代码注释与 API 文档.26 2.1.1.7 代码质量红线.27 2.1.2 代码仓库可靠性.28 2.1.2.1 仓库性能.29 2.1.2.1 仓库容灾.30 2.1.2.3 仓库安全.32 2.1.2.4 仓库可扩展

4、性.33 2.1.3 构建可靠性.34 2.1.3.1 构建效率.34 2.1.3.2 构建成功率.37 2.1.4 制品可靠性.38 2.1.4.1 制品下载可靠性.38 2.1.4.2 制品部署可靠性.40 2.1.4.3 制品安全可靠性.41 2.2 研发保障工程体系设计.42 2.2.1 面向研发保障的持续集成流水线.42 2.2.2 面向研发保障的可观测设计.46 2.2.3 面向研发保障的操作调度操作平台.48 2.2.4 面向研发保障的 ITSM 平台.51 2.2.5 面向研发保障的容器平台.51 2.2.6 面向研发保障的编译加速平台.53 2.3 研发保障案例.55 2.3

5、.1 腾讯游戏全球研发保障实践.55 2.3.2 某语音直播公司研发过程保障实践.129 SRE Elite 精选原因.129 3 入网控制.152 3.1 运行环境适配.152 3.1.1 运营环境设计.152 3.1.2 容器云适配.154 3.1.3 数据库存储适配.157 3.1.4 信创适配.158 3.2 运行环境交付.163 3.2.1 基础资源服务.163 3.2.2 可观测策略.165 3.2.3 自动化策略.167 3.3 测试策略.169 3.3.1 连通性验证.169 3.3.2 功能测试.171 3.3.3 性能压测.174 3.3.4 数据迁移.179 3.4 变更

6、评审.180 3.4.1 稳定性架构设计评估.180 3.4.2 非功能性技术评估.182 3.4.3 变更保障准备工作评估.185 3.4.4 新系统或新业务上线保障评估.186 4 变更管理.188 4.1 发布管理与变更管理关系阐述.189 4.2 变更体系设计.191 4.2.1 变更体系设计原则.191 4.2.2 变更及发布流程设计.192 4.2.3 变更的工程体系设计.215 4.3 变更管理案例.243 4.3.1 B 站变更防控的设计与实践.243 4.3.2 携程云平台基础设施变更管理实践.266 4.3.3 某银行变更管理设计与实践.288 4.4 发布管理案例.307

7、 4.4.1 中移互联网敏捷发布平台建设实践.307 4.4.2 某证券变更一体化平台建设实践.326 4.4.3 游戏 GitOps 发布管理实践.344 5 故障应急.351 5.1 故障应急体系设计.351 5.1.1 故障应急体系设计原则.351 5.1.2 故障应急流程设计.351 5.1.2.1 故障发现.351 5.1.2.1.1 监控发现.351 5.1.2.1.1 巡检发现.354 5.1.3 人工上报（舆情，客服，运营人员等）.356 5.2 故障诊断.356 5.2.1 应急协同.356 5.2.2 故障定界.359 5.2.3 影响评估（影响人数，范围，上报级别）.36

8、2 5.3 故障恢复.363 5.3.1 架构自愈.363 5.3.2 应急预案（已知的预案）.364 5.3.3 应急维护（人工干预，未知预案）.364 5.3.4 恢复验证.365 5.4 故障复盘.365 5.4.1 复盘组织.366 5.4.2 根因分析.369 5.4.3 制定改进.371 5.4.4 问题跟踪.373 5.2 故障应急工程体系设计.374 5.2.1 面向故障应急的监控设计.374 5.2.2 面向故障应急的作业平台设计.378 5.2.3 面向故障应急的 ITSM 设计.382 5.3 故障应急案例.386 5.3.1 小米故障应急响应经验分享.386 5.3.2

9、 中国联通数字化监控平台稳定性保障实践.415 5.5.3 腾讯全球化游戏故障管理实践.447 5.5.4 XX 银行应急管理一体化平台建设实践.487 5.5.5 美图故障管理体系搭建实践.502 6 上线后持续优化工作.557 6.1 用户体验优化.557 6.1.1 基于用户端的直接用户体验优化.558 6.1.2 基于系统端的间接用户体验优化.558 6.2 重大技术保障.562 6.2.1 整体统筹保障.562 6.2.2 技术方案保障.563 6.2.3 工具可靠性保障.564 6.2.4 突发事件保障.566 6.2.5 示例 1：哀悼日停止游戏服务保障.567 6.2.6 示例

10、 2:交易类大促核心保障流程和方案.573 6.2.7 示例 3：银行类通用重大保障活动.576 6.2.8 示例 4：发布会直播通用重大保障活动.578 6.3 运维琐事的日常管理及优化.583 6.3.1 运维琐事的介绍.583 6.3.2 运维琐事的质量管理.585 6.3.3 运维琐事的效率管理.586 6.4 业务全生命周期工具建设.588 6.4.1 研发期工具建设.589 6.4.2 上线期工具建设.590 6.4.3 运营期工具建设.591 6.4.4 下线期工具建设.592 6.5 运营成本分析及优化.593 6.5.1 运营成本分析及优化的必要性.593 6.5.2 运营成

11、本实时监控.594 6.5.3 运营成本分析及优化的指标.594 6.5.4 运营成本的统计及分析方法.596 6.5.4 运营成本的优化方法.599 6.5.5 运营成本优化持续运营.602 6.6 混沌工程.604 6.6.1 正常行为定义.604 6.6.2 设计和实施混沌实验.605 6.6.3 监控和分析实验结果.606 6.6.4 优化和修复问题.607 6.6.5 持续迭代和改进.608 6.7 应用服务 SLI/SLO.608 6.7.1 什么是 SLI/SLO.608 6.7.2 如何建设 SLI/SLO.609 6.7.3 如何持续迭代 SLI/SLO.613 6.8 持续

12、改进.615 6.8.1 效率持续改进.615 6.8.2 质量持续改进.617 6.8.3 安全持续改进.618 6.8.4 人员能力持续提升.620 6.8.5 流程持续改进.621 7 平台工程.624 7.1 标准应用平台工程建设.624 7.1.1 应用元信息平台.625 7.1.2 统一资源供给.628 7.1.3 持续集成.629 7.1.4 持续部署.633 7.1.5 部署编排.636 7.1.6 可观测.640 7.1.7 成本（定价、用量、出账）.641 7.2 异构应用平台工程建设.644 7.2.1 总体设计.645 7.2.2 aPaaS 结构设计.646 7.2.

13、3 iPaaS 结构设计.652 7.2.4 通用原子设计.654 7.2.5 SaaS 分级.661 7.2.6 服务管理.664 7.2.7 安全与审计.666 附录.671 1 参考文献.671 2 术语.671 i 网址：SRE-E 微信：SRE 精英联盟 版权声明版权声明 这项作品采用 CC BY-ND 4.0 许可进行授权。要查看此许可的副本，请访问 http:/creativecommons.org/licenses/by-nd/4.0/CC BYCC BY-ND 4.0 DEEDND 4.0 DEED 署名署名-禁止演绎禁止演绎 4.0 4.0 国际国际 您可以自由地：共享 在

14、任何媒介以任何形式复制、发行本作品 在任何用途下，甚至商业目的。只要你遵守许可协议条款，许可人就无法收回你的这些权利。惟须遵守下列条件：署名 您必须给出 适当的署名，提供指向本许可协议的链接，同时 标明是否（对原始作品）作了修改。您可以用任何合理的方式来署名，但是不得以任何方式暗示许可人为您或您的使用背书。禁止演绎 如果您 再混合、转换、或者基于该作品创作，您不可以分发修改作品。没有附加限制 您不得适用法律术语或者 技术措施 从而限制其他人做许可协议允许的事情。声明：您不必因为公共领域的作品要素而遵守许可协议，或者您的使用被可适用的 例外或限制 所允许。不提供担保。许可协议可能不会给与您意图使

15、用的所必须的所有许可。例如，其他权利比如 形象权、隐私权或人格权 可能限制您如何使用作品。1 网址：SRE-E 微信：SRE 精英联盟 第一章第一章 SRE 整体介绍整体介绍 1.1 前言前言 Google 在 2003 年启动了一个全新的团队“SRE 团队”，该团队旨在通过软件工程的方法提高应用系统的可靠性；随着 SRE 相关理论和实践在 Google 的日臻成熟，SRE 实践也从 Google 慢慢地扩散到了整个行业。自从 SRE 的理念进入中国以来，就已经引起了很多企业的关注和效仿，但各企业实施 SRE 的方法各异，SRE 的实现效果也各不相同。与此同时，中国的互联网行业中涌现出了一批对

16、 SRE 充满热情的倡导者，他们为社区做出了各种贡献；包括：孙宇聪翻译出版了SRE：Google 运维解密、赵成在极客时间开设了课程SRE 实战手册，以及赵舜东在社区里积极地布道分享等等，不胜枚举。2022 年，由赵成等人牵头，首批来自于互联网、运营商、金融等行业领军企业的 SRE 团队负责人齐聚一堂，组织了 SRE 研讨社区，定期开展社区分享活动，共同探讨 SRE 在各企业里的发展路径，分享各自的实战经验，并总结出了这份来自一线实战的、详实而持续更新的SRE 实践白皮书。社区每年都吸纳新的成员，逐年更新本白皮书内容，力求真实客观地描述国内企业 SRE 团队的工作方式。在实践白皮书初稿长达两年

17、的整理过程中，我们看到 2 网址：SRE-E 微信：SRE 精英联盟 了不同企业对 SRE 的理解，并尽可能统一大家对相似场景的定义；我们看到了不同企业对 SRE 职能领地的扩展，并将成功团队的经验提炼成案例供大家参考；我们也看到了在这两年的编写过程中，不同企业 SRE 团队的真实变化，并及时将其更新到实践白皮书中。总之，在未来的每个季度，我们都会将各 SRE 团队的最新职能、组织形式、技术迭代等现状，补充到实践白皮书中。2023 年，中国信息通信研究院（下简称信通院）云计算与大数据研究所（下简称云大所）稳定性保障实验室的专家加入了 SRE 研讨社区，深度的参与到社区交流当中，为SRE 实践白

18、皮书的编写工作提供了专业指导。1.2 SRE 发展历程发展历程 SRE 运动在全球的发展经历了 20 年，下面是部分重要事件：2003 年，Google 成立了第一个 SRE 团队；2010 年，Facebook 拥有了一个 SRE 团队；2014 年，USENIX 协会主办的首届 SREcon（网站可靠性工程会议）在美国举行，大会成为了 SRE 专业人士交流经验和最佳实践的重要平台，标志着 SRE 作为一个独立且重要的专业领域在全球范围内的正式认可。3 网址：SRE-E 微信：SRE 精英联盟 2016 年，前 Google SRE 孙宇聪翻译出版了首部中文专业书籍SRE：Google 运维

19、揭秘，在国内引起了很大的反响，很多企业开始学习并成立自己的 SRE 团队；2016 年，Netflix 成立了“核心 SRE 团队”。Uber 开始撰写有关其如何使用 SRE 的文章；2016 年，蚂蚁集团在国内成立了第一支 SRE 团队，主要攻坚容灾架构，后续拓展到高可用、资金安全等多个业务风险领域；2017 年，LinkedIn 开始宣传其“SRE 文化”；2017 年，浙江移动正式组建应用 SRE 团队，开始收口 IT 系统的集成部署、应急保障、架构治理等工作职责，加速了传统企业的运维数字化的转型进程；2018 年，赵成在某次 SRE 的聚会上，拉起了“聊聊 SRE”微信群，国内 SRE

20、 人才开始聚拢，SRE 社区初步成型，并逐步成为了最具影响力 SRE 中文社区；2021，阿里 CTO 线第一支横向 SRE 团队成立，隶属于技术风险与效能部，负责集团全局稳定性保障、资源成本等方面工作；2022 年，腾讯在内部技术岗位设置中，新增了 SRE，标志着腾讯内部 SRE 体系的正式成立；2023 年，信通院云大所稳定性保障实验室牵头编制服务韧性工程（SRE）成熟度模型标准，推动该领域深入研究与实践应用，并在稳定性保障实验室成立了专门的“SRE 工作组”。4 网址：SRE-E 微信：SRE 精英联盟 1.3 SRE 的目标的目标 Site Reliability Engineerin

21、g（SRE）的主要目标是通过结合软件工程和系统运维的最佳实践，提高大规模分布式系统的可靠性、可用性、性能和效率。以下是部分 SRE 追求的核心目标：可靠性：SRE 的首要目标是确保服务和系统的可靠性。这包括减少故障、提高系统的稳定性，以确保用户在任何时候都能够获得一致的高质量服务。可扩展性：SRE 致力于设计和实施能够随着用户需求增长而扩展的系统。这涉及到对系统的架构和资源进行优化，以便在不降低性能的情况下，适应实际工作负载持续不断的峰谷状态变化。性能：SRE 关注系统的性能，旨在确保系统能够在合理地时间内快速响应用户请求。这包括对系统瓶颈的持续监控和优化，以提高整体性能。自动化：SRE 倡导

22、自动化运维工作，以减少人为错误和提高效率。通过自动化，可以更快速地部署新功能、检测并响应故障，并合理的开展系统的升级和维护工作。监控和告警：SRE 强调对系统的全面监控，以便及时发现并解决问题。通过设置有效的告警系统，可以在重大问题发生前迅速做出反应，从而减少对用户的影响。5 网址：SRE-E 微信：SRE 精英联盟 故障恢复：SRE 强调迅速而有效地恢复服务，以最小化用户体验的中断。这包括制定和演练紧急情况的应急计划。企业实现 SRE 核心目标的过程并不相同，落地路径各异。不论 SRE 部门（团队）在企业中的存在形式和所处位置，SRE 相关实践工作存在于大量流程中。这些工作流程与研发、测试、

23、运维、产品运营等团队紧密的融合在一起，所有参与团队都在上述共享的 SRE 目标上做着各自的贡献。6 网址：SRE-E 微信：SRE 精英联盟 第二章第二章 SRE 的组织架构的组织架构 SRE 团队在组织中的存在意义主要是确保系统的可靠性和高效运行。通过引入 SRE 角色，组织可以更好地平衡软件开发速率和系统稳定性之间的需求，从而实现更高水平的可用性、性能和自动化。通常 SRE 团队在组织中使命如下：可靠性优先：SRE 团队致力于确保服务的高可用性和可靠性。他们关注系统的稳定性，采取工程化方法来减少故障和提高系统的稳定性。自动化运维：SRE 团队推动自动化运维工作，以减少手动操作的错误和提高效

24、率。通过自动化，可以更快速、可靠地进行部署、监控、故障检测和修复等操作。质量保证：SRE 团队参与服务的全生命周期，包括设计、开发、部署和维护阶段，以确保系统在不同阶段都能保持高质量。快速创新：通过减少故障和提高系统的稳定性，SRE 团队为开发团队提供了更稳定的平台，使其能够更专注于业务创新和新功能的开发。7 网址：SRE-E 微信：SRE 精英联盟 在组织架构中，SRE 团队的存在形式可以各不相同，这主要取决于组织的规模、业务需求和文化。以下是一些常见的 SRE 团队的存在形式：中心化 SRE 团队：由一个专门的 SRE 团队负责支持整个组织的可靠性工作。这种模式有助于集中专业知识，确保在整

25、个组织中实施一致的最佳实践。嵌入式 SRE 团队：SRE 团队成员被嵌入到各个产品或服务团队中，与开发团队紧密合作。这种模式有助于更好地集成可靠性工作到产品开发的全过程中。混合模式：一些组织采取混合模式，既有中心化的 SRE 团队，又在一些关键项目中嵌入 SRE 角色。这种方式能够兼顾专业化和贴近业务的优势。每种存在形式都有其优势和适用场景，关键在于根据组织的需求选择最合适的模式。不论哪种方式，SRE 的目标都是通过自动化和工程方法提高系统的可靠性和效率。下面是国内某几家一线互联网 SRE 团队在组织架构中的设置模式。8 网址：SRE-E 微信：SRE 精英联盟 9 网址：SRE-E 微信：S

26、RE 精英联盟 参考以上各个公司 SRE 团队在组织架构中的位置，通常 SRE 团队需要承担以下几类职责：监控、事故响应、事后回顾、测试与发布、容量规划、工具开发和可用性改进等。由于各个公司的业务形态的不同，SRE 团队在组织架构中也有不同的定位和名称，包括：SRE 产品运维、互联网 SRE 组、AIoT SRE 组、信息技术 SRE 组、业务 SRE 组等。10 网址：SRE-E 微信：SRE 精英联盟 第三章第三章 SRE 的职能的职能 1 可靠性可靠性架构架构设计设计 可靠性架构设计是指在进行系统架构设计的过程中，根据系统的可靠性需求，采用分布式设计、解耦设计、冗余设计等高可靠性的架构设

27、计方案，以提升系统的可靠性。在进行可靠性架构设计的过程中，SRE 团队需要将应用架构设计流程完全融入其中，并与研发团队共同参与架构设计和评审工作。在系统设计阶段，应尽量消除可能出现的单点、容量等潜在风险，并提前为可能出现的系统架构风险做好应急准备。11 网址：SRE-E 微信：SRE 精英联盟 1.1 应用韧性架构应用韧性架构 1.1.1 分布分布式式设计设计 在系统中，存在被划分为职责明确、粒度合适且易于管理的组件，这些组件（如计算资源、业务部分、数据等）都可以进行分布式的部署和运行。组件之间相互独立、互不干扰，通过分布式设计可以提高开发效率和可靠性。组件的拆分和分布可以通过复制、根据功能进

28、行垂直拆分、或根据用户与访问模式水平拆分等形式。在设计时应该充分考虑到组件间可能存在的相互干扰以及如何平衡不同组件之间的负载，并将系统所承受的压力进行均匀分配，以减轻压力对系统整体性能的不良影响。1.1.2 解耦设计解耦设计 在架构设计中，可以将各种逻辑功能划分为不同的服务模块，确保不同模块的故障对其他模块的影响是最小，从而最大限度地降低模块之间的耦合度。通过这种方式，可以将系统划分为多个相互独立的功能模块来实现。尤其值得注意的是，业务的主要逻辑与其他非核心模块是独立的，因此业务非核心模块的故障并不会对业务的核心功能产生负面影响。1.1.3 冗余设计冗余设计 为了确保资源有足够的安全余量，每个

29、组件都需要有足够和合理的冗余实例，以确保单一组件实例的失效不会对业务的正常运行造成影响。对于不同类型的组件，我们需要明确地定义冗余量和冗 12 网址：SRE-E 微信：SRE 精英联盟 余类型。在实际应用中，由于设备故障或者操作不当等原因导致服务器出现性能下降或崩溃现象时，系统会出现异常状态并产生大量信息。应用程序可能部署多个机房，当这些机房中有数据冗余时，一个位置的错误可以通过另一个位置的数据进行修正，确保整个系统的连续性和可靠性。为了提高系统可靠性，通常采用读-写分离的技术进行数据的冗余管理。读写分离是一种冗余的设计方式，缓存和数据库之间存在数据冗余，当缓存服务宕机时，可以从数据库回源到缓

30、存。1.1.4 熔断设计熔断设计 熔断机制是应对雪崩效应的一种微服务链路保护机制，如果目标服务的调用速度较慢或超时次数较多，则此时会熔断该服务的调用。对于后续的调用请求，不再继续对目标服务进行调用，直接返回预期设置好的结果，可以快速释放资源。一般来说，熔断需要设置不同的恢复策略，如果目标服务条件改善，则恢复。1.1.5 限流设计限流设计 限流是一种系统设计技术，用于控制访问应用程序或服务的流量，防止资源过载。常见的限流策略包括固定窗口、滑动日志、漏桶和令牌桶算法。这些方法可以帮助系统应对高流量，保持稳定性和可靠性。在实施时，通常需要结合其他系统保护措施，如队列、缓存、服务降级和熔断，以实现全面

31、的流量控制和系统保护。13 网址：SRE-E 微信：SRE 精英联盟 当流量被限制后，系统通常会采取以下措施之一：拒绝多余的请求、将请求排队等待处理、返回错误码（如 HTTP 429 Too Many Requests）、或者提供一个降级的服务响应。这些措施可以缓解服务器压力。1.1.6 降级设计降级设计 降级机制是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略地降级，以此缓解服务器资源的压力，释放服务器资源以保证核心任务的正常运行。从降级配置方式上，降级一般可以分为主动降级和自动降级。主动降级是提前配置，自动降级则是系统发生故障时，如超时或者频繁失败，自动降级。其中，

32、自动降级可分为超时降级、失败次数降级、故障降级。1.1.7 可观测设计可观测设计 为了保证系统的透明性并迅速定位问题，采用可观测的设计方法变得尤为关键。可观测设计涵盖了日志记录、实时监控、追踪以及度量等多个方面，从而实现了系统状态和行为的可量化以及可分析性。在可观测的设计中，日志应当详细地记录所有的关键事件，监控系统需要能够实时捕获关键的性能指标，跟踪机制应具备跨服务请求的追踪能力，度量指标则应全方位地反映系统的健康状态。另外，健康检查机制需要自动地对系统组件状态进行评估，当出现异常指标时，告警机制会立即告知相关的工作人员。通过这些措 14 网址：SRE-E 微信：SRE 精英联盟 施，我们可

33、以清晰地观察到系统的运行状态，从而为后续的维护和优化工作奠定了稳固的基础。1.2 基础设施保障基础设施保障 1.2.1 机房多活机房多活 系统所部署的机器或所在地需具备一定的冗余性。包括同机房多活、同城多活和异地多活等不同级别。将要建设的机房要求具有独立性，尤其是网络环境，机房之间通过专线来进行连接。1.2.2 网络容灾网络容灾 数据中心之间的互联网络是 DC 之间业务连接的重要载体，对存储灾备网络的时延要求较低、带宽较大、可靠性较高；业务灾备网络需要实现链路备份和快速的路由收敛。1.3 数据灾备数据灾备 1.3.1 数据备份数据备份 即对核心数据进行备份和恢复的能力。需对核心数据进行实时备份

34、，并具备快速容灾切换的能力。需对备份恢复的能力进行周期性地验证。1.3.2 数据回滚数据回滚 在系统出现异常情况下，迅速有效地恢复故障前数据状态，减少了故障给业务系统带来的冲击。回滚是否有效取决于回滚执行过程和回滚决策是否及时。15 网址：SRE-E 微信：SRE 精英联盟 2 研发保障研发保障 通常说法是，SRE 处置的线上可靠性问题中，有 70%左右源自CD 阶段（详见第三章第 4 节“变更管理”），15%左右源自研发阶段（例如代码的低质量、高维护成本等）。对于初创的 SRE 团队，应该将工作重心放在 CD 与 CO 阶段，做好救火工作，同时夯实 CD-CO 阶段的工程化，保障 SLA。在

35、取得阶段性成果的基础上，我们应逐步拓展至研发服务领域，并进入持续集成（CI）领域。此举旨在尝试降低研发阶段可靠性问题的根源，减少至少 15%的相关因素。更为更重要的是打通 CI-CD，以乙方服务心态保障业务团队的研发连续性，追求平台工程的研运一体化理念的落地。有些企业是由质量团队或者独立的效能团队承担这一部分职能，也有业务研发兼职的情况，SRE 团队应该本着以往运维团队的服务传统，将业务研发环境视为一个独立的线上业务，以服务心态尝试“接管”研发环境中代码仓库、CI 流水线、各类测试环境、代码分析扫描平台、制品仓库等研发基础设施的运维工作，并保障其可靠性，进而提高业务团队的生产效率，降低其出错概

36、率。有能力的 SRE 团队接下来可以依托自身的工程化能力将这些工具升级改进，与 SRE 前期已经建设的 CD-CO 平台整合，形成覆盖代码全生命周期的“研发运维运营”一体化的平台工程基础设施。这种发展路径借助运维 SRE 与业务开发团队的紧密关系减少了内耗，16 网址：SRE-E 微信：SRE 精英联盟 CI-CD-CO 全路径由 SRE 团队建设避免了轮子，还减少了例如 PE、DevOps 等小众的公司级岗位设置。研发过程可靠性，指的是以 SRE 理论驱动研发连续性建设，提升研发管线的工业化水平，保障版本能够高质量迭代，从而持续保障业务的线上可靠性，同时兼顾了版本迭代效率；SRE 主导的研发

37、连续性保障，可以拆解为代码可靠性、代码仓库可靠性、构建可靠性和制品可靠性四个方面，每个阶段分别对其可靠性进行定义并提出相应的改善措施；2.1 研发保障体系设计研发保障体系设计 2.1.1 代码可靠性代码可靠性 代码是基于一定需求实现，用于构建对应软件的文件集合。代码质量从基础上决定了软件的成败，是软件开发过程中不可忽视的一环。在软件版本快速迭代的今天，如何构建高质量的代码更显得至关重要。代码可靠性的落地仅靠宣导或者文档还远远不够，需要建设完善的检查工具并量化效果，一般由平台 SRE 建设相关的工具，因此需要平台 SRE 需要深入了解影响代码可靠性的常见问题及提升措施，不断完善代码检查工具的能力

38、；17 网址：SRE-E 微信：SRE 精英联盟 2.1.1.1 代码缺陷代码缺陷 代码缺陷是指影响代码稳定运行的问题，或者未达到设计时的预期功能。缺陷产生的原因有多种，比如：软件的复杂性、编写的错误、需求歧义等。代码缺陷的及时发现与修复，对项目进度与工程质量至关重要。代码缺陷检测，一般可采用静态分析法或动态分析法。静态代码分析是指无需运行被测代码，通过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。动态分析方法则一般应用于软件的测试运行阶段，在软件程序运行过程中，通过分析

39、动态调试器中程序的状态、执行路径等信息来发现缺陷。1代码缺陷规避措施 代码缺陷种类较多，无法完全罗列，这里选取部分最为常见的缺陷并介绍对应的规避办法：1）指针错误使用 指针的错误使用，一般要避免空指针、野指针，避免指针类型不匹配，不返回局部变量的指针。2）内存非法访问 非法内存访问是指程序试图读取或写入未分配/受保护的内存，如数组越界等，这将会导致程序的不可控行为。因此，必须确保程 18 网址：SRE-E 微信：SRE 精英联盟 序正确地分配和释放内存，避免缓冲区溢出等现象。也可使用静态分析工具检测代码中的内存非法访问问题。3）变量未初始化 使用未初始化的变量，可能导致未知错误。一般来讲，变量

40、需要在声明时赋予初始值。4）资源泄漏 常见的资源泄漏包含 socket 泄漏，文件句柄泄漏，内存泄漏等。产生原因是由于未能正确释放已经分配的内存或其他资源，导致这些资源被长期占用。资源泄漏不仅会造成资源的浪费，系统性能下降，严重时超出系统限制会导致程序崩溃。避免资源泄漏，在编程过程中，需要在资源使用完毕后进行资源的释放，如 socket/文件句柄的关闭，动态分配内存的释放。5）竞争死锁 竞争死锁是指多个线程或进程持有资源，又互相竞争等待对方资源而导致死锁的情况。解决死锁问题，一般可采用超时使用机制、统一获取资源顺序和死锁检测机制来打破死锁产生的必要条件。6）不当的 API 使用 不当的 API

41、 使用，会导致程序异常。可通过仔细阅读 API 文档，了解 API 的使用方式，在使用 API 前进行充分测试的方法来规避。2效果评估 19 网址：SRE-E 微信：SRE 精英联盟 代码缺陷数作为代码质量指标之一，可以从数量、严重程度来归类。在度量层面，一般使用百行告警数来衡量代码缺陷指标。通过配置代码缺陷规则集，采用缺陷检测工具扫描，生成检测报告。根据缺陷的严重程度分为严重告警（空指针、数组越界等），一般告警（变量未初始化等）和提示告警（如代码风格等）。设定各个告警等级的权重，统计代码行数，最终计算出百行代码缺陷告警数。百行缺陷告警数=（严重告警 W1+一般告警 W2+提示告警 W3）/代

42、码行数 100（W1/W2/W3 为权重系数）2.1.1.2 代码规范代码规范 代码规范主要是指是否遵守了团队或者业界的编码规范。代码规范主要涵盖：代码风格（如注释、空代码块、命名、格式化等），与异常处理等部分。代码规范有助于提高代码可读性与可维护性，从而提升团队内开发效率。代码可读性帮助相关技术人员能够轻松阅读并理解代码意图与实现方式。代码从分支发起到主干的合并请求前，必须进行代码检查，这也是提前发现问题的方法之一。1代码规范提升措施 1）代码风格 20 网址：SRE-E 微信：SRE 精英联盟 良好的代码风格会帮助开发人员阅读和理解符合该风格的源代码，并且避免错误。此处所讲述的代码风格包括

43、但不限于：命名规范，表达式与语句，缩进，对齐，注释，代码布局等。对于不同的编程语言，适用于不同的代码风格，对于同一项目或开发团队，应当使用统一的代码风格。（1）命名规范，命名要能够直观的表达本身的意图，同时具备可读与可搜索性，尽量遵循一些通用的写法。在此基础上命名长度应当尽量精短，避免触发代码行字符数限制规范；（2）缩进，一般采用 4 个空格缩进，而不使用 tab 键（特殊语言除外）（3）统一字符编码格式，通常采用 UTF-8 编码（4）单行字符数限制，长度一般不超过 120（5）行尾换行符，一般使用换行符 LF，禁止使用回车键 CR 2）异常处理 异常处理是为了防止一些未知错误产生而采取的措

44、施。适当的使用异常处理能够提高程序的容错性。在处理异常方面，需要遵循：（1）只在可能出异常的块进行精准捕获处理；（2）捕获的异常必须处理或抛出给上层调用方；（3）异常处理效率较低，应避免使用异常做条件控制 2效果评估 对于代码规范的效果评估，可以采用百行告警数来衡量。21 网址：SRE-E 微信：SRE 精英联盟 百行告警数=（严重告警 W1+一般告警 W2+提示告警 W3）/代码行数 100 注：（W1/W2/W3 为权重系数）百行告警数可以用来评估代码的质量和稳定性，较高的百行告警数可能意味着代码存在较多的缺陷和潜在问题，需要更多的测试和修复工作；2.1.1.3 代码安全代码安全 安全性是

45、指在为正常访问提供服务的同时，也能拒绝非法访问。同时不因为代码设计或实现的原因，导致信息泄漏/非法侵入/系统崩溃等问题。1代码安全性提升措施 1）防止敏感信息泄漏 敏感信息可分为系统敏感信息与应用敏感信息。系统敏感信息包含业务系统的基础环境信息，如系统版本、组件版本等；应用敏感信息包含用户信息和应用信息等，如用户 TOKEN、密码、IP 等。系统敏感信息泄漏会为攻击者提供更多的攻击方法，应用敏感信息泄漏危害则因泄漏信息内容而决定。解决方法：（1）避免硬编码，禁止将密码等敏感信息写入到代码，应该以配置或后台下发形式读取 22 网址：SRE-E 微信：SRE 精英联盟（2）处理异常时，避免将系统信

46、息、DEBUG 信息、或者敏感文件的路径输出到用户可见处 2）预防安全漏洞 代码安全漏洞，指编码过程中因不当的处理逻辑引发的安全风险；常见的代码安全漏洞有：（1）脚本（SQL）注入，可通过减少拼接命令，对命令参数值进行过滤/校验避免（2）XSS 攻击，可以使用安全的 JavaScript 框架和组件，同时主动检测发现，转义输入等减少（3）越权访问，是由于权限设计错误，未授权用户获取甚至修改其他用户的信息。需要通过最小化原则的权限设计与审计来规避（4）通信安全，一般是由于未使用加密信道进行通信导致，可以通过使用加密/私有协议通信来避免 3）第三方组件安全 软件开发中不可避免的会引入依赖库，或者第

47、三方 SDK。这些第三方组件作为系统的一部分，与原生代码并无本质区别，它们的安全性也同样影响整个系统。因此，需要在减少对第三方组件引入的基础上，加入相应的安全评估机制。对于第三方组件的评估，我们主要从以下几个方面：（1）组件安全风险应在引入前/上线前/定期进行安全扫描（2）组件合规风险包括使用协议合规和监管数据合规 23 网址：SRE-E 微信：SRE 精英联盟（3）组件稳定性应当使用经过实际验证的 LTS 版本 2效果评估 在衡量代码安全性方面，可以从敏感信息泄漏、系统漏洞、第三方高危组件等几个方面来考量。可以通过代码扫描工具，扫描出已知系统漏洞与敏感信息，以及第三方高危组件的引入情况。在得

48、到敏感信息，安全漏洞个数，以及第三方高危组件个数后，可以制定代码安全性红线。一般来讲，敏感信息、安全漏洞是绝对不允许的。对于第三方高危组件，也要经过安全评估测试，其标准与本身代码相同。（1）对于敏感信息与安全漏洞，必须彻底清除（2）第三方高危组件，还可以采用 LTS 覆盖率可以用来衡量系统中使用的第三方高危组件稳定性。LTS 覆盖率=第三方高危组件LTS 数/第三方高危组件数 2.1.1.4 代码圈复杂度代码圈复杂度 圈复杂度是一种代码复杂度的衡量标准，可以用来衡量一个模块流程判定结构的复杂程度。圈复杂度大说明程序代码的判断逻辑复杂，可用来表示对给定代码进行测试、维护或故障排除的难度，以及代码

49、生成错误的可能性。同时，也可用来帮助开发人员确定是否需要对程序进行重构，以降低程序的复杂度，提高代码质量。1圈复杂度改善措施 24 网址：SRE-E 微信：SRE 精英联盟 降低函数圈复杂度的主要通过对代码重构来进行，一般有以下几种方法：（1）将大函数拆分成多个小函数，每个小函数只负责单一功能（2）将条件判定提炼出来，成为独立函数（3）简化、合并条件表达式（4）优化循环结构，减少循环嵌套、使用更简单的循环结构等 2效果评估 圈复杂度反应了代码的耦合度，圈复杂度越高的代码会有越多潜在的 BUG。对于圈复杂度，可以从以下指标衡量：（1）单函数圈复杂度最大值小于等于 20（2）项目平均圈复杂度，一般

50、不大于 4 项目平均圈复杂度=所有函数圈复杂度之和/所有函数个数 2.1.1.5 代码重复代码重复 代码重复指的是程序中存在相同或类似的代码段。在不同的位置或程序中出现相同的代码，会造成了代码冗余和浪费。代码重复，不仅导致项目代码量的增加，影响程序的可读性和可维护性，增加代码的错误率和修改难度，也是设计不佳的一个标志。代码重复的表现形式多种多样，常见形式有：（1）完全一样的代码（2）仅重命名标识符的代码 25 网址：SRE-E 微信：SRE 精英联盟（3）仅变量赋值不一样的代码（4）插入或删除语句的代码（5）重新排列语句的代码 1代码重复改善措施 降低重复代码，是代码优化的重要方面之一，一般需

51、要对相关功能进行重构。常见的改善措施，主要是抽取公共代码、封装函数、使用继承和多态等（1）抽象出公共方法或函数，将重复的代码封装在一个函数或方法中（2）使用继承或接口，将共同代码放在父类或接口中，子类只实现自己的特定部分（3）使用设计模式，如工厂模式、模板方法模式等（4）利用现有的框架或库，避免自己重写 2效果评估 代码重复的度量，可以使用代码重复率来表示，可以通过静态扫描工具得出。代码重复率，指的是在一段代码中重复出现的代码段的比例。代码重复率越高，代码的可维护性和可读性就越差。代码重复率=重复行数/代码总行数 在实际的工程中，一般建议：（1）单文件代码重复率最大值小于等于 10%26 网址

52、：SRE-E 微信：SRE 精英联盟（2）项目平均代码重复率小于等于 10%2.1.1.6 代码注释与代码注释与 API 文档文档 代码的注释与 API 文档编写是软件开发过程中非常重要的一部分，可以提高代码的可读性和可维护性。通过代码注释可以帮助阅读者快速理解代码的功能和实现方式。API 文档则是其他开发者了解使用软件的重要途径。开发者应该养成写注释和文档的好习惯，为自己和其他开发者节省开发时间。1代码注释与 API 文档提升措施（1）注释目的在于使阅读者能够快速掌握注释对象的使用方式与原理，良好的注释应包 含注释对象的产生意图，设计考量与如何使用；注释一般应当包含文件注释，类/结构体注释，

53、函数方法注释，变量注释以及适当的代码段注释；对于规范化命名的变量与简单函数方法，可以不进行注释。（2）API 文档，应当描述各个类和方法的功能和使用方法，同时遵循行业和国际标准，具备兼容性和实时性。2效果评估 对于注释与 API 文档的考量，可以从 API 文档覆盖率，代码注释行密度来衡量。1）注释行密度=注释行数/总行数*100 27 网址：SRE-E 微信：SRE 精英联盟 此标准用于衡量百行代码中，所包含注释行数，一般认为低于5 表示几乎没注释。2）API 文档覆盖率=已覆盖 API 接口数量/总 API 接口数量 此标准用于衡量对外 API 文档的完善程度；一般来讲，至少需要达到 80

54、%覆盖率，即覆盖大部分的 API 功能，忽略了一些不太重要或不常用的 API；同时也需要定期更新，使文档保持最新、全面、准确的状态。2.1.1.7 代码质量红线代码质量红线 代码质量红线是指在开发过程中，开发团队所设定的一些规则和标准，用于确保代码质量达到一定的水平，也是衡量代码质量的一个综合考量。这些规则和标准通常是基于行业最佳实践和经验总结制定的，是团队开发的一种约束和保障。当代码质量超越红线时，就需要开发团队及时进行修正和优化，以确保代码质量和运行稳定性。1质量红线改善措施 质量红线的触发标准是基于每个质量指标的。提升每项指标质量有助于避免触发红线，也可以帮助开发团队提高软件开发的效率和

55、质量，减少错误。2效果评估 质量红线一般包含以下几个指标：（1）代码缺陷 28 网址：SRE-E 微信：SRE 精英联盟（2）代码风格（3）代码安全性（4）圈复杂度（5）代码重复率（6）代码注释和文档（7）单元测试覆盖率 通过在代码合并、转测等场景下，对以上每个指标单独设定阈值，可以划定出不同场景下的质量红线，当某项指标触发质量红线时终止后续的 CI/CD 流程，并要求开发团队进行修复。2.1.2 代码仓库可靠性代码仓库可靠性 代码仓库就是存放源代码和资源的地方，亦称版本库、代码库，其核心功能是版本控制，记录一个或若干文件的变化，以便后续查看特定版本修订的情况;代码仓库出现问题，对代码拉取、项

56、目开发、编译构建等都会造成影响，所以代码仓库的可靠性是整体研发流程可用性的关键一环；代码仓库的可靠性包括：仓库性能、仓库容灾、仓库安全和仓库可扩展性四个方面；代码仓库的可靠性主要侧重网络优化、部署优化、配置优化、安全提升等等工作，可由服务 SRE 和安全人员来承担相关能力的建设；29 网址：SRE-E 微信：SRE 精英联盟 2.1.2.1 仓库性能仓库性能 代码仓库的性能通常是指代码仓库对代码的存储、管理和处理时的速度和效率，包括代码提交和拉取的速度、分支合并的速度等，高性能的代码仓库，可以减少开发人员的等待时间，缩短产品交付周期；1代码仓库性能提升措施（1）控制代码仓库的大小：代码库的大小

57、会直接影响仓库的性能，因为大型代码仓库需要更多的时间来处理和查找文件。因此，需要合理控制仓库大小，及时删除不需要使用的文件，并合理设置文件的保存周期；（2）合理设置代码仓库结构：如果代码仓库的结构合理，可以更快地查找和访问文件，从而提高性能，例如，某些版本管理软件，支持大文件单独存储在仓库之外，仓库中实际只存储一个很小的文本指针，可以将存储大文件的目录设置使用更适合的存储形式；（3）版本工具选型：不同的版本控制工具可能会对性能产生不同的影响。例如，Git 和 SVN、P4 的架构和设计理念的差异，在处理大文件的性能存在差异，需要根据业务资源文件的数量和大小、团队的多地分布特性等综合选择；（4）

58、网络优化：如果多个人同时访问代码仓库，网络连接的速度也会影响性能，在评估代码仓库性能时，需要考虑网络连接的速 30 网址：SRE-E 微信：SRE 精英联盟 度和质量，可在离用户就近的网络区域，部署边缘节点，缓存最近的版本，减少网络距离传输损耗，提高访问速率；（5）硬件升级：硬件也会影响代码仓库的性能，例如，使用较高 IO 性能的磁盘，可以提高代码仓库的读取速度；（6）集群化：通过集群化来部署代码仓库，可以让代码仓库支持更大规模团队的使用；2效果评估 一般采用下面 3 个指标来评估仓库的性能（1）文件下载速度：通常是指每秒传输的数据量，常见的单位有比特/秒（bps）、千比特/秒（Kbps）、兆

59、比特/秒（Mbps）和千兆比特/秒（Gbps）等；（2）下载卡顿率：是指从仓库中下载时出现卡顿的频率或时间占比，通常使用百分比（%）来表示；（3）并发请求量：一般团队多人同时拉取或者提交代码可能会影响速度，通常使用 QPS 来表示系统每秒钟的请求量；2.1.2.1 仓库容灾仓库容灾 代码仓库容灾是指代码仓库在经受自然灾害、设备故障、网络故障、人为错误等不可预测的问题后，通过备份、容错机制和恢复策略在最短时间内恢复到正常可用的状态。完备的代码仓库容灾机制，可以避免团队或公司核心代码资产遭受损失。1代码仓库容灾提升措施 31 网址：SRE-E 微信：SRE 精英联盟（1）数据备份：定期对代码仓库的

60、数据进行备份，确保在数据丢失或损坏时能够及时恢复。（2）多地备份：将备份数据存储在多个地方，以防止单点故障。（3）容错机制：使用容错技术，如 RAID 等，以防止硬件故障导致数据丢失。或者将本地普通硬盘替换为云硬盘，云硬盘中的数据以多副本冗余方式存储，会避免数据的单点故障风险。（4）灾备恢复策略：制定灾备恢复策略，以便在发生灾难时能够及时恢复。（5）人员培训：对相关人员进行培训，提高应对灾难的能力和应变能力。2效果评估 一般使用以下几个指标来评估代码仓库容灾效果（1）恢复时间目标（RTO）：Recovery Time Objective，他是指故障发生时间到故障恢复时间，两个时间点之间的时间段

61、称为RTO；（2）恢复点目标（RPO）：Recovery Point Objective，是指系统恢复到怎样的程度。这种程度可以是上一周的备份数据，也可以是上一次的实时数据；（3）投入产出比（ROI）：Return of Investment，容灾系统的投入产出比，可以使用最高的性价比方案来达到容灾效果，为团队节省成本；32 网址：SRE-E 微信：SRE 精英联盟 2.1.2.3 仓库安全仓库安全 代码仓库的安全性是指代码仓库中存储的代码等数据受到保护的程度，以防止未经授权的访问、篡改、泄露和破坏。保护代码仓库的安全性包括但不限于访问控制、数据加密、代码审查、安全漏洞、操作审计、私有网络部署

62、等。高安全性的代码仓库可以保护代码的机密性，完整性，避免因安全漏洞造成团队或者公司的损失和风险。1代码仓库安全性提升措施（1）访问控制：评估代码仓库中代码的访问控制机制，包括用户认证、授权、权限管理等，确保只有授权的用户能够访问仓库中的代码。（2）数据加密：评估仓库中存储的关键元数据或者敏感代码是否采用了合适的加密技术进行保护，以防止敏感信息泄露。（3）代码审查：评估代码审查机制，确保代码质量和安全性。详细可参考：4.2.1.3 代码安全。（4）安全漏洞：评估代码仓库中可能存在的安全漏洞，包括代码中的漏洞、第三方库中的漏洞等。（5）操作审计：评估代码仓库的操作审计，确保所有操作可追踪，以便及时

63、发现和应对安全事件。（6）私有化部署：将代码仓库部署在私有网络中，例如，企业、学校的内部网络中，相比公网中的外部代码托管服务理论上会更安全；33 网址：SRE-E 微信：SRE 精英联盟 2效果评估 安全往往只有 0 和 1 的概念，要么安全，要么不安全，不存在中间状态，因此代码安全可靠性的效果评估可通过代码泄露等安全事件的发生与否来评估，同时通过审计能力来保障安全事件发生时具备可回溯能力；（1）代码泄漏次数：代码仓库代码泄露事件的次数；（2）漏洞数量：代码仓库中发现的漏洞数量；（3）访问控制：是否具备精细化权限控制的能力；（4）审计能力：是否具备良好的审计能力；2.1.2.4 仓库可扩展性仓

64、库可扩展性 代码仓库的可扩展性是指代码仓库在面对不断增长的代码量、用户数量、访问频率等变化时，能够保持高效的性能，同时可以方便的通过软硬件来扩展功能和架构，以满足未来的需求，代码仓库的可扩展性对一个快速发展中的团队尤其重要。1代码仓库可扩展性提升措施（1）分布式版本控制系统：使用支持分布式版本控制系统，比如 Git，可以支持代码仓库的架构可扩展性，可以将代码库分散在多个服务器上，从而实现横向可扩展；（2）集群化：使用集群化技术，如 Kubernetes 等容器编排系统，可以实现代码仓库的自动化部署和管理；34 网址：SRE-E 微信：SRE 精英联盟（3）功能扩展：使用插件等能力，结合业务的个

65、性化诉求，扩展版本控制系统的功能，满足团队的研发需求；2效果评估 代码仓库可扩展的能力可使用以下两个指标评估（1）架构可扩展性：代码仓库架构是否支持水平横向扩展。（2）功能可扩展性：是否可以通过插件扩展版本控制系统的功能。2.1.3 构建可靠性构建可靠性 构建是指在构建机上把代码、资源文件等源文件编译打包成可执行的程序文件的过程；在当前的持续集成/持续交付的软件开发模式下，若构建出现问题，则新的软件版本无法快速发布验证，软件质量就会受到影响，所以构建的可靠性对于软件服务的可靠性和迭代效率起到了重要作用；构建可靠性主要由构建效率和构建成功率两个方面组成；构建可靠性提升涉及构建工具建设与规划、业务

66、层改造优化、软硬协同等多个方面，一般需要由平台 SRE、业务开发、服务 SRE多角色共同参与；2.1.3.1 构建效率构建效率 构建效率即构建速度，取决于从构建启动到构建结束的耗时情况，构建耗时过长的话软件版本无法按时交付，对业务版本迭代效率产生了影响，构建可靠性就无从谈起。35 网址：SRE-E 微信：SRE 精英联盟 1构建效率提升措施（1）流程自动化 利用自动化构建工具或脚本把构建各个环节串联起来，减少各环节之间的等待时间；（2）并行化 通过把一些构建流程从串行改成并行，优化构建流程，提升构建速度。（3）增量构建 在构建机上执行一次构建时把构建过程中的一些临时文件、中间产物存起来作为构建

67、缓存，等下一次构建时，由于一般情况下只有部分代码被修改了，那么没有被修改的代码就能免去构建环节，直接使用上次的构建缓存，这样就通过增量构建的方式减少了需要构建的内容，降低了构建耗时。针对构建机首次构建时没有缓存的问题，可以搭建构建缓存共享服务器（例如 UE 引擎的 DDC 服务器），一台构建机的构建缓存会生成到缓存共享服务器上，供其他构建机使用。（4）分布式编译 相对单机有限的资源来讲，集群的力量无疑是强大的：一个人计算 100 道数学题，相比 100 个同样能力的人一人计算 1 道题，孰优孰劣不言而喻。分布式编译加速就是利用集群的资源，将单个节点的工作分配给一大批节点，然后再汇总结果。根据需

68、要，资源数 36 网址：SRE-E 微信：SRE 精英联盟 量可以近乎无限地扩充，不再受制于单机的物理架构；时间上，集群工作所需要的时间往往是原来的几分之一。（5）软硬协同 部分构建任务比如代码预处理、资源文件处理无法通过分布式编译加速分发到远端，只能在构建机本地处理，此时本地构建机性能就成为了瓶颈，可以针对性地提升本地构建机的 CPU/内存/磁盘IO 性能，再结合分布式编译系统，软硬协同提升构建速度。（6）多进程编译 有些编译软件默认只开启单进程编译，导致构建机硬件性能未得到充分利用，此时可以通过开启多进程编译来提升构建速度。2效果评估（1）基于基线：使用构建耗时超出基线比例来评估单次构建的

69、效果，每次正常构建完成后，把本次构建耗时上报上去，持续若干天后，我们就能得到一段时期内的多次稳定构建耗时数据，把这些数据求一个平均值之后，我们就得到了这一段时期的构建耗时基线。当一次构建耗时超出基线很多时（比如超出基线 20%），这次构建就可能出现了性能问题，在得到构建耗时基线以后，我们可以将当前构建耗时与基线进行对比来作为 SLO，比如不超过基线 10%即为健康；（2）基于阈值：按不同的业务实际情况设置不同的阈值，例如设置构建耗时不大于 2H 为可靠性的衡量标准；37 网址：SRE-E 微信：SRE 精英联盟 2.1.3.2 构建成功率构建成功率 构建成功率指指定时间内，构建成功次数占构建总

70、次数的比例。构建成功率低的话，需要多次构建才能产生可交付的版本，也是影响构建可靠性的一个关键因素；1构建成功率提升措施（1）保障构建环境可靠性 构建成功率受到构建环境影响，当构建机异常时（比如缺少某个依赖包，连不上代码仓库，磁盘故障等），构建就会失败。我们需要保证构建环境的可靠性，比如通过自动化方式批量部署构建机，避免手动部署时遗漏某些依赖包；尽量利用云上的高可靠性网络、计算和存储。（2）PreBuild 预编译检查 通常的构建是拉取代码后再执行后面的编译流程，这就要求开发编写完代码后必须提交到代码仓库再启动构建。其实可以在提交代码到仓库之前就把问题暴露出来，问题越早发现，修复解决的成本越低；

71、提交到代码库的代码质量越高，问题越少，团队协作起来就越顺畅，越高效。PreBuild 就是在提交代码到仓库之前，利用本地 PreBuild 工具进行本地代码检查或传输代码到远端进行预编译代码检查，从而尽早发现问题，实现质量左移。2效果评估（1）基于基线评估：每次构建完后将成功/失败状态进行上报，统计一天的构建成功率，持续若干天后，我们就能得到一段时期内 38 网址：SRE-E 微信：SRE 精英联盟 的多天稳定构建成功率，把这些数据求一个平均值之后，我们就得到了这一段时期的构建成功率基线。当某天的构建成功率超出基线很多时（比如超出基线 20%），这次构建就可能出现了性能问题。在得到构建成功率基

72、线以后，我们可以将当前构建成功率与基线进行对比来作为 SLO，比如不低于基线 10%即为健康。（2）基于阈值评估：按业务需求设置固定的成功率阈值，例如80%，可以取一个固定周期的所有构建进行统计分析并进行对比，例如以天/周/月等单位。2.1.4 制品可靠性制品可靠性 制品为构建过程的产物，包括软件包、测试报告、应用配置文件等，最终提供给研发、测试等多个角色，用于下载并部署到 PC、console、移动端、服务器等多种不同的设备，从而完成发布和交付；制品的可靠性分为制品下载可靠性、制品部署可靠性、制品安全可靠性三个方面；制品可靠性提升涉及制品库工具建设与规划、安全、部署分发等多个方面，一般需要由

73、平台 SRE、服务 SRE、安全人员共同参与；2.1.4.1 制品下载可靠性制品下载可靠性 随着企业的快速发展，研发团队规模的扩大，为拓展全球市场在国内海外多地建立研发团队，制品的高效交付和管理也成为影响 39 网址：SRE-E 微信：SRE 精英联盟 研发效率的关键，制品分发缓慢、下载困难等为代表的制品库不可用挑战，急需快速解决；1制品下载可用性提升措施（1）多地分发：根据研发的不同地域分布，按需设置制品的分发策略，实现构建完成后多地制品分发，从而达到提升制品速率的目的；（2）P2P：制品的下载往往具备一定的峰值规律，例如早高峰会出现大量的集中下载，为提升并发下载的速率，可以使用 P2P 的

74、下载策略，下载用户越多，速率越快；（3）专属工具：制品的下载使用专属下载工具，能够支持分片下载、断点续传、多线程、热点缓存等特性；（4）镜像源加速：建设距离用户更近用户的镜像源，来提升制品依赖的拉取速度，减少下载中断；2效果评估 （1）下载成功率，下载成功率=1-（失败请求数/用户请求数），失败请求是指制品库返回的错误码为服务器内部错误码的请求（错误码500）；但不包括触发频控导致的限流请求或者制品库升级、变更、停机而导致的失败请求。用户请求指的是 制品库服务器端接收到的用户发送的请求，但不包括未经身份验证、鉴权失败或者欠费停服状态下的请求。用户端由于黑客攻击而对制品库的请求，或者由于配置了跨

75、区域复制、生命周期规则而在后端异步执行的请求，均不视为有效请求或失败请求 40 网址：SRE-E 微信：SRE 精英联盟（2）下载速度，下载速度=包大小/下载耗时，下载速度和制品的存储区域分布及用户所在的区域有较大的关系，可针对不同地域、国家可设置差异化的可用性衡量指标；2.1.4.2 制品部署可靠性制品部署可靠性 在制品下载完成后，还有一项重要的下游能力，即制品的自动化部署，使用户实现对制品产物即时体验的能力；在大型业务研发过程中，多种研发角色手动安装制品产物非常耗时，在没有自动化部署的情况下执行诸如软件安装和升级会消耗大量研发人员的时间和精力，且对迭代的效率有较大的影响；制品部署是指通过技

76、术手段，打通构建流水线，将构建完成的制品主动推送到用户多种类型终端的过程，用自动化的方式对制品进行分发、安装、更新，让用户以较低的时间成本获取到构建产物，减少临时下载制品对迭代效率的影响，尤其对于具备超大制品的业务类型，制品部署的可靠性尤为重要；1制品部署可用性提升措施（1）多用途支持：为满足不同的测试验证目的，一个项目往往会设置多条构建流水线，例如用于逻辑、性能、开发调试等多种不同类型，制品部署能力需要支持到多种类型；（2）多平台支持：制品的分类按平台分有 iOS、安卓、PC、console 等，每种平台都多种不同类型的 OS 版本和设备型号，碎片 41 网址：SRE-E 微信：SRE 精英

77、联盟 化程度高，预部署能力需要良好的机型兼容适配能力，能够支持多种不同类型的设备和平台；2效果评估（1）部署成功率，部署成功率=成功部署次数/总分发次数（2）部署人工耗时，一个完善的预分发方案应该尽量减少用户等待的时长，通过部署人工耗时指标来驱动减少人工参与；2.1.4.3 制品安全可靠性制品安全可靠性 制品在持续构建过程中的包依赖，以及构建完成的产物（含Docker 镜像、npm、helm、maven 等多种不同类型的格式），可能存在一些安全风险，导致制品不可靠；1制品安全性提升措施 （1）漏洞扫描，制品需要经过经过漏洞、license 信息的扫描与分析，并对漏洞和不合规的 license

78、告警并输出安全合规报告，漏洞库需要及时更新；（2）设置质量红线，禁止下载未经安全扫描或者未通过安全扫描的制品；（3）访问控制，针对不同角色设置差异化的权限，防止资源泄露和，减少恶意盗取制品风险，权限以最小化为原则；（4）操作审计，提供制品库的操作审计功能，保证制品的下载使用等操作操作可追溯；2效果评估 42 网址：SRE-E 微信：SRE 精英联盟（1）漏洞扫描覆盖度：扫描能力能够覆盖足够多的制品库类型；（2）漏洞扫描速度：漏洞扫描的速度和及时性，能够在漏洞产生后，以最快的速度发现异常；（3）漏洞扫描准确性：漏洞库及时更新和维护，确保制品安全扫描结果的准确性；（4）访问控制：是否具备精细化权限

79、控制的能力；（5）审计能力：是否具备良好的审计能力；2.2 研发保障工程体系设计研发保障工程体系设计 2.2.1 面向研发保障的持续集成流水线面向研发保障的持续集成流水线 持续集成（CI）是现代软件开发中的关键实践，通过自动化的方式将代码的构建、测试、部署等环节有机结合，确保代码在每次提交后都能快速集成并验证，从而提高软件开发的效率和质量。面向研发保障的持续集成流水线设计，旨在通过一系列自动化工具和流程，保障工程编译，静态代码检查，测试用例运行和部署发布。另外，通常情况下，平台需要提供以下关键组件能力：43 网址：SRE-E 微信：SRE 精英联盟 流水线：流水线：通过可视化手段展示团队现行的

80、研发流程，实现编译、测试、部署等环节的一体化管理，确保流程的顺畅与高效。代码检查：代码检查：提供精细化的代码审查解决方案，从多个维度检测代码中的缺陷、安全漏洞以及规范性问题，确保产品质量得到充分保障。代码库：代码库：企业内部代码托管服务 凭证管理：凭证管理：为代码库、流水线等关键服务提供多样化的凭证与证书管理功能，增强系统的安全性。环境管理：环境管理：可以将企业内部的开发编译机托管至流水线，统一管理 研发商店：研发商店：由流水线插件和流水线模板构成，插件用于整合企业内部的多种第三方服务，模板则助力企业研发流程的标准化。编译加速：编译加速：通过并行编译，编译缓存，硬件匹配优化的手段，显著提升构建

81、任务的执行效率。制品库：制品库：通常基于分布式存储架构，具备扩展能力，其功能涵盖制品扫描、分发、晋级、代理、包管理等，同时提供多种依赖源仓库，如 generic（二进制文件）、maven、npm、pypi、oci、docker、helm、composer、nuget 等，以满足不同开发需求。持续集成流水线的设计需要遵循以下几个关键原则：自动化：尽可能将所有的构建、测试、部署步骤自动化，减少人为干预和错误。44 网址：SRE-E 微信：SRE 精英联盟 快速反馈：确保每次代码提交后，开发者能够快速得到构建和测试结果，及时发现并修复问题。可重复性：流水线的每一步都应该是可重复的，确保在不同环境下执

82、行结果一致。可扩展性：流水线设计应具备良好的扩展性，提供接口及相关的扩展机制，对接更多的插件，满足多样化的流水线能力需求。可观测性：提供全面的监控和日志记录，便于问题定位和分析。在流水线可视化设计上，尽量采用 Stage/Job/Task 三层结构展示，方便快速定位问题。1.Stage（阶段）由多个 Jobs（作业）组成；同一个 Stage 下的 Job 执行方式为并行，由于 Job 之间是相互独立的，某个 Job 失败后，其它的 Job 会被运行到完成；45 网址：SRE-E 微信：SRE 精英联盟 一个 Job 失败，则该 Stage 失败。2.Job 可以运行在一个构建环境里，比如运行在

83、 macOS；也可以作为不需要构建环境的普通任务调度编排。它有如下特性：由多个 Tasks(插件)组成；46 网址：SRE-E 微信：SRE 精英联盟 一个 Task 失败，则该 Job 失败，其余 Task 将不会运行；Task 也被称为流水线插件，通常是一个单独的任务，如拉取 Git 仓库代码等。Task 必须包含在 Job 内，同一个 Job 内的 Tasks 都是从上往下顺序执行（启用了高级流程控制的 Task 除外）。2.2.2 面向研发保障的可观测设计面向研发保障的可观测设计 面向研发保障的可观测设计旨在通过全面的监控和分析，确保流水线的透明性和可控性。在流水线中，构建机承受着极大

84、的工作负载压力，CPU 负载接近满负荷，同时占用大量内存和磁盘空间。此外，由于代码和配置问题，构建任务失败的可能性较高。通过可观测性工具，团队能够实时监控流水线状态，快速定位和解决问题。要做好流水线的可观测性，要从以下几个维度进行考虑：1.1.构建机的监控构建机的监控 CPUCPU 和内存使用率：和内存使用率：监控构建机的 CPU 和内存使用情况，确保资源分配合理，防止资源耗尽导致构建失败。47 网址：SRE-E 微信：SRE 精英联盟 GPUGPU 使用率使用率：对使用 GPU 加速的构建任务，监控 GPU 的使用情况，包括利用率、温度和显存占用，以确保其高效运行。磁盘空间：磁盘空间：定期检

85、查磁盘使用情况，清理不必要的文件，确保有足够的空间进行构建。特别是游戏制品巨大 网络流量：网络流量：监控网络流量，确保构建机与其他系统的通信顺畅，避免因网络问题导致的构建延迟。2.流水线监控 构建状态：构建状态：实时监控每个构建任务的状态，包括成功、失败、进行中等，帮助快速识别问题。任务队列：任务队列：监控流水线中的任务队列，优化任务调度，防止任务积压。执行时间：执行时间：分析各个阶段的执行时间，识别性能瓶颈并进行优化。3.3.日志监控日志监控 错误和警告：重点关注日志中的错误和警告信息，及时采取措施解决问题。历史日志分析：通过分析历史日志，识别常见问题和趋势，改进构建流程。4.Trace 4

86、.Trace 跟踪跟踪 48 网址：SRE-E 微信：SRE 精英联盟 构建的过程基本上等同于一条 Trace，通过对构建过程进行 OpenTelemry 等链路跟踪协议后，进行上传，可以实现更细粒度的构建成功跟踪。如下图，通过上报到 Jaeger 后，可以实现每个编译步骤的消耗时长的可视化。5.5.告警触达告警触达 该平台将指标、仪表盘以及告警信息推送至研发团队，使研发人员能够更全面地掌握持续集成环节中出现的问题，从而进一步释放系统可靠性工程师（SRE）的人力资源，并提高研发效率，降低沟通成本。2.2.3 面向研发保障的操作调度操作平台面向研发保障的操作调度操作平台 操作调度平台在研发保障过

87、程中发挥了至关重要的作用，确保各项操作任务能够高效、准确地执行，并减少人为干预带来的风险。该平台主要负责以下几个关键工作领域：1.CD 发布管理 49 网址：SRE-E 微信：SRE 精英联盟 在持续交付（Continuous Delivery,CD）过程中，操作调度平台承担着发布管理的核心职责。它不仅能确保从代码提交到生产环境的全过程自动化和高效运作，还能够通过智能调度来优化资源使用和任务执行的顺序。自动化流程编排：操作调度平台通过自动化流程编排，将代码提交后的各项任务（如编译、测试、部署等）整合到一个无缝的流程中，并自动调度这些任务的执行顺序，以避免资源冲突或执行瓶颈。通过与 CI/CD

88、工具链的深度集成，平台能够在任务之间进行动态调度，确保每个流程步骤都在最佳时间点执行。50 网址：SRE-E 微信：SRE 精英联盟 智能调度算法：平台利用智能调度算法，根据任务的优先级、依赖关系和资源可用性，动态调整任务的执行顺序和分配的计算资源。这种调度策略不仅能够优化资源利用率，还能提高部署效率，减少因资源不足或冲突导致的延迟。2.批量化操作 批量操作是操作调度平台的另一重要功能，它支持对大规模操作任务的统一管理和调度，极大地提高了研发团队处理日常运维任务的效率。统一任务调度：操作调度平台能够将大量重复性、标准化的操作任务（如批量更新配置、批量重启服务等）整合到一套自动化流程中，并通过统

89、一的调度机制进行管理。并行执行与任务分片：为了提高批量操作的效率，平台支持并行执行和任务分片技术。它能够将大规模任务分解为多个小任务，并分配到不同的计算节点并行执行，从而显著缩短任务的整体执行时间。此外，平台还具备任务依赖管理功能，确保各子任务按顺序正确执行。51 网址：SRE-E 微信：SRE 精英联盟 动态资源分配：批量操作过程中，平台能够动态分配计算资源，根据任务的实时需求调整资源分配策略，以确保在高峰期也能保持高效执行。2.2.4 面向研发保障的面向研发保障的 ITSM 平台平台 IT 服务管理平台（IT Service Management,ITSM）在研发保障中起到了至关重要的作用

90、，为研发团队提供了统一、标准化的管理工具和流程，确保研发过程中的各类服务请求、事件管理、问题解决、变更控制等工作能够高效、有序地进行。2.2.5 面向研发保障的容器平台面向研发保障的容器平台 容器平台为研发团队提供了一个高效、灵活、可扩展的环境，以便快速部署、测试、和迭代应用。52 网址：SRE-E 微信：SRE 精英联盟 为了有效支持研发团队的工作流程，容器平台必须具备一系列专门设计的功能，确保研发过程的高效和稳定。自动化自动化 CI/CDCI/CD 管道集成：管道集成：容器平台与 CI/CD 工具链无缝集成，支持自动化构建、测试、和部署。通过 Jenkins、GitLab CI 等工具，容

91、器平台能够在代码提交后自动触发构建和部署任务，大大缩短了研发周期。环境隔离与多租户支持：环境隔离与多租户支持：通过命名空间和 RBAC（Role-Based Access Control）等机制，容器平台可以实现环境隔离，支持多个团队和项目的并行开发。这种隔离不仅限于资源使用，还包括网络和安全配置，确保不同团队之间的独立性和安全性。观测性平台对接观测性平台对接：容器平台需要能与观测平台实现无缝的对接，将运行于容器的指标，日志，链路上报的观测平台中，并能实现监控告警。敏捷发布与回滚机制：敏捷发布与回滚机制：容器平台支持蓝绿部署、金丝雀发布等敏捷发布策略，能够在不影响整体服务的前提下逐步发布新版本

92、并监控其表现。一旦发现问题，平台可以快速回滚到之前的稳定版本，减少对业务的影响。测试环境治理：测试环境治理：针对实际研发工作环节中，测试环境搭建流程过长，测试资源无法充分利用和测试设备日常维护人力成本高的问题，基于容器平台，以 k8s 工作负载的方式部署运行管理多个测试环境。具体架构如下 53 网址：SRE-E 微信：SRE 精英联盟 2.2.62.2.6 面向研发保障的编译加速平台面向研发保障的编译加速平台 编译构建是项目开发和发布过程中的重要环节，同时也是非常耗时的环境，有些项目执行一次完整的构建需要几十分钟甚至几个小时，各种编译构建加速工具都能在一定程度上减小构建时长。整体架构如下：编译

93、加速工具包运行于用户构建机，为构建机上的编译任务接入加速服务 分布式编译服务为集中式部署，负责接受编译加速工具包加速请求，调度加速资源，并负责加速任务过程全生命周期管理 分布式资源集群通过分布式编译服务引擎服务统一动态调度，直接为用户编译提供分布式加速 54 网址：SRE-E 微信：SRE 精英联盟 分布式加速底层通过 disttask 分布式任务引擎实现，disttask各模块功能介绍如下：remoter worker 运行在分布式资源集群中中，负责接收，执行和返回分布式任务 local server 运行在构建机上，实现分布式任务底层基础功能，并可扩展不同应用场景的分布式任务实现 dist

94、task_executor 通用任务执行器，接管实际编译中的编译命令(如 gcc 命令，clang 命令)，是构建工具和分布式基础服务之间的桥梁 基于 disttask 提供的接口，根据实际场景需要，实现独立的构建工具 55 网址：SRE-E 微信：SRE 精英联盟 2.3 研发保障案例研发保障案例 2.3.1 腾讯游戏全球研发保障实践腾讯游戏全球研发保障实践 SRE EliteSRE Elite 精选原因精选原因 这是一个完整的游戏行业研发保障案例。面对游戏研发中的复杂研发管线、大文件版本管理、冗长的构建过程和频繁的更新需求等挑战，SRE 团队通过稳定性保障、平台工具建设、以及与业务开发团队

95、的有效分工，实现了高效的研发保障。此案例覆盖了研发保障的多个关键模块，在代码可靠性，代码仓库可靠性、制品分发、以及构建加速等多个方面进行了优化，显著提升了代码提交和构建的成功率，并有效解决了代码库卡顿和文件分发效率低等问题。相关的优化内容非常的详尽细节，具有很强的实践性，且大部分关键组件提供了开源的实现案例，非常值得参考。（一）背景及设计原则（一）背景及设计原则 56 网址：SRE-E 微信：SRE 精英联盟 大型游戏研发对研发管线有独特的要求大型游戏研发对研发管线有独特的要求 伴随着腾讯游戏多元化的诉求日趋增长，越来越多的游戏开发团队开始尝试多地共研模式，这在工程版本控制、编译构建、制品共享

96、等方面都提出了新的挑战。游戏行业的研发具有以下独特特点和挑战：1.复杂且研发管线：用户提交的不仅是源代码，还可能包含体积达数百兆的单个素材文件，这些文件需要进行版本管理，而且还需要对原始素材文件为不同终端进行渲染，耗时巨大，出包过程可能长达 5-6 小时。而如果中途构建失败，第二天项目进度就会受到影响。2.版本库性能：版本库中包含大量大文件，整个代码库的体积可能超过上 PB，而且随着游戏生命周期的延续，代码库只会越来越庞大。以此未经优化前，用户在访问或修改版本库里头的资源时容易卡住，而游戏团队的规模可能达到上百人，人力成本极其高昂，如果卡住一个小时损失就会非常巨大。3.项目团队协作及代码质量问

97、题：目前游戏的制作已经进入工业化生产的阶段，每个游戏项目可能都有几十人甚至上百人的参加，如何解决由于参与人数众多而带来的代码冲突以及代码质量不统一问题。57 网址：SRE-E 微信：SRE 精英联盟 4.业务制品构建耗时长，严重影响协同效率和敏捷开发。对于普通互联网应用安装包普遍在 500M 以内，单次构建在 30 分钟以内，游戏安装包和资源文件加起来一般可达 5G-20G 以上，客户端包单次构建耗时需要 2-5H 左右；5.激进的发布时间：游戏行业竞争极其激烈，游戏内部经常衍生出新的玩法和素材，用户期望极高，玩家口味变化极快，前期宣发费用极其高昂，项目必须如期上线才能减少前面投入的风险。6.

98、频繁的更新：根据用户反馈，游戏需要频繁出包进行调整，并引入新玩法、新皮肤和新角色，7.制品分发效率及安全：现在的游戏动则几十到上百 GB 的包，如何进行快速，稳定地分发，送到大量的测试及渠道用户。如何保障制品的安全。8.多方协作带来的安全问题：游戏行业已经从从小作坊，演变成类似于好莱坞式工作室的分工协作模式，大量的资源需要通过外包的形式进行分包协作。由此带来安全问题非常突出，不少的竞争对手或者说相关的产业都会盯上我们的整体的研发流程，在游戏新版本的研发过程中，如果一旦出现了资源的泄露，玩法的泄露，数值的泄露，有可能就会导致竞争对手或者黑产的狙击，很有可能导致版本需要重做，数百人月的工作量付之东

99、流。如牵涉到核心资产，如核心代码，核心引擎等，甚至会出现私服的情况，影响整个游戏的未来的生存。58 网址：SRE-E 微信：SRE 精英联盟 举个例子，某日凌晨 1 时许，由于机房故障，部分流水线的构建机下线，我们本以为这么晚应该不会有用户进行构建，本决定第二天再修复。结果，凌晨 2 点和 3 点就有用户在公司论坛进行投诉，据了解，因为代码改动直接到了当天凌晨 1 点多，因此他们的构建时间只能选择在凌晨 2 点，才能满足版本在当天进行提测发版的进度要求。此事让我们更深刻理解到研发管线的可靠性对业务的研发管线的可靠性对业务的重要价值。重要价值。总之，解决以上问题，做好研发保障，保障研发管线的高效

100、安总之，解决以上问题，做好研发保障，保障研发管线的高效安全运行，价值巨大，挑战巨大。全运行，价值巨大，挑战巨大。SRESRE 团队负责研发保障是一个合适的选择团队负责研发保障是一个合适的选择 研发阶段的可靠性是指，以 SRE 理论驱动研发的可用性建设，提升研发管线的工业化水平，保障版本能够按正常周期迭代，从而实现高质量持续交付有效价值的目标 从软件工程的角度：从软件工程的角度：SRE 的稳定性保障工作，本质上是软件工程的一部分，也就是运维左移，从源头保障软件的质量 从从 SRE SRE 专业能力的角度：专业能力的角度：利用 SRE 团队既有平台能力又有服务能力的特点，从平台和服务两个地方切入，

101、建立 SRE 团队主导的工具平台和服务体系，让研发团队在平台和服务上需求都得到最大化的满足。59 网址：SRE-E 微信：SRE 精英联盟 服务上，SRE 团队做研发服务，可以复用现有的运维支持体系，与研发相比，SRE 有高度的业务可用性意识和能力，能很好的保障业务研发工具链的可用性，防止因为工具链的不可用或性能低下，影响业务团队研发效率。工具上，SRE 团队可以复用，开发，并扩展在 CO/CD 领域的工具去进行研发保障，例如，利用可观测的平台，对研发工具链的健康状态以及使用体验进行观测，度量研发工具链上下游健康状态，故障时快速定位根因，同时提供成熟的可观测落地方案，标准化实施，降低建设成本

102、从组织分工上的角度：从组织分工上的角度：SRE 团队负责研发保障，业务开发负责产品功能开发，对于企业来说，可以发挥最大的投入产出比。SRE 可以更体系化和规模化进行全面保障。业务开发的本质逻辑是更加聚焦快速开发迭代版本，完成产品功能开发。理想状态下，业务开发无需关注研发平台上下游所有组件的稳定性。从职业发展来说，SRE 工程师在 SRE 组织中，有明确的成长路径和岗位通道，且通过从 CO/CD 扩展到 CI 域，扩展了职业发展方向，并且与相关能力设置在业务开发团队相比，更具有稳定性和成长性。60 网址：SRE-E 微信：SRE 精英联盟 简单来说，简单来说，SRE SRE 团队是既有服务意识，

103、又有平台及产品的建设团队是既有服务意识，又有平台及产品的建设能力，从软件工程的角度整体保障角度，完成了业务研发不擅长但能力，从软件工程的角度整体保障角度，完成了业务研发不擅长但是有迫切需求的工作。因此，是有迫切需求的工作。因此，我们认为由我们认为由 SRE SRE 工程师去从事研发工程师去从事研发保障的工作，是一个高保障的工作，是一个高 ROI ROI，合乎组织利益及各方干系人利益，能，合乎组织利益及各方干系人利益，能提升研发效率，可持续的解决方案。提升研发效率，可持续的解决方案。本案例最后总结部分，会有我们业务研发同学对 SRE 从事专业度的认可和反馈。在此基础上，SRE 切入研发保障，需要

104、注意以下三点：稳定高效：稳定高效：需要 SRE 团队在服务上有韧性，和研发团队建立信任。低成本定制：低成本定制：SRE 团队能够低成本的为每一个业务定制研发流水线方案，定制个性化需求，例如兼容多种代码库等这就要求我们的方案必须是 PaaS 模式，也就是平台工程的效果。安全可靠：安全可靠：一方面是研发团队对代码安全的要求，例如外包开发团队的代码安全。我们通过离岸云研发模式解决另一方是研发环境的安全性，避免代码泄露事件发生。平台能力和服务能力方面，做到稳定高效，低成本定制，安全可靠，让用户对 SRE 团队提供的研发服务产生依赖，用户用的越深入，与 SRE 团队的绑定就越紧密，SRE 团队的研发服务

105、就会可持续，从而建立长期服务关系。61 网址：SRE-E 微信：SRE 精英联盟 （二）（二）体系设计及关键流程体系设计及关键流程 SRE 团队提供的全托管研发保障体系，涵盖从代码提交、代码仓库管理、构建流程到制品分发的全过程。通过代码分析、仓库安全管理、编译加速、制品共享等多项服务，确保了研发过程的高效性和安全性。大部分情况下，研发只需要往平台提交代码的后，后继的环节将不需要进行干预，即可高效获取到相应的制品。图中还包括由 SRE 团队研发并提供的支持的 PaaS 平台，SRE 团队利用相关的平台能力，提供持续集成、观测、批量操作、ITS 管理、计算和容器平台等功能，进一步优化研发环境。62

106、 网址：SRE-E 微信：SRE 精英联盟 整体个体系强调 SRE 团队在提升研发效率、保障流程稳定性和安全性中的关键作用。备注：案例中可能会提及到各个平台的简称，此处进行统一进行备注说明：蓝盾：蓝鲸持续集成平台的简称，开源地址https:/ 标准运维：蓝鲸智云标准运维的简称，开源地址 https:/ ITSM：蓝鲸流程服务的简称，开源地址 https:/ 容器平台：蓝鲸容器管理平台简称，开源地址 https:/ BKTurbo：蓝鲸编译加速平台简称，开源地址 https:/ CodeCC 代码检查：CodeCC 插件(腾讯代码分析插件），开源地址 https:/ 制品库：蓝鲸制品库简称，开源

107、地址 https:/ 63 网址：SRE-E 微信：SRE 精英联盟（1 1）代码可靠性研发研发保障实践）代码可靠性研发研发保障实践 某游戏客户端通过质量红线保障各阶段代码质量某游戏客户端通过质量红线保障各阶段代码质量 在某游戏客户端业务研发过程中，我们经常会有类似的困惑：确立了团队的编码规范，但还是有不符合规范的代码被合入；拥有自己的转测试标准，但是只能人工跟进，不能落实到自动化流程中；在版本的后期，Bug 数居高不下。但很多问题是可以在前期通过代码检查和单元测试发现的。为了解决上述问题，借鉴丰田精益生产的思想，腾讯打造了质量红线 Gate 服务。质量红线的思想起源于丰田精益生产的立即暂停系

108、统（stop-the-line Andon），又称为安灯（Andon）系统。当车间生产流水线上的员工遇到麻烦，立即拉一下信号灯，班组长就会立即跑过来帮助解决，其生产流水线也会停止直到问题解决。这样能够尽早暴露问题，解决问题，而不是把问题流到生产汽车的后续步骤。解决方案解决方案 64 网址：SRE-E 微信：SRE 精英联盟 质量红线是指通过设置质量标准，控制流水线的行为，使得每一阶段的出口质量都必须符合质量标准的一种服务。设计思想设计思想 设计思想如下 1、独立成质量红线服务，基于关键点控制质量 从用户使用场景出发，将开发、部署测试环境、部署生产环境等相关的插件（共 10 个）选出作为关键控制

109、点。这些控制点插件在流水线中可以非常灵活地编排，但只要质量红线设置了标准，就必须质量达标控制点才能执行通过。2、指标灵活可扩展 设计了统一的指标定义规范和指标灵活可扩展的机制。主要包括系统插件指标（主要是 CodeCC 代码检查）、脚本任务指标、研发商店插件指标；65 网址：SRE-E 微信：SRE 精英联盟 3、支持为代码合入设立红线 支持设置质量要求，并通过流水线 Git/Github 事件触发机制与工蜂/Github 串联起来。以工蜂为例，当用户在工蜂发起 MR 时，会通过 Merge Request hook 触发流水线执行。流水线执行拉取代码、代码检查、单元测试等操作。若不满足质量要

110、求，质量红线就会让流水线失败，并将失败的结果回写到 Code，作为 MR 的辅助决策。4、与流水线融合 质量红线被设计为一个独立服务后，虽然有集中管理的便利，但用户对其感知度不高。只有用户正确配置了红线之后，才能在流水线看到，较难被用户发现。且用户创建红线时各项信息只能一项项填写，有时不知道怎么填比较好。为了用户更好地使用它，我们在设计上将红线和流水线服务进行了融合。关键流程包括：关键流程包括：1 确立团队 Git 工作流 Git 相比 SVN，其优势不仅在于是一个分布式版本控制系统，而且在于其强大的分支管理能力。其中 Git 工作流，主要是需要定义好分支策略。在项目初期，团队只有 23 人。

111、此时往往不需要额外分支，一个 master 打天下。但是随着团队逐步壮大，大家发现代码冲突越来越严重，同时由于缺少代码检视（Code Review），部分质量较差的代码和无关内容也时不时被提交上去。66 网址：SRE-E 微信：SRE 精英联盟 为了解决这个问题，“分支开发、主干发布”模式呼之欲出。团队从主干上拉出分支，并在分支上开发软件新功能或修复缺陷。当某个分支（或多个分支）上的功能开发完成后要对外发布版本时，通过 MR（Merge Request）合入主干。在 MR 时，进行 CR 代码检视。2 确定团队质量标准 为了保证合入 master 的代码质量，团队需要设立自己的代码质量标准，例

112、如编码规范、单元测试等。但是单单依靠人肉代码检视CR，很难保证新合入的代码都符合规范。而工具自动化执行，能够做到客观准确、持续检查。因此我们可以将质量标准，放到腾讯DevOps 平台提供的一系列工具之中。以腾讯代码检查平台为例，可以支持五个维度的代码质量标准。像缺陷、安全和代码规范，都能通过规则配置来进行具体调整，以便适应不同团队的要求。67 网址：SRE-E 微信：SRE 精英联盟 缺陷：BKCheck 工具可检查出空指针、内存泄漏、数据越界、并发缺陷等问题；安全：敏感信息工具可以检测密码泄露、内部 IP 泄露等问题；代码规范：九款工具可以检测出逻辑、变量、代码风格、最佳实践等代码规范问题；

113、圈复杂度：可以检查出过于复杂的函数。函数复杂度越高，存在缺陷的风险越大；重复率：可以检查项目中复制粘贴代码片段等问题，避免产生大量冗余代码。以腾讯 DevOps 平台上的 Bash/Batch Script（脚本任务）为例，支持用户自由编写自己的脚本。例如可以支持单元测试，将单元测试用例执行失败数作为团队要求，也能支持获取 Tapd（腾讯内部需求管理/缺陷平台）遗留缺陷数作为质量要求。3 配置流水线和质量红线 在确定了这些质量标准之后，如何将其与 Git 工作流无缝衔接起来呢？3.1 创建一条 MR 触发执行的流水线 首先，我们需要配置一条 DevOps 流水线，它能在发起 MR 时自动执行，

114、拉取相应代码进行分析。添加 Git 事件触发的插件，并将事件类型设置为 Merge Request Hook。当工蜂项目中新增 MR 时会触发该流水线。68 网址：SRE-E 微信：SRE 精英联盟 添加拉取 Git 代码的插件，并将分支名称设置为$hookSourceBranch。$hookSourceBranch是一个流水线变量，指代源分支。例如从 feature1 分支向 master 合并代码，那么feature1 就是源分支，master 是目标分支。因为源分支在 MR 中可能会变化，有时是 feature1，有时是 feature2，有时是feature3，因此使用流水线变量更加灵

115、活方便。添加 CodeCC 代码检查插件，选择语言和规则集。例如可以选择IEG 缺陷检查、腾讯代码规范，还有啄木鸟安全检查、重复率和圈复杂度等。69 网址：SRE-E 微信：SRE 精英联盟 3.2 配置质量红线 接着我们需要给这条流水线配置一条质量红线。通过质量红线，我们可以将团队代码质量标准固化到流程之中。以某 Java 项目为例：指标 设置如下图。对于 CheckStyle，一般接入后首次扫描会产生不少告警，全部修复清零较为困难，因此这里设置的指标为”Checkstyle 接入前历 70 网址：SRE-E 微信：SRE 精英联盟 史告警数=300，Checkstyle 接入后新告警数99

116、%78 网址：SRE-E 微信：SRE 精英联盟 b)页面访问服务可用率，预期99%计入不可用需要满足的条件：可用率1000 SVN代码仓库可靠性案例代码仓库可靠性案例 SVN 仓库容灾仓库容灾主从架构主从架构 SVN 选择成熟的主从架构来进行容灾。1.主服务器（Master）：主服务器负责存储和管理主要的版本库。所有的提交操作都首先发生在主服务器上。2.从服务器（Slave）：从服务器是主服务器的一个副本，它复制了主服务器上的所有数据。从服务器的主要作用是备份主服务器的数据，以及在主服务器出现故障时提供访问服务。79 网址：SRE-E 微信：SRE 精英联盟 3.同步过程：为了保持主服务器和

117、从服务器之间的数据一致性，需要定期进行同步操作。同步过程可以通过 SVN 的 svnsync 工具来实现。同步操作会将主服务器上的最新更改复制到从服务器上。4.故障切换：当主服务器出现故障时，可以将从服务器提升为主服务器，继续提供服务。SVN 仓库性能 1.1.读写分离读写分离 保证主从一致性后，可以在 Server 前面添加路由节点，将用户请求转发到从库，实现读写分离。2.2.就近读取就近读取 80 网址：SRE-E 微信：SRE 精英联盟 对于跨地域集群的仓库，现在支持一个集群部署多个跨地区的节点，集群内自动同步。用户通过访问当地的域名，实现就近访问和跨地区协作。3.3.边缘加速边缘加速

118、边缘加速服务简单来说就是通过在职场办公区域楼层或者大厦，就近部署一个 Cache 节点，当有内容下载的时候，会自动的缓存到 Cache 节点。后续有其他同职场的同事再次进行拉取的时候，将会优先从 Cache 节点进行拉取，这样一来，不仅能够享受局域网的下载速度，也能分担多人下载时服务端的压力，让服务更稳定，同时下载速度也会更快。81 网址：SRE-E 微信：SRE 精英联盟 4.4.存储冷热分级存储冷热分级 随着整体业务不断稳步前进，SVN 仓库的数量不断增加，其所需存储计算资源也随之上涨。在降本增效的大环境下，成本飞涨、资源利用率低等问题显露无遗。对此，我们针对所有仓库进行冷热分级，确保在不

119、影响用户正常使用的前提下，尽可能的压榨服务器性能，提升资源利用率，节约运营成本。整体方案 数据采集：对仓库数据使用情况进行多维度采集 热度分析：分析仓库数据热度情况，进行标记 冷数据迁移：对标记的冷数据迁移到低成本存储集群 SVN 仓库可扩展性版本分片 82 网址：SRE-E 微信：SRE 精英联盟 一些项目经过多年发展，仓库容量已经快达到单块盘存储容量上限了，我们采取了称之为“版本分片存储”的方式，挂载多块盘+软链来解决这个问题。如上图所示，我们通过在服务器上新挂载盘 2，将老的版本文件迁移到新挂载的盘 2 上，并在原来的盘 1 上创建软链，软链指向新挂载盘 2 的文件夹路径。当用户访问 S

120、VN 仓库时，还是访问盘 1 的文件，大部分时间都是访问较新的版本文件，如果访问到旧的版本文件时，还能通过软链访问到迁移到盘 2 的文件。SVN 仓库安全 源代码对企业的重要性不言而喻，因此加强源代码保护至关重要。可以从源代码本身、内部企业人员权限和做好监控审计等三方面着手，进一步加强企业重要源代码的安全性。一、源码分级 对源码进行分级，确保和明确重要源码的保护措施。83 网址：SRE-E 微信：SRE 精英联盟 企业内部源码具有优先层级，明确哪些核心代码需要被保护。对于保密等级高的代码：1、授权范围：仅仓库的项目成员有权限访问。2、禁止通过任意方式突破代码仓库原有的授权范围，包含不仅限于 f

121、ork、push 到其他仓库等。3、禁止在无权限访问的范围保存、发布、讨论、传播。4、禁止下载或保存源代码到非开发环境机器，例如本地办公机、个人电脑、U 盘等存储媒介以及云平台（如各类网盘、网络笔记等）等。二、精细化控制 精细化访问控制，对于员工的权限进行限制。为不同角色分配访问权限应遵守最小授权原则，根据场景设置必要权限；针对转岗或职责调整员工应及时收回相关项目代码仓库权限并清理本地保存代码；对于非项目参与同学不应该给予项目访问权限，特殊情况应该邮件申请报备；任何人如果需要调用其他工程的代码，在不必要的情况，不提供源代码，应采用 API 调用等方式；三、监控和安全审计 配套建设代码仓库安全审

122、计和监控系统 尝试越权访问时触发告警 84 网址：SRE-E 微信：SRE 精英联盟 大批量异常拉取代码时触发告警 代码拉取、提交记录长期可追溯 SVN 仓库可观测 1.SVN 仓库仓库 SLI定义定义 代码仓库提供”代码拉取推送、页面访问、接口“三种服务类别，按照下表定义考核目标 类别类别 指标指标 计算方式计算方式 目标目标 SVN仓库代码拉取推送 服务可用率（用户拉取和推送代码成功请求数/用户拉取推送代码总请求数）*100%99%页面访问 服务可用率（用户请求成功数/用户访问总请求数）*100%99%接口 服务可用率（接口请求成功总数/请求总数）*100%95%85 网址：SRE-E 微

123、信：SRE 精英联盟 2.2.可用性可用性 SLOSLO 服务不可用：指标计算结果低于目标，则该类别提供的服务不可用 86 网址：SRE-E 微信：SRE 精英联盟 服务可用性=（1-不可用的总时长/总服务时长）*100%P4仓库可靠性案例仓库可靠性案例 P4（Perforce）仓库介绍 Perforce，简称 P4，是一款功能强大的集中式版本控制系统，广泛应用于软件开发、游戏开发、芯片设计和数字资产管理等领域。它提供了版本控制、工作空间管理、变更处理和分支模型等功能，支持跨平台操作，并且能够处理大型文件和二进制文件。国内使用 P4 的公司有阿里巴巴、腾讯、华为、字节跳动、长安汽车等，海外使用

124、 P4 的公司有育碧、甲骨文、思科、英伟达、三星等。注：注：Perforce 是 Perforce Software,Inc.的商标和产品，使用 Perforce 需要向 Perforce Software,Inc.购买产品使用授权。P4P4 仓库性能仓库性能 87 网址：SRE-E 微信：SRE 精英联盟 1.架构优化-Proxy 由于 P4 Commit 服务器（主服务器，存储所有仓库和提交记录）默认是单点服务的模式，当用户量很大的时候，就会遇到网卡和磁盘 IO 瓶颈，导致拉取很慢。此时可以搭建 Proxy 作为缓存服务，用户访问 Proxy，Proxy 发现本机上有缓存文件，就会直接返回

125、给用户，而不会再去请求 commit 服务器，这样就减轻了 commit 服务器的压力。如果 Proxy 发现本地没有缓存文件，就会请求 commit服务器，把文件拉下来存在本地作为缓存，并把文件传给用户。整个机制与 CDN 类似。可以部署多台 Proxy，分流用户请求，提升并发承载能力，另外 Proxy 部署需要尽量靠近用户地域，起到边缘加速作用。88 网址：SRE-E 微信：SRE 精英联盟 Proxy 预拉取：正常情况下，只有当用户拉取了代码，proxy 上才会有缓存，这样就导致一个新文件创建后用户首次拉取的时候是都没有缓存的，会回源到 commit 给 commit 造成压力，我们可以

126、在服务器上定时用程序来模拟用户拉取 P4 文件，生成缓存，这样真正用户访问的时候就没有回源压力了。2.2.架构优化架构优化-EdgeEdge Proxy 在远距离（跨城、跨国）大批量小文件传输时表现不佳，因为仍需要访问 Commit 去执行大量的 metadb 数据读写操作，此时可以在用户本地部署 edge 来进行优化。Edge 把 workspace 和shelve 数据放到了本地，这样拉取时只需要读写本地 Edge 的metadb，大幅提升效率。89 网址：SRE-E 微信：SRE 精英联盟 Edge 还可以搭配 proxy 使用，用户先访问 Proxy，Proxy 连接Edge 进行缓存

127、。3.3.存储优化存储优化 p4d（commit/replica/edge）的数据文件主要分为 3 类：DB文件（db.*）、事务日志（journal）、仓库文件（depot），三类文件有不同的要求。1.DB 文件（db.*）内容：版本控制与管理用数据表 90 网址：SRE-E 微信：SRE 精英联盟 特点：超低延迟高带宽的随机读写 设备选择：高性能 SSD 2.事务日志（journal）内容：事务流水日志，可搭配 checkpoint 用来恢复数据 特点：可持久的顺序写入，对顺序写入性能有要求 设备选择：高性能 SSD 或 HDD 3.仓库文件（depot）特点：高空间占用，对延迟要求不高

128、设备选择：大容量高带宽设备，最好能支持扩容，例如大容量 SSD、HDD 或 NFS 部署时建议把 DB 文件、事务日志文件和仓库文件分 3 块盘部署，以达到最佳性能。Proxy 上的数据以缓存数据为主，对读写性能要求高，可以使用多块本地 SSD 盘组建 Raid0 阵列来使用。四、多地访问优化 Commit 部署在用户最多的城市，CommitStandby 需要和 Commit同城不同机房。Proxy、Edge 需要在用户所在的城市就近部署 P4P4 仓库容灾仓库容灾 91 网址：SRE-E 微信：SRE 精英联盟 数据备份方式 热备份：集群中的 replica 节点或 standby 节点

129、冷备份：DB:历史 checkpoint+历史 journal 仓库：rsync 等文件拷贝机制 热备：镜像（replica）节点备份内容 Replica 节点包含主节点的完整元数据+仓库数据镜像 可以帮助主节点分担处理读请求 灾备：随时可以切换为主节点 根据灾备机制完整性，分为 replica 和 standby 根据接受的请求类型，分为 forwarding 和 read-only 实际类型：forwarding-replica、read-only replica、forwarding-standby、(read-only)standby 92 网址：SRE-E 微信：SRE 精英联盟 热

130、备：Standby 节点备份内容 standby 基本特性与对应的 replica 一致，具备对应replica 的所有功能，standby 可以看做改进型的 replica。相同点：热备节点 完整的数据同步备份 分担部分请求处理 standby 提升了灾备场景的能力，不同点：更完善的 journal 同步机制，避免数据丢失或集群状态不一致 failover 机制，实现自动主备切换 Mandatory 模式下同步确认机制降低集群性能 DB 数据冷备份 冷备对象：最近一个 checkpoint 和 checkpoint 以来的 journal 其他 checkpoint 和 journal 可以

131、用来支持回滚等操作 93 网址：SRE-E 微信：SRE 精英联盟 方法：Journal 和 DB 放在不同的存储设备上 定期跑 checkpoint 和 journal rotation 历史 checkpoint 和 journal 进行可靠存储 可靠存储包括：使用可靠的存储设备（Raid1 磁盘阵列，云存储，备份系统等方案）多副本机制 P4P4 仓库安全仓库安全 我们制定了一些安全加固规范：公网连接必须配置 SSL 加密 公网访问需要通过安全组对来源 IP 进行限制 P4 密码安全级别必须设置成 3 以上：p4 configure set security=3 禁止自动创建用户：p4 c

132、onfigure set dm.user.noautocreate=2 强制新用户修改密码：p4 configure set dm.user.resetpassword=1 启用监控：p4 configure set monitor=25（这里至少要是 2，建议用 25 来开启锁 DB 进程监控）94 网址：SRE-E 微信：SRE 精英联盟 开启审计日志：使用-A 参数开启审计日志，例如 p4d-A/data/perforce/auditlog P4 需要用非 root 账号部署，禁止监听高危端口 权限表里默认的所有用户写权限要去掉（write user*/.）P4P4 仓库总体架构仓库总体

133、架构 为了满足内部员工和外部供应商共同使用 P4 的需求，基于性能、容灾、安全三方面的优化方案，我们设计了如下 P4 集群架构。内部员工直接访问开发网的 P4 集群，供应商通过云桌面在离岸研发专区（专门为供应商设立的网络专区）访问 proxy，请求通过智能网关转发到开发网 P4 集群，以此来达到内部员工和外部供应商在安全、可靠、高效的情况下使用 P4 协同办公的能力。95 网址：SRE-E 微信：SRE 精英联盟 SRE 可靠性提升措施：1.使用统一账号系统，提供统一鉴权；2.元数据（含权限表、用户表、trigger 等）自动备份，一键恢复；3.集群化部署，主备容灾，使用云盘避免机器故障导致数

134、据丢失；4.代码拉取、提交、删除、变更记录接入公司审计系统；5.人员离职、组织架构变更，邮件提醒权限删除；6.禁止供应商 office 网络连接 P4，只能在云桌面内部访问；7.p4auth 服务器单独架设，commit 异常，切换 replica；96 网址：SRE-E 微信：SRE 精英联盟 P4 版本要求：P4 HAS 要求 p4 版本2019.2，若 P4 版本无法升级到 2019.2 以上可以不用 HAS 而是用公司内部 LDAP 鉴权。P4P4 仓库扩展性仓库扩展性 1.trigger P4 的 trigger 机制可以在用户执行特定命令时触发对应的程序，从而扩展仓库功能。以下列举

135、一个 P4 登录鉴权的的trigger 案例。Triggers:ldapAuth auth-check auth/data/script/p4auth_ad-no_null 389%user%这个 trigger 的类型为 auth_check，会在用户登录时触发，调用/data/script/p4auth_ad-no_null 这个程序，把用户登录用户名加和密码传给 这个 ldap 服务器的 389端口，校验通过用户即可成功登录 P4 服务器。2.容量管理容量管理 97 网址：SRE-E 微信：SRE 精英联盟 由于 P4 上经常会存储很多大的二进制文件，硬盘空间容易满。我们建设了容量管理系

136、统，利用 P4 SDK 分析出每个目录、每个文件的所有历史版本占用的存储空间总大小。容量管理系统可以基于 P4 的 filetype+S 属性，配置每个文件在服务器上保存的历史版本个数，自动清理超出设置范围的历史版本文件。P4P4 仓库可观测性仓库可观测性 1.1.监控建设监控建设 98 网址：SRE-E 微信：SRE 精英联盟 基于用户访问 P4 的进程网络、存储调用链，我们建设了主机监控、进程性能监控、并发连接监控、锁 DB 监控、锁 DB 进程分析等监控能力。主机监控：监控 P4 集群各主机 CPU、内存、磁盘、网络等使用情况 99 网址：SRE-E 微信：SRE 精英联盟 进程监控：监

137、控 p4 连接进程（p4d、p4p）的 CPU、内存、IO 等使用情况 P4 并发连接数监控：监控 P4 的并发连接数情况 锁 DB 监控：监控各个 P4 DB 表的锁 DB 情况（不锁为 0，读锁为 1、写锁为 2）锁 DB 进程分析：分析出锁 DB 进程以及该进程具体锁了哪些 P4 DB 表，并且能一键批量暂停、恢复、终止异常 P4 连接。2.2.可用性可用性 SLOSLO 首先设定 SLI 指标 目标 100 网址：SRE-E 微信：SRE 精英联盟 P4 并发连接数 前四周的周峰均值*150%P4 锁 DB 持续时间 开发-联调-测试-发布整个流中，最频繁的动作就是开发-联调的过程。特

138、别在微服务、多人协作开发的模式下，往往会出现开发人员有多个版本需要在集群环境中调试的情况。而且在调试过程中也必须通过流水线发布才能发布到集群中，流水线的耗时等待更加加剧了这个过程。实现方案 如果想要加速这个过程，最好的方式为：让开发人员拥有在本地 IDE 开发调试一样的方式，对集群中的服务进行调试。这样就减少了流水线的发布等待过程；借助子环境的隔离能力可以做到服务 150 网址：SRE-E 微信：SRE 精英联盟 版本的隔离，解决多人服务争抢的问题；借助子环境流量染色的能力，实现服务间的功能联调。方案前后对比如下所示：既能降低开发人员的学习成本（与本地 IDE 调试一致），又能加速研发过程。1

139、51 网址：SRE-E 微信：SRE 精英联盟 我们通过自主研发 Vscode、Jetbrains 插件的方式，为开发人员赋予了这样的能力。IDE 插件的运行流程如下：i.当开发人员需要进行远端调试时，会克隆当前服务在集群中的工作负载，并为其打上开发人员的标识（子环境、用户），使其作为服务的一个“子环境”在集群中运行；ii.借助复用“CSI”的代码加速功能，将开发人员本地的代码增量同步到工作负载中；iii.启动服务，并针对相应语言启动一个调试服务器（例如 golang 对应 dlv）；iv.通过端口转发，将本地 IDE 的调试客户端连接到集群的调试服务器上；v.调试结束后，回收集群中对应的资源

140、。如此一来，便实现了开发人员在本地远程调试服务的功能。（三）（三）总结及展望总结及展望 目前，公司内部已有超过 95%的业务实现了容器化，且 80%的业务运行在服务网格中，覆盖了所有核心业务。基于 Kubernetes 和服务网格等云原生基础设施，公司构建了一套从应用研发到发布上线的全流程保障体系，将效率和稳定性视为生命线。152 网址：SRE-E 微信：SRE 精英联盟 面向未来，随着大模型与 AI 应用的兴起，研发过程保障迎来了新的机遇与挑战。例如，使用大模型辅助编码、进行代码审查（Code Review）以及问题排查等，大模型在研发领域展现出巨大潜力。我们将重点思考如何基于大模型构建一个

141、能够保障各场景应用研发过程的体系，以进一步提升研发效率和质量。3 入网控制入网控制 3.1 运行环境适配运行环境适配 3.1.1 运营环境设计运营环境设计 产品在经过了核心概念的提炼，通过对市场分析、确立用户定位、关注用户体验和产品风险等方面后，建立项目筹备小组，在完成了开发产品原型，验证技术风险，及通过相关评审确定进入量产阶段以完成产品的全部内容的开发。此时，将进入产品面向用户的试运营阶段，根据新产品评价体系每月对产品运营数据指标进行评测和汇报；确定产品质量是否已经达到面向外部用户的产品品质；通过相关评审来后项目组可根据项目实际情况开启正式运营。通过运营环境的规划与设计，可以根据过往的运营经

142、验形成可运营规范，帮助项目组和研发规避相同的风险，同时结合运营策略进行推演正式运营后的情况，以此来提前发现潜在的风险和问题，便于和运营、研发团队进行评估和优化排期。同时，对于规模化测试所需人力、用户体验、成本预估、设备及机房选型、网络带宽资 153 网址：SRE-E 微信：SRE 精英联盟 源及周边组件的容量，可用性等进行提前的评估和筹备。鉴于越来越多的组织采用多云环境，我们在规划过程中特别注重对公有云、私有云和混合云的供应商进行优劣势分析，同时充分考虑运营环境与云服务的耦合程度，做出恰当的选择和权衡。从组织结构上来说，可以成立一个专家组，主要的工作项是横向提炼各业务在运营阶段中的各种共性问题

143、、解决方案的沉淀和刷新，确立可运营规范。同时，在业务的关键节点参与技术评审。对业务支撑团队，在进行运营环境规划与设计时，主要可分为如下几个步骤：架构。业务决定量产并分配到支撑团队后，支撑团队需获取业务架构说明书部署文档，运营节点（建议近三个月为宜）等必要的业务相关文档从而了解业务架构、各模块功能和通信逻辑、容灾及技术指标等信息。以传统模式部署还是云原生模式部署，在这个环节会确定下来。评审。运维专家及支撑团队组织项目组、研发团队进行可运营规范、评审标准、版本交付规范等的宣导;深入就业务架构，运营目标涉及的技术问题进行专项沟通，以此来对业务有个整体了解，梳理风险及问题。验证。通过对业务测试环境的搭

144、建，掌握业务搭建方法，并分析可自动化和改善的点，此阶段非必须建设自动化，因为业务架构成熟度和交付结构可能会经常变动。同时根据对外测试的的目标选定部署的机房、机型及合适的网络运营商等环境规划。154 网址：SRE-E 微信：SRE 精英联盟 对齐。正式运营阶段筹备前根据节点时间进行倒推梳理整体支撑的检查列表，明确工作项、完成时间、负责人和细节部分，并与干系人逐一明确对齐，共同完善。和研发、运营共同确定业务稳定性目标 SLO 及相关的指标 SLI，以及围绕用户体验所需的场景和分析方式，并做好相关的数据埋点、呈现和监控。对于基线数据提前做好规划和收集。迭代。配合业务压测，了解性能瓶颈，并重点进行方案

145、的拟定和保障实施。根据运营中的问题刷新风险问题列表，并设计解决方案持续跟进，并在下次产品迭代更新后进行实际效果验证。3.1.2 容器云适配容器云适配 随着云原生技术的不断发展，容器以及 Kubernetes 等技术的长足发展给企业数字化转型带来了便利。容器技术将软件运行环境打包成一个“集装箱”，方便在不同环节进行传递；而 Kubernetes 则将容器的调度和部署标准化，让开发运维人员不再关注资源层面的调度和容灾。容器云适配则是通过云平台、Kubernetes 和 Docker等云原生技术帮助企业降低成本，加快业务迭代，对企业数字化转型提供强有力的技术支撑。通过容器云适配可以简化了服务部署等方

146、面的运维管理的复杂度，让业务团队更加专注于自身核心业务逻辑的开发，从而实现快速的业务迭代。同时通过虚拟化、资源池化以及弹性调度等技术，155 网址：SRE-E 微信：SRE 精英联盟 增加资源交互弹性，帮助业务团队不断降低资源成本，因此 SRE 应推动业务容器云的适配。改造筹备。筹备相关的内容主要目的是梳理各模块之间的逻辑以及交互方式，便于针对容器环境进行适应型评估，明确业务架构与容器环境之间的差距，便于业务进行架构调整。例如按照业务进程进程本身是否缓存数据，可分为有状态模块和无状态模块，无状态模块。同时还需要关注进程的服务发现机制，如果业务自己有成熟的服务注册机制，例如业务自行设计的服务注册

147、中心，那么在容器化的过程中，优先会有部分模块会落入 Kubernetes 集群中。网络评估。一般情况下，Kubernetes 的集群内与集群外是两套独立的网络，一旦容器化后落入 Kubernetes 集群中，内网访问时网络链路就会发生变化，也就是 overlay 网络。在 overlay 方案中，我们可以认为集群中的所有容器，默认都可以通过 IP 地址相互直连。集群内可以主动访问集群外，但是集群外看到的来源 IP 是集群节点的 IP 地址，并不知道容器 IP 地址。即使知道容器 IP 地址，集群外也不能直连容器 IP 地址基于这些条件，业务需要评估各模块访问关系，确认落入集群中后是否需要进行针

148、对性适配。工作负载评估。工作负载评估的基础原则是如何基于业务无损、不停机更新的情况下，可以选用哪种工作负载进行容器管理。对于各类更新方式：滚动更新、蓝绿发布、金丝雀发布，业务落地容器化必须至少选择一种方式进行管理，这个是保障我们利用好容器特性的基础。常用的工作负载是 Deployment 和 StatefulSet，是 156 网址：SRE-E 微信：SRE 精英联盟 Kubernetes 原生提供的分别解决微服务部署，有状态服务部署的方案。建议优先评估是否可以采用原生工作负载进行部署。弹性伸缩评估。弹性伸缩是云计算中一种常用的方法。通过设置伸缩规则来自动增加/缩减业务资源。HPA 是 Kub

149、ernetes 基于弹性伸缩进行的规则设计，Kubernetes 对 Workload 的资源使用（CPU，Mem）、自定义 Metric 指标进行负载评估：当负载超过设定高水位时，例如 CPU 平均负载超过 60%，就扩容 Pod 实例以降低负载到设定水位之下。当负载低于设定低水位时，例如 CPU 平均负载低于 20%，裁剪 Pod 实例以释放资源，降低成本。要实现水平扩缩，业务需要在业务逻辑与架构上实现优雅退出、负载均衡。优雅退出：业务容器负载降低时，HPA 会针对模块实例进行缩容操作，业务容器必须要优雅退出，保障业务逻辑顺利完成退出动作。负载均衡：当负载增加时，HPA 会直接增加容器数量

150、。无状态服务的处理方式较为简单，可以通过前置的负载均衡器有效均衡负载；有状态服务则需要业务动态感知实例/容量变化，合理分配玩家至新增服务实例。容器云适配后的交付和管理。容器云适配后建议使用 GitOps 来进行持续交付。GitOps 是由 Alexis Richardson 在 2017 年首次提出的，该模型主张将 Git 作为“单一事实来源”来管理和同步开发和生产环境，而不是使用传统的基础设施管理和部署方式。GitOps 的核心思想是将应用系统的声明性基础架构和应用程序定义存放在 Git 版本库中。将 Git 作为交付流水线的核心，每个开发 157 网址：SRE-E 微信：SRE 精英联盟

151、人员都可以通过提交拉取请求（Pull Request）并使用 Git 来加速和简化 Kubernetes 的应用程序部署和运维任务。每个环境都应该有一个代码仓库，用于定义给定集群的期望状态，然后 GitOps operator 会持续监控特定分支（通常是 master 分支），并在探测到 Git 发生变更后，将此次变更传递到集群，并更新 Kubernetes etcd 中的状态。通过使用像 Git 这样的简单熟悉工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上。3.1.3 数据库存储适配数据库存储适配 为确保项目数据库运行的稳定性、可靠性、可扩展性、安全性以及高性能，SR

152、E 应该对数据库存储进行适配或优化，确保可以为应用程序提供高质量、高性能、稳定性强的数据存储和访问服务。主要包含以下几个方面：选择合适的数据库类型。根据项目需求、项目架构设计和数据模型等，选择合适的数据库类型，如果数据具有固定的结构和关系，那么关系型数据库（如 MySQL、PostgreSQL、Oracle 等）可能是更好的选择。如果数据具有动态的结构，那么非关系型数据库（如 MongoDB、Cassandra、Redis 等）是更推荐的选择。除数据模型外，在评估数据库类型的时候还需要考虑项目的数据规模、业务场景、可扩展性、性能、一致性、可用性、成本等因素，综合考虑数据库选型。158 网址：S

153、RE-E 微信：SRE 精英联盟 数据库部署和配置。选择合适的服务器部署数据库服务，并进行最佳的数据库参数配置，如调整内存、连接数、缓存等参数，以满足项目所需的数据库运行的性能和资源需求。数据库高可用和扩展。根据项目需求，实现数据库的高可用和扩展，如搭建主从复制、分布式设计、读写分离等。数据库监控和告警。实施数据库监控，收集数据库关键性能指标（如 QPS、慢查询、磁盘空间等），并设置合适的告警阈值，以便在出现问题时及时发现并处理。数据库备份和恢复。制定数据库备份策略，定期备份数据，确保数据安全。同时，要熟悉并掌握数据库恢复流程，以便在发生数据丢失或损坏时能够快速恢复。数据库性能优化。分析数据库

154、性能瓶颈，优化查询语句、索引、表结构等，提高数据库性能。数据库安全。保障数据库安全，如设置合理的权限、防止 SQL注入攻击、加密敏感数据等。3.1.4 信创适配信创适配 在政策推动下，自主可控成为当下热点。各大企业均在进行自主可控替代，加大信创布局。信创产品相较于传统商业产品，信创产品的技术成熟度、生态成熟度存在着客观差距。对于 SRE 来说，针对含有信创产品的运行环境适配，需要建立以下工作流程：总体 159 网址：SRE-E 微信：SRE 精英联盟 目标制定、信创产品选型、产品验证测试、推动适配改造、业务测试、割接上线、运行保障。总体目标制定。根据发展趋势，企业在整体 IT 投入中，明确对信

155、创产品的采购比例。从而制定企业自主可控的总体战略目标，即年度含信创替代的项目计划，以及项目中进行信创替代的比例和对象，绘制全局信创替换后的架构图，重点标注端到端自主可控列表，包含硬件、数据库存储、容器平台及组件、终端等。每一次的信创项目完成后，均可以更新端到端的全局信创架构图以及具体的信创产品应用清单。信创端到端全局示意图 信创产品选型。确定项目的信创替代目标后，具体在哪一层进行信创产品的替代也随之明确。根据项目的生产环境及业务场景，对替换对象进行选型。以数据库存储、硬件、中间件这些为例，SRE有以下维度的选型策略。1）数据库存储 在信创过程中，SRE 参与各类信创项目的开展，为确保生产运维的

156、可维护性，SRE 需要在组件选型适配上重点关注。项目需要通过不同的业务场景完成数据库选型，从联机事务处理过程、后台批 160 网址：SRE-E 微信：SRE 精英联盟 量事务处理过程、联机分析等业务场景构建出业务主要特征，根据操作特性、数据量、实时性、一致性和 SQL 依赖等主要特征来适配业务场景。2）硬件（服务器、操作系统）在操作系统选型上需要从管理清晰度、公司战略、使用成本和可维护性为出发点，综合考虑开源和商业的使用版本。3）中间件 在中间件选型上要根据业务开发语言的适配程度、改造难度、可维护性等综合考虑，更多的了解实例基础配置的差异性，以及各类中间件产品的特性，维护过程中的复杂性等确认选

157、型产品。产品验证测试。针对各个产品，搭建同比于生产规模的产品测试环境，主要包含计算环境以及网络环境。对产品自身的相关项进行测试，以体现产品的能力。测试完后，输出详细总结报告，报告中应包含每一个测试项的结果指标、现存 bug、和原有的非信创产品的横向指标比对。以数据库产品测试为例，会进行数据类型及语法测试、数据库性能测试（包含数据查询、更新、删除、聚合、多表关联等场景）、业务 SQL 测试、高可用测试、数据备份和恢复测试、可维护性测试（包含错误检测和提示、日志信息、在线升级等）。完成所有产品测试后，把测试过程中发现的问题和风险整合到产品测试报告，以供选型决策参考。161 网址：SRE-E 微信：

158、SRE 精英联盟 推动适配改造。确定好信创替代产品后，根据信创产品的特性，需要已有应用架构做关联适配，主要包含两类，一类是集成部署架构的适配改造，如一些国产化的操作系统，部署配置应按照其系统路径进行调整；另一类是应用的代码适配改造，确保兼容信创产品后不影响系统稳定性。以下列了分布信创的适配改造场景：1）针对硬件（服务器、操作系统类）进行编译适配：针对语言编译类型选择不同方案适配 CPU 架构；通过容器封装或者构建相似环境实现操作系统适配；2）针对数据库 进行数据库解耦及开发框架升级：将与数据库多样化交互收敛到中间层，降低 90%换库导致的应用改造工作量；将分布式事务控制在应用层；禁用存储过程和

159、数据库链，禁止面向特定特性进行编码，实现面向对象编程。3）针对终端 进行代码适配：业务 SQL 类、函数类调整，CSS 布局，渲染适配调整；弹窗异常、回调事件不触发、按钮无效、无法投屏等适配。业务测试。在应用架构根据信创产品进行适配改造后，进入业务测试阶段，首先在测试环境上，使用测试数据进行功能、性能测试，并进行切换演练。确认过程无误后，在真实环境搭建的信创新集群上进行测试。1）功能测试 162 网址：SRE-E 微信：SRE 精英联盟 第一轮采用生产核心的业务场景或回归测试用例，对信创集群进行接口调用。梳理报错场景进行分析改进。2）性能测试 使用自动化压测平台，对信创集群进行压测，根据新集群

160、和生产集群的比例，对比压测后的响应结果，评估集群的性能情况。3）非功能测试及切换演练 针对评审中因引入信创产品后，可能引起的非功能性，比如由于数据库中间件的新增，需要重点测试批量数据操作的性能，由于开发框架的调整，需要重点测试故障转移、接口超时设置生效、服务熔断能力等。此外，由于信创集群的引入，在割接中当晚会使用流量倒换的模式，把部分流量切换到信创集群/平面。所以需重点测试切换能力是否可以快速生效。割接上线。通常情况下，为确保生产业务的稳定性，涉及信创产品替代的项目，采用先单平面改造上线，通过流量控制，把一部分生产流量引导信创平面进行验证，并行运行稳定后，再进行全量替换的方案。割接当晚首选不停

161、服发布，首先把部分流量引入到信平面，进行功能、性能及其他非功能性测试验证。验证无误后，把新老平面并行运行，并进行相应的测试验证。重点测试平面间切换开关的演练，如果次日业务量高峰时新平面出现问题，可随时启动切换开关，把流量全部引导到原有的老平面。163 网址：SRE-E 微信：SRE 精英联盟 运行保障。针对信创项目割接，建设应急处理的三板斧，切流、重启、扩容，首先应保证割接次日系统异常时可通过切流快速应急恢复，其次信创平面的容器云平面，可实现自动重启。此外，还应具备弹性扩缩容或人工接入时的一键扩容能力。确保生产业务系统的稳定性。在可观测维度，重点关注将信创领域的关键指标整合进统一的运维监控体系

162、中。鉴于信创涉及从端到端的技术栈改造，其磨合过程可能较为漫长，因此，我们可以考虑采用 eBPF 技术来实现对网络、系统和应用的全链路监测，从而为系统故障诊断和持续稳定运行提供坚实的支撑。3.2 运行环境交付运行环境交付 3.2.1 基础资源服务基础资源服务 围绕稳定性系统下，SRE 需要提供一个可恢复性、可扩展性的基础资源服务。基础资源包括：服务器、存储、网络、数据库、中间件等。SRE 应推动通过服务化方式交付基础资源。主要需要完善如下方面的内容：推动可恢复性的基础设施环境建设。可恢复性的基础设施环境是指信息系统依赖的硬件基础设施环境、应用平台、中间件、数据库等资源能够有效地从故障中恢复。为了

163、达到可恢复性，这些基础设施在技术选型、构建、运行保障中，需持续考虑到各种风险，包括自然灾害、技术灾难、请求激增、人为错误或外部攻击等，并采 164 网址：SRE-E 微信：SRE 精英联盟 取预防性、冗余性、高可用架构等以减少潜在的损失。它还具有在发生灾难后快速恢复的能力，这包括备份、冗余、快速恢复服务和关键信息系统的保护。可恢复性的基础设施环境还强调在设计和规划阶段就考虑到恢复能力，而不仅仅是灾害应对和恢复阶段。以云的方式交付基础设施环境。SRE 应推动混合云的平台服务能力建设，以支持按需选择一个能够满足需求的云服务。SRE 根据应用程序的要求、用户的数量、数据流量等因素，在云平台的服务目录

164、，在线选择资源池的 CPU、内存、存储、网络、数据库、中间件、平台应用服务等资源，并提交相关申请。SRE 可以在线查看已分配的资源和运行的应用程序，并可以通过管理终端对应用程序进行管理和维护，例如，启动、停止、重启、删除等操作。当不再需要某项资源时，可在线释放该资源，并将其返回到资源池中。同时，SRE 应在云环境部署应用程序，包括安装和配置应用程序、配置相关的网络、安全设置，以及在部署完成后，对云环境进行管理和监控，以确保其正常运行和安全性。量化评估基础资源环境。SRE 应建立量化基础资源服务的稳定性与成本管理指标，包括平台性能（资源服务的平均响应时间、吞吐量、处理能力等）、可靠性（资源服务的

165、可用性、容错性、故障率等指标）、可扩展性（资源服务的系统扩展性、负载均衡能力、资源管理能力等指标）、安全性（数据安全性、访问控制、漏洞管理等指标）等。成本指标，以及资源成本管理（资源的利用率、调用次数等指标）。165 网址：SRE-E 微信：SRE 精英联盟 3.2.2 可观测策略可观测策略 可观测主要是为了应对 IT 运行环境与技术架构复杂性，重点解决 SRE 在故障发现、故障诊断与故障恢复环节的应急过程管理。要求 SRE 需要从原来只负责可用性被动保障的角色跳出来，站在白盒角度看系统运行状况，剖析系统层面的运行信息。SRE 在推动可观测试策略时，需建立以下工作流程：制定可观测标准化规范。为

166、有效实施可观测性策略，需推动监控、日志、链路追踪等相关技术规范的制定，确保信息系统满足这些技术要求。规范应聚焦于增强主动监控性能指标数据上报能力，优化日志的标准化和可读性，实施数据埋点以建立链路追踪，并提供必要的基础设施服务支持，如系统监控数据上报和日志采集分析。技术规范应适用于新建和现有系统的持续优化，并明确配套的工作流程，确保可观测性工作贯穿软件的需求、设计、开发、测试等各环节。此外，组织内需要加强规范宣讲，推动系统架构师和研发工程师等人员认识到可观测是系统建设的必要条件。建立可观测工作小组。可观测在生产保障中应用，但具体工作涉及产品、研发、测试、运维多个团队的协作，SRE 需根据可观测规

167、范建立以系统或业务为单位的可观测工作小组，以提升协同效率。SRE 是可观测工作小组的牵头人，负责推动具体系统可观测能力的持续建设。因此，SRE 需要清楚的知道系统的业务运行状态、应用服务状态、批处理状态、性能管理、容量水位、依赖环境等黄金指标，明确相关黄金指标的数据计算逻辑，推动相关功能的建设 166 网址：SRE-E 微信：SRE 精英联盟 与验收。同时，需要提前参与到系统设计阶段，梳理指标异常监控策略，以及系统依赖的应用平台、系统软件、基础设施、上游系统的监控策略，以及如何通过应用日辅助故障定位。另外，需将系统的上下游、交易请求链路、资源依赖等关系作为软件交付物之一，系统能够为感知链路节点

168、的健康状况提供数据。融入需求设计评审阶段。SRE 在系统的非功能性设计评审阶段，应参与可观测方案的制定，提出软件可观测需求，并明确具体的监控、日志、链路的数据埋点，以及工具支持的需求。跟踪可观测的技术实现。在入网控制阶段，SRE 应构建完善的数据采集、加工与处理平台，涵盖日志管理（如 ELK）、性能指标监控（如 Prometheus、Zabbix）、链路追踪（如 Zipkin、Apache Skywalking），持续性能剖析（如 Pyroscope），eBPF 无埋点观测等能力。为了处理和分析不同工具产生的可观测数据，我们建立了一个统一的数据关联框架，该框架包括数据收集器、处理器、存储系统以

169、及查询和可视化工具。这些组件共同作用，实现了多种观测数据的关联融合，并支持多层次的数据下钻和追踪，构建起了一个可观测的拓扑结构。此外，还需建立一套全面的数据质量监控机制，覆盖数据的生成、收集、加工和使用各个环节，以确保数据的准确性，可靠性及实时性。167 网址：SRE-E 微信：SRE 精英联盟 验收可观测策略交付。SRE 在入网控制阶段应验收可观测相关数据埋点、可观测工具、生产环境配置等工作，确保系统上线后，配套的可观测工作机制能够顺利开展。3.2.3 自动化策略自动化策略 SRE 应尽可能的推动自动化一切的工作期望。自动化策略是将事件驱动思维模式融入到运维的方方面面，可以从思维、技术两个角

170、度发力。思维角度，即 SRE 组织从一线操作、二线运维、管理岗位，要对重复性、操作性的工作琐事有天然的排斥感，并想方设法用软件方式代替手工操作。技术角度，一是从 SRE 工具层面建立以原子脚本、编排任务、任务调度的自动化操作能力；例如，通过编写脚本来自动化日常运维任务，并使用如 Terraform 等工具来实现基础设施即代码（Infrastructure as Code，IaC），确保环境的一致性和可重用性。二是将 SRE 手工操作标准化，并将标准的运维操作场景化，基于场景将自动化操作与工作机制相结合；这可以通过编写标准操作手册（SOPs）并将其转化为可执行的代码。三是 SRE工作前移，推动应

171、用系统自身自愈或无人值守的可靠性设计。推动定时任务集中管理策略。为了解决定时任务的作业调度可靠执行问题，在没有集中作业调度策略前，SRE 需要各显神通，采用类似 crontab、Windows 定时作业，以及基于软件系统程序的定时作业等解决方案。由于多个定时作业执行状态可能会相互影响，分散式的定时作业管理容易引发风险、效率、管理等问题，比如：168 网址：SRE-E 微信：SRE 精英联盟 遗漏某些重要的业务调度步骤引发账务风险，手工任务周期设置有误导致任务漏做或重复做风险，调度批次异常无法及时发现的风险，人工重复执行不可重复操作作业任务，重复建设调度管理工具扩大成本等。因此，SRE 应推动集

172、中式的作业调度自动化管理，例如部署 Kubernetes CronJobs 等工具，将规律性的任务固化由机器执行，支持多种目标端对象的任务执行、支持统一采控的远程任务执行、支持低代码的流程编排、支持快速应对作业异常处置等能力，解决系统稳定性保障涉及的生产力、安全控制等问题。推动软件交付的自动化策略。软件交付是 IT 的关键价值创造，持续交付是提升软件交付速度的一个工程实践。持续交付的软件发布方式提倡全自动化，即围绕软件程序的部署，编排发布各环节的自动化操作。发布流水线是自动化策略落地的关键技术，流水线将一个软件发布环节串联起来，让软件交付过程中不同的角色可以透明地看到整个过程。同时，通过线上化

173、各环节的执行步骤能够量化持续交付的水平，比如自动化测试覆盖率、缺陷数量、每天构建次数、发布平均时长等，量化数据能让团队清晰地看到低效环节并进行改进。对于不同的应用系统，SRE 应建立针对性的自动化发布策略，比如针对敏态应用，SRE 还要推动蓝绿、灰度/金丝雀、滚动、红黑的自动化部署策略等。推动故障自愈策略。自动化的故障自愈是指通过自动化的方式，在系统出现故障时快速、准确地恢复到正常状态，减少人工干预的必要性，提高系统的稳定性和可靠性。SRE 在推动系统的故障 169 网址：SRE-E 微信：SRE 精英联盟 自愈时，可以从应用程序应对异常时自愈的自动化，包括应用程序健壮性涉及的降级、熔断等，以

174、及在应用程序以外配置的自动化自愈策略。从技术实现角度，主要需要解决自动化故障检测策略涉及的预设的故障检测规则和算法，系统可以自动检测故障，并根据预先设置的动作自动修复。推动应急预案自动化策略。SRE 首先需推动应急预案的线上化，线上化应急预案有助于将标准化动作自动化，比如针对主机、应用服务、容器等最小运行对象单元的应急。线上化应急预案后，可推动预案的策略管理，支持多种策略组合、策略发布与组装、场景编排、通用场景等。接下来，SRE 应推动预案策略与自动化工具、接口和流程执行，关联场景绑定。3.3 测试策略测试策略 3.3.1 连通性验证连通性验证 通常在项目集成部署完成后，SRE 会联合开发团队

175、对部署的环境先做连通性测试，目的是保证各个系统或模块之间的数据传输正常、请求和响应的格式正确，并且确保接口在不同条件下的稳定性和可靠性。主要可以分为以下四个步骤：确定测试目标、构建测试请求、单调用连通性测试、压测连通性测试、记录和报告测试结果 1）确定测试目标 根据部署的架构图，确定要测试的系统范围以及调用通路，列出各个系统模块要测试的接口清单，包括系统模块名称、URL、IP 170 网址：SRE-E 微信：SRE 精英联盟 地址、端口号等信息，以及被测试接口的功能、参数、请求方法（如 GET、POST 等）和预期响应格式（如 JSON、XML）等。2）构建测试请求 根据接口的特点和需求选择合

176、适的测试工具。一般选取最核心的业务功能创建连通性的测试请求，包括请求的 URL 或 IP 地址、请求方法、请求头、参数等。3）单调用连通性测试 利用选定的核心业务功能测试请求，对各系统模块接口发起单笔调用，检查返回的数据格式、数据内容是否满足预期结果。用此方法遍历各个系统模块之间的边界连通性。4）压测连通性测试 完成基本的单笔调用连通性测试后，为进一步评估接口的性能。利用压测工具，对核心业务场景用力发起生产 100%的压力测试（目前实际使用过程中，有流量回放能力的公司，直接取核心业务的生产流量即可）。检查成功率，对错误响应进行核实，明确是功能参数问题还是性能问题，并予以改正。5）记录和报告测试

177、结果 记录测试过程中的关键信息和结果，并生成测试报告。测试报告应包括测试目的、测试环境、测试脚本、测试结果、问题和建议等内容。171 网址：SRE-E 微信：SRE 精英联盟 3.3.2 功能测试功能测试 SRE 功能测试主要指在开发已完成交付测试，提交可交付代码版本的基础上，正式接入生产环境进行的测试，其功能测试主要包括版本功能测试（针对当次版本变更功能的测试，验证可用性、准确性）和回归测试（针对系统现有核心功能进行回归验证，确保非当次版本变更内容的准确性）。整体功能测试可以分为以下几个步骤：测试流程和计划制定、生产验证测试执行、当晚缺陷处理及次日故障跟踪、测试故障分析及评估、测试用例持续设

178、计和维护。1）测试流程和计划制定 制定上线功能测试管理流程，贯穿测试过程中缺陷的提出、处理、复测、结束等各个阶段，按照工作任务规范职责，形成测试计划清单，及时高效地关键节点进行监控，从而保证上线验证测试的有效性，以提高系统上线的整体质量。2）生产验证测试执行 第一阶段：测试数据准备；第二阶段：测试执行。将自动化用例通过平台一键式发起执行，在确认所有自动化计划发起完成之后，开始执行手工用用例。上线当晚上测试组根据上线范围进行自动化测试，如遇到异常情况影响测试进度，及时通知客户并协调相关人员处理。测试组严格执行上线测试流程，明确红线时间，完善联动升级和通报机制，确保上线测试过程顺畅。3）当晚缺陷处

179、理及次日故障跟踪 172 网址：SRE-E 微信：SRE 精英联盟 生产当晚问题处理：主要分为四步，对于生产实时出现的问题，及时上报上线或变更管理员，协调相关资源协作排查问题，同时实时通报问题现象、进展、解决方法和最终处理结果。测试报告编写：功能测试组编写系统验收测试报告，测试报告内容包括缺陷发现时间，测试进度，缺陷的准确描述，以及后续缺陷修复情况等。测试进度通报：功能测试组对生产验证测试报告进行通报，若当晚未发现缺陷，则发送 60 分钟核心用例测试阶段性通报；若当晚发现缺陷，则发送问题发现通报并且整点时要发送问题进度通报。测试缺陷处理：当测试发现缺陷，先做专业性的判断，是否为真缺陷还是业务理

180、解问题，或者是电脑、手机、网络等客观因素导致的缺陷，若为真实缺陷，联合开发团队共同解决当晚的测试缺陷。测试任务结束：如果当天上线依然存在遗留问题或故障，需要交接给次日保障人员持续跟踪、解决和通报。同时，生产上线当晚测试内容进行总结，内容主要包含准发布验收测试问题分析、生产验证问题分析、生产次日相关故障分析、生产验证测试分析，并输出上线生产验证情况总结。1）测试故障分析及评估 对生产上线当晚测试发现的问题或故障进行还原，并将故障现象和测试抓包数据反馈给保障值班人员。通过保障值班人员处理之后，将故障进行记录，包括故障现象、解决方式、故障分析等信 173 网址：SRE-E 微信：SRE 精英联盟 息

181、。以每周为维度统计上线次日故障，罗列出 SRE 相关故障总数，划分出重大故障、重要故障、一般故障的个数，进而细分未覆盖故障数与已覆盖故障数目，分析得出故障未覆盖原因以及问题归属系统，评估可进行优化覆盖用例数目。经生产验收核心业务回归测试后，系统或平台未发现任何重大故障。这意味着系统在回归测试过程中成功通过了核心业务功能的验证，并且没有发现对系统关键功能或数据造成重大影响的故障。减少了重要故障的风险。重要故障指的是那些可能导致系统崩溃、数据丢失、功能不可用或对业务流程产生重大负面影响的故障。然而，需要注意的是，虽然没有发现重大故障，但仍可能存在一些较小的问题或不太常见的故障情况，因此仍需对系统进

182、行持续的监控和改进。2）测试用例持续设计和维护 用例库基于业务量、投诉量、故障标准和企业考核标准将业务分成四个星级，星级越高，业务越重要。并定义二星级以上为核心业务，在生产回归测试中予以覆盖。对用户有独立入口操作的页面定位为业务场景，作为用例建设的基础。通过调研用户使用系统的习惯，录制前台 UI 操作用例。并通过对核心参数进行多枚举值覆盖的方式，建设多路径覆盖的测试用例，对 UI 用例进行补充。每一轮生产验证测试复盘完后沉淀的改进方案和补充用例，都会纳入测试用例库。174 网址：SRE-E 微信：SRE 精英联盟 自动化用例维护均在上线前 1 至 2 天内完成，可以确保系统上线前的最后一轮检查

183、和修复。自动化用例维护涉及对已有的自动化测试脚本进行更新和修复。当系统发生变更或更新时，现有的自动化用例可能会因为页面结构或功能变动而失败。因此，在上线前，测试团队会仔细检查自动化用例的稳定性和有效性，并根据需要修复脚本中的问题。演练平台创建计划演练发起周期性测试，提高测试效率和准确率。3.3.3 性能压测性能压测 性能测试包括压力测试与负载测试。全链接压力测试通过超负荷的负载条件来测试系统的稳定性和可靠性，以确定系统在极限负载下是否能够正常工作。负载测试则模拟用户访问系统，检测系统在不同负载下的响应时间和资源使用情况通过。在进行全链接压力测试时，定义性能指标和测试场景，设计合适的测试用例，并

184、可使用 Jmeter 工具执行测试。通过监控系统的性能指标和记录测试结果，可以分析系统的性能瓶颈并提供优化建议。总结而言，性能测试是一种评估系统性能和稳定性的测试方法。通过模拟真实场景的用户行为和系统负载，它可以评估系统在不同负载下的性能指标，并发现性能问题和瓶颈。1）全链路压测工作流程制定 制定上线压力测试管理流程，贯穿测试过程中方案设计、缺陷的提出、处理、复测、结束、上线后的复盘改进等各个阶段，按照 175 网址：SRE-E 微信：SRE 精英联盟 任务分类明确职责，且各任务对应到具体方案及工作清单，保证生产压测管理流程可以切实得到执行，从而保证生产压测的有效性，以提高系统上线的整体质量。

185、2）全链路压测方案设计 针对某次项目压测，根据不容的业务场景，设计压测方案，主要确定实施范围和实施方法。（1）确定实施范围和压测指标 按照生产实际业务大类，可以分为查询类和办理类，因模拟受理类业务容易产生脏数据，工作量成本和代价较大（受理占比较大的一些场景可以考虑模拟受理类）。通常情况下我们的压测实施范围首先定位为查询类业务。针对生产系统如此多的查询类场景，既要能够压测出生产瓶颈，同时又能够将影响面降到最低，较好的方法是选取 TOP 查询类的场景作为压测范围。压力测试无论是生产环境还是测试环境，都需执行相关的指标来衡量压测的效果，也便于后续统计评估同一个接口在各月的性能趋势。（2）确定实施方法

186、 集中化场景压测：指单纯的查询类生产业务压测，跟真实生产业务场景存在一定的差异，为了更真实的拟合生产实际，考虑通过对单集群的压力测试来反应真实的生产场景。混合性场景压测：针对爆发式增长的特殊业务场景，比如“充值送话费”活动，“充值”等，他们主要的特征是在某个特定时间段集中迸发而导致业务受理的瞬时高峰，因此，我们需要模拟混合 176 网址：SRE-E 微信：SRE 精英联盟 业务场景对系统进行压测，测试系统的性能短板，并指导资源的最佳配置。3）全链路压测执行（1）执行生产验证测试必要条件 各系统都连接好，可以测试全流程的业务；生产环境测试结果能够真实反映系统运行状况；生产环境能测试一些入网环境无

187、法测试的场景；生产验证测试能够发现一些由于环境差异导致的软件缺陷。（2）测试执行的工作项 其一是测试案例执行，其二是执行结果汇总，指第三方测试组对测试案例执行结果进行汇总；处理缺陷即是生产测试验证支撑组修复测试过程中缺陷，提交测试用例让执行组进行回归测试；其四是测试管理工具的管理与维护；最后是协调与管控，对执行过程中遇到的问题协调多方进行处理与解决。（3）生产验证测试执行策略 生产验证测试执行就是根据测试案例编写阶段编写的生产环境测试用例来执行，不过在执行测试是有几个地方需要注意：仔细检查软件生产环境是否搭建成功；注意测试用例中的特殊说明；注意全面执行测试用例，每条用例至少执行一遍。执行测试用

188、例时，要详细记录软件系统的实际输入输出，仔细对比实际输入和测试用例中的期望输入是否一致，不要放过一些偶然现象。（4）实时监控 177 网址：SRE-E 微信：SRE 精英联盟 对于生产压测主要监控内容有：云平台监控、日志监控、应用监控、CSF 接口监控、网络监控、服务治理监控、主机监控等等。4）生产当晚问题处理以及次日故障跟踪 对于生产实时出现的问题，及时上报上线或变更管理员，协调相关资源协作排查问题，同时实时通报问题现象、进展、解决方法和最终处理结果。测试报告编写：测试组编写系统验收测试报告，测试报告内容包括测试结果，缺陷修复情况等。测试报告核实：测试组对生产验证测试报告进行核实，主要核对测

189、试执行状况、测试结果、缺陷修复情况。测试报告发布：入网测试报告核实通过后，测试管理组组长发布入网测试报告。生产准出确认：根据测试计划和测试报告分析各项指标作为评判依据，如案例覆盖率、入网测试通过率、关键业务测试通过率、端到端测试通过率等，测试结果是否满足准出条件。最后是生产次日故障跟踪，主要是用于确定压测当晚的实施效果是否存在不足或遗漏，跟踪人员通过次日跟踪也能够更加熟悉生产，对保障生产稳定性以及全链路压测和生产环境的紧密型都有极好效果。5）压测总结报告分析与评估 对测试结果进行分析，根据测试目的和目标给出测试结论。通过对接口流量的业务成功率、系统成功率和生产耗时等重要指标进 178 网址：S

190、RE-E 微信：SRE 精英联盟 行详细的分析，这些采集到的数据被视为本次上线压测接口的基线，用于评估系统在压力下的表现。在性能回归测试的压测过程中，性能测试组成员会将实际的接口耗时、业务和系统成功率与基线进行比较。这样的比较能够清楚地显示出接口性能的升降幅度，进而判断出系统可能存在的性能瓶颈和潜在问题。同时，性能测试组成员也会积极抛出问题并持续追踪这些问题。在追踪的过程中，他们会对各个问题进行深入的分析，并提出切实可行的建议和优化方案。这些建议和优化方案的目的是为了解决相应的问题，并最大程度地提升系统的性能和稳定性。通过持续的压测和性能优化工作，性能测试组成员能够不断改进系统的性能，并确保系

191、统在高负载情况下仍能够正常运行。为业务的顺利进行提供了坚实的基础，也保证了用户能够获得更好的体验和服务质量。6）全链路压测自动化与维护 基于开源的 Jmeter 工具做定制开发，形成全链路压测自动化工具。其架构是控制台、压力生成器、分析器，主要作用是配置测试场景，通知代理器进行数据初始化或清理，搜集测试过程中被测系统各个环节的性能数据，并根据要求模拟一定数量的虚拟用户对被测系统发送业务请求，实现对被测系统的压力测试，其中一个虚拟用户对应一个业务并发；将会发送测试的过程及结果数据信息给控制台进行采集汇总。最终分析并展示测试结果，同时对测试结果进行保存。179 网址：SRE-E 微信：SRE 精英

192、联盟 每月例行对生产全链路压测结果、测试账号、测试数据和测试场景用例进行检查，对场景变化的用例进行及时维护，对出现问题的测试账号、测试数据等及时的修复，以确保生产压测的准确性和安全性，确保各种数据可持续、可继承、可追溯。3.3.4 数据迁移数据迁移 1）数据完整性和准确性测试 由 DBA 采用数据库稽核工具，支持同构/异构数据库间的数据稽核比对，包括 count 稽核和表全字段稽核，通过监控可以快速定位两端的差异，保证两端数据库同步数据的完整性和准确性；并且支持割接后增量数据回传，保障割接后发生故障能够快速回切恢复。2）可用性测试 由 SRE 进行迁移可用性测试，目的是确保数据在迁移后能够正确

193、地被使用。测试所有核心及非核心的功能，并确保它们达到预期的结果。另外，在迁移完成后的一段时间内（如每日早晨的开门测），针对之前已经测试过的功能进行再次回归测试，以确保在迁移后的初期没有引入新的错误。3）性能测试 由 SRE 进行迁移性能测试，测试系统的在迁移后的性能是否与之前相同。同全链路性能测试的方案，按步骤进行验证。180 网址：SRE-E 微信：SRE 精英联盟 3.4 变更评审变更评审 变更评审主要是为了降低系统变更投产带来的风险，并让变更如期交付业务。变更评审中，不同的 SRE 组织会在系统交付生命周期的不同阶段建立相对应的变更评审机制，比如项目立项环节的可用性评审、技术或部署架构可

194、用性评审，设计阶段的非功能性、可运维性评审，上线环节的 CAB 评审等。3.4.1 稳定性架构设计评估稳定性架构设计评估 SRE 组织为了推动稳定性架构管理，建议在整个技术线层面建立跨团队的技术架构管理组织，负责制定稳定性架构管理规范、技术组件规范，以及相应的技术管理与技术评审流程。SRE 应重点从高可用、故障恢复、可扩展性、数据完整性、部署环境角度推进相关评估工作。高可用是运维管理的一条底线保障要求，运维主要工作是消灭单点风险，提升系统韧性，比如数据库中提到的主备、主从、分布式，数据中心的两地三中心、分布式多活，以及将一个应用系统同一个服务组件部署在多个数据中心机房、不同物理机的多个虚拟机上

195、、为应用的负载均衡提供网络硬件或软件负载均衡器、提供具备高可用架构消息中间件等 PaaS 云服务等。为了更好的推进评估工作，SRE 需要提前提供架构高可用的规范，制定通用组件、信息系统架构高可用参考模式，将高可用要求更早的落地在系统设计过程中。181 网址：SRE-E 微信：SRE 精英联盟 故障恢复可借鉴最佳实践、具体信息系统的特点等，制定相应的故障恢复能力要求。在应用系统层面，需关注应用拆分、服务或系统交互解耦、服务无状态、减少总线节点服务依赖、增加异步访问机制、多层次的缓存、数据库优化、限流与削峰机制、基础设计快速扩容等。在基础设施层面，可恢复性的基础设施环境需能够有效地从自然灾害或人为

196、灾难中恢复，即考虑到各种风险，包括自然灾害、技术灾难、人为错误或网强行攻击等，并采取预防措施以减少潜在的损失，至少应包括备份、冗余、快速恢复服务和关键信息系统的保护。技术架构的可扩展性是指在不影响现有系统功能和性能的前提下，系统能够扩展或增强其功能的能力。通常涉及对系统设计、架构和模块化的考虑，以便于未来的扩展和升级。包括：将系统拆分为多个独立的子系统或模块，每个拆分的部分负责特定的功能和业务逻辑，降低整个系统的复杂度与模块间的耦合度，提高扩展性；支持横向与纵向的扩展能力，通过增加服务器数量与提高每个服务器的处理能力，来提高整个系统的处理能力，或通过升级单个服务器或组件的硬件，来提高其处理能力

197、；系统支持弹性伸缩，即根据系统的负载情况自动调整计算和存储资源，以实现系统的动态扩展和缩减;减少总线节点服务依赖，由多节点组成的逻辑交互改为端对端的访问方式，减少影响交易因素，少自身性能问题影响其他应用系；增加异步访问机制，同步的机制在性能出现问题时，会在短时间消耗完最大连接数，哪怕这个最大并发数是正常情况下的 10 倍，182 网址：SRE-E 微信：SRE 精英联盟 将同步连接改异步通讯，或引入消息队列都是解决上述问题的方案；支持多层次的缓存，可以从前端、应用内部、数据库等层面建立缓存。数据完整性是运维保障的底线要求，持久化数据的生命周期通常会比系统与硬件的生命周期长很多，很多新系统上线或

198、架构调整都考虑数据迁移工作。同时，还要关注一些复杂性数据处理，比如：批次、清算、对账等操作，这些操作极易受数据问题影响，运维侧需要关注数据处理的异常中断原因定位、哪些环节是可以应急中断、中断后是否支持多次重试、与第三方系统约定数据不一致时以哪方为基准等等应急处置机制。选择合适的部署环境需要考虑多种因素，包括应用程序的特性、性能要求、可扩展性、可靠性、安全性、服务提供商的支持和成本效益等。不同的因素将对部署环境的选择产生重要影响，比如某些应用程序可能需要大量的内存和计算资源，有些需要选择能够提供高吞吐量和高数据处理能力的平台服务，有些需要选择云服务使应用程序能够随着需求的变化而扩展，有些需要选择

199、高度稳定与安全性的基础设施环境。3.4.2 非功能性技术评估非功能性技术评估 运维的非功能性设计是主动应对可运维性问题的切入点，直接决定系统在生产环境的成本与收益，甚至决定系统生命周期的长短。以下罗列运维侧需要推动的非功能设计。183 网址：SRE-E 微信：SRE 精英联盟 系统运行状况可观测。云原生提出可观测的监控指标、日志、链路三要素同样适用于传统以主机为代表的技术架构。运维是在一个黑盒子的成品上进行监控、日志、链路完善，像 NPM、APM、BPM等是运维侧发起的一些解决方案。从非功能设计看可观测，需要运维前移，推动必要的监控、日志、链路相关的研发规范，提升主动上报监控性能指标数据的能力

200、，优化日志的可读性，并提供必要的基础设施服务支持，比如支持系统监控数据上报、日志采集分析等。故障隔离与服务降级。故障隔离和服务降级的目的是以牺牲部分业务功能或者牺牲部分客户业务为代价，保障更关键的业务或客户群体服务质量，是防止连锁性故障蔓延的方法。在设计中，运维侧需要从系统或业务角度，梳理应用系统所调用的各个服务组件，对各个服务组件出现故障时的假设，及应对措施。性能评估。性能容量管理主要基于响应时间（系统，功能，或服务组件完成一次外部请求处理所需的时间）、吞吐率（在指定时间内能够处理的最大请求量）、负载（服务组件当前负荷情况）、效率（性能除以资源，比如 QPS=并发量/平均响应时间）、可扩展性

201、（垂直或水平扩容的能力）等黄金指标开展。性能问题对稳定性的挑战不仅仅是单组件不可用，更大挑战是某个组件性能问题不断扩散到别的组件，导致大规模的故障。性能问题极易引发复杂的异常问题，SRE 需要加强相应的技术评估。184 网址：SRE-E 微信：SRE 精英联盟 终端版本向下兼容。移动化后终端版本的管理越来越重要，在架构上一方面需要尽量保证升级后的版本要向下兼容正在流通的低版本的可用性；另一方面要对流通的版本进行收敛管理，支持多种在线更新机制。基于基础平台运行。无论是基础设施平台，还是 PaaS 层的应用平台，或持续交付工具链，系统均需要尽量与公司现有基础平台对接，避免引入新的技术栈。可配置而非

202、硬编码。在应急时，发现有些“参数”硬编码在程序中，无法快速调整，需要推动配置管理。另外，IP 的 DNS 域名改造也是可配置的一个方向，减少人工在后台修改。日志规范化。日志分析是认识应用系统的关键手段，SRE 可关注以下几点：一是“存储”，因为行业或企业内部有保存日志数据的要求，需要一个成本可控、可横向扩容、支持海量日志数据的管理平台；二是“查询”，日志是感知线上系统运行状况，了解代码级问题的一个窗口，在出现业务问题、故障应急等场景下，可以利用日志查询问题，需要建立实时的数据采集、高效的日志检索能力；三是“监控”，基于日志分析关键字、正则检索、模式匹配等方式，能够提供监控能力；四是“分析”，对

203、日志的非结构数据进行加工处理，生成非结构化数据，进行运行数据分析，实现异常发现、故障定位、性能分析、容量评估等分析工作。测试方案完备。在测试方案评审中，SRE 应重点围绕性能、容量、压力、稳定性架构等测试方案的评审。评审的角度包括，测试 185 网址：SRE-E 微信：SRE 精英联盟 用例的描述是否清晰，测试用例的执行结果是否符合要求，测试结论涉及遗留问题的应对措施等。3.4.3 变更保障准备工作评估变更保障准备工作评估 变更带来系统稳定性风险。从生产变更故障引发率看，来自变更的故障遥遥领先其他因素引发的故障，变更后通常是运维组织最为繁忙的时段。不管是大的软件基线，还是小到一个功能迭代，甚至

204、一个参数或配置的调整，也可能引发一个重大故障。变更带来的风险点很多，有设计上的程序缺陷类的问题，也有管理上的版本管理的问题，也有操作层面的执行问题，也可能是协作层面上下游系统沟通不畅引发的相互影响的问题等，解决变更带来的风险问题是一个极为复杂的系统性工作。SRE 可考虑从以下工作中加强变更保障的评估。监控和告警是否就绪。建立完善的监控覆盖面，包括基础设施、平台软件、数据库、中间件、操作系统、性能等技术指标监控，与特定系统相关的业务功能、客户体验指标监控，以及与系统上线后重要业务功能首笔出现的监控。运行健康检查方案是否就绪。需建立完善的监控和预警体系是保障系统可运维性的重要手段，能够实时监控系统

205、的各项指标，及时发现问题并进行预警，以便及时处理问题。应急预案是否就绪。故障应急工具是否就绪：系统出现故障时，需要能够快速恢复并进行处理，避免故障扩大化。186 网址：SRE-E 微信：SRE 精英联盟 技术运营工作是否就绪。系统上线后，需要进行全面的运营管理工作，包括用户服务、首笔业务发生的跟踪、异常数据或逻辑问题的处理、安全管理等方面的内容，以确保系统能够稳定、高效地运行。文档是否完善。根据组织软件交付的协同机制，明确新系统上线的文档交付清单，比如：项目与需求、技术架构图、测试结论（含压力测试）、安装部署（与环境相关）、应用/业务监控、首笔功能监控及保障、重要功能清单、重要配置与参数、运行

206、效能评估等文档。知识库是否就绪。建立完善的知识库是保证系统可运维性的重要基础，需要对系统的各项功能和操作进行详细的描述，并建立知识库，以便在需要时能够快速查找相关信息。3.4.4 新系统或新业务上线保障评估新系统或新业务上线保障评估 新系统或新业务上线是从 0 到 1 的过程，具体的工作通常包括：上线准备工作、制定技术方案、评估测试管控、上线文档准备、风险评估、安全保障措施、运维监控准备、上线过程协同、上线发布、系统验收、上线试运行等。新系统或新业务上线给企业带来机会与挑战。一方面，作为项目重要里程碑，新系统将为企业业务发展或运营管理助力，通常业务需求方会投入大量精力在上线后的运营推广工作，以

207、期望更好地 187 网址：SRE-E 微信：SRE 精英联盟 给业务及客户带来价值；另一方面，新系统上线带来众多的不确定性因素，需要对不确性因素进行管理。不确定性包括：新业务流程的合规性、数据安全、隐私安全等问题；新业务对现有上下游系统在业务及性能层面的影响；新系统在设计上是否满足业务活动的性能、容量要求；配套的稳定性相关的监控、日志、应急、数据备份等非功能性需求是否就绪；功能已知缺陷的影响是否评估；发布上线、环境部署、下线方案是否就绪；对系统业务运行情况的观测能力等 新系统或新业务自身的业务风险可能会对存量业务流程产生影响。在加强风险评估工作上，SRE 应加强以下风险的评估：新系统业务带来的

208、风险防范、监管合规、数据安全、隐私安全等问题；新系统业务流程可用性、终端体验、数据准确性等风险；新系统业务对现有上下游系统在容量、性能方面的影响，以及上下游配合改造对原有业务带来的影响；新系统资源、架构、重要功能是否满足业务期望，以及接下来业务活动的性能、容量要求；系统压力测试、容量评估方案、功能遗留缺陷等是否评估到位等；另外，SRE 还应主动推动以下工作：标准化先行，建立业务与技术层面的合规、风险、隐私、安全等方面的管理要求，并辅助相关技术检测手段。188 网址：SRE-E 微信：SRE 精英联盟 业务系统非功能性需求的建设，比如系统回退、版本切换、灰度发布、终端体验感知等配套功能的实现。业

209、务系统技术运营需求的建设，比如对首笔业务感知、业务流水监测、关联系统的技术运营监测等。系统性能与容量管理，包括相关评估指标、基线容量设计、指标数据加工、容量评估分析报告、压力测试等工具建设。同时，针对可能突增的业务模式，SRE 需要建立限流、削峰机制。架构优化上，需要前端系统做交易并发控制开关，必要时进行前端限流、削峰，以及后端服务降级，通过一些前端交互设计减少客户的体验影响，重点保障系统的核心服务。SRE 通过聚焦新系统或新业务上线阶段，做好运维工作左移，提前做好资源交付能力建设提高系统上线速度，利用运维平台能力建设帮助业务研发专注业务逻辑，提前参与到架构及非功能性需求的研发与验收，能够让系

210、统上线后融入平台化管理模式。4 变更管变更管理理 根据业界经验及 Google 多本 SRE 书籍的论述，约 70%左右故障是由变更引起的。然而，业务发展中的变更是不可避免的，因此，通过变更管理来控制变更的风险，尽可能降低由变更导致的故障率和影响范围，是提升系统稳定性的一条可持续且高 ROI 的路径，也是每个 SRE 团队面临的关键课题。189 网址：SRE-E 微信：SRE 精英联盟 4.1 发布管理与变更管理关系阐述发布管理与变更管理关系阐述 发布是软件工程术语，变更是系统工程术语，在各自领域，这两个概念常常相互包含对方。SRE 关注的核心问题是业务应用的稳定性，SRE 所涉及的“发布”大

211、多特指代码变更，而“变更”的范围则包含了硬件变更（网络设备、主机、存储等一切 IaaS 硬件）、系统软件变更（各类 OS 等）、应用软件变更（同 SRE）、安全设施（机房配套设施及安全防护设备）等一切对 IT 系统调整的动作。因此本白皮书将“发布”定义为“变更”的一部分，特指版本发布。发布管理是指整个软件开发周期中，软件从开发阶段转移到生产环境的过程。这个过程包括规划、调度、控制以及测试软件版本的构建、部署和交付。发布管理的重点是确保软件的新版本能够顺利、有效地发布，同时减少对现有系统运行的影响。在 SRE 领域，发布管理通常强调自动化部署流程，以减少人为错误，提高发布速度和可靠性。变更管理则

212、更加宽泛，涵盖了所有对生产环境可能造成影响的活动，包括软件更新、运行环境、配置修改等。变更管理的目标是确保所有变更都是经过计划、测试和批准的，从而最小化任何负面影响，确保系统的稳定性和可靠性。变更管理流程通常包括变更的申请、评估、批准和监控。190 网址：SRE-E 微信：SRE 精英联盟 关于两者的关系：发布管理是变更管理的一个子集：在 SRE 框架下，所有的软件发布都应视为变更，因此需要遵循变更管理的流程和原则。这意味着每一个软件发布都需要经过严格的审查和批准过程，以确保它不会对生产环境造成不可预见的负面影响。相互支持的目标：尽管两者的焦点不同，但发布管理和变更管理的最终目标都是提高服务的

213、稳定性和用户满意度。通过精细的发布管理，可以有效地推出新功能和修复，同时通过严格的变更管理可以确保这些发布不会导致服务中断或性能下降。共享的实践和工具：在实际操作中，SRE 团队会使用各种工具和实践来支持这两个过程，例如版本控制系统、自动化测试、持续集成和持续部署（CI/CD），以及监控和警报系统。这些工具和实践不仅支持快速安全的代码发布，也帮助团队管理复杂的变更。发布（Release），指将经过测试的、验证正确的软件版本（包括但不限于客户端、服务端程序，相关配置文件、数据等）导入到目的变更地点的行为。通过规范有效的发布管理流程，可以使发布实施更快，成本更优，风险更小，保障业务的稳定性和可用性

214、。发布管理（Release Management）的目标是确保所有线上生产环境的版本发布行为具备可控性和可追溯性，具体包括但不限于以下几个方面：191 网址：SRE-E 微信：SRE 精英联盟（1）合理定义发布计划，以确保对业务影响最小化，并降低风险。（2）确保发布到生产环境的版本统一，并经过必要的版本质量保证过程。（3）确保包含安装、测试、验证和回退等发布过程中的各个环节操作的规范性。（4）确保发布相关的利益干系人（如 SRE/研发/测试/产品/运营团队和用户等）的行动一致性。在国内业界的实践中，不同职责的团队所肩负的变更任务会不一样，例如，基础架构部门，云平台部门 SRE 更多的是进行基础

215、架构层面的变更管理，而业务 SRE 更多负责发布管理，所以以下的内容侧重点，差异性也会因此而出现。4.2 变更体系设计变更体系设计 4.2.1 变更体系设计原则变更体系设计原则 SRE 关注的核心是业务应用系统的稳定性，SRE 描述任何问题都是从软件工程的视角出发，围绕业务系统做出某方面调整改造，或者开发了某些管理系统。Google SRE 针对变更管理强调自动化操作的技术实践，包括渐进式发布、过程和结果的反馈/检测、回退等。4.1 中明确了在 SRE 视角下变更包含发布，发布特指代码变更，以及发布与变更在工程层面应该共享实践及工具，因此 SRE 变 192 网址：SRE-E 微信：SRE 精

216、英联盟 更体系设计的原则包括两点：严谨的变更流程以及通用的工程化体系。4.2.2 变更及发布流程设计变更及发布流程设计 4.2.2.14.2.2.1 变更发布变更发布准备准备 由于变更/发布涉及到产品、开发、测试和运营等多个职能团队的参与，因此在正式实施操作之前，必须进行一系列充分的事前准备工作。作为线上环境的第一责任人，SRE 在整个发布过程中担负着“总协调”的角色。在发布前，SRE 需要进行以下关键任务：1.审核变更发布产品功能和服务的可靠性。2.评估变更发布的风险，并制定相应的应对策略。3.选择合适的变更发布方式和方案，以最大程度降低影响。4.协调各职能团队完成相应的准备工作，确保协同合

217、作。5.主导制定具有可操作性的发布流程清单，确保流程的顺畅执行。6.预先制定针对各种可能的变更发布异常的快速执行应急预案，以确保对突发情况的迅速响应。（1 1）变更风险评估变更风险评估 变更风险评估是指在进行软件发布或系统变更前，对可能存在的风险进行评估和分析，以便在变更过程中及时采取措施来降低风险，确保变更的稳定性和可靠性。在业务全生命周期中，产品希望 193 网址：SRE-E 微信：SRE 精英联盟 在用户侧得到快速验证和反馈，这就要求每次的功能迭代都能快速发布到线上环境，而 SRE 围绕业务的性能和稳定性，更加关注线上环境的持续稳定运行，变更带来改变，改变带来风险，变更与稳定在某种程度上

218、存在冲突，因此，针对线上环境的每一次变更/发布（包括常规发布和紧急发布），引入风险评估环节变得尤为重要。由于变更概念较为宽泛，为使读者深入理解后续环节，本章节后续内容将以变更中最为重要的版本发布（代码变更）为例，介绍风险评估之后的环节。1版本发布容量风险评估 通常情况下，新功能的发布往往会带来临时用户访问量的急剧增长。因此，SRE 在执行发布之前需要做好容量风险的评估工作。为了做到这一点，一方面可以依据发布前压力测试的数据，结合运营数据模型（包括发布过程中和之后的流量及增速预测），提前准备足够的发布容量冗余，并尽量避开在业务高峰期进行发布；另一方面，可以选择将首次发布限制在某一单独区域的用户，

219、通过该区域的容量增长数据的分析，建立后续大规模发布时的信心和预期。2版本发布依赖风险评估 发布依赖风险评估主要包括基础设施、程序引用、下游依赖以及上游调用几个关键方面。在基础设施方面，涵盖计算、存储、网络等要素，需要确保相关基础设施负责人积极参与发布过程，进行全面的风险评估和制定相应预案。在程序引用方面，包含第三方类库、代码、数据等，必须避免偶发性故障、程序 Bug、系统错误或 194 网址：SRE-E 微信：SRE 精英联盟 安全问题对发布正确执行造成影响。对于下游依赖，应设定合理的超时时间，提前有效预估和沟通下游流量，防止对下游系统造成过度负担，确保强依赖变成弱依赖，同时高优先级应用不得依

220、赖低优先级应用。至于上游调用，需要明确各调用方的身份，根据不同优先级制定合适的分配、限流和熔断策略，以确保整体系统的稳定性和可用性。3版本发布异常风险评估 并非每次发布都能按计划如期完成，作为 SRE，我们需在发布前进行细致的异常风险评估，主要涉及发布延时、发布故障以及发布回退（包括程序、配置、数据回退）这三个方面，以应对潜在的不确定性。发布延时指的是由于停机发布实际所造成的停机时长超出原计划时长，或者由于热更新不停机发布新功能用户无法使用，从而对业务可用性产生不利影响。发布故障指的是在发布过程中人为操作不当或不可预知原因而引发的故障，例如文件、配置发布出错，主机、网络设备故障等。至于发布回退

221、，指的是在发布过程中发生无法正常推进的情况，导致线上环境的用户数据受到污染，必须将业务的程序、配置和数据回退到发布前的某一时刻。为确保系统的稳定性，我们必须在发布前充分评估这些异常风险，以准备好应对可能的挑战。4其它风险 在新功能上线初期，面临着业务竞争、无法控制的用户行为等因素引发的诸多风险，其中包括大量的 DDoS 攻击、客户端滥用行为 195 网址：SRE-E 微信：SRE 精英联盟 等。这种情况可能导致服务过载，甚至新功能的崩溃等问题。因此，SRE 在新功能发布上线之前需要通过有效的压力测试来规划业务应对这些挑战。最佳的做法是为新服务设计具备“功能开关”的机制，并灵活运用灰度和阶段性发

222、布的方法。通过详尽的压力测试，可以模拟和评估在真实环境中可能发生的各种情景，从而有效预测系统在高负载和攻击情况下的表现。同时，引入“功能开关”机制使得在遇到问题时可以迅速关闭或切换功能，以减轻系统负担。此外，采用灰度发布和阶段性发布的策略，可以逐步将新功能引入生产环境，降低潜在问题对整个系统的冲击，使问题的范围得到有效控制。通过这些规划和策略，SRE 能够更好地保障新功能的上线稳定性，降低因各类风险而导致的服务中断和性能问题的风险。效果评估：SRE 理念倡导拥抱风险，对于发布服务来讲，不可能做到 0 风险，发布的可靠性并不是一味的追求越高越好，因为极高的可靠性需要付出巨大的成本，与实际的回报不

223、成正比。在错误预算（Error Budget）的允许范围内，根据当次发布服务的具体情况，评估风险容忍度，并预留处理风险突发情况的时间。此外，在尽可能减少计划外停机时间（unplanned downtime）的基础上，寻找质量、效率、成本和安全之间的平衡点，是一种有效的发布风险评估方法。196 网址：SRE-E 微信：SRE 精英联盟（2 2）发布）发布方式确定方式确定 发布方式是软件开发和维护过程中采用的一系列策略和方法，旨在确保应用程序的性能、可靠性和可用性。SRE（Site Reliability Engineering）发布方式的核心目标是最小化应用程序停机时间和风险，并确保新版本应用程

224、序经过充分测试和验证，具备良好的性能和可靠性。典型的 SRE 发布方式涵盖蓝绿部署、金丝雀发布、滚动发布和灰度发布。此外，在发布过程中，还存在着多种具体的部署方式，如整包部署、增量部署和容器化部署，它们主要区别在于所采用的技术实现方式。零风险发布是 SRE 不断追求和实践的目标，为此有多种发布方式可供选择，以满足不同的发布需求。在选择 SRE 发布方式时，主要考虑以下几个方面：1基于应用程序的复杂性 在面对高复杂度的应用程序时，可能需要采用蓝绿部署或滚动发布等发布策略，以确保整体应用程序的连续可用性。蓝绿部署允许同时运行两个版本的应用程序，其中一个版本是当前稳定版本，而另一个版本则是待验证的新

225、版本。经过充分的测试和验证后，可以逐步将流量切换至新版本，直至完全替代旧版本。相较之下，滚动发布则以逐步更新应用程序不同部分的方式来保障整个应用程序的可用性。2基于可靠性需求 197 网址：SRE-E 微信：SRE 精英联盟 如果应用程序对可靠性要求很高，可能需要使用蓝绿部署、金丝雀发布或灰度发布等方式，以确保新版本应用程序的性能和可靠性得到充分测试和验证。金丝雀发布可以逐步增加新版本应用程序的流量，以测试其性能和可靠性。如果出现问题，可以立即回滚到旧版本。灰度发布可以将新版本应用程序的流量引导到一小部分用户，以测试其性能和可靠性。如果出现问题，可以立即回滚到旧版本。当应用程序对可靠性的要求极

226、高时，常常需要考虑采用蓝绿部署、金丝雀发布或灰度发布等发布策略，以确保新版本应用程序的性能和可靠性是经过充分测试和验证的。金丝雀发布允许逐步增加新版本应用程序的流量，从而评估其性能和可靠性。在发现问题的情况下，能够迅速回滚至旧版本，确保系统稳定性。另一方面，灰度发布则能够将新版本应用程序的流量引导至一小部分用户，以进行性能和可靠性测试。同样，在发现问题时，也能够立即回滚至旧版本，以最大程度地降低潜在影响。3基于 SRE 团队能力和经验 在团队经验不足或缺乏自动化工具支持的情况下，推荐选择更为简单的发布方式，例如滚动发布。滚动发布以逐步更新应用程序不同部分的方式确保整个应用程序持续可用。相较而言

227、，当团队拥有丰富经验和自动化工具支持时，可以考虑采用更为复杂的发布策略，如蓝绿部署、金丝雀发布或灰度发布。这些高级发布方式能够 198 网址：SRE-E 微信：SRE 精英联盟 更精细地控制新版本的推出，从而最大程度地保障系统的可用性和稳定性。4基于时间压力 在面临时间压力时，选择合适的发布方式至关重要，以确保应用程序更新的及时性不以牺牲质量为代价。滚动发布和灰度发布是在此类情况下推荐的策略，因为它们能够提供快速且连续的部署能力。滚动发布允许按计划逐步替换应用程序的旧版本，这种逐步更新的方法有助于维持应用程序的持续可用性，同时允许在必要时快速回滚。灰度发布则通过将新版本引入给一小部分用户，以实

228、现对新版本性能和可靠性的快速测试。这不仅加快了反馈获取的过程，还降低了潜在风险，因为任何问题都可以在影响扩大之前迅速被识别和解决。选择这些策略有助于团队在紧迫的时间框架内有效地推进项目，同时通过及时的反馈和验证确保新版本的性能和可靠性。这种灵活性在处理紧急部署或快速迭代时尤为重要，确保了即使在时间压力下，也能保持应用程序的稳定性和用户满意度。效果评估：SRE 发布方式的评估标准主要涵盖故障率、可重复性、回滚能力、时间效率以及用户满意度等多个方面。通过对这些关键指标的 199 网址：SRE-E 微信：SRE 精英联盟 综合考量，我们能够全面评估不同发布方式的优劣，并选择最为适宜的发布策略来有效地

229、管理应用程序的更新和维护。这一系统化的评估方法有助于深入理解各种发布方式在实践中的表现，从而为决策者提供明智的选择。通过对 SRE 发布方式的精准度量，我们能够更加精细地调整发布流程，以满足应用程序更新的需求，同时最大程度地确保系统的稳定性和性能。（3 3）发布协调发布协调 发布协调是 SRE 团队在软件发布全过程中协调各个团队、统筹推进各发布环节，以确保发布过程的顺利进行。每次业务上线发布都牵涉到产品、开发、测试、运营、市场等多个职能团队，其成功依赖于这些团队的紧密合作。由于 SRE 团队在日常工作中积累了丰富的产品知识、技术架构能力，并建立了良好的跨团队关系，使其成为最为适宜协调各团队的角

230、色。在发布前、发布中和发布后，SRE以全局视角统筹整个流程，引导团队构建可靠、可扩展、稳定且性能卓越的产品。（1）制定详细的发布计划，与开发团队和其他相关团队协商，明确发布时间、版本号等信息。借助功能发布上线日期，逆向规划代码提交截止时间、测试打包、发布前准备和发布停机时长等排期，并与所有相关团队成员确认方案和排期，输出发布电子流和工单。200 网址：SRE-E 微信：SRE 精英联盟（2）审核发布产品的新功能和内部服务，确保它们与原有业务的可靠性标准一致，并提供提升可靠性的具体建议。对于发布的业务模块，通过 SRE 技术手段检测和预防可能增加停机时间或妨碍性能目标的单点故障，制定高可用性和快

231、速灾难恢复方案。（3）在发布过程中作为多个团队之间的联系人，考虑当前发布的影响范围。可以迅速组建一个虚拟团队，联系相关职能人员，包括但不限于产品、运营、开发、测试人员，通过线上线下会议的沟通方式，持续检查发布版本所涉及的各团队工作进展。（4）跟进发布所需任务的进度，负责处理发布过程中的所有技术相关问题，包括但不限于构建发布自服务模型的平台工程，提升自动化程度，解决由资源不足引发的容量问题，以及通过服务降级处理过载的技术预案等。（5）作为发布全流程的“守门人”，决定所有发布项是否都是“安全的”，确保发布过程进入可控状态，降低发布失败率，缩短发布时间周期。效果评估：SRE 团队通过与其他团队（如开

232、发、测试团队等）的协调合作，以确保发布过程的顺利高效，并最大程度地减少对用户的影响。对其效果进行评估可从以下几个方面进行衡量：发布效率：通过协调发布流程，降低了团队间的沟通成本，缩短了相互等待的时间，提升了发布效率。201 网址：SRE-E 微信：SRE 精英联盟 发布稳定性：SRE 团队与其他团队协作，始终将业务稳定性视为首要衡量指标，确保发布版本在生产环境中稳定运行，减少故障和停机时间。发布质量：通过协调发布流程，SRE 团队能够保证发布版本的质量，涵盖代码、文档和测试等多个方面的质量保证。用户满意度：通过协调发布工作，最大程度地减少对用户的负面影响，包括减少停机时间、降低用户投诉数量，提

233、升用户体验，从而提高用户的满意度水平。（4 4）发布执行清单发布执行清单 发布执行清单是指在正式操作之前由业务 SRE 团队制定的详细清单，其中包含了软件或系统发布的所有步骤和操作。其主要目的在于确保发布操作流程的顺利和成功。该清单通常由业务 SRE 团队编写，并在发布过程中按照既定的操作方案进行实施。完善且准确的发布执行清单能够有效保障发布过程中避免由于人为操作导致的发布步骤缺失或执行不准确而引发的系统中断。（1）发布执行清单包含但不限于以下要素：a.各步骤的具体执行内容及预估耗时。详细的执行命令能够降低发布过程中人员操作失误的可能性，而预估耗时则有助于 SRE 发现执行步骤是否存在异常，并

234、评估发布总耗时。202 网址：SRE-E 微信：SRE 精英联盟 b.执行成功确认手段。清晰的执行成功确认手段有助于在发布过程中尽早发现系统中断，并增强发布过程中的信心，例如，通过观测请求量指标是否恢复到 7 天前的环比水平。c.操作回滚步骤。清单必须包括回滚步骤，以便应对发布过程中可能出现的问题和故障。d.测试与验证步骤，至少要包含新功能的测试与验证，以及用户关键链路的基础功能的测试。确保该次发布新增加的功能和关键链路的验证符合预期 e.发布操作人员协同，对于跨团队或多实施人员的发布，需要相关的实施人员要做到知会和协同，尤其是对于有前后顺序的步骤，需要前置步骤实施完毕并且结果符合预期后才能进

235、行后置步骤的实施。（2）发布执行清单按执行顺序分为发布前、发布中、发布后三个阶段。发布前的检查清单应关注于检测评估发布前置环境是否符合发布条件，发布中的执行检查清单则包括具体的发布变更操作，发布后的执行检查清单主要用于验证此次发布是否成功。（3）利用工具化模板将发布流程清单线上录入，通过可视化的图形界面进行任务流程编排和执行。采用插件对接与开发的方式，实现与发布操作所需工具和平台的调用，从而实现发布流程清单的跨系统调度自动化。这样可以减少发布过程中的人为切换等待时间，并降低人工操作的失误。203 网址：SRE-E 微信：SRE 精英联盟（4）发布清单应在团队中共享，以避免人员单点问题。在发布过

236、程中，应当在发布清单中记录发布执行起止时间、实施内容、实施人员等关键信息，作为后续发布流程回顾及优化的依据。效果评估：SRE 发布执行清单是一个旨在规范发布过程的详细清单，其目标在于确保发布过程的高效性和流畅性，以最小化故障和停机时间。对 SRE 发布清单的效果评估可以从以下几个方面考虑：发布速度：SRE 发布清单提供了一个标准化的发布流程，有助于团队更迅速地将新功能和问题修复版本发布到生产环境中，从而显著提高整体发布效率。发布稳定性：SRE 发布清单中涵盖了各种验证步骤，可在发布前进行充分的测试和验证，以确保发布的版本在生产环境中运行稳定。这一方法大幅减少了故障和停机时间，从而增强了系统的整

237、体稳定性。发布质量：SRE 发布清单中包括回归测试、性能测试等步骤，确保发布版本的高质量。通过这些措施，不仅提高了系统的整体质量，还提升了用户的满意度。（5 5）应急预案制定应急预案制定 发布应急预案是一项用于指导发布过程中处理紧急情况和发布事故的战略性计划。通常由专业的业务 SRE 团队编写并在发布过程中备用，旨在确保发布的系统在任何情况下都能保持安全和稳定。204 网址：SRE-E 微信：SRE 精英联盟 应急预案在发布工程中扮演着业务连续性管理的关键角色。即便在充分准备和严格执行的情况下，每次发布变更仍然存在不可预知或无法评估的风险，SRE 通常通过应急预案来应对这些挑战。在系统非预期中

238、断的情况下，SRE 可能面临巨大的压力，并且在短时间内难以全面了解业务系统的上下游状态。这种情况下，临时决策的恢复方案可能因未全面考虑而引入新问题。因此，为避免引发更严重的问题，SRE 有必要在发布前充分准备应急预案。制定发布应急预案的整体原则应遵循以下几个步骤：（1）明确应急预案范围和目标：详细列出此次发布应急预案的覆盖范围和应对目标，包括需要关注的模块、业务指标、观测手段、预案启动条件、实施方案以及实施后的预期表现。这样有助于协助 SRE 在发布过程中做出准确的判断和应急操作。（2）发布过程和完成后的监测：在发布过程和完成后，SRE应通过监测指标来判断是否发生了非预期状况，并确定是否需要启

239、动应急预案，以提前发现系统中断。（3）与发布协调步骤的联动：当出现超出预期的情况时，应快速组建故障团队，制定团队人员清单和分工计划，以缩短系统中断的恢复时间。SRE 发布的应急预案制定步骤如下：（1）确定应急预案的范围和目标：明确此次发布应急预案的覆盖范围和应对目标，包括哪些紧急情况需要应对，以及应急预案的主要目标是什么。同时，对可能发生的紧急情况进行分类和分 205 网址：SRE-E 微信：SRE 精英联盟 级，制定相应的应急响应计划，包括行动步骤、通信流程、资源调配等。（2）组建应急响应团队的成员和职责：确定应急响应团队的成员和职责，包括开发团队、测试团队、运维团队等。建立紧急联系方式，包

240、括电话、邮件、即时通讯等，以确保在紧急情况下能够及时联系。同时，需要定期组织团队审查和更新应急预案，以保持其有效性和适应性。（3）制定详细的应急预案内容：包含但不限于：a.预发布测试：在正式发布之前进行预发布测试，确保版本的稳定性和兼容性。b.限流措施预案：在版本发布期间采取限流措施，以避免系统过载和崩溃。c.监控和报警预案：加强监控和报警机制，及时检测和响应系统异常和故障。d.回滚计划预案：如果版本发布出现问题，立即启动回滚计划，将系统恢复到之前的稳定状态。（4）应急预案演练：根据应急预案制定应急演练计划，并进行演练，评估应急预案的有效性和实用性。效果评估：效果评估方面，可以从以下几个方面来

241、衡量：（1）有效性：应急预案是否能够有效地应对发布事故，包括是否能够快速响应、准确识别问题、及时采取措施、有效恢复等。206 网址：SRE-E 微信：SRE 精英联盟（2）可操作性：应急预案是否易于操作和使用，包括是否能够提供清晰的指导和说明、是否能够让发布操作人员快速掌握和操作、是否能够减少人为错误等。（3）可维护性：应急预案是否易于维护和更新，包括是否能够及时更新和修订、是否能够保持最新的技术和流程、是否能够在下一次的发布中继续复用等。4.2.2.24.2.2.2 版本发布版本发布实施实施 （1 1）发布前确认）发布前确认 发布准备是指在正式进行发布操作之前所需要操作的一系列步骤，以确保发

242、布流程的顺利和成功进行。在执行正式发布之前，SRE（Site Reliability Engineering）工程师需执行如下工作，但不限于：环境备份、制品预分发、告警屏蔽以及各项准备工作的最后确认。（1）发布流程确认。需要在发布前与相关干系人对齐整体发布内容，需要明确各项发布的时间及执行内容。（2）风险评估。需要对发布内容进行全面评估，以确定发布对现有系统的安全性、机器性能、环境依赖等是否会产生影响，通过风险评估可以避免在变更过程中出现无法回滚、安全漏洞等问题。（3）环境备份。在发布前，必须对系统的数据、配置以及业务程序进行备份，以确保在出现问题时能够快速恢复。数据备份范围 207 网址：S

243、RE-E 微信：SRE 精英联盟 包括但不限于业务数据库、文件系统等，而配置备份则包含业务配置文件、证书文件等。选择适当的备份方式（手动或自动备份），以确保备份的及时性和完整性。（4）制品预分发。制品预分发是指在发布前将需要更新的文件提前分发到目标服务器，以便在发布时能够快速更新。这一步骤有效缩短了发布时间，降低了发布过程中出现问题的风险。完成预分发后，需要进行验证，确保预分发的制品能够正确地更新到目标服务器上。（5）监控告警屏蔽。为防止发布停机时引发不必要的告警，SRE在前置工作中需要屏蔽部分监控告警指标，以防止告警风暴的发生。设置合理的屏蔽时长，并记录屏蔽监控指标的详细信息，包括指标名称、

244、屏蔽时间范围、屏蔽原因等。同时，需要避免屏蔽敏感指标或对系统安全性产生负面影响，以确保非发布模块的稳定性和安全性。（6）各项准备工作的最后确认。作为发布前准备工作的把关人，业务 SRE 需确认测试是否充分、发布环境是否准备就绪、备份和恢复是否有效、风险评估和应急预案是否充足、通知是否及时准确、发布执行清单是否完整清晰等相关事项。（7）效果评估。发布前置工作的效果可从以下几个方面考虑：发布成功率：衡量发布前置工作效果的重要指标之一是发布成功率。较高的发布成功率表示前置工作效果较好。208 网址：SRE-E 微信：SRE 精英联盟 发布耗时：另一个衡量效果的指标是发布时间。若前置工作充分，发布时间

245、应缩短，提高发布效率。问题处理速度：若出现问题，评估前置工作效果的一个指标是问题处理速度。充分的前置工作应该能够加速问题解决，减少系统故障时间。用户反馈：用户反馈是评估前置工作效果的另一个关键指标。不良的用户反馈表明前置工作未达到预期效果，需要进一步改进。（2 2）发布执行发布执行 发布执行是 SRE 团队负责执行一系列发布操作，包括停服、更新、起服等，以将新功能成功发布到线上正式环境并对用户开放。为确保每次业务新特性稳定上线，SRE 团队需制定可靠的发布执行规范和发布意外防范机制，以确保各类对象（如二进制程序、配置文件、数据库及依赖环境）以可重现、自动化的方式发布到业务生产环境。发布执行的主

246、要步骤包括：部署：执行部署脚本，将软件部署到指定目录。测试：在部署完成后进行功能、性能和安全等测试，以确保新版本正常运行。监控：通过监控告警手段监测发布后运行状态，及时发现并解决问题，保障系统稳定性和可靠性。209 网址：SRE-E 微信：SRE 精英联盟 回滚：如果出现问题，按照已制定的应急预案和操作流程，及时回滚到上一个版本。发布执行过程中还应包括以下内容，包括但不限于：自服务模型：SRE 发布工程师通过开发工具、制定最佳实践，使整个发布执行过程自动化，不再需要 SRE 工程师干预。研发团队或其他第三方人员可以自主掌握和执行发布操作，构建发布执行的自服务模型。发布操作的简单化：用户可见的功

247、能应尽快发布上线，以减少每个版本之间的变更。发布执行时应按小批次进行，易于理解每次发布对系统的影响。通过逐步改变系统，同时考虑每次变更对系统的改善和退化，寻找最佳方案。发布操作的标准化：统一运维操作入口，降低复杂度，提高可管理性。避免手工误操作，防范悲剧发生，将原本复杂易错的手工操作实现标准化运维，使运维操作更加可靠。同时，减少由运维人员手工误操作所带来的业务风险。发布执行的稳定性与灵活性：平衡稳定性和灵活性，通过构建通用发布流程、实践和工具，提高发布执行的可靠性。最小化发布执行流程和工具对开发人员灵活性的影响。最小化意外复杂度：SRE 团队需不断努力消除发布执行过程中的必要复杂度，发现并提出

248、抗议，以减少引入的意外复杂度。效果评估：对发布执行效果进行准确性、成功率和效率三个方面的评估：210 网址：SRE-E 微信：SRE 精英联盟（1）准确性：操作是否按照计划和目标进行，是否准确无误地完成了发布操作。（2）成功率：发布执行的成功率是否高，是否达到预期目标，是否影响了业务的稳定性和可用性。（3）效率：发布执行的效率是否高，是否在规定时间或提前完成任务。（3 3）发布验证发布验证 SRE 发布验证是指在软件发布后对已部署的软件进行验证和测试，以确保软件能够正常运行，并满足预期的功能和性能要求。发布验证贯穿于 SRE 的整个发布过程中，而不是仅仅存在于部署后。根据不同的发布计划，存在不

249、同的验证流程，其中包括但不限于以下几个方面：1稳定性验证 稳定性指系统要素在外界影响下表现出的某种稳定状态。对于应用程序而言，稳定性是保障系统能够满足 SLA（服务水平协议）所要求的服务等级协议的关键。在应用程序发布过程中，应持续关注关键的：基础指标、应用指标及业务指标。基础指标：所依赖的系统和基础设施层面的指标 例如：系统负载、内存容量、网卡流量 应用指标：能够反馈业务依赖的接口服务是否可用的指标 例如：请求速率、请求时延、请求成功率 211 网址：SRE-E 微信：SRE 精英联盟 业务指标：能直观的反馈业务或者系统功能是否可用的指标 例如：在线人数、订单量、评论量 确保应用程序能够以一个

250、安全的状态持续运行。如果观察到系统整体处于非稳定状态，应及时采取相应的应急措施，以将发布的影响降到最小。2确定性验证 应用程序的发布通常旨在修复缺陷或提供新特性，因此发布的结果应该是确定的。在发布过程中，对应用程序进行持续观察，只有在一个或多个周期内应用程序的运行状态符合预期，功能性或缺陷性的改动能够生效时，才能将发布视为有效。一旦发现应用程序在发布过程中出现了非预期的情况，应及时记录并评估是否需要继续发布，以规避风险。3依赖性验证 依赖性指系统中不同组件之间的相互依赖关系。一个复杂的系统通常由多个组件组成，系统中某个组件的变动可能对整体系统产生影响。在发布过程中，应关注与发布程序存在依赖关系

251、的其他组件的运行情况，以确保应用程序的改动不会对其他组件造成预期外的影响。最好在发布前对依赖组件的运行情况进行评估，尤其是对性能或时延要求较高的组件，以避免对业务造成雪崩效应。4效果评估 SRE 发布验证的效果可以从以下几个方面进行评估：212 网址：SRE-E 微信：SRE 精英联盟 发布验证的平均时间：衡量发布验证的平均时间，即发布验证开始到完成的时间。发布后的稳定性：衡量发布后系统的稳定性和可靠性。发布后的性能：衡量发布后系统的性能，包括响应时间、吞吐量、并发量等。发布后的用户满意度：衡量发布后用户的满意度，包括用户的反馈和投诉等。通过对这些标准的综合评估，可以优化发布验证的流程和方法，

252、提高系统的稳定性和可靠性。（4 4）应急预案实施应急预案实施 SRE 发布应急预案实施是指在软件系统发布过程中，对于突发紧急情况，SRE 团队采取一系列紧急措施以确保发布过程的稳定性和安全性。以下是 SRE 发布应急预案实施的详细步骤：（1）紧急通知：在出现紧急情况时，SRE 团队应立即通知相关人员，包括但不限于开发团队、测试团队和运维团队，以便共同制定应急方案。（2）应急方案选择：SRE 团队根据事先制定的应急方案，选择最适合情况的解决方案。这包括确定问题的性质和影响、采取的紧急措施、修复时间等关键因素。213 网址：SRE-E 微信：SRE 精英联盟（3）紧急回滚：在紧急情况下，如果发布过

253、程出现问题，SRE团队应立即执行回滚操作，将系统还原到之前的稳定版本，以最小化对用户的影响。（4）问题排查和解决：SRE 团队应立即进行问题排查，采取必要的措施来解决问题，以确保发布过程的稳定性和安全性。（5）事后总结：在问题解决后，SRE 团队应进行全面的事后总结。这包括对应急过程的分析，问题原因的详细剖析，以及提出改进措施，以便在下次发布中更有效地执行。通过 SRE 发布应急预案实施，团队能够迅速、有效地应对紧急情况，保障发布过程的稳定性和安全性，最终提升用户满意度。效果评估：发布应急预案实施的效果可以从以下几个方面进行评估：（1）预案执行情况：应急预案是否能够按照预定计划执行，是否能够应

254、对突发情况做出及时调整。（2）故障恢复时间：应急预案是否能够快速、有效地解决故障，缩短故障恢复时间，减少业务影响。（3）用户投诉数量。应急预案实施后，用户投诉数量是否下降，是否能够有效地保障用户的服务体验。（4）实施效益。应急预案是否在合理的成本下，能够限制发布故障的影响范围，最大限度地减少业务损失。214 网址：SRE-E 微信：SRE 精英联盟 通过对这些方面的全面评估，团队可以更好地了解 SRE 发布应急预案实施的实际效果，为未来的发布过程提供有针对性的改进建议。4.2.2.34.2.2.3 发布发布总结总结 SRE 发布总结是指在软件系统发布后，SRE 团队进行的一系列总结和评估活动，

255、旨在深入挖掘问题、总结宝贵经验，并提炼出切实可行的改进措施，以优化未来的发布过程。SRE 发布总结通常包括以下详尽步骤：（1）数据收集：收集涵盖发布过程各个方面的数据，其中包括但不限于发布时间、故障和停机时间、用户反馈等多维度信息。（2）数据分析：对所收集的数据进行深入分析，以明确识别发布过程中存在的问题和瓶颈，确保全面了解系统性能和用户体验。（3）经验总结：精炼并深度总结发布过程中所获得的经验和教训，包括成功实践的要点以及需要改进的方面，为未来的发布活动提供宝贵指导。（4）改进措施提出：根据对经验和教训的深入总结，明确提出一系列切实可行的改进措施，以不断提高发布过程的质量和效率。（5）改进实

256、施：将提炼出的改进措施有机地融入到发布计划中，并在下一次发布活动中有序实施，以确保团队在实践中持续演进。215 网址：SRE-E 微信：SRE 精英联盟 通过 SRE 发布总结，团队得以持续优化发布流程，提升发布效能和质量，有力保障业务的稳定性和可用性，最终为提高用户满意度奠定坚实基础。4.2.3 变更的工程体系设计变更的工程体系设计 为了减少因变更引发的故障，SRE 团队应通过软件工程体系设计一套通用的，可持续性的变更系统。4.2.3.1 4.2.3.1 面向变更管理的面向变更管理的 ITSMITSM 设计设计 ITSM 全称（Information Technology Service M

257、anagement）,面向变更管理的 ITSM 工单设计要以“变更流程管理，变更风险评估，变更窗口管理，变更自动化，变更知识库”作为核心的功能，从而确保更严谨、有效地实施变更操作。(1)(1)变更流程管理变更流程管理 ITSM 系统需提供变更流程管理的基础能力，以承载变更管理流程规范落地，其中包括：变更定义：支持变更流程负责人对变更管理的业务表单和工作流进行自定义。变更申请：支持变更申请人填写变更工单需求并提交变更申请。变更审核：支持变更复核人对变更内容进行复核及修订。216 网址：SRE-E 微信：SRE 精英联盟 变更审批：支持对变更申请进行审批，包括单人审批、多人会签审批、多级审批等。变

258、更实施：支持对变更实施的结果进行记录。(2)(2)变更风险评估变更风险评估 对变更的风险进行评估是变更管理中的重要一环，不同的变更风险级别会对应不同的变更管理策略。因此，ITSM 工具应该能辅助提升变更风险识别的准确度，减少因风险误判而引发的故障，包括：变更风险级别定义：支持风险级别自定义。变更风险评估规则：支持风险影响因子和风险计算规则的定义。变更影响面分析：支持与 CMDB 进行联动，获取变更直接影响或间接影响的资源对象，以分析本次变更可能影响的关联资源。变更资源保障分析：支持与存储资源系统，云资源系统等进行联动，以分析本次变更所需要的基本的硬件资源和人力资源。变更冲突检测：支持与人员工作

259、日程联动，提供可视化的变更事件“日历日程”，结合变更日程分析可能存在的冲突。217 网址：SRE-E 微信：SRE 精英联盟(3)(3)变更窗口管理变更窗口管理 变更窗口的定义是变更风险管控的重要手段，在影响较小的时间段实施变更，即使变更过程中出现异常也能将损失降低到最小。ITSM 工具需提供变更窗口维护和合规性检测的能力，包括：变更窗口维护：支持对可执行变更的时间段进行定义，以供变更申请时进行选择。变更窗口合规性检测：支持将变更实施的时间计划与变更窗口的定义进行联动校验，以确保不会出现实际变更实施在变更时间窗口之外的情况。(4)(4)变更自动化变更自动化 企业业务的敏捷、研发的敏捷都会导致运

260、维变更的频率增加，仅靠人工已难以满足变更效率的要求，不管是基础架构的变更还是应用版本的发布变更，都已经在寻求更高效的自动化执行工具。因此，ITSM 的变更管理能够与自动化工具便捷的集成也相当重要，复杂变更逐步抽象为多个低风险的标准变更，并将标准变更实现端到端的自动化。为实现与自动化的联动，ITSM 的设计应具备：1)第三方集成能力：支持如 API、脚本等系统集成方式，以获取自动化执行前所需的基础数据，或者合适的时机调用自动化动作。2)自动化流程节点：ITSM 的流程编排需支持自动化节点，以便于管理流和工程流之间衔接的编排。218 网址：SRE-E 微信：SRE 精英联盟(5)(5)变更知识库变

261、更知识库 知识库可以将过去的变更经验和知识进行整理和归类，在面临类似的变更需求时，可以用来学习培训，提供辅助决策，从而降低错误风险，减少重复工作，提高工作效率。知识库一定要进行分类整理，变更知识库要把“变更类型、变更原因、变更范围”作为主要的分类维度，再配合“关键字检索”的功能，就可以让变更知识库发挥重要的价值。变更类型：硬件变更、软件变更、配置变更、流程变更等 变更原因：故障修复、性能优化、功能增强、合规需求等 变更范围：单个系统内、多个系统等 4.2.3.2 4.2.3.2 面向变更管理的面向变更管理的 CMDBCMDB 设计设计 CMDB（Configuration Management

262、 Database，配置管理数据库）是一个存储 IT 基础设施中所有配置项（CI，Configuration Item）信息的数据库，包括硬件、软件、网络设备、服务等。CMDB 不仅存储配置项的属性信息，还存储配置项之间的关系。在变更实施过程中，CMDB 可以通过“配置模型、配置实例、场景联动”等能力，识别准确的“变更信息”，支持这些流程的运转、发挥配置信息的价值，帮助实施人员执行变更任务。219 网址：SRE-E 微信：SRE 精英联盟(1)(1)配置模型定义与管理配置模型定义与管理 1）模型管理：根据元数据之间的关联关系，将变更操作常用的一组数据定义为一个模型，比如主机模型，包括主机的名称

263、，操作系统，CPU，内存，磁盘，MAC 地址，CPU 架构，内网 IP，外网 IP，IPv4，IPv6，云主机实例 ID，云主机状态，创建时间，创建人，固资编号，设备 SN，主要维护人，备份维护人，所在省份，所属运营商，质保年限，SLA 级别，寻址方式等。按照这个方式，根据变更场景定义“业务模型，项目模型，交换机模型，负载均衡模型，防火墙模型”等。需要提供一个把这些元数据建立连接的“模型管理”的功能。2）模型关系：变更的配置数据之间，天然存在关系。使用“模型关系”定义模型之间是如何关联。要提供可视化的拖拽页面，通过关联关键字，在不同模型之间建立一对一，一对多的约束关系，所有实例支持无差异关联。

264、要提供关联关系的创建，删除。为了确保模型的基础功能，部分内置关联不可以删除和修改。220 网址：SRE-E 微信：SRE 精英联盟 (2)(2)配置元数据入库与消费配置元数据入库与消费 变更实施前，需要将与变更相关的配置项元数据录入 CMDB，包括网络设备、中间件、主机信息、虚拟化、流程信息、应用程序、维护人员、系统环境等，要支持批量录入、更新、导入等功能，支持通过 API、SNMP、日志分析等模式的自动发现入库元数据。变更发起后，周边系统可以通过订阅和推送的方式获取消费数据，不仅要做到消费数据的实时联动，还应该做到无缝连接运维体系，从而通过变更管理，实现 CMDB 配置数据的全生命周期管理。

265、221 网址：SRE-E 微信：SRE 精英联盟 1.资源入库：CMDB 的数据新增入库应支持与变更管理中的资源申请、应用投产等变更场景进行关联，在相应流程结束后，数据可自动新增录入 CMDB。2.资源变更：CMDB 的数据变更应支持与变更管理中的资源变更（如：主机扩容、设备迁移）、应用版本变更等变更场景进行关联，在相应流程结束后，数据可自动更新 CMDB。3.资源退库：CMDB 的数据变更应支持与变更管理中的资源退库（如：主机下线、设备报废）、应用下线等变更场景进行关联，在相应流程结束后，数据可自动更新 CMDB。支持更高效的变更管理流程是 CMDB 重要消费场景之一。变更管理流程主要是对

266、CMDB 中的数据信息进行查询消费，其中包括：222 网址：SRE-E 微信：SRE 精英联盟 1.配置项的基础信息查询：变更流程的发起环节，需要从 CMDB 获取变更对象相关的配置信息，以识别变更对象是否准确。因此，CMDB 工具的设计应考虑提供实例数据的信息查询接口。2.配置项的拓扑结构查询：变更流程的评估环节，需要从 CMDB 获取变更对象的关联信息，通过支撑、依赖、上下游等关联关系来识别变更的影响面，以辅助评估变更风险。因此，CMDB 工具的设计应考虑提供基于特定对象实例的拓扑结构信息查询接口。3.配置项的管理信息查询：变更流程的审批环节，需要通知对应的运维负责人。尤其针对重大变更，需

267、要组织变更的干系人一同进行审批。此时，需要从 CMDB 获取变更对象的组织、负责人等信息，以实现变更管理者进行准确的通知和会议组织。因此，CMDB的配置项模型设计应考虑管理信息字段的设计和维护。(3)(3)配置实例管理配置实例管理 1）支持配置实例的创建、更新和删除等能力，信息更新时，通过空值判断，长度校验，正则表达式等，确保数据准确。2）在变更发起时，要对实例进行准确的查询，支持全局查询，多维度联合查询，管理实例查询等。3）为了避免变更越权操作，所有的变更操作要按照角色，业务，实例，层级等多维护控制。4）提供操作审计的功能，对变更操作可以追溯，降低变更风险。223 网址：SRE-E 微信：S

268、RE 精英联盟 (4)CMDB(4)CMDB 与变更场景的联动与变更场景的联动 CMDB 的重要性上升，是因为不仅仅需要支撑变更管理流程更高效的运转，同时还需支撑后续的自动化变更执行。而自动化场景中，如何支撑好应用发布层面的变更是比较复杂的，CMDB 的模型设计需要重点考虑如何支撑好应用发布自动化的场景。CMDB 应用层的模型设计主要采用以业务为中心的设计理念，我们称之为“业务拓扑”：业务拓扑是对业务应用系统所提供的业务功能进行领域的划分，纵向来看，业务拓扑描述的是一个应用系统的划分规则，其最小颗粒度为单独对外提供服务能力的模块。224 网址：SRE-E 微信：SRE 精英联盟 第一、模块为业

269、务拓扑末端节点。模块在功能上对外提供独立的服务能力，在应用系统中为最小的组成部分，往下，与基础架构资源直接关联（中间件，主机，调用的数据库等）。第二、业务拓扑一般不要超过 3 层。超过三层的业务拓扑太深，容易出现管理上的混乱，不利于场景的消费和管理。第三、支持多环境管理。在应用从需求到发布的阶段中，需要在不同环境中进行进阶，开发环境，构建环境，测试环境，预发布环境，发布环境等。环境影响的不仅是基础架构资源的划分，还是影响应用配置的变动。不管是在 DevOps 还是 SRE 理论体系中，应用环境的管理都强调了其重要性。第四、支持多集群管理。这里的集群指的是分布式的集群。每个集群都对外提供相同的业

270、务服务，集群中包含着一个或多个模块。集群一般在互联网应用架构下出现的比较多，如：广东集群，广西集群。225 网址：SRE-E 微信：SRE 精英联盟 4.2.3.3 4.2.3.3 面向变更管理的作业平台设计面向变更管理的作业平台设计 变更是一个高频操作，作业平台（Job Platform）的目标是提供一个统一的软件工程体系，能够将变更中使用的“脚本执行，文件传输”等操作规范化，标准化，无需远程登录目标主机，就可以完成变更操作。通过这种设计，可以不断沉淀优秀的变更经验，为变更操作的自动化，与周边系统的联动，提供有力的功能保障。(1)(1)作业通道能力作业通道能力 设计一个先进的作业平台，首先在

271、底层需要有一个能面向海量、异构、跨区的 IT 基础架构的高性能、高可用、多功能化的作业通道能力。这些能力包括以下方面：1）任务服务。可以目标管控节点上的远程作业任务执行能力，如 Bash、Perl、Bat、PowerShel、Python、SQL 等。2）文件服务。提供文件快速传输能力，实现在不同的文件大小和节点规模下，动态调整组网策略以此达到最佳的文件传输效率，为业务提供高效稳定的底层文件传输服务。3）代理（Agent）。可以安装在业务需要管控的实体机、虚拟机或者容器里面，是任务执行和文件传输的实际执行者。代理还需要具备灵活的、可自定义的插件扩展功能，以支持通过 snmp、ipmi等各类协议

272、对各类 IT 设备或接口进行命令操作或数据获取。226 网址：SRE-E 微信：SRE 精英联盟 4）平台服务（Proxy 集群）。由于被管控的设备往往分散在各个网络区域，作业通道还需要支持在各个物理或虚拟网络区域部署高可用的 Proxy 集群，以实现高性能、高可用的跨区统一管控能力。(2)(2)变更脚本执行与变更文件分发变更脚本执行与变更文件分发 脚本执行和文件分发是作业平台最基本能力，工程化落地需要考虑以下几个方面：1）快速执行脚本能力。快速执行脚本提供的使用场景是针对需要快速执行的一次性任务，并且可能会反复调整脚本逻辑来执行得到用户想知道的结果，类似于在终端跳板机 Console 执行的

273、效果。脚本内容应支持手工录入和脚本库内容引用，并且支持各类的脚本语言；脚本需要支持传参，并且支持敏感参数的屏蔽；支持系统执行账号的指定或选择，并可支持执行超时等设置。2）快速文件分发能力。快速分发文件的目的也是为了让需要进行一次性传输文件的用户，可以快速的执行或调试并得到结果。除了基本的文件源地址与源目录、目标地址与目标目录的配置外，也应该支持传参、超时、执行账号选择等配置，还需要考虑分发的上传/下载限速以避免对生产网络造成业务影响。3）实例对象管理。作业平台是 SRE 体系下的一个能力模块，作业平台不应该维护一套独立的 IT 对象配置信息，而应该与 CMDB 进 227 网址：SRE-E 微

274、信：SRE 精英联盟 行对接，脚本执行与文件分发中的实例均应该来自于 CMDB 而不是在作业平台中单独维护。4）脚本库管理。脚本库是作业平台的重要资产，最常见的分类有两种，以 IT 对象类别以及场景类别，IT 对象包括从 IaaS 的硬件、网络、OS、虚拟化、容器等，到 PaaS 层的中间件、数据库、消息队列、缓存等，再到 SaaS 层的各类 Web 服务器，应用等。场景则是基于生命周期考虑的从资源交付、安全合规、巡检，到日常变更相关的启停、扩缩容、迁移、应急自动化、灾备切换、下线等操作场景。当然，脚本库的建设也需要考虑参数、版本、账号、调试等能力，这里不再一一赘述。5）文件管理。从场景上看文

275、件分发相关的场景包括软件安装、软件更新、配置文件更新、操作系统补丁下发等；从类型上看文件可简单分为二进制文件和可编辑的文档类配置文件。这两类文件有参数、版本、分类等通用的管理诉求，可编辑的配置文件还需要具备在线编辑、生产比对、KV 提取与发布的管理功能。(3)(3)变更作业模板与执行方案变更作业模板与执行方案 通过流程编排能力，将运维操作场景中涉及到的多个脚本执行或文件分发步骤组合成一个作业模板，这个作业模板尽可能把场景相关的共性逻辑都包含进去，然后再根据实际使用场景衍生出相应的执行方案，那么作业模板和执行方案的关系即为 一对多。228 网址：SRE-E 微信：SRE 精英联盟 1）作业模板。

276、作业模板需要具备基础信息、全局变量、作业步骤、作业编排四个基本能力。基础信息主要是描述作业模板名称、场景标签。全局变量需要支持字符串、命名空间、实例、加密字符串等类型。作业步骤需要支持执行脚本、文件分发、人工确认三种类型。作业编排则是可以将这些步骤进行串并行组合最终形成一个作业模板。2）执行方案。作业模板创建完后，即可以从模板中创建出一或多个根据场景需求定制的“执行方案”；每个执行方案可以从模板中勾选自己所需的步骤，修改全局变量的变量值。可以根据变更范围设置执行方案的策略和机制。滚动策略：按照百分比（10%，按每 10%台一批直至结束）或者具体的数值（10，按每 10 台一批直至结束）设置。滚

277、动机制：如执行失败则暂停、忽略失败，自动滚动下一批、不自动，每批次都人工确认。3）作业调度。作业执行方案可支持定时、立即开始、周期等多种调度能力。4）执行控制。作业执行过程中，根据业务需求需要提供相关的开始、暂停/恢复、终止/强制终止、人工确认等功能，并实时展示相关的运行状态。229 网址：SRE-E 微信：SRE 精英联盟(4)(4)变更操作安全变更操作安全(权限与审计权限与审计)1)高危语句拦截。作业平台应提供可自定义的高危语句自动检测与拦截功能，以避免高危变更命令操作对生产环境造成故障。2）权限管理。作业平台作为企业统一作业变更操作底座平台，需要具备足够细颗粒度、多维度、灵活适配各类组织

278、架构的权限设计，以保证安全的变更操作。从工程化落地的最佳实践讲，需要从整体 SRE 工程体系上进行权限中心的设计，作业平台的权限申请、审批、控制将由权限中心进行集中控制管理。3）作业审计。作业平台应提供所有通过页面执行、定时执行和 API 调用等渠道触发的任务历史查看记录以便于进行审计或在故障诊断中分析 IT 变更对故障的影响。4.2.3.4 4.2.3.4 面向变更管理的跨系统调度编排设计面向变更管理的跨系统调度编排设计 完整的变更过程，往往会涉及到对各个系统进行变更执行，例如变更前对监控告警策略的调整，变更过程完成对应用的更新和网络策略的变更，变更后进行全面的业务验证等。有些变更还需要考虑

279、多环境、多应用、多实例、多机房、多可用区的灰度变更流程设计，此时需要不仅是作业平台，还需要提供跨系统调度编排能力来实现变更全过程的自动化。230 网址：SRE-E 微信：SRE 精英联盟(1)(1)通用调度引擎通用调度引擎 通用调度引擎是整个跨系统调度编排设计的核心部分，它负责管理和调度不同系统之间的数据和业务流程，即就是变更的流程执行能力。在变更流程执行过程中，也要支持决策引擎和 FEEL 表达式解析器，让变更的操作流具备自动化的逻辑判断能力。流程引擎：可以解析，执行，调度由用户创建的流程任务，并提供如启动，暂停，继续，撤销，跳过，停止，强制失败，重试和重入等灵活的控制能力，支持立即、定时和

280、周期性启动的调度方式，支持并行、子流程等进阶特性，并可通过水平扩展来进一步提升任务的并发处理能力。决策引擎：基于 Python 的 DMN(Decision Model Notation)库，使用 FEEL(Friendly Enough Expression Language)作为描述语言，可以作为决策引擎，可用于流程引擎中分支网关条件表达式的解析，解决实际业务场景中的决策问题。流程调度引擎在设计的时候，可以分为任务执行层，资源管理层，编排和鉴权层。231 网址：SRE-E 微信：SRE 精英联盟 通用调度引擎需要具备并发处理能力、容错能力和可扩展性，以适应不同类型变更操作，如脚本执行、AP

281、I 调用、基于通用网络协议的变更操作等。(2)(2)编排能力编排能力 编排能力是将变更过程中各个系统的数据和业务流程进行有序组织和协调的能力。支持通过“可视化画布”的方式，拖拽变更流程中需要的节点，在变更流程中添加逻辑网关，如串行，并行，分支，汇聚，条件并行。支持嵌套编排，设置变更的子流程。提供基于流程即代码的自动化流程编排。变更流程节点中支持内置一些插件，这样制作一个变更流程将更高效。变更操作的基础插件：定时插件、HTTP 请求插件、发送通知插件、人工确认/暂停插件、审批插件、消息展示等。232 网址：SRE-E 微信：SRE 精英联盟 常用变更系统的插件：CMDB 的插件（删除主机，主机加

282、锁，修改主机服务状态，按照规则修改主机自定义属性，故障机替换，转移故障机至待回收/故障机/空闲机模块，批量更新主机/模块/集群属性，上交主机到资源池等），作业平台的插件（快速执行脚本，快速分发文件，获取任务日志等），ITSM 插件（更新变更日历，关闭变更工单等），监控插件（告警屏蔽插件，解除告警屏蔽插件等）。通过编排能力，在一个变更流程中，就可以编排多个系统的变更步骤，集中化地实现变更操作的自动化和批量处理。(3)(3)扩展插件市场扩展插件市场 当某个系统的变更操作过程较为复杂时，可以通过丰富的表单界面和验证逻辑将企业内部各个系统、各个平台的变更操作过程组装成一个标准插件模板，来实现体验更佳、

283、效率更高的调度编排能力。插件的开发需要具备完整的开发流程规范，包括高效的可视化低代码的开发方式、插件调试和快速发布能力。建设插件市场，要使用统一的、轻量化的插件开发框架（plugin-framework），开发者使用该框架进行插件开发，通过调用 233 网址：SRE-E 微信：SRE 精英联盟 plugin-framework 暴露出来的标准接口，完成系统插件功能的实现，并将其部署到变更管理的系统上，就可以使用插件的能力。一个插件在一次执行生命周期中可能会经过下图所示的状态转换，通过框架提供的方法，开发者可以在插件逻辑中进行任意合法的状态流转，以适配不同的业务变更场景。通用性的插件可以发布到“

284、插件市场”，共享插件资源。企业可以根据自身需求，从插件市场中选择合适的插件，以实现对不同系统的支持和扩展。234 网址：SRE-E 微信：SRE 精英联盟(4)(4)调度编排模板与任务调度编排模板与任务 编排后形成的流程称之为模板，模板应具备全局变量、版本管理、版本审批发布等功能。企业将一系列通用的变更操作和流程节点创建成调度编排模板。企业就可以快速构建和管理变更流程，提高变更管理的效率和准确性，降低变更风险。支持模版“创建，删除，更新”等管理功能，支持立即执行、定时执行、周期性执行的任务实例，支持“模板克隆”，“导入导出”等共享模版的功能，所有任务实例的执行记录均需要被保存，以便于搜索查看、

285、安全审计和运营分析。常用的低风险的变更操作，如针对测试环境的变更，可以将变更模版授权给非专业人员执行，即提供生成“轻模板，轻应用”的功能，限制模板的参数，生效范围等，将只能由运维/开发执行的变更操作，授权给测试/运营/策划等职能岗位使用。变更调度编排模板在跨系统调度编排设计中可以帮助企业快速实现特定场景下的变更操作。企业可以根据自身需求，选择合适的调度编排模板，并根据实际情况进行定制和优化。235 网址：SRE-E 微信：SRE 精英联盟 4.2.3.5 4.2.3.5 面向变更管理的微服务容器編排设计面向变更管理的微服务容器編排设计 随着业务发展，需要不断地对软件系统进行更新和优化，一些快速

286、迭代的业务场景逐步使用微服务的架构，就需要设计针对微服务架构的变更管理工程体系。(1)(1)微服务容器集群管理微服务容器集群管理 1)统一集群管理，纳管不同种类的 K8S 集群 在容器管理平台纳管不同来源的 K8S 集群，在业务持续建设过程中，在不同地域会综合考虑云厂商的能力、价格、以及业务特性，选择不同云厂商的容器服务。比如国内使用 TKE 和 ACK 容器服务，在海外使用 AWS 和 GCP 的容器服务。但业务是一个团队在维护，为了避免每个业务运维方都单独对接不同厂商的容器服务，额外增加适配和管理的成本。2)支持不同的集群管理模式 容器管理平台要能够支持不同的集群管理模式，来应对不同业务场

287、景需求。容器管理平台需要支持独立集群模式，以便特殊业务应用能够独享该集群资源，并提供对等的权限控制；对于自建独立集群需要提供配套的集群自动化运维方案；对于托管独立集群需要对接第三方管理平台。236 网址：SRE-E 微信：SRE 精英联盟 容器管理平台需要支持共享集群模式，在大型单个集群内提供基于 Namespace 级别或者 vCluster 级别的资源隔离能力，以应对业务在无需关心集群及节点资源情况下使用容器技术进行发布的场景。容器管理平台需要支持联邦集群模式。大型业务往往在分布式处理能力和容灾能力上有多地多中心部署的需求，容器管理平台需要提供联邦集群管理能力，便于业务像向单集群发布应用一

288、样向多集群发布应用。3)集群容量管理 容器管理平台在不同集群管理模式下，提供一致的容量管理方案。集群容量管理，能够实时查看集群容量，能够手动或者自动对集群进行扩缩容操作来满足容量设计要求。在集群容量管理自动工作时，应该具备按照一定的可配置策略，通过 CA 从节点池或者资源池获取节点，并自动加入对应集群，达成容量设计目标。4)统一对外暴露的 API 通过建设统一的容器管理平台，对外暴露统一的集群管理 API接口，对业务方屏蔽底层的 K8s 集群版本和厂商差异。同一个资源在不同的 K8s 版本中 APIVersion 是不一样的，为了规避发布业务方做持续适配，或者让第三方业务系统消费时单独适配，容

289、器管理平台需要适配差异，对外提供统一的 API 服务。5)表单化的集群资源管理能力 237 网址：SRE-E 微信：SRE 精英联盟 在不同集群模式下，对 K8s 集群提供表单化管理能力，能够对 权限范围内的 Node、Cluster、NodePool 等资源进行统一管理。能够实时查看权限范围内的集群状态、资源用量、CPU 利用率、装箱率、节点列表等基础信息；能够通过页面对权限范围内的集群进行增删改查。(2)(2)微服务应用部署及变更微服务应用部署及变更 1)管理微服务应用部署及变更配置和流程 以表单模式和 YAML 模式构建容器应用部署配置，包括但不限于编排 Deployment、State

290、fulSet、Service、ConfigMap 等资源对象。表单编排模式，是将 YAML 文件中的重要变量和常用变量抽取出来，做成让用户选择的表单，降低运维工程师使用门槛。表单模式的局限性在于，不是所有的容器配置都会支持在表单中支持，因此也需要支持以原 YAML 文件方式去编排容器应用，支持用户导入 YAML 文件，从 K8s 直接同步 YAML 文件等方式。不论是表单模式还是直接编辑 YAML 文件，均应提供不同部署及变更配置的版本管理能力，并支持不同版本间的比对、升级、回退。微服务应用的发布变更应该支持通过任务模板，创建多个步骤/节点执行微服务发布任务。发布任务模板中可以编排容器发布节点

291、，不同容器发布节点支持串行发布、并行发布等方式。针对微服 238 网址：SRE-E 微信：SRE 精英联盟 务场景，每次版本发布要灵活发布业务系统中的不同服务，因此节点需要支持灵活的开关，满足微服务特性要求。2)支持多样化的应用部署及变更方式 不同业务形态下，应用的特性有很大差异。容器管理平台应该具备多样化的编排调度能力，来支持不同类型应用的部署和变更。支持无状态应用的部署和变更。支持通过 K8s 原生 Deployment方式或者其他扩展 CRD 的方式，支持无状态应用的部署和变更，并提供过程可视化和结果的实时反馈。对有状态服务的支持。有状态应用往往是业务中的核心服务或者特殊服务，在业务系统

292、中往往具有重要的价值，容器管理平台应当通过扩展 CRD 方式对有状态服务提供更贴近真实场景的部署和变更能力。这些能力应该包括但不限于以下方面：a)容器原地更新能力；b)支持变更前置或后置处理；c)支持按照一定的步骤或者顺序完成部署或变更；d)支持部署或变更交互式过程控制；不管是无状态服务还是有状态服务，容器管理平台应该能够使用上述能力，依据用户设定的方式来动态调整应用实例个数来达成应用容量设定。当满足扩容条件时，自动拉起新的服务实例；满足缩容条件时，能够按照一定策略驱逐容器，并缩容容器实例，以达成应用容量设定目标，并兼顾减少碎片和装箱率要求。239 网址：SRE-E 微信：SRE 精英联盟 微

293、服务业务部署和变更，在灰度策略上有更灵活的选择。容器管理平台应该实现这些灰度策略，并管理灰度过程，以确保业务部署和变更的顺利。这些灰度策略，包括但不限于以下种类：滚动升级、蓝绿发布、金丝雀发布。在进行灰度变更时，能通过南北向流量调配来控制灰度过程。3)容器应用状态管理 容器管理平台提供页面，展示 Namespace、Workload、Pod、Container 级别的状态数据，使得用户能够以直观方式实时查看应用运行状况。除此之外，K8s 提供的 Service，以及其他自定义控制器，可能提供横向维度的映射关系，在应用状态管理页面，也需要对这类映射关系进行展示。在实际 SRE 工作中，往往同时涵

294、盖传统物理机、VM 和容器，为便于统一管理，在 CMDB 中需要维护容器应用拓扑关系，以及容器与母机的映射关系。在 CMDB 中的容器应用拓扑关系，可以精确到 Pod级别，以便于精确维护不同资源间的关系。240 网址：SRE-E 微信：SRE 精英联盟(3)(3)微服务容器的可观测微服务容器的可观测 微服务容器在变更时的，支持查看容器服务相关的事件、日志、监控。会调用 API 实时拉取事件和日志，采集监控数据，查看容器资源对应的详细监控数据。查看容器发布状态：会调用 K8s 接口查询容器资源的状态，比如 deployment 是否处于 running 状态，副本数是否符合预期 查看容器发布事件

295、：会调用 K8s 接口查询容器资源的事件，pod调度到哪个节点，镜像拉取成功，pod 启动成功等事件记录 查看容器发布日志：容器变更之后，运行中会产生容器日志，查看容器标准输出日志中是否存在较多 error 字段 查看容器发布监控：容器变更之后查看容器的 CPU、内存、网络等指标监控是否正常。4.2.3.6 4.2.3.6 面向变更管理的可观测设计面向变更管理的可观测设计 变更是导致生产故障的主要原因，因此在变更执行过程中，实时观测并感知因变更触发的各种业务异常如告警、故障等事件，是变更执行者主动并及时解决问题，降低故障影响半径的有效方式之一。为了实现变更的可观测性，需要具备以下几个能力：1.

296、变更影响分析：实时感知变更对系统或服务的影响，需先建立系统的依赖关系，包括业务依赖关系、应用调用关系和资源关联关系。业务依赖关系指变更对象与周边业务服务的依 241 网址：SRE-E 微信：SRE 精英联盟 赖关系；应用调用关系是指微服务之间的调用关系；资源关联关系则涵盖数据库、虚拟机、物理机等资源的关联。有了这些依赖关系，可以在变更过程中对变更对象及其关联对象进行观测，实时感知生产业务运行状态。2.全栈可观测：建设基于 Trace、Metric、Log 的可观测能力，并将这些能力与变更影响分析结合，实现对变更相关对象在变更过程中的全面可观测。3.灰度验证：变更通常以灰度方式进行，结合自动化验

297、证确保每批次变更无异常后再进行下一批次变更。根据不同业务与应用特征，可设计不同的批次变更时间间隔。4.流量闭环：全链路灰度是一种在微服务架构中实现应用版本平滑发布的技术。它不仅需要在网关处做灰度策略，还需要在微服务调用之间实现灰度。通过观测系统，我们应该能观测到在进行全链路灰度时，相关的流量在相应的泳道内闭环，不产生逃逸。而相关实现上，需要使用到链路跟踪数据。5.版本质量对比：通过观测手段，分析应用版本在性能、可用性、用户体验等方面的数据对比，以持续改进 CI/CD 链条质量。6.变更运营分析：从组织、对象、运维场景等多个方面对变更的成功率和服务质量进行统计分析，发现变更脆弱或问题环节并持续改

298、进优化。242 网址：SRE-E 微信：SRE 精英联盟 变更流程中，通常会采取研发/SRE/运维人员盯盘监控的方式进行业务分批变更及发布上线，这样可以在业务出现变更故障时，及时发现并由 SRE 进行业务止血操作或回滚，防止变更引入的风险进一步扩大，从而影响大量用户。以下是几个重要的监控指标，需要关注：1.SLO（Service Level Objective）指标：定义和监控 SLO，明确服务的目标水平（如响应时间、可用性等），并在变更过程中实时监控这些指标，确保服务质量不下降。2.RED（Rate,Errors,Duration）指标：请求速率（Rate）：监控每秒处理的请求数量，确保变更

299、不会导致请求速率异常波动。错误率（Errors）：监控请求的错误率，及时发现并处理变更引入的错误。请求持续时间（Duration）：监控请求的响应时间，确保变更不会导致响应时间显著增加。3.核心业务指标：业务关键性能指标（KPIs）：根据具体业务，定义和监控关键性能指标，如交易成功率、用户登录成功率、购买成功率等。用户行为指标：监控用户行为，如页面访问量、点击率等，评估变更对用户体验的影响。243 网址：SRE-E 微信：SRE 精英联盟 4.错误日志比例和数量：日志收集和分析：集中收集变更前后的错误日志，分析错误类型和数量，及时发现和解决问题。特别要提醒的是，除了在变更时需要监控数据外，在回

300、滚后的验证场景也需要进行密切的观测，以确保系统恢复到预期状态。4.3 变更管理案例变更管理案例 4.3.1 B 站变更防控的设计与实践站变更防控的设计与实践 SRE EliteSRE Elite 收录点评收录点评 该平台利用了 trace 和 CMDB 资源拓扑信息，以关联和聚合应用服务的变更，能够追踪并识别变更对整个服务生态系统的潜在影响，有助于提高故障排查的效率和准确性。在企业内不同部门存在多套发布变更系统，且短期难以推倒统一重建的情况下，从变更防控的视角，补充建设防控平台，通过统一模型、熔断控制等方式，实现自动化的集中式变更管控。（一）背景及设计原则（一）背景及设计原则 目前，在 SRE

301、 的业界，对变更的重视程度已然达到了顶峰。在实践过程中，基本上是围绕变更方案评审，变更发起前控制（重大 244 网址：SRE-E 微信：SRE 精英联盟 活动/节假日等关键时间控制），变更事件记录这些开展变更管理工作。这种做法应对传统的 IT 架构是足够的，但是在目前围绕云原生+微服务的这套复杂技术体系来看，存在着诸多问题，诸如：评审围绕流程驱动，在评审环节依靠人的经验来确保方案的正确性，过于依赖经验并难以持续保证效果 由于资源的稀缺性，难以确保每个变更都能够纳入评审，仅能覆盖部门高优重保的大型变更计划 评审行为仅能约束变更的发起，无法保障变更执行过程按照要求切实有效执行，比如强制分区灰度要求

302、，强制观察时间要求等 基于人操作的变更和平台操作的变更，围绕技术平台的基础设施和业务平台的配置变更，散落在各个地方，各自对于变更用了各自的流程定义和描述，难以收归一起管理和分析 单纯的变更记录，难以支撑当下复杂场景下由某个边缘变更、底层变更导致的级联故障定位 由于缺乏完整的变更管控技术框架，难以实现公司内部所有变更的平台托管，即无法知晓到底存在多少变更行为，哪些地方会发起变更，每次变更具体是变了什么东西，变更影响具体影响了什么对象和范围等 面对以上诸多局限，秉承技术问题还需要技术解法的原则，将变更作为一个独立的技术域，抽象和定义了变更的对象概念，规划和设计了变更管控技术框架，围绕这个框架打通从

303、变更元信息定 245 网址：SRE-E 微信：SRE 精英联盟 义、变更平台/场景接入、变更防控到变更分析的全流程链路，来实现变更的一体化和多层次管控。（二）体系设计详情（二）体系设计详情 B 站的变更防控方案基于行业最佳实践，构建了工程化的变更管控体系。通过标准化描述模型和过程模型、分层策略、全方位托管、灵活感知、准入准出检查和熔断机制，实现高效变更管理和价值挖掘。（1 1）变更定义）变更定义 统一变更描述模型 针对不同角色对变更的理解以及不同业务部门在语义的定义上是一定存在差异的。在 B 站，应用变更、配置变更和基础设施变更分别由不同平台承载。由于这几种变更场景对变更信息的定义存在差异，因

304、此实现不同类型变更统一管控的目标需要抽象出一个通用的变更信息模型。这个通用的变更信息模型将会作为一个中介层，跨越各种平台和部门，以统一的方式描述和定义变更信息，确保所有参与变更的个体和系统都有共通的理解和认知，从而提高变更管理的效率和准确性。变更描述模型应包含以下基本信息和管控信息作为元数据：246 网址：SRE-E 微信：SRE 精英联盟 基本信息 变更来源：用以标识具体的变更平台和平台唯一标识 变更对象：包括变更对象类型(应用/数据库/服务器等)和变更对象唯一标识 变更时间：变更具体执行的时间 变更人员：变更实际的操作人 变更环境：变更所生效的环境，比如 UAT/PRE/PROD 等 变更

305、内容描述：对变更操作的详细描述，包括 Release Notes 和详情描述，对于传达变更目的和实施细节非常重要。管控信息 变更目标：即期望通过变更来达成的目的，包括日常迭代、BUG 修复、故障处理等;变更场景：指具体的变更动作，包括迭代发布、配置发布、服务器上下线等;变更范围：即变更在线上环境的生效范围，包括机器分批生效模式以及流量比例分批生效等;变更影响：指本次变更影响的服务和基础设施 标准化的信息模型使得后续的变更感知、变更预检、变更防御以及变更审计等操作都能够基于统一的信息结构进行，有助于降低管理复杂性，提高协同效率。此外，对于其他技术风险领域的能力 247 网址：SRE-E 微信：S

306、RE 精英联盟 建设，这个模型也为故障定位、根因分析等方面提供了通用的数据结构和框架。统一变更过程模型 统一变更过程模型旨在提供标准化方法，以一致的方式描述和管理从提出到实施的整个变更生命周期。这个模型通常包括以下几个关键组成部分：一个变更的生效往往是基于一定范围和流程的，因此我们需要围绕这个过程进行变更流模型的定义。通过流模型定义，我们可以抽象出两类基本的变更流模型，分别适用于逐步生效的变更和无法拆分的变更：1、无法拆分的变更流模型：即一次性生效模型，适用于某些无法拆分或拆分成本较高的变更场景，例如 DB 配置类型变更。在这种模型下，变更控制防御能力主要集中在配置变更前后。2、逐步生效的变更

307、流模型：248 网址：SRE-E 微信：SRE 精英联盟 按机器分批生效：将变更分为若干批次，在每个批次中逐步将变更应用到不同的机器上。这种方式允许在不同的批次上实施更多的风险管控，以便更精细地监控和评估变更对系统的影响。按流量比例分批生效：允许按照预定的流量比例逐步引导用户访问到经过变更的系统。这种方式同样可以在不同阶段上实施风险控制，适用于需要更细粒度控制用户流量的情况。3、变更等级分层 变更等级分层策略根据潜在影响、风险和重要性将变更分级，以便更精确地控制和管理变更过程。这样的分层策略有助于组织更加精确地控制和管理变更过程，确保关键系统和应用的稳定性和可靠性。等级 含义 数量 生命周期定

308、义 使用场景 G0 仅 做 事 件 同步，无 管 控能力 一个 仅有一个事件同步节点 适用于无任何风险的变更，但数据需要提供给相关人员做检索、审计等场景 249 网址：SRE-E 微信：SRE 精英联盟 G1 仅 做 单 节 点的 变 更 前 后切面管控 一个 生命周期中仅有一个变更节点 适用于低风险变更，无需复杂风险管控能力，仅做事前准入性和事后完整性检查的场景 G2 有 完 整 的 变更 工 单，且工 单 下 关 联了至少 1 个批次的子节点 多个 生命周期分为四个阶段(工单开 始 各批次节点开 始 各批次节点结 束 工单结束)适用于多数逐步 生 效 的 变更，并需要配套进行风险管控的场景

309、 G3 在 完 整的 变 更 工 单感 知 基 础上，增 加 了变 更 提 单 阶段感知 多个 生 命周期在 G2等级的基础上，前置增加了变更提单阶段 G4 在 变 更提 单 感 知 的基 础 上，增加 变 更 无 人值 守 的 决 策能力 多个 生 命周期在 G3等级的基础上，变更提单后增加无人适用于需要系统进行无人值守代理执行变更的场景 250 网址：SRE-E 微信：SRE 精英联盟 值守决策阶段 以上某组织变更参考标准 每个管控等级的变更场景在满足前一级别的基础之上衍生出更多的变更要求和管控切面。基于标准的变更信息模型以及变更等级，我们就可以将变更管控单独抽离出来,在不同的平台业务上构

310、建统一的变更管控平台,使得 SRE 团队能够更专注于变更的风险防控与治理,同时平台业务团队更专注于平台研发本身。（2 2）变更管控平台架构设计）变更管控平台架构设计 变更管控平台面向不同用户提供丰富的功能，包括面向研发和SRE 的变更信息感知、检索和订阅，以及面向平台方提供的变更场景接入、托管等能力。以下是对每个功能的具体描述：251 网址：SRE-E 微信：SRE 精英联盟 变更信息接入：变更信息接入：通过标准变更信息模型，对整个变更场景进行完整定义，确保变更场景的一致性和可管理性。支持对变更场景的全生命周期进行编排，包括计划、执行、监控和反馈，提高变更管控的可追溯性和效率。变更信息感知：变

311、更信息感知：覆盖范围广泛，平台涵盖了服务器、网络、数据库、中间件、Pass、系统发布、系统配置、业务数据等多个领域的变更信息。提供变更搜索、变更订阅、影响面分析等功能，使用户能够快速准确地获取关于变更的信息。变更过程防控：变更过程防控：根据变更管控等级和防御能力，实现对变更风险的发现和阻断。提供灵活的变更防控策略，确保对不同等级的变更采用适当的防控手段。变更过程分析：变更过程分析：通过深入分析变更实施的各个环节，及时发现潜在隐患，优化变更策略，确保变更的顺利进行和业务稳定。变更结果度量：变更结果度量：通过对变更防控效果进行度量，包括场景覆盖率、风险检测质量、变更阻断准确率、变更防御执行效率等方

312、面的指标。通过分析结果，持续提高变更防控的各项指标，优化防控策略和执行效率。通过这些功能，变更管控平台不仅提供了全面的变更信息管理和感知能力，还支持对变更场景的标准化托管和灵活的防控策略。同时，通过变更分析功能，平台能够持续优化变更防控效果，提高整体的变更管理水平。252 网址：SRE-E 微信：SRE 精英联盟(3)(3)变更平台变更平台/场景接入场景接入 变更场景是整个变更管控的核心概念之一，因为所有管控动作都是基于变更场景的，这里也可以理解为变更的作用域。平台层面的接入情况，主要是元信息的录入和描述过程。在技术层面，我们主要将一个变更场景整体做了如下定义：253 网址：SRE-E 微信：

313、SRE 精英联盟 可以看到变更场景定义了一类变更，包括归属的变更平台，操作的变更资源，管控时所需的基础信息 Schema 和管控信息 Schema以及检查项等。每一个变更都基于具体的变更场景进行实例化，执行变更场景定义的管控动作和信息交互。因此,进行变更管控的第一件事就是定义需要管控的变更场景，变更源平台在接入自身平台后需要在 ChangePilot 上托管自身的变更场景后才能进行实际的变更管控。254 网址：SRE-E 微信：SRE 精英联盟(4)(4)变更元信息托管变更元信息托管 实现变更过程的精细化拆分，拆分前后阶段，拆分批次，拆分批次前后阶段等 基于变更单、批次单的前后阶段增加切面的检

314、查项能力嵌入 通过检查项实现过程的检测和干预 （5 5）变更感知）变更感知 围绕全域变更信息的整合，系统构建了分词与关联机制，通过多元化的检索与触达手段，以实现人与系统间变更信息的灵活流通。变更检索变更检索 255 网址：SRE-E 微信：SRE 精英联盟 在变更检索方面，系统设定了多种场景，包括针对单一对象或平台的时间跨度搜索，以及针对单人变更行为的搜索。检索场景检索场景 围绕单一对象的时间跨度搜索 围绕单一平台的时间跨度搜索 围绕单变更人的变更行为搜索 检索的维度涵盖了变更标题和变更状态的修改，变更的源平台、对象和环境，以及操作人员和影响范围。检索检索纬度纬度 变更标题、变更状态 变更源平

315、台、变更对象、环境 操作人、影响范围 （6 6）变更防控）变更防控 防控技术方案 变更防控方面，系统依托于变更流模型，实现了链式执行，并通过设置检查项进行准入准出。256 网址：SRE-E 微信：SRE 精英联盟 执行策略包括观察者模式和执法者模式，以及阻断变更过程、预警提示异常、升级审批阻断变更过程等防控策略。系统还建立了熔断机制，以应对变更系统请求失败的情况。通过以上的设计，达成了变更防控的技术方案。防控能力概述 变更系统的防控能力包括通用检查项如封网拦截、SLO 检查、批次检查、环境监察等，以及自定义检查项如安全扫描、业务代码发布 SOP 等。这些检查项旨在防止不符合标准的变更进入生产环

316、境。举例一，有业务进行灰度变更之后，SLO 迅速下降，这个时候系统就会进行拦截，阻止业务继续进行发布，避免导致更大的故 257 网址：SRE-E 微信：SRE 精英联盟 障。另外，可能的场景包括，批次检查避免用户不进行任何的灰度等。举例二，安全团队，希望对发到线上的制品包有一个安全扫描，则可以使用构建自定义检查项，避免有安全风险的制品流入到生产环境中。技术交互模式 258 网址：SRE-E 微信：SRE 精英联盟 259 网址：SRE-E 微信：SRE 精英联盟（7 7）变更价值挖掘与可视变更价值挖掘与可视 通过多维度视角对变更数据进行挖掘，以发现风险点，明确优先级，并可视化项目价值。运营面板

317、和检查项面板为团队提供了实时的数据视图。260 网址：SRE-E 微信：SRE 精英联盟 运营面板 检查项面板 （8 8）开放能力开放能力 开放能力包括全量或按纬度的变更消息投递，便于让上下游系统对变更相关消息进行记录并消费。例如，可以与监控系统或审计系统进行联动。261 网址：SRE-E 微信：SRE 精英联盟 1.变更订阅 订阅服务允许用户根据服务、业务、组织等多维度进行订阅，包括自身变更、上下游变更，以及变更的平台和场景。触达机制涵盖个人、群组、webhook 等多种方式。2.变更分析 通过对变更故障的深入分析，我们发现很大一部分异常并非源自本服务的变更，而是由上下游依赖或更基础的设施变

318、更所引起 262 网址：SRE-E 微信：SRE 精英联盟 的。为了解决这一挑战，ChangePilot 利用了 trace 和 CMDB 资源拓扑信息，以关联和聚合应用服务的变更。具体而言，我们利用 trace 分析获取了应用服务的上下游关系，同时通过 CMDB 资源拓扑信息分析得到了应用服务所管理的资源架构，包括存储层（如数据库集群、缓存集群等）、计算层（包括容器、物理机实例）以及网关层等关键资源信息。随后，通过统一的资源标识符进行检索，我们能够有效地聚合变更信息。这种方法使我们能够更全面地了解应用服务的生态系统，包括其上下游关系和底层资源架构。通过整合这些信息，ChangePilot能够

319、追踪并识别变更对整个服务生态系统的潜在影响。这不仅有助于准确定位变更引起的异常，还提供了更深层次的可视化和理解，有助于提高故障排查的效率和准确性。263 网址：SRE-E 微信：SRE 精英联盟 264 网址：SRE-E 微信：SRE 精英联盟 （三）总结及展望（三）总结及展望 经验教训 265 网址：SRE-E 微信：SRE 精英联盟 在变更管理的实践中，我们总结出了五个关键日拱一卒的经验教训：充分设计、找准切入、兼顾效率、保持效用。以下是针对这些教训的优化建议：充分设计：在实施变更管理前，必须进行彻底的规划和设计。这意味着需要确保变更设计的可持续性和兼容性，避免频繁修改导致合作方的抵触。设

320、计阶段应考虑软件的建模标准，确保内部逻辑的变更不会影响外部接口。找准切入：在变更管理的初期实施阶段，应选取高频且容易出错的场景作为切入点，以此构建成功案例并推广。中期阶段，将成功模式推广到整个组织，包括低频但高风险的变更场景。通过展示数据驱动的成效，增强变更方案的吸引力。兼顾效率：在变更过程中，确保不过度干预日常业务和开发工作。通过设置如绿色通道和白名单等机制，优化变更流程，减少对业务运行的影响。其中，绿色通道，主要用于快速止损，仅豁免 1 个小时，即开即生效。而白名单主要用于长时间豁免管控规则，一般用于活动期间的保障场景下一旦出现问题需要快速止损的情况，需要事前提交申请，并审批通过。保持效用

321、：变更管理应注重实际效用而非理论上的改进。避免过度设计检查项，应聚焦于实际需要，确保变更控制的举措既有效又实用。同时，防止在没有明确需求的情况下引入不必要的变更。266 网址：SRE-E 微信：SRE 精英联盟 日拱一卒：持续的投入和改进是确保变更管理成功的关键。应建立长期的变更管理机制，将变更管理的标准和实践融入日常操作，逐步培养组织内对变更管理的认可和依赖。未来展望 愿景：实现 B 站变更防控体系的充分性、高效率和有效性。持续保稳提效，在复杂多变的业务情形下借助数据&智能建立可持续的变更防控机制。4.3.2 携程云平台基础设施变更管理实践携程云平台基础设施变更管理实践 SRE EliteS

322、RE Elite 收录点评收录点评 1，这是一个由混合云 SRE 团队提供的案例，作为基础设施质量的把控者，对变更的计划性和标准作业流程要求严格，对于企业内私有云 SRE 管理团队有一定的参考价值。267 网址：SRE-E 微信：SRE 精英联盟 2，大量使用了 IaC 的方式对基础架构进行管理及变更，其中使用 SaltStack 和 StackStorm 管理配置变更，使用 Kustomize 和Git Workflow 管理多个集群和环境的基础组件配置文件，对公有云资源使用 Terraform 进行管理，实现了全栈 IaC 落地。（一）背景及设计原则（一）背景及设计原则 携程云平台概览携程

323、云平台概览 携程基础设施采用混合云架构，云资源分布在自建数据中心和公有云供应商。携程混合云平台的 IaaS 层提供裸金属管理、虚拟化宿主机（KVM）、以及容器宿主机等多种底层资源类型。其中容器通过 Kubernetes 进行编排和交付。更上一层则是各种业务 PaaS 平 268 网址：SRE-E 微信：SRE 精英联盟 台，诸如在线应用、数据库（DB）、ElasticSearch、Kafka 等服务。在携程的技术架构中，由云技术团队负责主要计算、网络和存储三大资源类型的管理和交付。在计算资源方面，携程云团队管理超过 20 个 Kubernetes 集群，每个集群的节点数控制在 5000 个以下

324、，以减少单一集群故障对整体的影响。在虚拟化技术方案，携程云团队从使用 OpenStack 过渡到 KubeVirt 进行 VM 资源交付，目前运维管理约 3 万台虚拟机实例。网络虚拟化技术方面，携程云团队使用 OpenStack Neutron 和Calico 来管理虚拟机和裸金属服务器的网络。容器网络则主要基于Cilium 和 eBPF 技术。携程存储解决方案在私有云中主要使用Ceph，而公有云存储则采用 S3、OSS 等对象存储。文件存储方面，携程采用 JuiceFS 和 FastDFS 来满足不同的业务需求场景。（二）基础设施变更管理详情（二）基础设施变更管理详情 变更失败主要由两大因素

325、引起：人为因素和流程因素。269 网址：SRE-E 微信：SRE 精英联盟 首先，人为因素并非指操作人员故意造成故障。很多时候，故障是因为变更人员未能遵循既定规范和操作流程，导致变更失败。因此，携程要求变更实施人员在操作之前，自问自答如下三个核心问题，也称为“三步法则”：是否为合适人选：确保变更人员对任务有充分的理解和背景知识，而不仅仅是盲目执行上级的指令。是否具备必要能力：变更人员需评估自己是否有能力设计出完整的变更方案，包括发布计划和应急恢复计划。是否能控制整个任务：在变更过程中可能会遇到意外问题，变更人员需要有能力主导问题的解决和恢复。讨论这三步法则的目的，并不是完全消除人为因素导致的故

326、障，而是为了最大限度减少人为因素的影响。流程因素也极为重要。在设计变更时，应遵循几个基本原则：270 网址：SRE-E 微信：SRE 精英联盟 计划性：技术设施的变更应严格按照计划执行，与普通应用的变更略有不同。灰度原则：灰度执行变更，先小范围后大范围，以控制风险。可回滚性原则：确保每次变更都可以安全回滚至变更前的状态以应对可能的故障。避免循环依赖：变更过程中应避免循环依赖问题。风险评估机制：建立系统的风险评估流程，确保变更的安全性。计划性原则计划性原则 与普通应用的变更相比，基础设施变更应该严格按照计划执行，典型例子如 Kubernetes 4 个月的发布模式，在此参照下，基础架构进行变更前

327、，更应该制定更严格的计划。灰度原则灰度原则 严格按照 Availability Zone(AZ)定义，控制变更的灰度 不同 AZ 的服务，不依赖同一套基础设施服务 控制基础设施变更的爆炸半径 生产不同 AZ 的基础设施变更，时间上必须间隔 1 天 “慢即是快”271 网址：SRE-E 微信：SRE 精英联盟 携程采用了混合云架构，并建设了国内的同城三中心高可用体系。这意味着我们的基础设施变更必须严格遵循三个可用区（AZ）的原则，确保每个 AZ 的服务都具备高可用性。即使一个 AZ 出现故障，也不会影响到其他两个 AZ 的正常运行。此外，为了控制变更的风险范围，每个 AZ 所依赖的基础设施必须是

328、独立的，不能有共享的部分。最关键的一点是，不同 AZ 之间的基础设施变更需要有足够的观察期。携程云团队规定，任何基础设施的变更后，必须至少经过一天的时间来观察其效果。变更后需要经历至少一个流量高峰期来验证变更的稳定性，是否能抗住峰值流量压力。尽管看似放慢了变更速度，实际上这种方法能更有效地确保变更的质量和安全，避免了因急于求成而可能带来的风险。这种做法体现了一个重要原则：慢是快，即通过细致周到的计划和执行来实现更快、更稳定的长期发展。可回滚原则可回滚原则 基础设施变更比较复杂，工程师容易忽略回滚策略 测试环境需要验证回滚步骤是否可执行 部分极端情况，可以将新建集群作为回滚方案 依赖快速构建环境

329、的能力+数据备份+配置备份 典型的回滚策略 272 网址：SRE-E 微信：SRE 精英联盟 代码和配置文件都需要版本管理，杜绝仅回滚镜像 引入中间版本 谨慎删除旧字段 关于变更管理中的可回滚原则，这是一个在实践中经常被忽视的重要方面。在进行变更时，团队会制定一个回滚计划，但仅在测试环境或小范围灰度发布时未发现问题，往往不会去实际验证回滚计划的可行性。因此，携程云团队强调在测试环境中必须验证回滚策略的有效性。在一些极端情况下，比如之前升级 Ceph 集群时遇到的问题，集群无法启动，不得不重建集群并迁移数据，显示出在紧急情况下能够重建整个集群的能力是多么重要。携程云团队推崇代码与配置的分离原则，

330、在进行变更时，尽量避免同时修改代码和配置，避免定位困难。另外，考虑，引入中间版本，在数据库变更中，最佳实践是先添加新字段，迁移数据，然后再删除旧字段，而不是直接修改字段属性。这样做可以减少回滚的复杂性和出错的风险。总之，确保变更可回滚性不仅是为了应对可能的失败，也是确保整个系统可维护性和稳定性的关键措施。通过这些策略，能够更有效地管理技术变更，减少潜在的业务中断风险。杜绝循环依赖杜绝循环依赖 273 网址：SRE-E 微信：SRE 精英联盟 核心基础设施间的依赖需要定期梳理 核心基础设施自愈能力 网络&虚拟化控制器，做到无外部依赖自启动 容易忽略的依赖项:DNS 分布式存储 在管理基础设施时，

331、强调减少循环依赖的重要性，因为这些依赖关系往往会导致系统复杂化和潜在的运维问题。为此，携程云团队定期梳理核心组件的依赖关系，并确保这些关键组件具备自愈能力。特别是在网络和虚拟化控制器这两个方面，历史上曾经经历过断电事件、电力恢复后，理论上业务应该立即回复，但实际上却因为这两个核心组件未能及时启动而导致整个系统无法运作。这一经历强调了底层系统的自主性和弹性的重要性，它们需要能够在没有外部依赖的情况下自启动。此外，在进行技术变更时，经常被忽视的两个关键领域是 DNS和存储。这些系统虽然在日常操作中看似稳定，但在变更过程中，任何对这些系统的忽视都可能导致严重的业务影响。杜绝循环依赖杜绝循环依赖 梳理

332、基础设施管理服务，定义 P0/P1/P2 服务标准 274 网址：SRE-E 微信：SRE 精英联盟 针对 P0 业务，建立定期风险 review 机制，review 内容包括：故障爆炸半径 业务架构 业务部署规范 业务故障预案 针对 P0 业务，进行故障演练，验证是否满足服务 P0 级定义，并建立常态化演练机制 为了确保核心应用和基础设施的稳定性和可靠性，携程云团队建立了一个详细的风险评估机制，并对服务进行了等级划分，包括P0、P1 和 P2 级。这些服务级别的定义基于过去几年中对系统故障影响的分析，其中 P0 级指的是对业务影响最大的系统。对于 P0 级服务实施定期的审查，包括几个关键方面

333、：故障爆炸半径：评估单个故障点对系统的影响范围，确保高可用性，即单个可用区（AZ）的故障不会影响到其他区域。业务架构：分析业务依赖的系统和组件，确保这些依赖项的SLA 也符合高可用要求。部署规范：检查部署的规范性，确保所有操作不会发生预期外的行为和影响。275 网址：SRE-E 微信：SRE 精英联盟 标准操作流程手册（SOP）：经过定期演练的标准操作流程手册SOP，确保应用的所有者或管理者在发生故障时，可以依据 SOP 迅速恢复服务。此外，携程云团队每年会进行实际的突击演练，例如选择性断开一个机房的网络连接，来测试其他机房是否能够独立承担起 100%业务流量。这种演练帮助携程云团队验证系统的实际表现与预期是否一致。除了这些集中演练外，携程云团队还鼓励应用的所有者通过混沌工程的方式，定时注入模拟的网络故障（如断网、丢包、网络延迟增大），不断验证并提升自身应用的韧性，确保真正满足 P0 级服