01.研發(fā)效能提升的目標(biāo)和阻力

1.1 研發(fā)效能治理的目標(biāo)

首先我們看一下典型的 SaaS 軟件商業(yè)模式，無(wú)論是 SaaS 軟件初創(chuàng)公司還是企業(yè)內(nèi)部一個(gè)新興的業(yè)務(wù)，一開始都會(huì)面臨這樣一個(gè)假設(shè)性問題：如果這個(gè)問題得到解決，可以為業(yè)務(wù)帶來增長(zhǎng)、為企業(yè)帶來營(yíng)收，但重要的是：這有可能并不是客戶真正的痛點(diǎn)，這只是基于我們當(dāng)前的認(rèn)知所形成的一個(gè)有待驗(yàn)證的「假設(shè)」。之后企業(yè)會(huì)針對(duì)這個(gè)問題提供解決方案，然后把解決方案交付給客戶，在取得一些成功之后，我們會(huì)嘗試推向更大的市場(chǎng)和用戶。如果這個(gè)方案在一家公司能夠復(fù)制，我們會(huì)尋求在同行業(yè)或者跨行業(yè)的客戶中識(shí)別更多的增加機(jī)會(huì)，也可以采用先落地再擴(kuò)展(Land-and-Expand)策略，在存量客戶中挖掘更多的增長(zhǎng)機(jī)會(huì)。

在以上的流程中，企業(yè)所處的階段不同，其關(guān)注點(diǎn)也不盡相同：

從問題到解決方案：我們考慮的是問題和解決方案的匹配度(Problem-Solution-Fit)，評(píng)估的角度主要看解決方案是否真的可以解決對(duì)應(yīng)的客戶問題。

從方案觸達(dá)市場(chǎng)和用戶：企業(yè)更多會(huì)關(guān)注產(chǎn)品市場(chǎng)契合度(Product-Market-Fit，PMF)，這往往也是很多初創(chuàng)企業(yè)失敗的主要原因，我們具有功能強(qiáng)大的產(chǎn)品，但是用戶不愿意為我們的解決方案付費(fèi)。其根本原因是由于我們的解決方案是基于一個(gè)待驗(yàn)證的假設(shè)，這個(gè)假設(shè)從一開始可能就是錯(cuò)誤的。

擴(kuò)大規(guī)模：當(dāng)形成一定市場(chǎng)規(guī)模后，企業(yè)會(huì)努力擴(kuò)大規(guī)模，在這一階段，我們考慮更多的是軟件的靈活度，是否可以滿足潛在客戶的定制化需求。當(dāng)前的軟件也許可以解決 80% 的客戶訴求，但是從 80% 到 90% 的提升，也許需要付出更大的成本，除此之外還需要考慮這些定制化功能所帶來的長(zhǎng)期的維護(hù)成本。

如果我們帶著一家 SaaS 初創(chuàng)企業(yè) CTO 的帽子，思考如何提升整個(gè)團(tuán)隊(duì)的研發(fā)效能?這里可能會(huì)有很多答案，比如：提升研發(fā)人員的能力、招聘更多的研發(fā)人員、購(gòu)買先進(jìn)的開發(fā)工具，提高研發(fā)效率、進(jìn)行代碼和架構(gòu)治理等等，這個(gè)列表可能會(huì)很長(zhǎng)。為了體系化制定研發(fā)效能的提升策略，有的放矢地進(jìn)行研發(fā)效能投資，我們可以借助社區(qū)或者行業(yè)一些框架來輔助思考，但是我認(rèn)為現(xiàn)在很多研發(fā)效能框架存在兩個(gè)比較大的問題：

1. 關(guān)注點(diǎn)過度集中于從問題到解決方案的階段

我認(rèn)為研發(fā)效能治理不能脫離最終的產(chǎn)品價(jià)值，需要建立端到端的視角，不僅僅關(guān)注問題到解決方案這個(gè)階段，還需要思考解決方案是否可以真正滿足客戶訴求?是否可以支撐解決方案在更大的群體中擴(kuò)大規(guī)模?我們對(duì)研發(fā)效能的關(guān)注點(diǎn)需要繼續(xù)向用戶和市場(chǎng)延伸。

