软件质量保障体系建设

Posted 2023-04-09 java领域

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件质量保障体系建设相关的知识，希望对你有一定的参考价值。

前言

从事软件测试相关工作七年，做过功能测试、自动化测试、测试开发、性能测试、专项测试，也干过一段时间技术管理。

近几年随着行业成熟度的发展，对软件测试也有了更高的要求，很多测试团队开始转变为质量保障团队。

如何从质量保障的维度去更好的为业务提供支持，是我一直在思考的事情。

整理了自己的很多笔记，结合我在工作中遇到的种种场景，我梳理出了下面这张质量保障体系思维导图，供大家参考。

思维导图

三大体系

组织

愿景

所谓的愿景，就是长期规划，我们要到哪里去的问题。一个组织或者团队，是一定要有愿景的。在软件质量保障领域，所谓的愿景概括来说就四个字：保质提效。

保质，就是在日常交付中保障软件质量，并且在长期发展过程中，不断提高软件的质量。如何评估质量是否是稳定且不断提升的，就需要引入评估体系，用事实、结果、背后的分析逻辑和数据来证明。

提效，很好理解，提高效率。怎么提高效率呢？引入ROI体系，从交付时间、耗用资源、团队成长方面着手。

目标

有了愿景，还要将其拆分为不同的目标。行业在变，组织架构在变，因此目标也要跟随整体的变化而调整。

不同的企业在不同阶段有不同的侧重点和诉求。你不能要求一个初创企业要啥啥都有，也不能要求BAT啥都凑合。这是一个平衡和抉择的过程，可以参考CMMI模型来思考这一点。

规则

这里的规则不是强制要求大家一定要做什么，而是为了避免某些方式对团队和企业带来不好的影响。常见的规则比如：周报、信息同步机制、反馈机制

文化

谈到文化这一块，一直是很务虚的东西，很多同学对之嗤之以鼻，2020年之前我也是这么想的。

20年读了一本书：《重新定义公司：Google是如何运营的》。里面对企业文化这一部分做了很经典的解释：企业文化就是指导员工面临艰难选择时，做正确的选择。

管理

团队管理方面，我将其分为了下面四个体系，每个体系都包含不同的内容。

相关内容，可参考我之前的文章：从技术专家到技术管理，我对管理的思考

业务体系

如果团队规模较小，业务也不复杂，可以暂时不用拆分。但是当人数超过10人&业务开始划分不同团队时候，就要考虑做业务拆分了。

这里的业务拆分指的是根据组织架构将测试同学分为不同的组，每个组有一个小组长或team leader，提高管理效率，做好信息同步和反馈机制。

避免自己成为团队的瓶颈，从繁杂的管理中抽身出来，去思考并解决更高维度的问题。

资源体系

在团队管理中，无论是人力、设备还是时间，都可以纳入资源管理体系中。我将其分为了如下三个部分：

1、人力模型

新人目标：新人入职如何落地？如何快速适应业务迭代节奏？如何设定合理的目标来达成预期结果？
转正述职：招聘、新人培养都需要成本投入，设定合理明确的转正评估机制，结合上述的新人目标，可以帮助新人更好的落地。

2、能力模型

成长模型：工作一方面为了金钱物质回报，另一方面也是希望能够借助平台获得自我成长。设定成长目标和模型，可以帮助员工在不同的阶段知道自己该向什么方向努力，达成不同阶段的不同目标，这是没一个管理者都需要考虑的事情。
胜任力模型：一个团队的组织结构，从初级的倒T型，经过金字塔模型，最终演变成纺锥型。在不同阶段，随着组织结构的演变，处在不同阶段和层级的员工，需要设定不同的级别和胜任评估体系，助力团队跟随公司不断发展，适应组织结构的变化。一般来说，可以从工作经验、技术、业务熟悉度、项目推动能力、沟通协同方面来设定评估指标。

3、资产管理

云端资产：现在大多数互联网公司，都采用了云服务。对于质量保障团队来说，测试环境及内部自建技术平台涉及的云端资产，都需要通过一定的手段管理起来。当然一般这种事在运维团队，有CMDB体系来进行管理，可进行参考。
硬件资产：这里的硬件资产包括移动端测试机&pad等设备，当然可能也包括用来做兼容测试而采购的相关服务等设施。还有一点，员工办公所使用的包含电脑显示器等设备，一般会有IT部门来专门登记管理。如果没有，建议做好统计，便于员工入离职交接等。

