2024年SRE实践白皮书.pdf

SRESRE 实践白皮书实践白皮书 v1.0.3v1.0.3 2024年6月 SRE-E 修 订 记 录修 订 记 录 1.0.3 修订记录：第三章第 4 节变更管理依据 2024 年 4 月 13 日上海 B 站沙龙更新约 4 万字，包括 6 篇不同类型的企业案例 1.0.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 机房多活.14 1.2.2 网络容灾.14 1.3 数据灾备.14 1.3.1 数据备份.14 1.3.2 数据回滚.14 2 研发保障.15 2.1 代码可靠性.15 2.1.1 代码缺陷.15 2.1.2 代码规范.18 2.1.3 代码安全.20 2.1.4 代码圈复杂度.22 2.1.5 代码重复.23 2.1.6 代码注释与 API 文档.24 2.1.7 代码质量红线.25 2.2 代码仓库可靠性.27 2.2.1 仓库性能.27 2.2.2 仓库容灾.29 2.2.3 仓库安全.30 2.2.4 仓库可扩展性.32 2.3 构建可靠性.33 2.3.1 构建效率.33 2.3.2 构建成功率.35 2.4 制品可靠性.37 2.4.1 制品下载可靠性.37 2.4.2 制品部署可靠性.38 2.4.3 制品安全可靠性.40 3 入网控制.41 3.1 运行环境适配.41 3.1.1 运营环境设计.41 3.1.2 容器云适配.43 3.1.3 数据库存储适配.46 3.1.4 信创适配47 3.2 运行环境交付.52 3.2.1 基础资源服务.52 3.2.2 可观测策略.53 3.2.3 自动化策略.55 3.3 测试策略.58 3.3.1 连通性验证.58 3.3.2 功能测试.59 3.3.3 性能压测.62 3.3.4 数据迁移.67 3.4 变更评审.68 3.4.1 稳定性架构设计评估.68 3.4.2 非功能性技术评估.71 3.4.3 变更保障准备工作评估.73 3.4.4 新系统或新业务上线保障评估.74 4 变更管理.77 4.1 发布管理与变更管理关系阐述.77 4.2 变更体系设计.80 4.2.1 变更体系设计原则.80 4.2.2 变更及发布流程设计.80 4.2.3 变更的工程体系设计.103 4.3 变更管理案例.131 4.3.1 B 站变更防控的设计与实践.131 4.3.2 携程云平台基础设施变更管理实践.153 4.3.3 某银行变更管理设计与实践.175 4.4 发布管理案例.194 4.4.1 中移互联网敏捷发布平台建设实践.194 4.4.2 某证券变更一体化平台建设实践.213 4.4.3 游戏 GitOps 发布管理实践.230 5 故障应急.237 5.1 故障发现.237 5.1.1 监控发现.237 5.1.2 巡检发现.238 5.1.3 人工上报（舆情，客服，运营人员等）.240 5.2 故障诊断.241 5.2.1 应急协同.241 5.2.2 故障定界.243 5.2.3 影响评估（影响人数，范围，上报级别）.245 5.3 故障恢复.246 5.3.1 架构自愈.247 5.3.2 应急预案（已知的预案）.248 5.3.3 应急维护（人工干预，未知预案）.248 5.3.4 恢复验证.248 5.4 故障复盘.249 5.4.1 复盘组织.250 5.4.2 根因分析.253 5.4.3 制定改进.255 2如何做好故障改进.255 3改进措施的记录.256 3.5.4.4 问题跟踪.257 6 上线后持续优化工作.257 6.1 用户体验优化.257 6.1.1 基于用户端的直接用户体验优化.258 6.1.2 基于系统端的间接用户体验优化.259 6.2 重大技术保障.262 6.2.1 整体统筹保障.262 6.2.2 技术方案保障.263 6.2.3 工具可靠性保障.264 6.2.4 突发事件保障.266 6.2.5 示例 1：哀悼日停止游戏服务保障.267 6.2.6 示例 2:交易类大促核心保障流程和方案.273 6.2.7 示例 3：银行类通用重大保障活动.276 6.2.8 示例 4：发布会直播通用重大保障活动.278 6.3 运维琐事的日常管理及优化.283 6.3.1 运维琐事的介绍.283 6.3.2 运维琐事的质量管理.285 6.3.3 运维琐事的效率管理.286 6.4 业务全生命周期工具建设.288 6.4.1 研发期工具建设.289 6.4.2 上线期工具建设.290 6.4.3 运营期工具建设.291 6.4.4 下线期工具建设.292 6.5 运营成本分析及优化.293 6.5.1 运营成本分析及优化的必要性.293 6.5.2 运营成本实时监控.294 6.5.3 运营成本分析及优化的指标.294 6.5.4 运营成本的统计及分析方法.296 6.5.4 运营成本的优化方法.299 6.5.5 运营成本优化持续运营.302 6.6 混沌工程.304 6.6.1 正常行为定义.304 6.6.2 设计和实施混沌实验.305 6.6.3 监控和分析实验结果.306 6.6.4 优化和修复问题.307 6.6.5 持续迭代和改进.308 6.7 应用服务 SLI/SLO.308 6.7.1 什么是 SLI/SLO.308 6.7.2 如何建设 SLI/SLO.309 6.7.3 如何持续迭代 SLI/SLO.313 6.8 持续改进.315 6.8.1 效率持续改进.315 6.8.2 质量持续改进.317 6.8.3 安全持续改进.318 6.8.4 人员能力持续提升.320 6.8.5 流程持续改进.321 7 平台工程.324 7.1 标准应用平台工程建设.324 7.1.1 应用元信息平台.325 7.12 统一资源供给.328 7.1.3 持续集成.329 7.1.4 持续部署.333 7.1.5 部署编排.336 7.1.6 可观测.340 7.1.7 成本（定价、用量、出账）.341 7.2 异构应用平台工程建设.344 7.2.1 总体设计.345 7.2.2 aPaaS 结构设计.346 7.2.3 iPaaS 结构设计.352 7.2.4 通用原子设计.354 7.2.5 SaaS 分级.361 7.2.6 服务管理.364 7.2.7 安全与审计.366 附录.371 1 参考文献.371 2 术语.371 版权声明版权声明 这项作品采用 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 国际国际 您可以自由地：共享 在任何媒介以任何形式复制、发行本作品 在任何用途下，甚至商业目的。只要你遵守许可协议条款，许可人就无法收回你的这些权利。惟须遵守下列条件：署名 您必须给出 适当的署名，提供指向本许可协议的链接，同时 标明是否（对原始作品）作了修改。您可以用任何合理的方式来署名，但是不得以任何方式暗示许可人为您或您的使用背书。禁止演绎 如果您 再混合、转换、或者基于该作品创作，您不可以分发修改作品。没有附加限制 您不得适用法律术语或者 技术措施 从而限制其他人做许可协议允许的事情。声明：您不必因为公共领域的作品要素而遵守许可协议，或者您的使用被可适用的 例外或限制 所允许。不提供担保。许可协议可能不会给与您意图使用的所必须的所有许可。例如，其他权利比如 形象权、隐私权或人格权 可能限制您如何使用作品。SRE 实践白皮书（2024 年）1 网址：SRE-E 微信：SRE 精英联盟 第一章第一章 SRE 整体介绍整体介绍 1.1 前言前言 Google 在 2003 年启动了一个全新的团队“SRE 团队”，该团队旨在通过软件工程的方法提高应用系统的可靠性；随着 SRE 相关理论和实践在 Google 的日臻成熟，SRE 实践也从 Google 慢慢地扩散到了整个行业。自从 SRE 的理念进入中国以来，就已经引起了很多企业的关注和效仿，但各企业实施 SRE 的方法各异，SRE 的实现效果也各不相同。与此同时，中国的互联网行业中涌现出了一批对 SRE 充满热情的倡导者，他们为社区做出了各种贡献；包括：孙宇聪翻译出版了SRE：Google 运维解密、赵成在极客时间开设了课程SRE 实战手册，以及赵舜东在社区里积极地布道分享等等，不胜枚举。2022 年，由赵成等人牵头，首批来自于互联网、运营商、金融等行业领军企业的 SRE 团队负责人齐聚一堂组织了 SRE 研讨社区，定期开展社区分享活动，共同探讨 SRE 在各企业里的发展路径，分享各自的实战经验，并总结出了这份来自一线实战的、详实而持续更新的SRE 实践白皮书。社区每年都吸纳新的成员，逐年更新本白皮书内容，力求真实客观地描述国内企业 SRE 团队的工作方式。在实践白皮书初稿长达两年的整理过程中，我们看到了不同企业对 SRE 的理解，并尽可能统一大家对相似场景的定义；SRE 实践白皮书（2024 年）2 网址：SRE-E 微信：SRE 精英联盟 我们看到了不同企业对 SRE 职能领地的扩展，并将成功团队的经验提炼成案例供大家参考；我们也看到了在这两年的编写过程中，不同企业 SRE 团队的真实变化，并及时将其更新到实践白皮书中。总之，在未来的每个季度，我们都会将各 SRE 团队的最新职能、组织形式、技术迭代等现状，补充到实践白皮书中。2023 年，中国信息通信研究院（下简称信通院）云计算与大数据研究所（下简称云大所）稳定性保障实验室的专家加入了 SRE 研讨社区，深度的参与到社区交流当中，为SRE 实践白皮书的编写工作提供了专业指导。1.2 SRE 发展历程发展历程 SRE 运动在全球的发展经历了 20 年，下面是部分重要事件：2003 年，Google 成立了第一个 SRE 团队；2010 年，Facebook 拥有了一个 SRE 团队；2014 年，USENIX 协会主办的首届 SREcon（网站可靠性工程会议）在美国举行，大会成为了 SRE 专业人士交流经验和最佳实践的重要平台，标志着 SRE 作为一个独立且重要的专业领域在全球范围内的正式认可。2016 年，前 Google SRE 孙宇聪翻译出版了首部中文专业书籍SRE：Google 运维揭秘，在国内引起了很大的反响，很多企业开始学习并成立自己的 SRE 团队；SRE 实践白皮书（2024 年）3 网址：SRE-E 微信：SRE 精英联盟 2016 年，Netflix 成立了“核心 SRE 团队”。Uber 开始撰写有关其如何使用 SRE 的文章；2016 年，蚂蚁集团在国内成立了第一支 SRE 团队，主要攻坚容灾架构，后续拓展到高可用、资金安全等多个业务风险领域；2017 年，LinkedIn 开始宣传其“SRE 文化”；2017 年，浙江移动正式组建应用 SRE 团队，开始收口 IT 系统的集成部署、应急保障、架构治理等工作职责，加速了传统企业的运维数字化的转型进程；2018 年，赵成在某次 SRE 的聚会上，拉起了“聊聊 SRE”微信群，国内 SRE 人才开始聚拢，SRE 社区初步成型，并逐步成为了最具影响力 SRE 中文社区；2021，阿里 CTO 线第一支横向 SRE 团队成立，隶属于技术风险与效能部，负责集团全局稳定性保障、资源成本等方面工作；2022 年，腾讯在内部技术岗位设置中，新增了 SRE，标志着腾讯内部 SRE 体系的正式成立；2023 年，信通院云大所稳定性保障实验室牵头编制服务韧性工程（SRE）成熟度模型标准，推动该领域深入研究与实践应用，并在稳定性保障实验室成立了专门的“SRE 工作组”。SRE 实践白皮书（2024 年）4 网址：SRE-E 微信：SRE 精英联盟 1.3 SRE 的目标的目标 Site Reliability Engineering（SRE）的主要目标是通过结合软件工程和系统运维的最佳实践，提高大规模分布式系统的可靠性、可用性、性能和效率。以下是部分 SRE 追求的核心目标：可靠性：SRE 的首要目标是确保服务和系统的可靠性。这包括减少故障、提高系统的稳定性，以确保用户在任何时候都能够获得一致的高质量服务。可扩展性：SRE 致力于设计和实施能够随着用户需求增长而扩展的系统。这涉及到对系统的架构和资源进行优化，以便在不降低性能的情况下，适应实际工作负载持续不断的峰谷状态变化。性能：SRE 关注系统的性能，旨在确保系统能够在合理地时间内快速响应用户请求。这包括对系统瓶颈的持续监控和优化，以提高整体性能。自动化：SRE 倡导自动化运维工作，以减少人为错误和提高效率。通过自动化，可以更快速地部署新功能、检测并响应故障，并合理的开展系统的升级和维护工作。监控和告警：SRE 强调对系统的全面监控，以便及时发现并解决问题。通过设置有效的告警系统，可以在重大问题发生前迅速做出反应，从而减少对用户的影响。SRE 实践白皮书（2024 年）5 网址：SRE-E 微信：SRE 精英联盟 故障恢复：SRE 强调迅速而有效地恢复服务，以最小化用户体验的中断。这包括制定和演练紧急情况的应急计划。企业实现 SRE 核心目标的过程并不相同，落地路径各异。不论 SRE 部门（团队）在企业中的存在形式和所处位置，SRE 相关实践工作存在于大量流程中。这些工作流程与研发、测试、运维、产品运营等团队紧密的融合在一起，所有参与团队都在上述共享的 SRE 目标上做着各自的贡献。SRE 实践白皮书（2024 年）6 网址：SRE-E 微信：SRE 精英联盟 第二章第二章 SRE 的组织架构的组织架构 SRE 团队在组织中的存在意义主要是确保系统的可靠性和高效运行。通过引入 SRE 角色，组织可以更好地平衡软件开发速率和系统稳定性之间的需求，从而实现更高水平的可用性、性能和自动化。通常 SRE 团队在组织中使命如下：可靠性优先：SRE 团队致力于确保服务的高可用性和可靠性。他们关注系统的稳定性，采取工程化方法来减少故障和提高系统的稳定性。自动化运维：SRE 团队推动自动化运维工作，以减少手动操作的错误和提高效率。通过自动化，可以更快速、可靠地进行部署、监控、故障检测和修复等操作。质量保证：SRE 团队参与服务的全生命周期，包括设计、开发、部署和维护阶段，以确保系统在不同阶段都能保持高质量。快速创新：通过减少故障和提高系统的稳定性，SRE 团队为开发团队提供了更稳定的平台，使其能够更专注于业务创新和新功能的开发。在组织架构中，SRE 团队的存在形式可以各不相同，这主要取决于组织的规模、业务需求和文化。以下是一些常见的 SRE 团队的存在形式：SRE 实践白皮书（2024 年）7 网址：SRE-E 微信：SRE 精英联盟 中心化 SRE 团队：由一个专门的 SRE 团队负责支持整个组织的可靠性工作。这种模式有助于集中专业知识，确保在整个组织中实施一致的最佳实践。嵌入式 SRE 团队：SRE 团队成员被嵌入到各个产品或服务团队中，与开发团队紧密合作。这种模式有助于更好地集成可靠性工作到产品开发的全过程中。混合模式：一些组织采取混合模式，既有中心化的 SRE 团队，又在一些关键项目中嵌入 SRE 角色。这种方式能够兼顾专业化和贴近业务的优势。每种存在形式都有其优势和适用场景，关键在于根据组织的需求选择最合适的模式。不论哪种方式，SRE 的目标都是通过自动化和工程方法提高系统的可靠性和效率。下面是国内某几家一线互联网 SRE 团队在组织架构中的设置模式。SRE 实践白皮书（2024 年）8 网址：SRE-E 微信：SRE 精英联盟 SRE 实践白皮书（2024 年）9 网址：SRE-E 微信：SRE 精英联盟 参考以上各个公司 SRE 团队在组织架构中的位置，通常 SRE 团队需要承担以下几类职责：监控、事故响应、事后回顾、测试与发布、容量规划、工具开发和可用性改进等。由于各个公司的业务形态的不同，SRE 团队在组织架构中也有不同的定位和名称，包括：SRE 产品运维、互联网 SRE 组、AIoT SRE 组、信息技术 SRE 组、业务 SRE 组等。SRE 实践白皮书（2024 年）10 网址：SRE-E 微信：SRE 精英联盟 第三章第三章 SRE 的职能的职能 1 可靠性构架设计可靠性构架设计 可靠性架构设计是指在进行系统架构设计的过程中，根据系统的可靠性需求，采用分布式设计、解耦设计、冗余设计等高可靠性的架构设计方案，以提升系统的可靠性。在进行可靠性架构设计的过程中，SRE 团队需要将应用架构设计流程完全融入其中，并与研发团队共同参与架构设计和评审工作。在系统设计阶段，应尽量消除可能出现的单点、容量等潜在风险，并提前为可能出现的系统架构风险做好应急准备。SRE 实践白皮书（2024 年）11 网址：SRE-E 微信：SRE 精英联盟 1.1 应用韧性架构应用韧性架构 1.1.1 分布分布式式设计设计 在系统中，存在被划分为职责明确、粒度合适且易于管理的组件，这些组件（如计算资源、业务部分、数据等）都可以进行分布式的部署和运行。组件之间相互独立、互不干扰，通过分布式设计可以提高开发效率和可靠性。组件的拆分和分布可以通过复制、根据功能进行垂直拆分、或根据用户与访问模式水平拆分等形式。在设计时应该充分考虑到组件间可能存在的相互干扰以及如何平衡不同组件之间的负载，并将系统所承受的压力进行均匀分配，以减轻压力对系统整体性能的不良影响。1.1.2 解耦设计解耦设计 在架构设计中，可以将各种逻辑功能划分为不同的服务模块，确保不同模块的故障对其他模块的影响是最小，从而最大限度地降低模块之间的耦合度。通过这种方式，可以将系统划分为多个相互独立的功能模块来实现。尤其值得注意的是，业务的主要逻辑与其他非核心模块是独立的，因此业务非核心模块的故障并不会对业务的核心功能产生负面影响。1.1.3 冗余设计冗余设计 为了确保资源有足够的安全余量，每个组件都需要有足够和合理的冗余实例，以确保单一组件实例的失效不会对业务的正常运行造成影响。对于不同类型的组件，我们需要明确地定义冗余量和冗SRE 实践白皮书（2024 年）12 网址：SRE-E 微信：SRE 精英联盟 余类型。在实际应用中，由于设备故障或者操作不当等原因导致服务器出现性能下降或崩溃现象时，系统会出现异常状态并产生大量信息。应用程序可能部署多个机房，当这些机房中有数据冗余时，一个位置的错误可以通过另一个位置的数据进行修正，确保整个系统的连续性和可靠性。为了提高系统可靠性，通常采用读-写分离的技术进行数据的冗余管理。读写分离是一种冗余的设计方式，缓存和数据库之间存在数据冗余，当缓存服务宕机时，可以从数据库回源到缓存。1.1.4 熔断设计熔断设计 熔断机制是应对雪崩效应的一种微服务链路保护机制，如果目标服务的调用速度较慢或超时次数较多，则此时会熔断该服务的调用。对于后续的调用请求，不再继续对目标服务进行调用，直接返回预期设置好的结果，可以快速释放资源。一般来说，熔断需要设置不同的恢复策略，如果目标服务条件改善，则恢复。1.1.5 限流设计限流设计 限流是一种系统设计技术，用于控制访问应用程序或服务的流量，防止资源过载。常见的限流策略包括固定窗口、滑动日志、漏桶和令牌桶算法。这些方法可以帮助系统应对高流量，保持稳定性和可靠性。在实施时，通常需要结合其他系统保护措施，如队列、缓存、服务降级和熔断，以实现全面的流量控制和系统保护。当流量被限制后，系统通常会采取以下措施之一：拒绝多余的请求、将请求排队等待处理、返回错误码（如 HTTP 429 Too Many SRE 实践白皮书（2024 年）13 网址：SRE-E 微信：SRE 精英联盟 Requests）、或者提供一个降级的服务响应。这些措施可以缓解服务器压力。1.1.6 降级设计降级设计 降级机制是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略地降级，以此缓解服务器资源的压力，释放服务器资源以保证核心任务的正常运行。从降级配置方式上，降级一般可以分为主动降级和自动降级。主动降级是提前配置，自动降级则是系统发生故障时，如超时或者频繁失败，自动降级。其中，自动降级可分为超时降级、失败次数降级、故障降级。1.1.7 可观测设计可观测设计 为了保证系统的透明性并迅速定位问题，采用可观测的设计方法变得尤为关键。可观测设计涵盖了日志记录、实时监控、追踪以及度量等多个方面，从而实现了系统状态和行为的可量化以及可分析性。在可观测的设计中，日志应当详细地记录所有的关键事件，监控系统需要能够实时捕获关键的性能指标，跟踪机制应具备跨服务请求的追踪能力，度量指标则应全方位地反映系统的健康状态。另外，健康检查机制需要自动地对系统组件状态进行评估，当出现异常指标时，告警机制会立即告知相关的工作人员。通过这些措施，我们可以清晰地观察到系统的运行状态，从而为后续的维护和优化工作奠定了稳固的基础。SRE 实践白皮书（2024 年）14 网址：SRE-E 微信：SRE 精英联盟 1.2 基础设施保障基础设施保障 1.2.1 机房多活机房多活 系统所部署的机器或所在地需具备一定的冗余性。包括同机房多活、同城多活和异地多活等不同级别。将要建设的机房要求具有独立性，尤其是网络环境，机房之间通过专线来进行连接。1.2.2 网络容灾网络容灾 数据中心之间的互联网络是 DC 之间业务连接的重要载体，对存储灾备网络的时延要求较低、带宽较大、可靠性较高；业务灾备网络需要实现链路备份和快速的路由收敛。1.3 数据灾备数据灾备 1.3.1 数据备份数据备份 即对核心数据进行备份和恢复的能力。需对核心数据进行实时备份，并具备快速容灾切换的能力。需对备份恢复的能力进行周期性地验证。1.3.2 数据回滚数据回滚 在系统出现异常情况下，迅速有效地恢复故障前数据状态，减少了故障给业务系统带来的冲击。回滚是否有效取决于回滚执行过程和回滚决策是否及时。SRE 实践白皮书（2024 年）15 网址：SRE-E 微信：SRE 精英联盟 2 研发保障研发保障 研发阶段的可靠性是指，以 SRE 理论驱动研发的可用性建设，提升研发管线的工业化水平，保障版本能够按正常周期迭代，从而实现高质量持续交付有效价值的目标；为了实现满足版本迭代周期要求这个总体的可用性目标，将研发阶段拆解为代码可靠性、代码仓库可靠性、构建可靠性和制品可靠性四个方面，每个阶段分别对其可靠性进行定义并提出相应的改善措施；2.1 代码可代码可靠性靠性 代码是基于一定需求实现，用于构建对应软件的文件集合。代码质量从基础上决定了软件的成败，是软件开发过程中不可忽视的一环。在软件版本快速迭代的今天，如何构建高质量的代码更显得至关重要。代码可靠性的落地仅靠宣导或者文档还远远不够，需要建设完善的检查工具并量化效果，一般由平台 SRE 建设相关的工具，因此需要平台 SRE 需要深入了解影响代码可靠性的常见问题及提升措施，不断完善代码检查工具的能力；2.1.1 代码缺陷代码缺陷 代码缺陷是指影响代码稳定运行的问题，或者未达到设计时的预期功能。缺陷产生的原因有多种，比如：软件的复杂性、编写的SRE 实践白皮书（2024 年）16 网址：SRE-E 微信：SRE 精英联盟 错误、需求歧义等。代码缺陷的及时发现与修复，对项目进度与工程质量至关重要。代码缺陷检测，一般可采用静态分析法或动态分析法。静态代码分析是指无需运行被测代码，通过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。动态分析方法则一般应用于软件的测试运行阶段，在软件程序运行过程中，通过分析动态调试器中程序的状态、执行路径等信息来发现缺陷。1代码缺陷规避措施 代码缺陷种类较多，无法完全罗列，这里选取部分最为常见的缺陷并介绍对应的规避办法：1）指针错误使用 指针的错误使用，一般要避免空指针、野指针，避免指针类型不匹配，不返回局部变量的指针。2）内存非法访问 非法内存访问是指程序试图读取或写入未分配/受保护的内存，如数组越界等，这将会导致程序的不可控行为。因此，必须确保程序正确地分配和释放内存，避免缓冲区溢出等现象。也可使用静态分析工具检测代码中的内存非法访问问题。3）变量未初始化 SRE 实践白皮书（2024 年）17 网址：SRE-E 微信：SRE 精英联盟 使用未初始化的变量，可能导致未知错误。一般来讲，变量需要在声明时赋予初始值。4）资源泄漏 常见的资源泄漏包含 socket 泄漏，文件句柄泄漏，内存泄漏等。产生原因是由于未能正确释放已经分配的内存或其他资源，导致这些资源被长期占用。资源泄漏不仅会造成资源的浪费，系统性能下降，严重时超出系统限制会导致程序崩溃。避免资源泄漏，在编程过程中，需要在资源使用完毕后进行资源的释放，如 socket/文件句柄的关闭，动态分配内存的释放。5）竞争死锁 竞争死锁是指多个线程或进程持有资源，又互相竞争等待对方资源而导致死锁的情况。解决死锁问题，一般可采用超时使用机制、统一获取资源顺序和死锁检测机制来打破死锁产生的必要条件。6）不当的 API 使用 不当的 API 使用，会导致程序异常。可通过仔细阅读 API 文档，了解 API 的使用方式，在使用 API 前进行充分测试的方法来规避。2效果评估 代码缺陷数作为代码质量指标之一，可以从数量、严重程度来归类。在度量层面，一般使用百行告警数来衡量代码缺陷指标。通过配置代码缺陷规则集，采用缺陷检测工具扫描，生成检测报告。SRE 实践白皮书（2024 年）18 网址：SRE-E 微信：SRE 精英联盟 根据缺陷的严重程度分为严重告警（空指针、数组越界等），一般告警（变量未初始化等）和提示告警（如代码风格等）。设定各个告警等级的权重，统计代码行数，最终计算出百行代码缺陷告警数。百行缺陷告警数=（严重告警 W1+一般告警 W2+提示告警 W3）/代码行数 100（W1/W2/W3 为权重系数）2.1.2 代码规范代码规范 代码规范主要是指是否遵守了团队或者业界的编码规范。代码规范主要涵盖：代码风格（如注释、空代码块、命名、格式化等），与异常处理等部分。代码规范有助于提高代码可读性与可维护性，从而提升团队内开发效率。代码可读性帮助相关技术人员能够轻松阅读并理解代码意图与实现方式。代码从分支发起到主干的合并请求前，必须进行代码检查，这也是提前发现问题的方法之一。1代码规范提升措施 1）代码风格 良好的代码风格会帮助开发人员阅读和理解符合该风格的源代码，并且避免错误。此处所讲述的代码风格包括但不限于：命名规范，表达式与语句，缩进，对齐，注释，代码布局等。对于不同的编程语言，适用于不同的代码风格，对于同一项目或开发团队，应当使用统一的代码风格。SRE 实践白皮书（2024 年）19 网址：SRE-E 微信：SRE 精英联盟（1）命名规范，命名要能够直观的表达本身的意图，同时具备可读与可搜索性，尽量遵循一些通用的写法。在此基础上命名长度应当尽量精短，避免触发代码行字符数限制规范；（2）缩紧，一般采用 4 个空格缩进，而不使用 tab 键（特殊语言除外）（3）统一字符编码格式，通常采用 UTF-8 编码（4）单行字符数限制，长度一般不超过 120（5）行尾换行符，一般使用换行符 LF，禁止使用回车键 CR 2）异常处理 异常处理是为了防止一些未知错误产生而采取的措施。适当的使用异常处理能够提高程序的容错性。在处理异常方面，需要遵循：（1）只在可能出异常的块进行精准捕获处理；（2）捕获的异常必须处理或抛出给上层调用方；（3）异常处理效率较低，应避免使用异常做条件控制 2效果评估 对于代码规范的效果评估，可以采用百行告警数来衡量。百行告警数=（严重告警 W1+一般告警 W2+提示告警 W3）/代码行数 100 注：（W1/W2/W3 为权重系数）SRE 实践白皮书（2024 年）20 网址：SRE-E 微信：SRE 精英联盟 百行告警数可以用来评估代码的质量和稳定性，较高的百行告警数可能意味着代码存在较多的缺陷和潜在问题，需要更多的测试和修复工作；2.1.3 代码安全代码安全 安全性是指在为正常访问提供服务的同时，也能拒绝非法访问。同时不因为代码设计或实现的原因，导致信息泄漏/非法侵入/系统崩溃等问题。1代码安全性提升措施 1）防止敏感信息泄漏 敏感信息可分为系统敏感信息与应用敏感信息。系统敏感信息包含业务系统的基础环境信息，如系统版本、组件版本等；应用敏感信息包含用户信息和应用信息等，如用户 TOKEN、密码、IP 等。系统敏感信息泄漏会为攻击者提供更多的攻击方法，应用敏感信息泄漏危害则因泄漏信息内容而决定。解决方法：（1）避免硬编码，禁止将密码等敏感信息写入到代码，应该以配置或后台下发形式读取（2）处理异常时，避免将系统信息、DEBUG 信息、或者敏感文件的路径输出到用户可见处 2）预防安全漏洞 代码安全漏洞，指编码过程中因不当的处理逻辑引发的安全风险；SRE 实践白皮书（2024 年）21 网址：SRE-E 微信：SRE 精英联盟 常见的代码安全漏洞有：（1）脚本（SQL）注入，可通过减少拼接命令，对命令参数值进行过滤/校验避免（2）XSS 攻击，可以使用安全的 JavaScript 框架和组件，同时主动检测发现，转义输入等减少（3）越权访问，是由于权限设计错误，未授权用户获取甚至修改其他用户的信息。需要通过最小化原则的权限设计与审计来规避（4）通信安全，一般是由于未使用加密信道进行通信导致，可以通过使用加密/私有协议通信来避免 3）第三方组件安全 软件开发中不可避免的会引入依赖库，或者第三方 SDK。这些第三方组件作为系统的一部分，与原生代码并无本质区别，它们的安全性也同样影响整个系统。因此，需要在减少对第三方组件引入的基础上，加入相应的安全评估机制。对于第三方组件的评估，我们主要从以下几个方面：（1）组件安全风险应在引入前/上线前/定期进行安全扫描（2）组件合规风险包括使用协议合规和监管数据合规（3）组件稳定性应当使用经过实际验证的 LTS 版本 2效果评估 在衡量代码安全性方面，可以从敏感信息泄漏、系统漏洞、第三方高危组件等几个方面来考量。可以通过代码扫描工具，扫描出已知系统漏洞与敏感信息，以及第三方高危组件的引入情况。SRE 实践白皮书（2024 年）22 网址：SRE-E 微信：SRE 精英联盟 在得到敏感信息，安全漏洞个数，以及第三方高危组件个数后，可以制定代码安全性红线。一般来讲，敏感信息、安全漏洞是绝对不允许的。对于第三方高危组件，也要经过安全评估测试，其标准与本身代码相同。（1）对于敏感信息与安全漏洞，必须彻底清除（2）第三方高危组件，还可以采用 LTS 覆盖率可以用来衡量系统中使用的第三方高危组件稳定性。LTS 覆盖率=第三方高危组件LTS 数/第三方高危组件数 2.1.4 代码圈复杂度代码圈复杂度 圈复杂度是一种代码复杂度的衡量标准，可以用来衡量一个模块流程判定结构的复杂程度。圈复杂度大说明程序代码的判断逻辑复杂，可用来表示对给定代码进行测试、维护或故障排除的难度，以及代码生成错误的可能性。同时，也可用来帮助开发人员确定是否需要对程序进行重构，以降低程序的复杂度，提高代码质量。1圈复杂度改善措施 降低函数圈复杂度的主要通过对代码重构来进行，一般有以下几种方法：（1）将大函数拆分成多个小函数，每个小函数只负责单一功能（2）将条件判定提炼出来，成为独立函数（3）简化、合并条件表达式（4）优化循环结构，减少循环嵌套、使用更简单的循环结构等 2效果评估 SRE 实践白皮书（2024 年）23 网址：SRE-E 微信：SRE 精英联盟 圈复杂度反应了代码的耦合度，圈复杂度越高的代码会有越多潜在的 BUG。对于圈复杂度，可以从以下指标衡量：（1）单函数圈复杂度最大值小于等于 20（2）项目平均圈复杂度，一般不大于 4 项目平均圈复杂度=所有函数圈复杂度之和/所有函数个数 2.1.5 代码重复代码重复 代码重复指的是程序中存在相同或类似的代码段。在不同的位置或程序中出现相同的代码，会造成了代码冗余和浪费。代码重复，不仅导致项目代码量的增加，影响程序的可读性和可维护性，增加代码的错误率和修改难度，也是设计不佳的一个标志。代码重复的表现形式多种多样，常见形式有：（1）完全一样的代码（2）仅重命名标识符的代码（3）仅变量赋值不一样的代码（4）插入或删除语句的代码（5）重新排列语句的代码 1代码重复改善措施 降低重复代码，是代码优化的重要方面之一，一般需要对相关功能进行重构。常见的改善措施，主要是抽取公共代码、封装函数、使用继承和多态等 SRE 实践白皮书（2024 年）24 网址：SRE-E 微信：SRE 精英联盟（1）抽象出公共方法或函数，将重复的代码封装在一个函数或方法中（2）使用继承或接口，将共同代码放在父类或接口中，子类只实现自己的特定部分（3）使用设计模式，如工厂模式、模板方法模式等（4）利用现有的框架或库，避免自己重写 2效果评估 代码重复的度量，可以使用代码重复率来表示，可以通过静态扫描工具得出。代码重复率，指的是在一段代码中重复出现的代码段的比例。代码重复率越高，代码的可维护性和可读性就越差。代码重复率=重复行数/代码总行数 在实际的工程中，一般建议：（1）单文件代码重复率最大值小于等于 10%（2）项目平均代码重复率小于等于 10%2.1.6 代码注释代码注释与与 API 文档文档 代码的注释与 API 文档编写是软件开发过程中非常重要的一部分，可以提高代码的可读性和可维护性。通过代码注释可以帮助阅读者快速理解代码的功能和实现方式。API 文档则是其他开发者了解使用软件的重要途径。开发者应该养成写注释和文档的好习惯，为自己和其他开发者节省开发时间。1代码注释与 API 文档提升措施 SRE 实践白皮书（2024 年）25 网址：SRE-E 微信：SRE 精英联盟（1）注释目的在于使阅读者能够快速掌握注释对象的使用方式与原理，良好的注释应包 含注释对象的产生意图，设计考量与如何使用；注释一般应当包含文件注释，类/结构体注释，函数方法注释，变量注释以及适当的代码段注释；对于规范化命名的变量与简单函数方法，可以不进行注释。（2）API 文档，应当描述各个类和方法的功能和使用方法，同时遵循行业和国际标准，具备兼容性和实时性。2效果评估 对于注释与 API 文档的考量，可以从 API 文档覆盖率，代码注释行密度来衡量。1）注释行密度=注释行数/总行数*100 此标准用于衡量百行代码中，所包含注释行数，一般认为低于5 表示几乎没注释。2）API 文档覆盖率=已覆盖 API 接口数量/总 API 接口数量 此标准用于衡量对外 API 文档的完善程度；一般来讲，至少需要达到 80%覆盖率，即覆盖大部分的 API 功能，忽略了一些不太重要或不常用的 API；同时也需要定期更新，使文档保持最新、全面、准确的状态。2.1.7 代码质量红线代码质量红线 代码质量红线是指在开发过程中，开发团队所设定的一些规则和标准，用于确保代码质量达到一定的水平，也是衡量代码质量的SRE 实践白皮书（2024 年）2