浅谈海量平台的质量管理

讲师介绍：在互联网电商公司，做质量保障和技术保障10年+，之前在1号店做质量总监和高级技术总监,负责企业信息化平台研发、自动化运维开发、质量保证、工程效率、CI/CD、敏捷开发转型、中间件研发等工作。长期深度参与千人研发团队规模的业务成长、架构演进、敏捷开发转型、工程效能建设、过程改进与度量、软件测试等从0到1、从1到N的多年变革过程和创新实践。担任过多年公司周年庆、双11等大促活动的技术保障总负责人和总指挥。

今天的主题离不开DevOps和敏捷，从质量的角度切入，看看DevOps的生态下质量到底是怎么做的。因为时间关系，我从全面的角度分享一下这些年的思考和实际做的案例。

1. 读懂质量

首先看一下质量是什么。回顾一下历史上的质量事故。

第一个事故是日本的卫星，因为一行错误代码损失了18亿。
第二个是我以前的例子，我们有一个开发，凌晨二三点要做配置切换，调了闹钟，但是闹钟没有响，公司损失了2万元的订单。
第三个也是历史上我们的某个团队，那次上线没有改任何代码，结果订单跌了几个点，公司损失了4万元的订单。

除了第一个例子，其他例子看起来好像跟代码没有关系，而这些都是质量事故，到底什么是质量呢？它是不是质量部门的事呢？

质量特性里除了功能还有什么特性？（现场互动）

这几个方面在软件开发里用得比较多，即功能、性能、安全、易用、可靠。研发部门中，各个角色的关注侧重点不一样。研发工程师关注功能、性能多一些，安全部门就关注安全方面，运维部门关注可靠、性能多一些，各有侧重点。

质量工程师是一个能较完整去关注产品质量方方面面的角色，也是促进其他角色去全面关注质量的角色。

最近三年，我做得比较多的是从业务、开发、架构、运维、安全几个方面来综合管控技术风险。技术风险管控是对公司的生意负责，不仅仅是功能上去没有问题就OK了。我在2015年有一篇电商大促技术保障的分享里有比较全面的总结，这里我今天主要谈质量相关的管控工作。

那么质量管理涉及到哪些方面？我们暂不从学术理论上来探讨，就我过去十年多互联网质量管理方面的经历来看，我总结下来，互联网应用的质量管理工作，主要涉及到了发布管理、变更管理、风险管理、缺陷管理、配置管理这几个方面。从后面要讲到的质量保障全景图里，也可以看到我这个观点。

2. 思考、挑战、趋势

先来看看互联网系统的质量面临着怎样的挑战。

第一，从系统视角来讲，是业务海量访问的考验。

对于核心业务，重要性自不必说，一旦出错，哪怕几分钟，也可能是动辄几百万的直接资金损失。同时，看似不在主路径上的业务，比如某些在用户体验上能体现出自家特色和差异、增加用户粘性的模块，或者那些可以带动主营业务的转化和增长的模块。

这些业务模块出错，从公司整个业务大盘上看，只有1%的出错率，而其实波及的是数万到数十万的DAU，如果再加上峰值倍数的放大，影响用户数也是非常巨大的。

我把这些叫做长尾业务保障点。所以，无论是核心业务，还是长尾业务，影响的都是公司某一块业务和产品的业绩。

对研发团队特别是质量团队来说，1%的概率也是不容忽视的，这是传统“二八原则”无法指导我们的地方。这就是海量业务给质量保障带来的压力和挑战。这也是未来软件研发行业的必然趋势。

第二，从商业视角来讲。去年，京东提出“***零售”战略，新的商业模式，对于研发团队来讲也是新的挑战。

首先，它的商业需求来自于各种用户，有公司内部的，有外部商家的，有在线顾客的……
第二，在巨大体量下，业务还要继续高速的增长；
第三，在技术复杂度上，承载业务的终端不仅仅是主APP，还有微信、QQ、小程序以及延伸的其他APP产品。而智能物联的兴起，又让软件产品从手机这个终端发展到了其他终端，比如冰箱、音箱、电视等等。
同时，在工程效能方面，对敏捷的实施提出更高的要求：业务响应和交付要快，同时要保障品质和体验。
另外，千人研发规模，意味着有大量的部门在一起协同工作，所以对协同效率的要求也高。
可以看到，这里其实是有很多冲突的。有时候为了赶进度上线，要被迫牺牲一点质量，有时候跨部门的沟通有效率问题，进度周期就很紧。所以这是非常困难的事情。

第三，敏捷转型的挑战。