知识体系

这里的知识体系，主要指的是团队内部的能力建设和沉淀，主要包含如下几个方面：

1、技术博客

无论是工作职场中还是和同行交流中，我一向是比较鼓励大家写技术博客的。

这样无论是对个人知识的梳理总结，还是团队的技术能力沉淀都是有很大帮助的。长期以往坚持下来，还能形成品牌向外宣传，这也是吸引优秀候选人的一个方式。

2、业务串讲：前面提到随着企业的发展，业务规模越来越大也越来越复杂，业务串讲就显得很有必要。优点如下：

帮助不同team的同学了解不同的业务，便于日常工作理解；
遇到不同团队协同工作时，更明确交接的业务边界，提供沟通效率；
沉淀成业务知识库，可以让其他团队的同学&新入职的同学快速了解，离入职交接也更方便；

3、内部分享：这里的内部分享，指的是技术部门内部，上述的技术博客和业务串讲&知识库，都可以作为分享的素材来宣讲。

一方面可以让更多的同学了解到不同的知识，另一方面加深团队的影响力，这样有助于日常工作的开展。也能在一定程度上培养团队同学的沟通和表达能力。

4、外部培训：这个主要指下面几方面：

联合开源社区，合作举办技术沙龙、座谈会等类似的活动；
重量级的技术大会上做主题分享，主要目的是价值宣导和品牌影响力建设；

评估体系

如何理解这里的评估体系？围绕上文提到的保质提效相关的点，来分类进行评估。

1、问题管理

测试过程中遇到的BUG，分门别类，阶段性的总结梳理，输出质量保障参考手册/SOP；

2、版本管理

版本管理主要涵盖每个版本的服务发版次数、冒烟通过率、bug的reopen率、上线质量等因素。每个版本结束，除了向上做汇报，内部的复盘总结优化，也是很重要的。

3、项目管理

这里的项目管理，可以理解为PMO这个岗位做的一些事情，包括进度、风险、资源、deadline等因素。实际上无论是版本发布、和版本迭代同步进行的跨版本需求以及内部的一些独立项目，都可以采用这种方式来管理，总体上还是为了提高资源利用率以及风险前置。

4、效率管理

效率管理，我们之前的做法，一方面是通过调查问卷的方式，在部门内部开展调查，获取日常工作中影响工作效率的点，归纳汇总进行专项优化。另一方面，随着团队规模的不断扩大，整体的效率问题也会变成团队成长的一大问题，需要时刻重视。

专项

自动化体系

自动化体系的建设，目前来说在绝大多数稍有规模的互联网公司，都有不同的应用。

有UI自动化、APP自动化、接口自动化、单测自动化、埋点自动化以及自动化打包发布校验等方式。

最初的目标都是提高效率，降低手工的成本，让工作的个体突出发挥自己的思考能力，而不是手工的体力劳动。

在自动化体系建设中，主要需要考虑如下几点：

场景&用例&执行：这里需要注意的是场景的覆盖、用例的筛选以及执行效率；
框架&数据&CICD：人多了，需要注意避免团队内部造轮子，撸很多自动化框架。我个人对这点的理解是有成熟开源框架的，别自己造轮子。内部已有的，评估是否需要优化，而不是推到重构。自动化体系中，CICD是至关重要的一环，别忘记自动化的初衷。
提效&反馈&参与：自动化最终还是要解决的是效率问题，如上文提到的效率管理，需要持续不断的获得反馈，然后改进优化。说到参与，很多公司是自动化和功能测试工程师做了区分，实际上如果为了团队的整体成长，需要全员参与进来，有参与感，员工才能有收获和满足感。否则大部分人只靠工作本身的内容，是很难做到主动提升自己的。

防资损体系

什么叫资损？造成公司&客户资产损失的都算。比如公司发优惠券，多发且被用户使用了，造成公司成本支出。

比如用户的优惠券满足场景但无法在支付中使用，用户有了资损，实际上还是公司买单。还有部分舆情方面的东西，比如某个外部消息导致公司上了热搜，外部对公司的评价变差，对企业品牌造成不良影响。

