分享嘉宾

杨政权，腾讯云 Serverless 中心专家架构师，曾任 ThoughtWorks 中国北美事业部技术总监，先后担任大型团队的研发组长、技术总监和企业架构师角色，作为客户主要的技术接口人，主导并参与客户的技术战略制定、技术战略实施和企业架构治理的过程中，并积极参与到 DevOps、领域驱动设计、Serverless 和软件质量治理等各个社区中。

01. 

研发效能提升的目标和阻力

1.1 研发效能治理的目标

首先我们看一下典型的 SaaS 软件商业模式，无论是 SaaS 软件初创公司还是企业内部一个新兴的业务，一开始都会面临这样一个假设性问题：如果这个问题得到解决，可以为业务带来增长、为企业带来营收，但重要的是：这有可能并不是客户真正的痛点，这只是基于我们当前的认知所形成的一个有待验证的「假设」。之后企业会针对这个问题提供解决方案，然后把解决方案交付给客户，在取得一些成功之后，我们会尝试推向更大的市场和用户。如果这个方案在一家公司能够复制，我们会寻求在同行业或者跨行业的客户中识别更多的增加机会，也可以采用先落地再扩展（Land-and-Expand）策略，在存量客户中挖掘更多的增长机会。

从这个目标来思考研发效能提升，对于一些司空见惯的实践也会有更加深刻的理解，比如统一代码规范、引入自动化测试等等。因为我们认为符合规范的代码可以去提升软件的维护性，可以降低问题到解决方案的成本，所以我们要坚持代码符合规范；由于人工测试效率较低，在软件规模扩大时，我们认为通过引入自动化测试可以更加高效地验证解决方案和问题的匹配度，从而加速从左到右的价值流动，所以我们要坚持测试自动化。

同时从这个目标出发，在实践层面会有更大的想象空间：

• 如何加速端到端的价值流动/strong>

在产品设计中我们可以主张 MVP 的概念，一开始并不是要提供一个大而全的解决方案，而是找到 MVP –  最小化可行产品，快速验证想法，验证产品是否符合市场客户预期，然后取代手工部署应用的方式，做自动化运维、自动化应用部署，快速把解决方案推向市场与客户。也许我们可以参与到架构治理和产品设计中，制定指标定量分析软件架构的灵活度，让产品更加灵活，可以低成本适配客户需求；也许我们也可以尝试自动化的基础设施管理，缩短基础设施准备时间。

• 如何缩短反馈周期/strong>

我们交付的功能是否有真正创造价值据 Standish 的研究显示：20% 的软件特性经常被使用，而 30% 的特性偶尔使用，剩余 50% 的特性几乎很少使用或者完全不用。也许我们也可以主动尝试类似 A/B Testing、NPS（Net Promoter Score，净推荐值）等方法，让用户的反馈快速传递到产品团队。通过这个目标也可以驱动研发效能治理人员更多地参与到产品设计、架构设计、基础设施管理等工作中。

传统的运维方式还需要做容量预测，但难以在成本和效率之间平衡：当人工计划容量低于实际流量时，流量溢出、扩容速度慢，基础设施无法支撑实际业务需求；计划容量大于实际流量时，资源利用率低，企业成本的增加。

• 软件架构设计

可能有些同学会质疑：「基础设施的问题，似乎与研发没有什么关系」。但对于解决方案的复制，思考的视角不应该仅仅停留在基础设施级别，软件架构的设计也同样重要。从单体架构拆分成微服务，甚至更细粒度的函数（FaaS），是近年来业界非常流行的一个软件架构设计趋势，大大降低了解决方案复制的成本。

基于传统的虚拟机部署，一个应用的各个组件可能部署在多个虚拟机上，对于新的客户通过复制虚拟机的方式来复制解决方案。这种方式不但维护成本高，而且只能通过复制虚拟机的方式来支撑更大体量的用户，来满足弹性的诉求，而通过进一步拆分架构，把单体架构拆成微服务之后，解决方案的复制可以进行更加细粒度的控制。以一个电商应用为例，订单、仓储、物车等各个业务模块对弹性的要求是不同的，不管我们选择什么技术实现，这些弹性特征都不会变化，本质上这是业务需求的一部分。

除此之外，研发团队的工作负担重也是研发效能不足的重要原因之一，企业内部重复「造轮子」的现象屡见不鲜，也许这也是近年来中台、平台等概念流行的原因之一。

• 团队协作

前后端分离是一种典型的研发团队协作方式，后端提供 API，但有时候 API 无法及时提供，而前端开发者不了解服务器、数据库等搭建知识，也不了解后端的编程语言，具有一定的学习门槛，无法及时进行集成，导致上线时间延期，进而影响价值的流动速度，这些在制品（WIP）并没有形成完整的解决方案，也无法交付给客户使用，潜在的集成问题还有可能导致开发工作量增加。

举措二：分而治之，有的放矢分配投资

「领域驱动设计」是微服务设计重要的方法论之一，其中分为战略设计和战术设计两部分。战略设计的核心价值在于帮助企业从更加宏观的视角看待自身业务能力，而不是走完全采购或者完全自研的两个极端。通过从业务能力的角度分析哪些是企业的核心域，哪些是支撑域，哪些是通用域，对于核心域投入 80% 的研发力量，给企业带来差异化的竞争力；对于通用域，比如内容管理系统、登录、认证等方面，与企业核心竞争力无关的，完全可以交给云厂商或者第三方企业，使用开箱即用的标准化功能：

SSR 对于企业来说最大的价值在于实现业务自闭环，对于前端开发者来说，无需等待后端提供 API ，就可完成整个业务的端到端开发和测试，加速从左到右的价值流动；其次基于同样的基础设施描述文件，只需修改简单的配置，就可进行复制，进一步避免开发、测试和生产环境不一致的问题。

03. 

Serverless 发展趋势预测

最后从个人的角度，分享一下对 Serverless 下一阶段发展的展望：

第一个趋势是：「Serverless + X」

能够看到很多融合 Serverless 理念的产品在不断诞生，比如最近各大云厂商发布了 Serverless DB、Serverless 中间件、Serverless 容器平台等产品。从应用的视角来看，除了计算之外，还要考虑文件系统、对象存储、数据库等等，所以我认为未来动态伸缩、按量计费的 Serverless 产品矩阵会越来越丰富。

另外一个趋势是：「Serverless 作为应用的执行引擎」

这种形态下 Serverless 对于用户来说是无感知的，由于 Serverless 提供成本、可维护性、可扩展性等方面有巨大优势，Serverless 可以作为支撑 SaaS 等应用的底层驱动和引擎，进一步提升产品自身的竞争力。

此外基于 Serverless 理念的产品或者解决方案和边缘计算会有更好的融合，充分去利用云边端各个节点的算力，释放边端的潜能，在网络带宽延迟、能耗有限、数据敏感等复杂场景下会有更多的落地案例。

最后在开发工具、开发体验和方法论指导方面，和 Serverless 相关的工具和生态也会更加成熟。

以上是我主要分享的内容，谢谢。

本文作者：杨政权，编辑：冯怀玉。

• GitHub: github.com/serverless

• 官网: cloud.tencent.com/product/serverless-catalog

活动预告：

高可用架构技术分享 meetup 又开始了，高可用架构联合数列科技，本周六5.22，与唐扬、胡丽麟,徐汉彬、刘霄鹏四位老师，继续深入探讨峰值流量下的高并发实践。识别二维码或者点击阅读原文报名。

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览208256 人正在系统学习中

来源：高可用架构