2024年SRE实践白皮书v1.0.4

SRE实践白皮书 v1.0.4 2024年9月 SRE-Elite.com 修订记录 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修订记录： 增加了版权声明为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研发保障体系设计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仓库可扩展性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.1腾讯游戏全球研发保障实践55 2.3.2某语音直播公司研发过程保障实践129 SREElite精选原因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变更评审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.1B站变更防控的设计与实践243 4.3.2携程云平台基础设施变更管理实践266 4.3.3某银行变更管理设计与实践288 4.4发布管理案例307 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影响评估（影响人数，范围，上报级别）362 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中国联通数字化监控平台稳定性保障实践415 5.5.3腾讯全球化游戏故障管理实践447 5.5.4XX银行应急管理一体化平台建设实践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示例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运营成本实时监控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/SLO608 6.7.1什么是SLI/SLO608 6.7.2如何建设SLI/SLO609 6.7.3如何持续迭代SLI/SLO613 6.8持续改进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.2aPaaS结构设计646 7.2.3iPaaS结构设计652 7.2.4通用原子设计654 7.2.5SaaS分级661 7.2.6服务管理664 7.2.7安全与审计666 附录671 1参考文献671 2术语671 版权声明 这项作品采用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系统的集成