我们之前的做法是线上监控及时告警，专人专群处理。还有线上涉及资损的场景进行针对性校验，尽可能降低资损的成本以及造成的影响。

质量大盘体系

这里的质量大盘，大家理解为一个可视化的监控即可。即把上面我们提到的各项规则和措施，通过数据量化的方式管控起来，便于做决策。

性能测试体系

性能测试体系，由于之前的文章已经详细介绍过，这里不过多赘述，大家可以参考之前的文章。

文章链接：性能测试体系建设演进之路

稳定性治理体系

稳定性是一个很大的范畴，在质量保障体系中，稳定性的建设，主要集中在如下几点：

测试过程监控（如自动化通过率&冒烟通过率&性能容量变化趋势等）
测试环境稳定性治理（特别是有多套环境多个项目版本交叉使用以及频繁发布）
线上服务可用性监控（质量保障不仅只关注测试环境，线上的稳定性也至关重要）

写在最后

总感觉自己写了很多，又好像有很多内容无法一一表达。关于本篇文章中提到的部分内容，如稳定性治理，会在后续的文章中进行详细介绍。

本文仅供参考，请知悉。

如果本文对你有帮助，别忘记给我个3连，点赞，转发，评论，

咱们下期见！答案获取方式：已赞已评已关~

学习更多JAVA知识与技巧，关注与私信博主（666）

DevOps落地之五大基础保障体系建设

技术保障体系建设对于技术团队来说至关重要，为技术团队的交付效率、研发质量、系统稳定性以及资源成本做保障，很大程度上决定着技术团队的研发效能和技术体系的运转效率。互联网时代的业务形态变化快，对质量、效率、成本的要求更高，技术保障体系的作用越来越大。同时，DevOps 在各大互联网公司已经成为技术团队开展数字化转型和研发效能提升的可行性指导方法，进而也可作为技术保障体系建设的实施框架。

背景

作者曾就职于一家国内知名餐饮互联网公司，致力于餐饮产业全环节信息化、标准化和创新化的企业，技术团队规模500+。如同大多数创业公司一样，初期以追求满足业务快速上线为主，很难放缓脚步进行全面的技术体系建设，更没有充分时间进行技术保障体系建设。随着时间的推移，技术上的缺陷逐渐暴漏出来，甚至影响到业务的发展。

具体表现为如下6点:

系统编译、部署方式复杂，上线成功率低且耗时较长，一次上线经常持续到深夜。

缺少高可靠体系建设，故障发生时恢复时间较长甚至难以恢复。

IT资源管理混乱，带来严重的管理及安全风险。

研发缺乏有效的工程实践方法，研发效率和质量亟待提高，短时间内靠招人解决。

集中交付的研发模式以及强瀑布的项目管理方式无法满足频繁变更的业务形态。

技术团队的管理方式比较粗犷，缺乏有效的方法体系和平台工具支撑。

为解决这些问题，作者作为研发效能负责人，引导技术团队进行DevOps转型，通过组织的工程实践能力、制度体系、流程规范、平台工具几个方面进行了技术保障体系的建设规划。经过团队全员1年多的努力，初步完成技术保障体系建设。

本文将从5个维度讲述建设技术保障体系的方法。

技术保障体系包含5大基础保障体系：代码质量保障体系、测试质量保障体系、自运维管理体系、度量指标体系、稳定性体系，为技术团队的工程实践能力提升、产品研发流程规范落地、项目高效管理、研发效能提升等做保障。（限于篇幅，将概括性讲述）

同时，基于技术保障体系，作者主导搭建了技术团队的质量保障体系和精益运维体系（作为技术运营体系），作为技术团队研发质量和效率管理、系统稳定性管理的运营手段。作者通过项目（质量保障项目和精益运项目）的形式推进2个体系的周期性运转，同时希望通过大齿轮带动小齿轮的方式，确保技术保障体系的稳定运转。此部分，将在后续文章分享。

基于技术保障体系的质量保障体系

在管理方式上，以分层度量管理的方式驱动技术团队的反馈和改进：在CTO 层面，组建推进小组，把控改进方向，协调过程中问题解决；在技术部门负责人层面，通过部门质量分驱动发现问题和协调资源；在团队小组负责人层面，通过工程实践方法和平台工具最佳实践的方式，提升团队的工程实践能力和自运维能力，解决他们遇到的阻碍性问题。