2. 對(duì)于研發(fā)流程中的反饋周期關(guān)注度不夠

目前在很多研發(fā)效能治理框架中，我們可以見到很多指標(biāo)，比如發(fā)布次數(shù)、構(gòu)建次數(shù)、自動(dòng)化構(gòu)建速度等等，這些指標(biāo)關(guān)注的是從左到右價(jià)值流動(dòng)速度，但忽略了從右到左的價(jià)值反饋，而這些反饋可以加深我們對(duì)問題的理解，否則我們對(duì)于原先假設(shè)問題的認(rèn)知仍然會(huì)停留在「低認(rèn)知」水平。比如產(chǎn)品功能快速推廣到市場(chǎng)之后，使用頻率如何、用戶反饋如何，通過這些反饋的收集，我們也許會(huì)意識(shí)到：原來一開始這就是一個(gè)錯(cuò)誤的假設(shè)，從而及時(shí)去調(diào)整產(chǎn)品方向。所以回到研發(fā)效能治理本身，我認(rèn)為研發(fā)效能治理只有一個(gè)目標(biāo)，那就是：「加速價(jià)值流動(dòng)，縮短反饋周期，用低成本驗(yàn)證對(duì)問題的假設(shè)」，加速價(jià)值流動(dòng)和縮短反饋周期是手段，低成本驗(yàn)證問題假設(shè)是期望的結(jié)果。

從這個(gè)目標(biāo)來思考研發(fā)效能提升，對(duì)于一些司空見慣的實(shí)踐也會(huì)有更加深刻的理解，比如統(tǒng)一代碼規(guī)范、引入自動(dòng)化測(cè)試等等。因?yàn)槲覀冋J(rèn)為符合規(guī)范的代碼可以去提升軟件的維護(hù)性，可以降低問題到解決方案的成本，所以我們要堅(jiān)持代碼符合規(guī)范;由于人工測(cè)試效率較低，在軟件規(guī)模擴(kuò)大時(shí)，我們認(rèn)為通過引入自動(dòng)化測(cè)試可以更加高效地驗(yàn)證解決方案和問題的匹配度，從而加速?gòu)淖蟮接业膬r(jià)值流動(dòng)，所以我們要堅(jiān)持測(cè)試自動(dòng)化。

同時(shí)從這個(gè)目標(biāo)出發(fā)，在實(shí)踐層面會(huì)有更大的想象空間：

如何加速端到端的價(jià)值流動(dòng)?

在產(chǎn)品設(shè)計(jì)中我們可以主張 MVP 的概念，一開始并不是要提供一個(gè)大而全的解決方案，而是找到 MVP - 最小化可行產(chǎn)品，快速驗(yàn)證想法，驗(yàn)證產(chǎn)品是否符合市場(chǎng)客戶預(yù)期，然后取代手工部署應(yīng)用的方式，做自動(dòng)化運(yùn)維、自動(dòng)化應(yīng)用部署，快速把解決方案推向市場(chǎng)與客戶。也許我們可以參與到架構(gòu)治理和產(chǎn)品設(shè)計(jì)中，制定指標(biāo)定量分析軟件架構(gòu)的靈活度，讓產(chǎn)品更加靈活，可以低成本適配客戶需求;也許我們也可以嘗試自動(dòng)化的基礎(chǔ)設(shè)施管理，縮短基礎(chǔ)設(shè)施準(zhǔn)備時(shí)間。

如何縮短反饋周期?

我們交付的功能是否有真正創(chuàng)造價(jià)值?根據(jù) Standish 的研究顯示：20% 的軟件特性經(jīng)常被使用，而 30% 的特性偶爾使用，剩余 50% 的特性幾乎很少使用或者完全不用。也許我們也可以主動(dòng)嘗試類似 A/B Testing、NPS(Net Promoter Score，凈推薦值)等方法，讓用戶的反饋快速傳遞到產(chǎn)品團(tuán)隊(duì)。通過這個(gè)目標(biāo)也可以驅(qū)動(dòng)研發(fā)效能治理人員更多地參與到產(chǎn)品設(shè)計(jì)、架構(gòu)設(shè)計(jì)、基礎(chǔ)設(shè)施管理等工作中。