这是我2013年做敏捷转型时亲身经历的挑战。正如上面提到的，公司的业务在快速增长、研发团队已经接近千人规模、系统技术复杂度在上升、跨团队协作效率面临考验……因此，提高交付能力，不能再无限扩大规模，而需要解决效能的提升问题。

在敏捷测试转型过程中，技术手段、角色分工在变化，所以人数也在变化的。

下图是敏捷测试团队的人员变化情况，图上的数字，对测试团队来说可能是一个悲哀的。当然，老板最喜欢这个数字，因为公司人力成本在下降，或者说业务在增长、但人力成本得到了有效控制。

所以从大局来讲，我们需要意识到这是趋势，也是敏捷改革、工程效能建设的正确目标。

3. 构建海量平台的质量体系

3.1 如何构建保障体系

面对这样的挑战，怎么做质量保障的体系呢？

首先，从管理上，在组织架构的设计上，要进行转变和调整。这是质量管理组织架构需要的形态，包括业务测试组、验收支持组、框架平台组、配置管理组、过程审计组、过程规划组、技术风险组。这些在我之前带过的团队都有涉及。根据研发部门情况和所处阶段的不同，图中罗列的这些既可以是虚拟角色，也可以是一个实体组织。
如果研发对应的业务涉及多平台的，此时可能一个测试团队只对口某一个垂直的平台，这需要垂直以外的横向团队进行支持。这是设计验收支持组的目的。
过程审计是对研发过程进行审计，过程规划是进行管理平台规划和过程改进的，风险组在很多团队是缺失的。对这个团队的要求比较高，需要综合的能力。
其他组从字面上比较好理解，就不多说了。

3.2 京东质量保障体系

对于京东商城前台来讲，涉及的产品线形态很丰富，前面讲挑战的时候我也提到了。承载业务的被测对象从APP、咚咚、小程序等延伸开来，这个示意图描述了这个复杂情况。这时候质量保障各种包括哪些呢？

我这里尝试着概括总结出一套适合互联网测试行业参考的一套体系。

下面这个图，是我思考整理的质量保障体系一个全景图，这里稍微展开说一下。

有两个方面，左边是以技术为主的，右边是以管理为主的，两边是相辅相成的。左上角的是测试策略。每家公司都会根据自己的经验教训和业务特点，制定适合自己的测试策略。我这里总结的策略模型，希望能给同行带来参考。

从白盒测试开始，到App功能、性能、API和微服务以及用户体验和自定义的专项测试。这是测试团队最核心、最主要的工作。这些定义可以解决策略是否完整的问题。那么是否可以被执行、是否得到有效执行，是下面质量平台和右侧过程管理要来协助解决的问题。

质量平台包括质量管理平台、测试执行平台和测试监控平台。监控和运维有点区别，一部分是对代码的，一部分是对业务质量进行监控。过程管理与改进包括了流程标准规范、事件问题管理、过程度量与改进、演习演练管理、合规审计、敏捷抵近实施。量化管理包括能力评估模型、敏捷度量模型、平台产品度量模型、质量度量平台。

平台产品是我们有大量的平台，我们怎么来度量这些产品的质量？这也是要考虑的，这是支撑整个研发流程的一套产品。

3.3 京东“四化”建设

我对工程效能建设的总结是：“四化”建设，即标准化、自动化、积木化、智能化。

3.3.1 标准化建设

标准化建设，包括系统、应用、配置和人、角色，以及组织、团队、绩效。绝大多数标准、规范等的确立，通过过程定义组织比如QA团队来牵头解决。而最难的是组织团队和绩效，这是要从研发管理决策层发力才能有效解决的，需要在管理上进行创新。

我举个1号店的例子。在日常工作中，常会涉及要申请一个应用的上线、扩容，或者申请代码库访问权限等等，这些环节要有人审阅，要有人批。我们在做运维发布平台、代码库管理平台等平台时，要这些审核环节要实现谁来批，这就涉及组织架构的问题。

同一个部门，大几十号人甚至上百人，有一部分人在北京，有一部分人在上海，部门负责人是同一个人，人事上的组织架构比较扁平，最多只到三级部门，不设四级部门。

这些审批确认的事情，没必要不需要卷入他，只需要上海或北京某个团队Leader确认即可。或者，有时候是跨团队的项目，涉及多条业务线，项目周期还不短，几个部门抽调人员共同完成。

在这个项目上，有个负责人。在行政关系上，他可能只是项目中某一部分人的上级，项目中其他人不属于他管辖的团队，而这个项目的相关审核审批都需要这个Leader负责。

所以通过现在行政组织上的人事数据没有办法解决审批链的问题，怎么办？其实，再细想想，上面说的情况，不仅仅是审批上的事情，牵涉到整个研发过程中沟通、协作、决策、日常团队管理的方方面面。

