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

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

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

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

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

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

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

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

1. 關注點過度集中于從問題到解決方案的階段

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

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

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

從這個目標來思考研發(fā)效能提升，對于一些司空見慣的實踐也會有更加深刻的理解，比如統(tǒng)一代碼規(guī)范、引入自動化測試等等。因為我們認為符合規(guī)范的代碼可以去提升軟件的維護性，可以降低問題到解決方案的成本，所以我們要堅持代碼符合規(guī)范;由于人工測試效率較低，在軟件規(guī)模擴大時，我們認為通過引入自動化測試可以更加高效地驗證解決方案和問題的匹配度，從而加速從左到右的價值流動，所以我們要堅持測試自動化。

同時從這個目標出發(fā)，在實踐層面會有更大的想象空間：

如何加速端到端的價值流動?

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

如何縮短反饋周期?

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

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

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

圍繞以上的目標，我們在整個研發(fā)流程中仍然有很多挑戰(zhàn)和阻力，這次分享會著重從基礎設施管理、軟件架構(gòu)設計和團隊協(xié)作三個角度展開：

基礎設施管理

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

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

軟件架構(gòu)設計

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

團隊協(xié)作

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

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

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

Serverless 的概念

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

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

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

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

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

舉措一：托管基礎設施能力，降低基礎設施運維成本

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

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

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

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

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

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

SSR 對于企業(yè)來說最大的價值在于實現(xiàn)業(yè)務自閉環(huán)，對于前端開發(fā)者來說，無需等待后端提供 API ，就可完成整個業(yè)務的端到端開發(fā)和測試，加速從左到右的價值流動;其次基于同樣的基礎設施描述文件，只需修改簡單的配置，就可進行復制，進一步避免開發(fā)、測試和生產(chǎn)環(huán)境不一致的問題。

03.Serverless 發(fā)展趨勢預測

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

第一個趨勢是：「Serverless + X」

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

另外一個趨勢是：「Serverless 作為應用的執(zhí)行引擎」

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

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

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

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

分享嘉賓

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