此外不合理的分工方式也會(huì)延長(zhǎng)反饋周期，團(tuán)隊(duì)的組織結(jié)構(gòu)劃分應(yīng)該從業(yè)務(wù)的視角還是從人員角色的視角?在敏捷軟件開發(fā)中倡導(dǎo)的是全功能團(tuán)隊(duì)，在一個(gè)小的團(tuán)隊(duì)(Scrum Team)內(nèi)部包括產(chǎn)品、研發(fā)、測(cè)試甚至是運(yùn)維、UX，覆蓋某個(gè)產(chǎn)品或者業(yè)務(wù)的全研發(fā)流程，在一個(gè)團(tuán)隊(duì)內(nèi)部實(shí)現(xiàn)業(yè)務(wù)的閉環(huán)，在應(yīng)對(duì)變化時(shí)具有更高的響應(yīng)力;而基于角色的分工有時(shí)會(huì)導(dǎo)致交付流程的割裂，在整個(gè)研發(fā)過程中每引入一個(gè)新的角色就會(huì)增加一次上下文傳遞，還需要處理由此帶來的術(shù)語(yǔ)轉(zhuǎn)換和信息丟失問題。

1.2 研發(fā)效能提升的阻力

圍繞以上的目標(biāo)，我們?cè)谡麄€(gè)研發(fā)流程中仍然有很多挑戰(zhàn)和阻力，這次分享會(huì)著重從基礎(chǔ)設(shè)施管理、軟件架構(gòu)設(shè)計(jì)和團(tuán)隊(duì)協(xié)作三個(gè)角度展開：

基礎(chǔ)設(shè)施管理

這是我曾經(jīng)經(jīng)歷過的項(xiàng)目，客戶的服務(wù)器主要是使用虛擬機(jī)部署，使用負(fù)載均衡做流量分發(fā)，這也是一種非常典型的部署結(jié)構(gòu)。可以通過增加虛擬機(jī)，實(shí)現(xiàn)應(yīng)用的可擴(kuò)展。但由于預(yù)估容量不足，導(dǎo)致業(yè)務(wù)高峰期時(shí)，大量用戶出現(xiàn)請(qǐng)求超時(shí)的情況，這對(duì)于客戶意味著品牌聲譽(yù)受損、用戶流失。雖然可以通過創(chuàng)建虛擬機(jī)實(shí)例的方式進(jìn)行擴(kuò)容，但是仍然要做很多額外的配置。應(yīng)用底層有很多依賴的框架或語(yǔ)言運(yùn)行時(shí)需要安裝，安裝完成之后還需要配置和部署應(yīng)用，這個(gè)周期至少需要 1-2 個(gè)小時(shí)。繁瑣的基礎(chǔ)設(shè)施運(yùn)維限制了業(yè)務(wù)規(guī)模的擴(kuò)大，限制了解決方案向更大的群體復(fù)制。

傳統(tǒng)的運(yùn)維方式還需要做容量預(yù)測(cè)，但難以在成本和效率之間平衡：當(dāng)人工計(jì)劃容量低于實(shí)際流量時(shí)，流量溢出、擴(kuò)容速度慢，基礎(chǔ)設(shè)施無(wú)法支撐實(shí)際業(yè)務(wù)需求;計(jì)劃容量大于實(shí)際流量時(shí)，資源利用率低，企業(yè)成本的增加。

軟件架構(gòu)設(shè)計(jì)

