以下内容来自「云+ 社区技术沙龙 - 云原生专场：《从 Serverless 看软件研发效能的变革》」，深度好文，预计阅读需 35 分钟。01.
研发效能提升的目标和阻力
首先我们看一下典型的 SaaS 软件商业模式，无论是 SaaS 软件初创公司还是企业内部一个新兴的业务，一开始都会面临这样一个假设性问题：如果这个问题得到解决，可以为业务带来增长、为企业带来营收，但重要的是：这有可能并不是客户真正的痛点，这只是基于我们当前的认知所形成的一个有待验证的「假设」。之后企业会针对这个问题提供解决方案，然后把解决方案交付给客户，在取得一些成功之后，我们会尝试推向更大的市场和用户。如果这个方案在一家公司能够复制，我们会寻求在同行业或者跨行业的客户中识别更多的增加机会，也可以采用先落地再扩展（Land-and-Expand）策略，在存量客户中挖掘更多的增长机会。
在以上的流程中，企业所处的阶段不同，其关注点也不尽相同：
- 从问题到解决方案：我们考虑的是问题和解决方案的匹配度（Problem-Solution-Fit），评估的角度主要看解决方案是否真的可以解决对应的客户问题。
- 从方案触达市场和用户：企业更多会关注产品市场契合度（Product-Market-Fit，PMF），这往往也是很多初创企业失败的主要原因，我们具有功能强大的产品，但是用户不愿意为我们的解决方案付费。其根本原因是由于我们的解决方案是基于一个待验证的假设，这个假设从一开始可能就是错误的。
- 扩大规模：当形成一定市场规模后，企业会努力扩大规模，在这一阶段，我们考虑更多的是软件的灵活度，是否可以满足潜在客户的定制化需求。当前的软件也许可以解决 80% 的客户诉求，但是从 80% 到 90% 的提升，也许需要付出更大的成本，除此之外还需要考虑这些定制化功能所带来的长期的维护成本。
如果我们带着一家 SaaS 初创企业 CTO 的帽子，思考如何提升整个团队的研发效能？这里可能会有很多答案，比如：提升研发人员的能力、招聘更多的研发人员、购买先进的开发工具，提高研发效率、进行代码和架构治理等等，这个列表可能会很长。为了体系化制定研发效能的提升策略，有的放矢地进行研发效能投资，我们可以借助社区或者行业一些框架来辅助思考，但是我认为现在很多研发效能框架存在两个比较大的问题：1. 关注点过度集中于从问题到解决方案的阶段我认为研发效能治理不能脱离最终的产品价值，需要建立端到端的视角，不仅仅关注问题到解决方案这个阶段，还需要思考解决方案是否可以真正满足客户诉求？是否可以支撑解决方案在更大的群体中扩大规模？我们对研发效能的关注点需要继续向用户和市场延伸。2. 对于研发流程中的反馈周期关注度不够目前在很多研发效能治理框架中，我们可以见到很多指标，比如发布次数、构建次数、自动化构建速度等等，这些指标关注的是从左到右价值流动速度，但忽略了从右到左的价值反馈，而这些反馈可以加深我们对问题的理解，否则我们对于原先假设问题的认知仍然会停留在「低认知」水平。比如产品功能快速推广到市场之后，使用频率如何、用户反馈如何，通过这些反馈的收集，我们也许会意识到：原来一开始这就是一个错误的假设，从而及时去调整产品方向。所以回到研发效能治理本身，我认为研发效能治理只有一个目标，那就是：「加速价值流动，缩短反馈周期，用低成本验证对问题的假设」，加速价值流动和缩短反馈周期是手段，低成本验证问题假设是期望的结果。 从这个目标来思考研发效能提升，对于一些司空见惯的实践也会有更加深刻的理解，比如统一代码规范、引入自动化测试等等。因为我们认为符合规范的代码可以去提升软件的维护性，可以降低问题到解决方案的成本，所以我们要坚持代码符合规范；由于人工测试效率较低，在软件规模扩大时，我们认为通过引入自动化测试可以更加高效地验证解决方案和问题的匹配度，从而加速从左到右的价值流动，所以我们要坚持测试自动化。同时从这个目标出发，在实践层面会有更大的想象空间：在产品设计中我们可以主张 MVP 的概念，一开始并不是要提供一个大而全的解决方案，而是找到 MVP - 最小化可行产品，快速验证想法，验证产品是否符合市场客户预期，然后取代手工部署应用的方式，做自动化运维、自动化应用部署，快速把解决方案推向市场与客户。也许我们可以参与到架构治理和产品设计中，制定指标定量分析软件架构的灵活度，让产品更加灵活，可以低成本适配客户需求；也许我们也可以尝试自动化的基础设施管理，缩短基础设施准备时间。我们交付的功能是否有真正创造价值？根据 Standish 的研究显示：20% 的软件特性经常被使用，而 30% 的特性偶尔使用，剩余 50% 的特性几乎很少使用或者完全不用。也许我们也可以主动尝试类似 A/B Testing、NPS（Net Promoter Score，净推荐值）等方法，让用户的反馈快速传递到产品团队。通过这个目标也可以驱动研发效能治理人员更多地参与到产品设计、架构设计、基础设施管理等工作中。此外不合理的分工方式也会延长反馈周期，团队的组织结构划分应该从业务的视角还是从人员角色的视角？在敏捷软件开发中倡导的是全功能团队，在一个小的团队（Scrum Team）内部包括产品、研发、测试甚至是运维、UX，覆盖某个产品或者业务的全研发流程，在一个团队内部实现业务的闭环，在应对变化时具有更高的响应力；而基于角色的分工有时会导致交付流程的割裂，在整个研发过程中每引入一个新的角色就会增加一次上下文传递，还需要处理由此带来的术语转换和信息丢失问题。
1.2 研发效能提升的阻力
围绕以上的目标，我们在整个研发流程中仍然有很多挑战和阻力，这次分享会着重从基础设施管理、软件架构设计和团队协作三个角度展开：这是我曾经经历过的项目，客户的服务器主要是使用虚拟机部署，使用负载均衡做流量分发，这也是一种非常典型的部署结构。可以通过增加虚拟机，实现应用的可扩展。但由于预估容量不足，导致业务高峰期时，大量用户出现请求超时的情况，这对于客户意味着品牌声誉受损、用户流失。虽然可以通过创建虚拟机实例的方式进行扩容，但是仍然要做很多额外的配置。应用底层有很多依赖的框架或语言运行时需要安装，安装完成之后还需要配置和部署应用，这个周期至少需要 1-2 个小时。繁琐的基础设施运维限制了业务规模的扩大，限制了解决方案向更大的群体复制。传统的运维方式还需要做容量预测，但难以在成本和效率之间平衡：当人工计划容量低于实际流量时，流量溢出、扩容速度慢，基础设施无法支撑实际业务需求；计划容量大于实际流量时，资源利用率低，企业成本的增加。可能有些同学会质疑：「基础设施的问题，似乎与研发没有什么关系」。但对于解决方案的复制，思考的视角不应该仅仅停留在基础设施级别，软件架构的设计也同样重要。从单体架构拆分成微服务，甚至更细粒度的函数（FaaS），是近年来业界非常流行的一个软件架构设计趋势，大大降低了解决方案复制的成本。基于传统的虚拟机部署，一个应用的各个组件可能部署在多个虚拟机上，对于新的客户通过复制虚拟机的方式来复制解决方案。这种方式不但维护成本高，而且只能通过复制虚拟机的方式来支撑更大体量的用户，来满足弹性的诉求，而通过进一步拆分架构，把单体架构拆成微服务之后，解决方案的复制可以进行更加细粒度的控制。以一个电商应用为例，订单、仓储、物车等各个业务模块对弹性的要求是不同的，不管我们选择什么技术实现，这些弹性特征都不会变化，本质上这是业务需求的一部分。除此之外，研发团队的工作负担重也是研发效能不足的重要原因之一，企业内部重复「造轮子」的现象屡见不鲜，也许这也是近年来中台、平台等概念流行的原因之一。前后端分离是一种典型的研发团队协作方式，后端提供 API，但有时候 API 无法及时提供，而前端开发者不了解服务器、数据库等搭建知识，也不了解后端的编程语言，具有一定的学习门槛，无法及时进行集成，导致上线时间延期，近而影响价值的流动速度，这些在制品（WIP）并没有形成完整的解决方案，也无法交付给客户使用，潜在的集成问题还有可能导致开发工作量增加。以上是我对于研发效能治理目标和挑战的一些理解，接下来和大家分享 Severless 如何去提升研发效能。
02.
从 Serverless 的角度如何提升研发效能？
Serverless 的概念
大家也许是第一次接触 Serverless 这个概念，Serverless 是什么？具有什么价值？可以通过这个例子来理解 Serverless 的概念：比如有一个简单的出行需求，从出发地 A 到目的地 B，可以选择不同的解决方案，私家车 / 汽车租赁 / 网约车，不同方案有各自的特点：- 私家车：一次性付费，独占资源，维护成本很高，类似 IDC 机房里面的物理机；
- 汽车租赁：租约期付费，有一定维护成本，但还是需要自己开车，类似虚拟机；
- 网约车：按实际的用量计费，只需拿出手机 App，提出出行需求，这也是 Serverless 的理念；
Serverless 和传统的通用计算平台相比，能够真正做到按用量付费，可以大幅度节省服务器开销和运维成本。云函数 SCF 是腾讯云 Serverless 产品，在不需要购买虚拟机的情况下，就可执行代码，目前支持所有的主流的编程语言，包括 Node.js、Python、Java 等等，主要有以下几个特点：1. 节省服务器开销的节约，根据历史经验大概可以节省 10%-20%，具体的收益具体需结合业务场景、使用案例判断。2. 节省人工运维成本，与 Serverless 节省服务器成本相比，带来更大的价值在于降低人工运维成本。之前大量的保障可用性、可伸缩性的运维工作可以直接托管给云厂商来处理。
举措一：托管基础设施能力，降低基础设施运维成本
Serverless 是如何解决之前所提到的研发效能挑战？当尝试把一个解决方案推向更广的群体时，首先会遇到基础设施的问题，尤其是对于很多处于业务高速扩张的业务，比如某大型零售企业，一个月会开上百家门店，把同样的业务模式在更多的城市或者下沉市场进行复制时，基础设施稳定是保障业务增长的基石，Serverless 通过把可用性、容灾、备份和监控等传统的运维工作托管到云端，可以大幅度节约企业的基础设施复制成本，通过执行一条命令，即可实现环境的跨区域复制。此外无服务架构通过自动扩缩容，能够做到资源消耗和实际流量线基本保持一致，大幅度降低企业容量计划的成本，让企业可以集中精力关注于业务价值本身。
举措二：分而治之，有的放矢分配投资
「领域驱动设计」是微服务设计重要的方法论之一，其中分为战略设计和战术设计两部分。战略设计的核心价值在于帮助企业从更加宏观的视角看待自身业务能力，而不是走完全采购或者完全自研的两个极端。通过从业务能力的角度分析哪些是企业的核心域，哪些是支撑域，哪些是通用域，对于核心域投入 80% 的研发力量，给企业带来差异化的竞争力；对于通用域，比如内容管理系统、登录、认证等方面，与企业核心竞争力无关的，完全可以交给云厂商或者第三方企业，使用开箱即用的标准化功能：和微服务相比，Serverless 则借助于 FaaS（函数即服务）+ BaaS（后端即服务）的理念，在更细的粒度和场景进行能力的复用，对于研发效率的关注从服务级别提升至应用级别（如 Google Firebase 等），通过整合开箱即用的标准化 BaaS 服务以及可编程的函数进一步简化了应用的开发复杂度。
举措三：降低运维成本，优化组织内部分工
借助于服务端渲染技术（Server Side Rendering，SSR），前端开发者可以直接使用 JavaScript 编写后端 API。对于基础设施管理，Serverless 领域也有比较成熟的开发工具，比如 Serverless Framework，通过基本的 YAML 配置文件，就可以把完整的开发环境、测试环境构建出来。SSR 对于企业来说最大的价值在于实现业务自闭环，对于前端开发者来说，无需等待后端提供 API ，就可完成整个业务的端到端开发和测试，加速从左到右的价值流动；其次基于同样的基础设施描述文件，只需修改简单的配置，就可进行复制，进一步避免开发、测试和生产环境不一致的问题。03.
Serverless 发展趋势预测
最后从个人的角度，分享一下对 Serverless 下一阶段发展的展望：第一个趋势是：「Serverless + X」能够看到很多融合 Serverless 理念的产品在不断诞生，比如最近各大云厂商发布了 Serverless DB、Serverless 中间件、Serverless 容器平台等产品。从应用的视角来看，除了计算之外，还要考虑文件系统、对象存储、数据库等等，所以我认为未来动态伸缩、按量计费的 Serverless 产品矩阵会越来越丰富。另外一个趋势是：「Serverless 作为应用的执行引擎」这种形态下 Serverless 对于用户来说是无感知的，由于 Serverless 提供成本、可维护性、可扩展性等方面有巨大优势，Serverless 可以作为支撑 SaaS 等应用的底层驱动和引擎，进一步提升产品自身的竞争力。此外基于 Serverless 理念的产品或者解决方案和边缘计算会有更好的融合，充分去利用云边端各个节点的算力，释放边端的潜能，在网络带宽延迟、能耗有限、数据敏感等复杂场景下会有更多的落地案例。最后在开发工具、开发体验和方法论指导方面，和 Serverless 相关的工具和生态也会更加成熟。以上是我主要分享的内容，谢谢。
分享嘉宾
杨政权，腾讯云 Serverless 中心专家架构师，曾任 ThoughtWorks 中国北美事业部技术总监，先后担任大型团队的研发组长、技术总监和企业架构师角色，作为客户主要的技术接口人，主导并参与客户的技术战略制定、技术战略实施和企业架构治理的过程中，并积极参与到 DevOps、领域驱动设计、Serverless 和软件质量治理等各个社区中。