浅谈海量平台的质量管理

白凡

分享：顾复-京东商城首席测试架构师
编辑：白凡

讲师介绍：做质量保障和技术保障13年，在互联网电商公司，之前在1号店做质量总监和高级技术总监。从质量这条线上成长之后，担任了公司的大促保障的技术总负责人和总指挥人。最近六年，主要的工作是围绕质量保证做工程效率、CI/CD、敏捷开发转型。

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

1. 读懂质量

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

• 第一个事故是日本的卫星，因为银行代码损失了18亿。
• 第二个是我以前的例子，我们有一个开发，做支付的，凌晨二三点要做，调了闹钟，但是闹钟没有响，损失了2万。
• 第三个是我们购物的团队，那次上线没有改任何代码，结果订单掉了损失了4万。

这看起来好像跟代码没有关系，这些都是质量事故，到底什么是质量呢？它是不是质量部门的事呢？它围绕什么呢？

质量特性里还有什么特性？还有非功能性、安全、性能、体验都包含什么？
发布管理、变更管理、风险管理、缺陷管理、配置管理都有，我做得比较多的是管控风险。风险管控是对公司的生意负责，不仅仅是功能上去就没有问题了。
这几个方面在软件开发里用得比较多，即功能、性能、安全、易用、可靠。运维更多关注性能和安全，对于研发工程师来讲，功能、性能关注更多，安全部门就关注安全方面，各有侧重点。

2. 思考、挑战、趋势

做了这么多年，经历过很多挑战，从系统视角来讲，这是海量业务的考验。1%的概率影响的是十万DAU，再加上峰值背书的放大，对用户的影响范围更大。一个发生概率1%的考验，对研发团队来讲是不容忽视的，这是我们面对的压力。

去年，京东提到一个“无界零售”战略，对于研发团队来讲是新的挑战。

• 首先它的需求来自于各种用户，有内部的，有商家的，有用户的
• 巨大体量下还要求高速的增长
• 技术复杂度上，不仅仅是手机APP，还有手机QQ、小程序以及延伸的APP产品。涉及平台非常多，从手机这个终端到了其他终端，比如冰箱、音箱、电视等等。
• 工程项目方面，对敏捷的实施提出更高的要求，要快，同时质量不能下降
• 因为有大量的部门在一起工作，所以效率要求高。这里其实是非常有冲突的。有时候为了上线，要牺牲一点质量，有时候跨部门的沟通有非常大的效率问题，所以这是非常困难的事情。

下图是敏捷测试团队的变化，这是我2013年做敏捷转型时的挑战，它的业务在增长，研发团队在变化，敏捷测试转型过程中，人员是在变化的。老板最喜欢这个数字，因为成本在下降，速度在上升，但是对比研发部门来说是悲哀的。

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

3.1 如何构建保障体系

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

1. 首先，从管理上，在组织架构设计上，要进行敏捷转变。这是质量管理组织架构需要的形态，这些角色在我之前的团队都有，包括业务测试组、验收支持组、框架平台组、配置管理组、过程审计组、过程规划组、技术风险组。

2. 我们是多平台的，可能某一个垂直的平台只关注一个团队，这需要垂直以外的横向团队进行支持。

3. 过程审计是对研发过程进行审计，过程规划是进行改进的，风险组在很多团队是缺失的。对这个团队的要求比较高，需要综合的能力。

3.2 京东质量保障体系

下图是质量保障体系全景图，对于京东商城前台来讲，这里面有APP、咚咚（是企业内部与商家的沟通）、小程序等等，这些背景下，也有企业面对的复杂情况，这时候质量保障是什么呢？

有两个方面，左边是以技术为主的，右边是以管理为主的，两边是相辅相成的。左上角的是测试策略，从白盒测试开始。现在比较火的视频直播、点播，是以内容生态为发力的第二波互联网发力，这里面也有很多东西。埋点是对用户APP产生数据的跟踪。用户体验包括网络、多APP和交互。

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

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

3.3 京东“四化”建设

京东商城工程效能是“四化”建设——标准化、自动化、积木化、智能化。

3.3.1 标准化建设

标准化建设，包括系统、应用、配置和人、角色，以及组织、团队、绩效。最难的是组织团队和绩效，这是从管理发力的，其他的是可以通过QA。我们在做研发过程中，要申请一个上线、扩容，甚至要申请代码库等等，要有人审阅，要有人批。同一个团队，有一部分在北京，有一部分在上海，老板是一个，但实际工作里，这些审批流程不需要到老板，有时候是跨团队的合作，这些问题通过现在的行政组织没有办法解决，但是我们又必须要经过这些环节工作，怎么办？这时候，我们建了一个虚拟的组织，这个虚拟的组织打破了现在的行政组织，衍生出虚拟的团队架构，不是由人事维护，是由配置管理维护。

这个例子是2014年的，原先某个系统很乱，问题很多，我们做了标准化建设后，团队里原来是一两个工程师知道坑在哪里，但是这是不行的，但是我们要所有人知道坑在哪里。有了这个图后，非常清晰地看到所有的应用在依赖谁，老板也看到了，新入职的初级程序员也看到了，就能进行解耦。

下图表格在前面有看到同行分享过，这个表格是我们之前的原创。我们业务线很多，有各种不同的业务特征，有做财务的，有做前台的，用统一的代码质量标准是不行的，我们用不同的特征来做不同的约定。

3.3.2 自动化建设

自动化建设是两环。测试自动化策略就是分层设计、配合执行。

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

下图质量监控，电商网站搞很多活动，面对不同的消费者。这些活动一周要花20个人来进行检查，运维更多是看到平台层面的，这个监控是看质量层面的问题。

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

3.3.3 积木化建设

积木化建设就是平台架构演进规律，对于公司来说，是商业能力的进化，对技术来讲，是技术能力的比进化。

对内部平台来讲，我们理解是它肯定是从小型的工具、框架、原型到零散的脚本，通过模块化、服务化和可视化，最后形成一套东西，这就是我们演进的过程，积木化的目的最后是为了赋能。我们把自己要的东西挑出来，形成这样一个系统就可以做了，做一些简单的改造。

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

这是我在1号店做的，把当时所有做的内部平台都集成在一起。总结了两条，人进到公司，所有东西，包括代码库的权限，能看到的应用、做的发布等等都管控起来。当一个研发工程师产生一行代码的时候，这个代码在哪存、在哪打包、怎么出去、改了什么、经过哪些测试、上线之后有没有报错等等，这个环节通过体系构建起来。当初做的时候是一块一块做的，做下来后非常高效。

3.3.4 智能化建设

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

4. 总结与展望

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

不要为了做工具而做工作，我们做工具是为了解决问题，工具没有用，做了也白做，无论用了多牛的技术，没有用就不要做了。我们初心是强调价值。