可能有些同學(xué)會(huì)質(zhì)疑：「基礎(chǔ)設(shè)施的問題，似乎與研發(fā)沒有什么關(guān)系」。但對(duì)于解決方案的復(fù)制，思考的視角不應(yīng)該僅僅停留在基礎(chǔ)設(shè)施級(jí)別，軟件架構(gòu)的設(shè)計(jì)也同樣重要。從單體架構(gòu)拆分成微服務(wù)，甚至更細(xì)粒度的函數(shù)(FaaS)，是近年來業(yè)界非常流行的一個(gè)軟件架構(gòu)設(shè)計(jì)趨勢(shì)，大大降低了解決方案復(fù)制的成本。基于傳統(tǒng)的虛擬機(jī)部署，一個(gè)應(yīng)用的各個(gè)組件可能部署在多個(gè)虛擬機(jī)上，對(duì)于新的客戶通過復(fù)制虛擬機(jī)的方式來復(fù)制解決方案。這種方式不但維護(hù)成本高，而且只能通過復(fù)制虛擬機(jī)的方式來支撐更大體量的用戶，來滿足彈性的訴求，而通過進(jìn)一步拆分架構(gòu)，把單體架構(gòu)拆成微服務(wù)之后，解決方案的復(fù)制可以進(jìn)行更加細(xì)粒度的控制。以一個(gè)電商應(yīng)用為例，訂單、倉(cāng)儲(chǔ)、物車等各個(gè)業(yè)務(wù)模塊對(duì)彈性的要求是不同的，不管我們選擇什么技術(shù)實(shí)現(xiàn)，這些彈性特征都不會(huì)變化，本質(zhì)上這是業(yè)務(wù)需求的一部分。除此之外，研發(fā)團(tuán)隊(duì)的工作負(fù)擔(dān)重也是研發(fā)效能不足的重要原因之一，企業(yè)內(nèi)部重復(fù)「造輪子」的現(xiàn)象屢見不鮮，也許這也是近年來中臺(tái)、平臺(tái)等概念流行的原因之一。

團(tuán)隊(duì)協(xié)作

前后端分離是一種典型的研發(fā)團(tuán)隊(duì)協(xié)作方式，后端提供 API，但有時(shí)候 API 無(wú)法及時(shí)提供，而前端開發(fā)者不了解服務(wù)器、數(shù)據(jù)庫(kù)等搭建知識(shí)，也不了解后端的編程語(yǔ)言，具有一定的學(xué)習(xí)門檻，無(wú)法及時(shí)進(jìn)行集成，導(dǎo)致上線時(shí)間延期，近而影響價(jià)值的流動(dòng)速度，這些在制品(WIP)并沒有形成完整的解決方案，也無(wú)法交付給客戶使用，潛在的集成問題還有可能導(dǎo)致開發(fā)工作量增加。

以上是我對(duì)于研發(fā)效能治理目標(biāo)和挑戰(zhàn)的一些理解，接下來和大家分享 Severless 如何去提升研發(fā)效能。

02.從 Serverless 的角度如何提升研發(fā)效能?

Serverless 的概念

大家也許是第一次接觸 Serverless 這個(gè)概念，Serverless 是什么?具有什么價(jià)值?可以通過這個(gè)例子來理解 Serverless 的概念：比如有一個(gè)簡(jiǎn)單的出行需求，從出發(fā)地 A 到目的地 B，可以選擇不同的解決方案，私家車 / 汽車租賃 / 網(wǎng)約車，不同方案有各自的特點(diǎn)：

• 私家車：一次性付費(fèi)，獨(dú)占資源，維護(hù)成本很高，類似 IDC 機(jī)房里面的物理機(jī);
• 汽車租賃：租約期付費(fèi)，有一定維護(hù)成本，但還是需要自己開車，類似虛擬機(jī);
• 網(wǎng)約車：按實(shí)際的用量計(jì)費(fèi)，只需拿出手機(jī) App，提出出行需求，這也是 Serverless 的理念;

Serverless 和傳統(tǒng)的通用計(jì)算平臺(tái)相比，能夠真正做到按用量付費(fèi)，可以大幅度節(jié)省服務(wù)器開銷和運(yùn)維成本。

