网安加·百家讲坛 | 王立杰：质量与卓越：在DevOps中平衡开发速度与产品质量

作者简介：王立杰，资深敏捷创新教练、IDCF(国际DevOps教练联合会)联合发起人、华为云MVP、中国DevOps社区发起人，曾任京东首席敏捷创新教练、IBM客户技术专家，江湖人称“无敌哥”；最新著作《敏捷无敌之DevOps时代》、《京东敏捷实践指南》；指导过京东、小米、OPPO、海康威视、百度、招商银行等组织的敏捷转型。

一、DevOps的核心理念及其对速度和质量的双重追求

在当今的商业环境中，每家企业都深知安全无小事，因为安全问题不仅复杂，而且至关重要。同样，质量也是企业不可忽视的核心要素，安全与质量往往紧密相连，难以分割。在这样的背景下，DevOps作为一种融合了开发与运维的先进理念，逐渐成为企业提升效率与质量的关键工具。

当我们提及DevOps时，大家可能并不陌生，但DevOps的真正核心在于打破传统开发与运维之间的壁垒，实现两者之间的无缝协作，从而加速产品交付，提高产品质量。

但对于DevOps的概念，一千个读者就有一千个哈姆雷特，大家可能会想到如速度、价值、质量、流水线、精益、敏捷等。这些答案都是从不同的视角出发得出的结论。业务人员可能更关注价值，测试人员可能更看重质量，开发人员则可能更关心速度。

正是这些不同的关注点，推动了DevOps在不同领域的发展，形成了多个分支。例如，DevSecOps将安全融入DevOps流水线中，DevQaOps则专注于提升测试效率，而BizDevOps则强调从业务需求出发，推动DevOps在业务层面的应用。此外，随着AI和大数据技术的发展，这些新技术也为DevOps注入了新的活力。

从广义的角度来看，DevOps已经超越了传统的开发与运维范畴，延伸到了安全、业务架构、合规等多个领域。它更多地被定义为一种端到端的概括，覆盖了企业全生命周期的各个环节。在这个过程中，需要所有相关部门的协同合作，才能确保产品的高效交付与高质量。

然而，在实施DevOps的过程中，企业也面临着诸多挑战。特别是对于那些发展多年的大型企业来说，部门墙的存在往往阻碍了不同部门之间的协同合作。因此，如何打破部门墙，实现跨部门的高效协同，成为企业实施DevOps的关键。

回顾DevOps的发展历程，我们可以看到它为企业带来的巨大变革。从最初的代码构建需要数小时，到如今的快速迭代与持续交付，DevOps极大地提升了企业的工程与管理能力。

以特斯拉为例，它之所以能够在汽车行业中脱颖而出，很大程度上得益于其快速迭代的能力。特斯拉每周可以对每一款车型进行多次生产变更，这种速度在传统汽车行业中是难以想象的。特斯拉之所以能够实现这样的速度，背后离不开其强大的工程和管理能力。它采用了一套AI预测机制来预测未来芯片等关键部件的供应情况，并授权员工灵活采购，从而确保了生产的连续性和稳定性。同时，特斯拉还采用了硬件DevOps的流程，通过寻找可替代的芯片和自动化生产等方式，进一步提升了其生产效率和产品质量。

同样地，在国内也有许多企业应用DevOps理念取得了显著的成果。比如元气森林，通过将互联网产品的迭代思路应用于饮料行业，实现了产品的快速迭代与市场的快速响应。这种速度和质量并重的做法，对许多传统饮料行业来说，属于降维打击，这也是元气森林在竞争激烈的饮料市场中脱颖而出的关键所在。

二、在DevOps中，平衡开发速度和产品质量的关键策略

那么，如何实现快速交付的同时保证高质量呢？结合笔者在京东、小米、OPPO、海康威视以及京东方等多家企业的实践经验，下面分享一些关于如何通过DevOps理念优化企业流程，从而提升效率与质量的思考。

策略一：粒度与解耦

首先，我们要明确的是，无论是广义还是狭义的DevOps，其本质都是构建一个高效的流水线，让价值流快速、顺畅地流动。正如河流中的水流，当遇到小颗粒的石头时，能够轻松绕过，保持流速；而遇到大颗粒的石头时，则会受阻，流速减缓。因此，在DevOps实践中，我们需要关注管理的颗粒度。

管理的颗粒度越小，意味着我们能够更精确地控制每一个环节，从而降低阻力，提升效率。这涉及需求的颗粒度、内部任务拆解的颗粒度，以及交付的最小颗粒度。合理的需求颗粒度应该确保大部分任务能够在较短的迭代周期内完成，比如三个工作日或更短的时间内。这样的需求颗粒度有助于保持团队的敏捷性，快速响应市场变化。

除了管理颗粒度外，解耦也是提升效率的关键。在大型企业中，系统往往高度耦合，导致改动一处，牵动全身。这不仅增加了维护成本，也降低了系统的可扩展性和灵活性。因此，我们需要通过技术手段，如微服务架构，将系统拆分成更小的、独立的服务单元。

我们常听到关于中台建设、技术拆解、微服务架构的讨论。这些概念的核心目的都是提高系统的响应速度和灵活性。以京东为例，早在2014年，他们系统就开始进行大规模的应用拆分，到了2016年，应用数量已经高达2600多个，服务数量更是庞大。这样的拆分不仅是为了让系统更快，更重要的是从管理和系统的角度降低耦合度，提升系统的可维护性和可扩展性。

当然，每家企业的具体情况都不同，我们不能盲目追求所谓的“最佳实践”。而是应该根据企业的实际情况，从团队的架构组织、分支模式、测试模式、架构部署、基础设施、数据库等各个维度出发，思考如何解耦、如何降低管理颗粒度。