下文将分别介绍技术保障体系中各基础保障体系的建设过程。

代码质量保障体系

对于技术团队而言，代码质量的重要性不言而喻。不过，在技术团队落实代码质量保障体系之前，研发团队表现出严重的问题。

集中交付的研发模式导致研发人员集中提测、集中上线，问题也会集中爆发，往往因为上下游服务依赖、协作沟通不畅导致项目上线延期。

研发提测质量差，导致测试时间严重压缩，职能间出现互相抱怨现象，协作效率差。

技术团队的改进，往往是脚痛医脚头痛医头，陷入局部优化的困境。并且，技术团队尚未掌握通过平台度量驱动团队改进的方法。

作者给出的解决方案是建立技术中心的代码质量保障体系，结合工程实践、流程规范、平台工具相结合的方法，通过分层度量驱动不同层级负责人发现问题和改进问题。同时，通过项目的形式推进代码质量保障体系稳定运转和落地。

代码质量保障体系

1）通过自运维管理等平台（CI）和单元测试能力的提升，培养一线研发人员代码持续集成、频繁构建的研发习惯，提前暴露研发过程中问题。

2）围绕代码生命周期设置质量门禁，比如在代码提交阶段，通过构建流水线中质量门禁自动把控研发人员每次提交代码的静态质量、单测、构建耗时等问题，质量门禁不通过则构建直接失败。并在团队内部实施每日构建一次流水线等原则，将问题的解决分布到日常。

3）专项项目治理，质量推进小组每周通过分层会议，分层管理技术团队二级和三级负责人。协助二级负责人分析各部门问题，协调问题解决资源，推进技术重构和代码评审等实践落地；赋能三级负责人工程实践方法，分享共性问题解决方法，协助解决阻碍性问题，推进单元测试、频繁构建、接口自动化测试、代码评审等实践落地。

4）通过部门代码质量分（各代码质量指标、质量待办等的加权综合值）作为部门代码质量的考核标准（平台扫描出来质量问题，作为减分项；部门内部通过实践执行标准发现的问题，登记为质量待办，作为加分项，鼓励提前暴露问题；待办延期完成则作为减分项），也作为作者推进各技术部门落地保障体系的抓手。

基于项目的周期性运转和推进，代码质量保障体系中工程实践方法和平台工具也在技术团队各层级执行和应用起来，以此形成技术团队的代码质量保障工作框架。

代码质量保障工作框架

在二级部门负责人会议上（处理过程），作者会提供质量分析报告以及各部门质量分（诊断过程），针对报告分析内容以及当周各部门形成的质量待办进行定性定责（仅限之前会上未确定优先级和负责人的待办），最终将问题都落实为平台质量待办，并确定计划完成时间。作者作为项目经理会持续跟进质量待办的完成情况，协调资源，协助问题解决。

代码质量保障体系管控着代码从“编写”到“发布”阶段的质量问题，为后续质量保障体系的建立打下基础，也是效能团队在技术团队成功建立的第一个保障体系。

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第1章的故事主线，其中详细讲解了代码质量保障体系中工程实践、流程规范、平台工具的落地执行过程以及实施策略等。

测试质量保障体系

当开发人员已经养成“频繁构建”的工作习惯时，测试团队大部分还处在手工测试阶段。为了让测试角色能够适配新的开发模式，产研团队必须进行测试左移实践能力的提升。经过作者调研，发现如下几点问题。

1）从全局看，技术团队的产研流程规范则强调强瀑布式的研发模式（PMO制定管理），开发人员完全提测完后，测试人员才能介入本次的测试流程。

2）从过程看，测试团队在技术团队比较弱势，往往成为上线延期、质量问题的受害者。

3）从局部看，由于测试过程全都是手工测试，之前为解决开发提测延期问题，招聘很多测试人员，当业务处在休整期时，资源利用率不高。

作者综合产研流程规范、测试人员能力、平台工具等维度，给出如下解决方案。

1）与PMO部门协作，优化产研流程规范，强调各角色左移活动环节，提前关注质量。

