以下内容来自「云 + 社区技术沙龙 – 云原生专场：《从 Serverless 看软件研发效力的改革》」，深度好文，预计浏览需 35 分钟。

分享嘉宾

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

01. 研发效力晋升的指标和阻力

1.1 研发效力治理的指标

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

<img src=”https://main.qcloudimg.com/raw/4f21627d08fac2759705c9b47125d0bf.jpg” width=”700″/>

在以上的流程中，企业所处的阶段不同，其关注点也不尽相同：

• 从问题到解决方案 ：咱们思考的是问题和解决方案的匹配度（Problem-Solution-Fit），评估的角度次要看解决方案是否真的能够解决对应的客户问题。
• 从计划触达市场和用户 ：企业更多会关注产品市场符合度（Product-Market-Fit，PMF），这往往也是很多初创企业失败的次要起因，咱们具备功能强大的产品，然而用户不违心为咱们的解决方案付费。其根本原因是因为咱们的解决方案是基于一个待验证的假如，这个假如从一开始可能就是谬误的。
• 扩充规模 ：当造成肯定市场规模后，企业会致力扩充规模，在这一阶段，咱们思考更多的是软件的灵便度，是否能够满足潜在客户的定制化需要。以后的软件兴许能够解决 80% 的客户诉求，然而从 80% 到 90% 的晋升，兴许须要付出更大的老本，除此之外还须要思考这些定制化性能所带来的长期的保护老本。

如果咱们带着一家 SaaS 初创企业 CTO 的帽子，思考如何晋升整个团队的研发效力？这里可能会有很多答案，比方：晋升研发人员的能力、招聘更多的研发人员、购买先进的开发工具，进步研发效率、进行代码和架构治理等等，这个列表可能会很长。为了体系化制订研发效力的晋升策略，对症下药地进行研发效力投资，咱们能够借助社区或者行业一些框架来辅助思考，然而我认为当初很多研发效力框架存在两个比拟大的问题：

1. 关注点适度集中于从问题到解决方案的阶段

我认为研发效力治理不能脱离最终的产品价值，须要建设端到端的视角，不仅仅关注问题到解决方案这个阶段，还须要思考解决方案是否能够真正满足客户诉求？是否能够撑持解决方案在更大的群体中扩充规模？咱们对研发效力的关注点须要持续向用户和市场延长。

2. 对于研发流程中的反馈周期关注度不够

目前在很多研发效力治理框架中，咱们能够见到很多指标，比方公布次数、构建次数、自动化构建速度等等，这些指标关注的是从左到右价值流动速度，但疏忽了从右到左的价值反馈，而这些反馈能够加深咱们对问题的了解，否则咱们对于原先假如问题的认知依然会停留在「低认知」程度。比方产品性能疾速推广到市场之后，应用频率如何、用户反馈如何，通过这些反馈的收集，咱们兴许会意识到：原来一开始这就是一个谬误的假如，从而及时去调整产品方向。

所以回到研发效力治理自身，我认为研发效力治理只有一个指标，那就是：「减速价值流动，缩短反馈周期，用低成本验证对问题的假如」，减速价值流动和缩短反馈周期是伎俩，低成本验证问题假如是冀望的后果。

<img src=”https://main.qcloudimg.com/raw/f80ca29537c6544e7e09600fd4d04073.jpg” width=”700″/>

从这个指标来思考研发效力晋升，对于一些司空见惯的实际也会有更加粗浅的了解，比方对立代码标准、引入自动化测试等等。因为咱们认为符合规范的代码能够去晋升软件的维护性，能够升高问题到解决方案的老本，所以咱们要保持代码符合规范；因为人工测试效率较低，在软件规模扩充时，咱们认为通过引入自动化测试能够更加高效地验证解决方案和问题的匹配度，从而减速从左到右的价值流动，所以咱们要保持测试自动化。

同时从这个指标登程，在实际层面会有更大的设想空间：

• 如何减速端到端的价值流动？

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

• 如何缩短反馈周期？

咱们交付的性能是否有真正发明价值？依据 Standish 的钻研显示：20% 的软件个性常常被应用，而 30% 的个性偶然应用，残余 50% 的个性简直很少应用或者齐全不必。兴许咱们也能够被动尝试相似 A/B Testing、NPS（Net Promoter Score，净推荐值）等办法，让用户的反馈疾速传递到产品团队。通过这个指标也能够驱动研发效力治理人员更多地参加到产品设计、架构设计、基础设施治理等工作中。

<img src=”https://main.qcloudimg.com/raw/e561b1fc6aca1352a5c222235e616c25.jpg” width=”700″/>

此外不合理的分工形式也会缩短反馈周期，团队的组织构造划分应该从业务的视角还是从人员角色的视角？在麻利软件开发中提倡的是全功能团队，在一个小的团队（Scrum Team）外部包含产品、研发、测试甚至是运维、UX，笼罩某个产品或者业务的全研发流程，在一个团队外部实现业务的闭环，在应答变动时具备更高的响应力；而基于角色的分工有时会导致交付流程的割裂，在整个研发过程中每引入一个新的角色就会减少一次上下文传递，还须要解决由此带来的术语转换和信息失落问题。