云函數(shù) SCF 是騰訊云 Serverless 產(chǎn)品，在不需要購(gòu)買虛擬機(jī)的情況下，就可執(zhí)行代碼，目前支持所有的主流的編程語(yǔ)言，包括 Node.js、Python、Java 等等，主要有以下幾個(gè)特點(diǎn)：

• 節(jié)省服務(wù)器開銷的節(jié)約，根據(jù)歷史經(jīng)驗(yàn)大概可以節(jié)省 10%-20%，具體的收益具體需結(jié)合業(yè)務(wù)場(chǎng)景、使用案例判斷。
• 節(jié)省人工運(yùn)維成本，與 Serverless 節(jié)省服務(wù)器成本相比，帶來更大的價(jià)值在于降低人工運(yùn)維成本。之前大量的保障可用性、可伸縮性的運(yùn)維工作可以直接托管給云廠商來處理。

舉措一：托管基礎(chǔ)設(shè)施能力，降低基礎(chǔ)設(shè)施運(yùn)維成本

Serverless 是如何解決之前所提到的研發(fā)效能挑戰(zhàn)?當(dāng)嘗試把一個(gè)解決方案推向更廣的群體時(shí)，首先會(huì)遇到基礎(chǔ)設(shè)施的問題，尤其是對(duì)于很多處于業(yè)務(wù)高速擴(kuò)張的業(yè)務(wù)，比如某大型零售企業(yè)，一個(gè)月會(huì)開上百家門店，把同樣的業(yè)務(wù)模式在更多的城市或者下沉市場(chǎng)進(jìn)行復(fù)制時(shí)，基礎(chǔ)設(shè)施穩(wěn)定是保障業(yè)務(wù)增長(zhǎng)的基石，Serverless 通過把可用性、容災(zāi)、備份和監(jiān)控等傳統(tǒng)的運(yùn)維工作托管到云端，可以大幅度節(jié)約企業(yè)的基礎(chǔ)設(shè)施復(fù)制成本，通過執(zhí)行一條命令，即可實(shí)現(xiàn)環(huán)境的跨區(qū)域復(fù)制。此外無(wú)服務(wù)架構(gòu)通過自動(dòng)擴(kuò)縮容，能夠做到資源消耗和實(shí)際流量線基本保持一致，大幅度降低企業(yè)容量計(jì)劃的成本，讓企業(yè)可以集中精力關(guān)注于業(yè)務(wù)價(jià)值本身。

舉措二：分而治之，有的放矢分配投資

「領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)」是微服務(wù)設(shè)計(jì)重要的方法論之一，其中分為戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)兩部分。戰(zhàn)略設(shè)計(jì)的核心價(jià)值在于幫助企業(yè)從更加宏觀的視角看待自身業(yè)務(wù)能力，而不是走完全采購(gòu)或者完全自研的兩個(gè)極端。通過從業(yè)務(wù)能力的角度分析哪些是企業(yè)的核心域，哪些是支撐域，哪些是通用域，對(duì)于核心域投入 80% 的研發(fā)力量，給企業(yè)帶來差異化的競(jìng)爭(zhēng)力;對(duì)于通用域，比如內(nèi)容管理系統(tǒng)、登錄、認(rèn)證等方面，與企業(yè)核心競(jìng)爭(zhēng)力無(wú)關(guān)的，完全可以交給云廠商或者第三方企業(yè)，使用開箱即用的標(biāo)準(zhǔn)化功能：

和微服務(wù)相比，Serverless 則借助于 FaaS(函數(shù)即服務(wù))+ BaaS(后端即服務(wù))的理念，在更細(xì)的粒度和場(chǎng)景進(jìn)行能力的復(fù)用，對(duì)于研發(fā)效率的關(guān)注從服務(wù)級(jí)別提升至應(yīng)用級(jí)別(如 Google Firebase 等)，通過整合開箱即用的標(biāo)準(zhǔn)化 BaaS 服務(wù)以及可編程的函數(shù)進(jìn)一步簡(jiǎn)化了應(yīng)用的開發(fā)復(fù)雜度。