产品技术评审线：改造之前的评审方式，增加横向拉通的评审会议（比如增加全局的产品方案、技术方案评审），重新定义各负责人职责（测试负责人需提前介入上游活动环节）以及过程完成标准（关键环节的质量准入标准）。

测试流程线：改变之前的测试流程，将测试活动进行细化，按照执行顺序将用例管理、用例评审、制定测试计划过程进行分解，定义每个测试活动的参与角色。

2）与测试部门负责人协作，找出具有测开能力的测试人员，从技术中心维度组建自动化测试组，针对核心业务场景实施自动化测试，降低大量重复的回归测试时间，培养测试团队接口自动化工程实践能力。适配研发过程频繁构建、频繁验证的需求。

3）将测试过程的产研规范落实到在线测试平台。打通测试平台和自运维管理平台，将接口自动化测试计划接入每次部署流水线，实现自动化集成测试。

4）为解决测试人员编程能力弱问题，前期脚本实现由开发配合测试共同完成，形成结对编程；为解决上下游接口调用实现问题，组织开发提前实现场景化接口依赖的SDK；为解决造数问题，组织测试间互相提数据需求，由各测试人员实现并维护到平台造数中心。

以此形成技术团队的测试质量保障体系。此后，各部门接口自动化测试结果也作为代码质量保障体系考核的一部分，并由作者作为项目经理推进开展。

测试质量保障体系

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第2章的故事主线，其中详细讲解了测试左移实践过程中各角色职能职责的变化、产研流程规范的改进、在线测试平台的落地以及接口自动化测试实践的实现等过程。

自运维管理体系

2021年初，技术团队决定业务上云，并要求在第二季度完成全面迁移某云。上云对于任何没有相关经验的技术团队来说都是巨大的挑战。这种挑战不仅来自底层技术架构能力的改变，还有产研间的协作方式和研发模式的改变。只有寻找到能够适配云环境的管理模式、工程实践方法以及工具平台，上云后的降本增效作用才能够真正体现出来。

技术团队上云面临挑战的主要是技术体系的改造和适配，也就是技术保障体系和技术支撑体系的改造。因为只要技术保障体系和底层架构改造适配的好，就能够降低技术团队的上云门槛，研发人员只需了解一些基础的云原生相关背景知识，即可像原来一样工作。对于技术保障体系的改造，效能团队面临的挑战如下。

1）需要充分理解云上研发、云上运行服务的特点，充分利用其服务化、自助化、弹性伸缩以及资源共享特性，充分发挥公有云已有的功能，帮助技术团队屏蔽掉云原生相关的“专业”门槛问题，比如构建部署模式改变、配置管理升级、系统架构重构适配、安全风控担忧、资质认证、权限管控等方面的问题。

2）需要深入改造自运维管理平台（CI/CD），如何在不影响技术团队当前“研发习惯”的前提下，通过DevOps工作框架协助技术团队实现云环境下的协作模式和研发模式转型，进而协助技术团队实现团队自治，培养自运维能力。

作者综合技术团队持续集成的研发实践、基于虚拟机维度的平台部署实践以及技术团队的研发管理模式，给出如下解决方案。

1）基于GitLab 的CI/CD模块快速搭建基于Kubernetes 环境下的构建和部署平台，满足研发团队上云的基础诉求。同时，通过平台约束流水线触发规则、流水线终止操作规范、服务统一暴露方式等，避免影响到之前的产研协作效率和代码提测质量。

2）组织CTO和技术部门负责人讨论有关自运维管理平台改造升级的问题，确认改进方向，主要确认技术团队CI的实践理念，即快速集成、频繁构建、质量内建和快速反馈；以服务为中心建设CI/CD 平台，这个思路不仅要改造此平台，还需要改造CMDB等。

3）通过平台改善之前强职能部门间的协作方式（组织架构也要做相应调整），云环境下研发模式强调研发人员自运维，提升技术团队整体的自运维能力，弱化职能运维的管理。

结合技术工程实践和平台工具的改造，为技术团队落实自运维管理体系。

自运维管理体系

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第3章的故事主线，其中详细讲解了平台如何实现如上技术工程实践提升研发效率、保障技术团队的研发质量，研发人员如何通过平台实践自运维管理等。

度量指标体系