1.2 研发效力晋升的阻力

围绕以上的指标，咱们在整个研发流程中依然有很多挑战和阻力，这次分享会着重从基础设施治理、软件架构设计和团队合作三个角度开展：

• 基础设施治理

这是我已经经验过的我的项目，客户的服务器次要是应用虚拟机部署，应用负载平衡做流量散发，这也是一种十分典型的部署构造。能够通过减少虚拟机，实现利用的可扩大。但因为预估容量有余，导致业务高峰期时，大量用户呈现申请超时的状况，这对于客户意味着品牌名誉受损、用户散失。尽管能够通过创立虚拟机实例的形式进行扩容，然而依然要做很多额定的配置。利用底层有很多依赖的框架或语言运行时须要装置，装置实现之后还须要配置和部署利用，这个周期至多须要 1-2 个小时。繁琐的基础设施运维限度了业务规模的扩充，限度了解决方案向更大的群体复制。

<img src=”https://main.qcloudimg.com/raw/0b8d631eefc969b16992feeb875d3a7a.jpg” width=”700″/>

传统的运维形式还须要做容量预测，但难以在老本和效率之间均衡：当人工打算容量低于理论流量时，流量溢出、扩容速度慢，基础设施无奈撑持理论业务需要；打算容量大于理论流量时，资源利用率低，企业老本的减少。

• 软件架构设计

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

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

除此之外，研发团队的工作负担重也是研发效力有余的重要起因之一，企业外部反复「造轮子」的景象不足为奇，兴许这也是近年来中台、平台等概念风行的起因之一。

• 团队合作

前后端拆散是一种典型的研发团队合作形式，后端提供 API，但有时候 API 无奈及时提供，而前端开发者不理解服务器、数据库等搭建常识，也不理解后端的编程语言，具备肯定的学习门槛，无奈及时进行集成，导致上线工夫延期，近而影响价值的流动速度，这些在制品（WIP）并没有造成残缺的解决方案，也无奈交付给客户应用，潜在的集成问题还有可能导致开发工作量减少。

<img src=”https://main.qcloudimg.com/raw/71ff65bb37fdd52ef25a2cc804713d70.jpg” width=”700″/>

以上是我对于研发效力治理指标和挑战的一些了解，接下来和大家分享 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 通过把可用性、容灾、备份和监控等传统的运维工作托管到云端，能够大幅度节约企业的基础设施复制老本，通过执行一条命令，即可实现环境的跨区域复制。

此外无服务架构通过主动扩缩容，可能做到资源耗费和理论流量线根本保持一致，大幅度降低企业容量打算的老本，让企业能够集中精力关注于业务价值自身。

<img src=”https://main.qcloudimg.com/raw/0ca6606958fd7e12ef2949f75aa94723.jpg” width=”700″/>

动作二：分而治之，对症下药调配投资

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

<img src=”https://main.qcloudimg.com/raw/7eaa4e2e64e3e9d10be6a91b4cfa9f1e.png” width=”700″/>

和微服务相比，Serverless 则借助于 FaaS（函数即服务）+ BaaS（后端即服务）的理念，在更细的粒度和场景进行能力的复用，对于研发效率的关注从服务级别晋升至利用级别（如 Google Firebase 等），通过整合开箱即用的标准化 BaaS 服务以及可编程的函数进一步简化了利用的开发复杂度。

动作三：升高运维老本，优化组织外部分工

借助于服务端渲染技术（Server Side Rendering，SSR），前端开发者能够间接应用 JavaScript 编写后端 API。对于基础设施治理，Serverless 畛域也有比拟成熟的开发工具，比方 Serverless Framework，通过根本的 YAML 配置文件，就能够把残缺的开发环境、测试环境构建进去。

<img src=”https://main.qcloudimg.com/raw/387668cfdce27eeb66f1f486cca8fc4d.jpg” width=”700″/>

SSR 对于企业来说最大的价值在于实现业务自闭环，对于前端开发者来说，无需期待后端提供 API，就可实现整个业务的端到端开发和测试，减速从左到右的价值流动；其次基于同样的基础设施形容文件，只需批改简略的配置，就可进行复制，进一步防止开发、测试和生产环境不统一的问题。

03. Serverless 发展趋势预测

最初从集体的角度，分享一下对 Serverless 下一阶段倒退的瞻望：

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

可能看到很多交融 Serverless 理念的产品在一直诞生，比方最近各大云厂商公布了 Serverless DB、Serverless 中间件、Serverless 容器平台等产品。从利用的视角来看，除了计算之外，还要思考文件系统、对象存储、数据库等等，所以我认为将来动静伸缩、按量计费的 Serverless 产品矩阵会越来越丰盛。

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

这种状态下 Serverless 对于用户来说是无感知的，因为 Serverless 提供老本、可维护性、可扩展性等方面有微小劣势，Serverless 能够作为撑持 SaaS 等利用的底层驱动和引擎，进一步晋升产品本身的竞争力。

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

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

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

One More Thing

立刻体验腾讯云 Serverless Demo，支付 Serverless 新用户礼包 👉 腾讯云 Serverless 老手体验。