SRE实践白皮书1.0.3

SRE实践白皮书 v1.0.3 2024年6月 SRE-Elite.com 修订记录 1.0.3修订记录： 第三章第4节《变更管理》依据2024年4月13日上海B站沙龙更新约4万字，包括6篇不同类型的企业案例1.0.2修订记录： 增加了版权声明为CCBY-ND4.0 修正了目录没有3.1.1的问题 修改了页眉的时间点 修正了部分错别字 目录 第一章SRE整体介绍1 1.1前言1 1.2SRE发展历程2 1.3SRE的目标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.1B站变更防控的设计与实践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/SLO308 6.7.1什么是SLI/SLO308 6.7.2如何建设SLI/SLO309 6.7.3如何持续迭代SLI/SLO313 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.1.2统一资源供给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.2aPaaS结构设计346 7.2.3iPaaS结构设计352 7.2.4通用原子设计354 7.2.5SaaS分级361 7.2.6服务管理364 7.2.7安全与审计366 附录371 1参考文献371 2术语371 版权声明 这项作品采用CCBY-ND4.0许可进行授权。要查看此许可的副本，请访问http://creativecommons.org/licenses/by-nd/4.0/ CCBY-ND4.0DEED 署名-禁止演绎4.0国际 您可以自由地： 共享—在任何媒介以任何形式复制、发行本作品在任何用途下，甚至商业目的。 只要你遵守许可协议条款，许可人就无法收回你的这些权利。惟须遵守下列条件： 署名—您必须给�适当的署名，提供指向本许可协议的链接，同时标明是否（对原始作品）作了修改。您可以用任何合理的方式来署名，但是不得以任何方式暗示许可人为您或您的使用背书。 禁止演绎—如果您再混合、转换、或者基于该作品创作，您不可以分发修改作品。 没有附加限制—您不得适用法律术语或者技术措施从而限制其他人做许可协议允许的事情。 声明： 您不必因为公共领域的作品要素而遵守许可协议，或者您的使用被可适用的例外或限制所允许。 不提供担保。许可协议可能不会给与您意图使用的所必须的所有许可。例如，其他权利比如形象权、隐私权或人格权可能限制您如何使用作品。 第一章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职能领地的扩展，并将成功团队的经验提炼成案例供大家参考；我们也看到了在这两年的编写过程中，不同企业SRE团队的真实变化，并及时将其更新到实践白皮书中。总之，在未来的每个季度，我们都会将各SRE团队的最新职能、组织形式、技术迭代等现状，补充到《实践白皮书》中。 2023年，中国信息通信研究院（下简称信通院）云计算与大数据研究所（下简称云大所）稳定性保障实验室的专家加入了SRE研讨社区，深度的参与到社区交流当中，为《SRE实践白皮书》的编写工作提供了专业指导。 1.2SRE发展历程 SRE运动在全球的发展经历了20年，下面是部分重要事件：2003年，Google成立了第一个SRE团队； 2010年，Facebook拥有了一个SRE团队； 2014年，USENIX协会主办的首届SREcon（网站可靠性工程会议）在美国举行，大会成为了SRE专业人士交流经验和最佳实践的重要平台，标志着SRE作为一个独立且重要的专业领域在全球范围内的正式认可。 2016年，前GoogleSRE孙宇聪翻译出版了首部中文专业书籍 《SRE：Google运维揭秘》，在国内引起了很大的反响，很多企业开始学习并成立自己的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工作组”。 1.3SRE的目标 SiteReliabilityEngineering（SRE）的主要目标是通过结合软件工程和系统运维的最佳实践，提高大规模分布式系统的可靠 性、可用性、性能和效率。以下是部分SRE追求的核心目标： 可靠性：SRE的首要目标是确保服务和系统的可靠性。这包括减少故障、提高系统的稳定性，以确保用户在任何时候都能够获得一致的高质量服务。 可扩展性：SRE致力于设计和实施能够随着用户需求增长而扩展的系统。这涉及到对系统的架构和资源进行优化，以便在不降低性能的情况下，适应实际工作负载持续不断的峰谷状态变化。 性能：SRE关注系统的性能，旨在确保系统能够在合理地时间内快速响应用户请求。这包括对系统瓶颈的持续监控和优化，以提高整体性能。 自动化：SRE倡导自动化运维工作，以减少人为错误和提高效率。通过自动化，可以更快速地部署新功能、检测并