舉措三：降低運(yùn)維成本，優(yōu)化組織內(nèi)部分工

借助于服務(wù)端渲染技術(shù)(Server Side Rendering，SSR)，前端開發(fā)者可以直接使用 JavaScript 編寫后端 API。對(duì)于基礎(chǔ)設(shè)施管理，Serverless 領(lǐng)域也有比較成熟的開發(fā)工具，比如 Serverless Framework，通過基本的 YAML 配置文件，就可以把完整的開發(fā)環(huán)境、測(cè)試環(huán)境構(gòu)建出來。

SSR 對(duì)于企業(yè)來說最大的價(jià)值在于實(shí)現(xiàn)業(yè)務(wù)自閉環(huán)，對(duì)于前端開發(fā)者來說，無(wú)需等待后端提供 API ，就可完成整個(gè)業(yè)務(wù)的端到端開發(fā)和測(cè)試，加速?gòu)淖蟮接业膬r(jià)值流動(dòng);其次基于同樣的基礎(chǔ)設(shè)施描述文件，只需修改簡(jiǎn)單的配置，就可進(jìn)行復(fù)制，進(jìn)一步避免開發(fā)、測(cè)試和生產(chǎn)環(huán)境不一致的問題。

03.Serverless 發(fā)展趨勢(shì)預(yù)測(cè)

最后從個(gè)人的角度，分享一下對(duì) Serverless 下一階段發(fā)展的展望：

第一個(gè)趨勢(shì)是：「Serverless + X」

能夠看到很多融合 Serverless 理念的產(chǎn)品在不斷誕生，比如最近各大云廠商發(fā)布了 Serverless DB、Serverless 中間件、Serverless 容器平臺(tái)等產(chǎn)品。從應(yīng)用的視角來看，除了計(jì)算之外，還要考慮文件系統(tǒng)、對(duì)象存儲(chǔ)、數(shù)據(jù)庫(kù)等等，所以我認(rèn)為未來動(dòng)態(tài)伸縮、按量計(jì)費(fèi)的 Serverless 產(chǎn)品矩陣會(huì)越來越豐富。

另外一個(gè)趨勢(shì)是：「Serverless 作為應(yīng)用的執(zhí)行引擎」

這種形態(tài)下 Serverless 對(duì)于用戶來說是無(wú)感知的，由于 Serverless 提供成本、可維護(hù)性、可擴(kuò)展性等方面有巨大優(yōu)勢(shì)，Serverless 可以作為支撐 SaaS 等應(yīng)用的底層驅(qū)動(dòng)和引擎，進(jìn)一步提升產(chǎn)品自身的競(jìng)爭(zhēng)力。

此外基于 Serverless 理念的產(chǎn)品或者解決方案和邊緣計(jì)算會(huì)有更好的融合，充分去利用云邊端各個(gè)節(jié)點(diǎn)的算力，釋放邊端的潛能，在網(wǎng)絡(luò)帶寬延遲、能耗有限、數(shù)據(jù)敏感等復(fù)雜場(chǎng)景下會(huì)有更多的落地案例。

最后在開發(fā)工具、開發(fā)體驗(yàn)和方法論指導(dǎo)方面，和 Serverless 相關(guān)的工具和生態(tài)也會(huì)更加成熟。

以上是我主要分享的內(nèi)容，謝謝。

分享嘉賓

楊政權(quán)，騰訊云 Serverless 中心專家架構(gòu)師，曾任 ThoughtWorks 中國(guó)北美事業(yè)部技術(shù)總監(jiān)，先后擔(dān)任大型團(tuán)隊(duì)的研發(fā)組長(zhǎng)、技術(shù)總監(jiān)和企業(yè)架構(gòu)師角色，作為客戶主要的技術(shù)接口人，主導(dǎo)并參與客戶的技術(shù)戰(zhàn)略制定、技術(shù)戰(zhàn)略實(shí)施和企業(yè)架構(gòu)治理的過程中，并積極參與到 DevOps、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、Serverless 和軟件質(zhì)量治理等各個(gè)社區(qū)中。