策略二：内建质量

然而，仅仅拆分是不够的。我们还需要思考如何确保在高速交付的同时，保持高质量。这里就不得不提到全面质量管理的大师戴明博士。他提出的14条原则中，第三条对我们特别有启示意义：停止依靠大规模检查去获取质量，而是要实现内建质量。

内建质量，简而言之，就是在产品或服务的生产过程中，将质量控制融入每一个环节，而非仅在最终环节进行检验。以矿泉水为例，好的水源、多层次的净化、灌装过程中的严格消毒，共同造就了一瓶好水。这样的质量不是靠最后的质检员来保证的，而是在生产过程中逐步实现的。同样，在软件开发中，我们也应摒弃过度依赖手工测试的做法，转而通过内建质量的方式，确保每一个环节的输出都符合质量标准。

那么，如何在软件开发中实现内建质量呢？

从流水线的角度来看，关键在于在各个关键环节设置质量门禁。这包括需求门禁、代码质量门禁、测试质量门禁以及竞品质量门禁等。通过这些门禁的设置，我们可以确保只有符合特定要求的需求、代码和测试才能进入下一个环节，从而有效避免质量问题在后续环节中的放大。

在需求管理方面，我们将需求拆分成小颗粒度，并为每个需求设定准入标准。这些标准包括验收标准、UI/UE原型、外部依赖关系的打通、安全合规和性能要求的提出等。此外，我们还提出DoR，确保所有相关方都已做好准备。同时，在需求完成并准备上线时，也需要满足一定的准出标准，以确保需求的质量得到保障。

策略三：一包到底

在多个组织中，我们发现分支和打包、发布过程特别混乱。因此，我们特别强调“一包到底”的发布策略。这一策略要求从代码库构建出的一个包，在经过各个环境的测试并满足质量标准后，才能被发布到线上。这样可以确保发布到线上的包与最初开发和测试的包是一致的，从而有效避免质量问题的发生。然而，在实际操作中，我们发现很多公司在早期都难以做到这一点。这主要是因为大家的理念还没有跟上，缺乏对内建质量和一包到底重要性的认识。

综上所述，实现高速交付下的高质量管理，需要我们在生产过程中融入质量控制，设置质量门禁，严格管理需求，以及采用一包到底的发布策略。只有这样，我们才能在保持高效率的同时，确保产品的质量得到持续的提升。

策略四：左移和右移

在软件开发与产品交付的过程中，测试策略的制定至关重要。其中，“左移”与“右移”作为两种关键的测试理念，对于平衡速度与质量具有重要意义。

首先，我们来谈谈“左移”。左移测试策略的核心在于将测试活动尽可能提前到软件开发周期的早期阶段。通过编写大量的单元测试用例，我们可以确保每个代码行在单独测试时都能正常工作。这种做法的好处在于，它能够在源头上发现并解决问题，从而降低后期出现质量问题的风险。单元测试用例的编写不仅有助于提升代码质量，还能促进开发人员的代码设计能力，确保他们在编写代码时就考虑到测试的需求。

然而，仅仅依靠左移测试策略是不够的。在实际项目中，我们还需要考虑速度与成本的平衡。有时，为了追求更高的质量而投入过多的时间和资源，可能并不划算。这时，我们就需要引入“右移”测试策略。

右移测试策略的核心在于将测试活动延伸到软件开发的后期阶段，甚至直接面向终端用户。通过灰度发布、用户反馈收集等方式，我们可以了解用户对产品的真实需求与反馈，从而对产品进行针对性的优化。

以元气森林为例，他们通过在社交媒体上发布广告，广告中明确标注了产品的特点：“0糖、0脂、0卡、猕猴桃味”，这种精准的定位和明确的宣传会吸引感兴趣用户点击并跳转到电商平台购买产品。然而，当用户点击广告并跳转到购物平台时，却可能会遇到商品不存在或链接错误的情况。面对这种情形，用户的第一反应往往是认为自己点错了链接。当用户再次尝试点击广告并仍然无法找到对应商品时，他们可能会开始怀疑运营团队是否配错了商品链接。此时，如果用户选择在购物平台上搜索该商品，并添加了多个关键字进行精确搜索，但仍然无法找到，用户可能会感到困惑和不满。

然而，这正是元气森林所期望的测试效果。他们通过这种方式，测试了用户对这款新饮料的兴趣程度。如果用户对这款饮料不感兴趣，那么即使投入大量人力物力进行开发，也可能无法获得市场的认可。元气森林通过这种收集用户反馈，了解用户对产品的兴趣程度，并据此决定是否继续开发该产品的测试方式，不仅节省了成本，降低了开发风险，还能更准确地捕捉市场需求。

除了元气森林的案例外，灰度测试也是平衡速度与质量的重要手段之一。以京东和OPPO为例，他们在推出新版本或新功能时，都会采用灰度测试的策略。他们选择一小部分用户作为测试对象，观察他们在新版本上的使用情况，包括崩溃率、用户投诉和上传的信息等。如果测试结果显示新版本表现良好，那么才会逐步扩大测试范围，最终将新版本推向全体用户。

京东和OPPO在灰度测试上的要求略有不同。京东要求的崩溃率控制在千分之一到千分之二之间，而OPPO则要求更为严格，崩溃率必须控制在万分之五以下。无论是京东还是OPPO，他们都通过灰度测试成功地平衡了速度与质量，提高了产品的稳定性和用户体验。

这些实战案例为我们提供了宝贵的经验和启示，帮助我们更好地理解和应用测试策略中的左移和右移理念。