所以最彻底的解决办法，还是在组织架构上想办法。我们建了一个新的实体组织，叫Domain，这个组织是依托现有人事上的组织结构而衍生出新的实体团队架构，Domain的大小和划分由管理者依据一定的标准规范决定。Domain的数据不由人事部门维护，是由研发部门内某团队提供维护和管理。

这个例子是2014年我们在敏捷实施过程推动系统解耦的例子。我们经常听到说某个系统很乱，问题很多，具体是问题点在哪里，只有这个团队里少量熟悉情况的一线工程师知道坑在哪里。但是涉及应用多，要他们去花大量时间梳理又不现实。

这样的团队想要实施2周交付、Story拆解等敏捷实践几乎不可能。我让配置管理做完代码工程和编译构建的标准化，有了这个图后再来看这个团队，每个人都非常清晰地看到所有的应用在依赖谁，老板也看到了，新入职的初级程序员也看到了，这时候架构解耦、重构的时机就到了，再去推动各相关方的难度也降低了。

最后这个团队成为敏捷转型成功的典型团队，研发的交付效率名列前茅。

下图的表格在前两年有看到被同行作为DevOps的一种实践在相关大会上分享过。这个表格是2013年我们质量团队的原创。我们业务线很多，有各种不同的业务特征，有做财务的，有做前台的，用统一的代码质量标准是不行的。所以我要求工程效能团队在最初设计时，就支持用不同的特征来做不同的约定，QA团队也对应地制定规范。其中不少实施细节，时间关系就不展开了，欢迎线下沟通。

3.3.2 自动化建设

自动化建设是两环。测试自动化策略就是分层设计、配合执行。这个现在已经是行业普遍共识，就不解释了。我们看几个例子。

举个例子，京东的代码扫描是食蚁兽，日均检查服务项目240多个，发现问题平均40个/天，可灵活配置检查规则。

下图质量监控，电商网站搞很多活动，面对不同的消费者。这些活动一周要花20个人来进行检查，运维监控平台侧重系统平台层面的，这个监控侧重某一具体业务层面的质量问题。

我们有很多平台，这个活动渠道对应的是APP，但微信里没有。很遗憾，这个活动在微信渠道放出去了，我们也会进行平台适配检查。

3.3.3 积木化建设

我的理解，积木化建设就是平台架构演进规律。积木化对于一个企业来说，是商业能力的进化，对一个研发团队来讲，是技术能力的进化。

从我带领过的工程效能平台、自动化运维平台、中间件平台、质量平台等建设经历来看，它肯定是从小型工具、框架原型、零散脚本，通过模块化、服务化和可视化的一系列改造进程，最后逐步形成一套灵活、可插拔、可组合对外提供服务的新的生态体系，这就是我们演进的过程。

这个过程也达到了积木化的最终目的——赋能。面对新的业务、新的应用需要我们提供解决方案，我们只要把需要的东西挑出来，做一些简单的改造和配置，就可以了对外了。

比如这个例子，现有系统有各自原来的模块在工作，怎么协作起来？就是这样一个积木的建设。

YHD工程效能云服务是我在1号店做的。通过各个环节上将原有封闭的系统进行功能服务化、数据标准化、流程自动化的一系列改造，最终形成了一套完整的研发管理服务有机整体。

内容比较丰富，时间关系，简单来说，两条。

第一，人。工程师进到公司，所有东西，包括代码库的权限、能看到的应用、做的发布等等都自动管控起来。

第二，产物。当一个研发工程师产生一行代码的时候，这个代码在哪存、在哪打包、怎么出去、改了什么、经过哪些测试、上线结果、监控反馈、研发测试成本收益、过程质量/效率等等。

3.3.4 智能化建设

智能化建设，我们也还在路上。

现在分享的案例不多。这是我们用户的反馈，但对于收集，不同的问题需要给不同的部门，对用户在线上提交的反馈问题进行了分析，用了语义匹配和聚类分析。比如说某些类型问题是反馈给运营部门的，某些问题是反馈给研发的等等。

4. 总结与展望

从前到后，一个完整的视角来看。因为DevOps打破了墙，形成整体的管理，但是里面的矛盾需要平衡，最终的目的是追求质量管理的极致。

这是我之前的一位质量经理的心得，我觉得很有共鸣，最后也分享给大家。很多公司都有建设平台的团队，质量部门也是如此。

在DevOps流行的今天，大家似乎热衷于此，而忽视了真正在业务一线为质量保障奋斗的工程师们。不要为了做工具而做工作，我们做工具是为了解决问题。高大上的工具，无论用了多牛的技术，落不了地，做了也白做。强调质量，我们的初心是为实现产品给用户带去的价值。