在软件开发领域，特别是研发效能领域，度量是一个无法回避的话题。

研发效能领域的实践者和软件领域的管理者只有掌握如何建立度量指标体系、如何选取关键的数据指标、如何做好度量运营以及掌握实践过程中的指导原则和方法，才能够从全局视角协助并驱动各层级管理者发现和解决团队中的问题。

在技术保障体系度量改进过程中，逐渐发现如下几个严重问题。

1）对于技术团队管理者来说，针对每个体系的度量指标都比较难以达成一致，缺乏有效的实践框架，核心问题在于缺乏对每个效能域的实践认知。

2）各平台拥有独立数据库，都有相应的度量模块，模块间缺乏有效的关联性，平台间的指标获取比较繁琐，需要互相提供API接口。

3）每次度量指标需求的实现都需要平台前端发版上线，灵活度不高。

团队采用轻量数据 ELT 形式，将业务系统的数据经过抽取、清洗和转换之后加载到数据仓库，实现“实时数据”和“T+1数据”的集中获取。表现层通过BI工具Metabase集成到各平台前端，指标变更只需调整Metabase数据逻辑规则和可视化方式即可，解决每次需求实现均需平台发版的问题。另外，针对研发效能域、持续交付域以及项目交付域，经过实践都落实了度量模型和指标，并且在研发管理体系、质量保障体系、项目管理体系中应用。同时，通过平台间消息（度量指标信息）驱动负责人和研发人员及时发现、反馈和解决问题。

以此形成度量指标体系，更便捷可靠地支撑技术保障体系稳定运转。

度量指标体系

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第4章的故事主线，其中详细讲解了平台如何搭建度量指标体系、如何选择合适的研发效能度量指标以及如何通过闭环消息驱动团队改进等。

稳定性支撑体系

公司经过一年的发展，技术团队已经初具规模，随着业务量的增加，告警事件和线上问题频繁发生，各技术部门也开始频发故障。每次研发核心例会上，各部门负责人经常会针对一个线上问题是哪个团队引起的而争执不清，因为每个问题的发生都是多面性的：可能是外部环境问题，可能是上下游服务依赖问题，也可能是整体技术架构问题。

从技术保障体系来看，作者在与技术团队做复盘过程中发现如下问题。

1）技术体系中以CMDB为中心的运维基础服务体系理念已经基本形成，并且CMDB已经完成以服务为中心的轻量化改造，但技术支撑体系的资源管理平台尚未进行适配，导致研发人员需到各资源管理平台自行管理操作，并且没有对接工单审核，很容易导致线上故障。

2）当系统稳定性较差时，各种监控告警信息、平台消息、故障信息对研发人员形成了消息轰炸，没有一个平台能够承载这些事件的管理、指挥解决以及知识沉淀，导致问题的处理效率较差。经调研，重复出现的同类型故障数占总数的13%。

3）部署过程规范线下约束较弱，部署前检查、部署过程中审核、部署后监控流程执行不到位，导致线上问题80%都是由于人为因素导致。

作者综合复盘结果，决定立项，通过精益运维项目推进稳定性体系的有效实施和落地。

1）联动架构运维团队组建资源治理专家组（分布式中间件、MySQL、虚拟机、日志等），改造各平台对接CMDB和工单系统，通过工单约束服务资源的申请、审核和解绑，将所有服务依赖的资源数据落实到CMDB，作为元数据管理，以CMDB作为技术体系全局唯一权威数据源。同时，CMDB支持定期与云平台和资源管理平台进行资源的自动化校准，保证数据的可靠性和唯一性。

2）搭建事件管理平台，收集和获取全面的事件数据，协助事件“指挥官”更加精准地进行事件指派；针对核心业务场景指定技术负责人作为指挥官，提高问题的解决效率；当问题定性为故障时，需走故障应急流程。同时，研发人员可以根据事件管理平台自查询分析历史共性事件的解决方案；并且通过分类，很容易度量分析各部门线上问题和故障等。

3）将部署过程中流程和规范的检查在自运维管理平台实现线上化管理。

以此形成稳定性支撑体系。同时，稳定性支撑体系将技术团队进行的压测、故障植入、故障应急响应、故障复盘等工程实践的结果作为事件源，纳入稳定性质量管理流程。