營收活動： 高頻高壓倒逼出的積木式開發(fā)
本期作者
前言
你會如何總結(jié)你的工作內(nèi)容？
“CURD”，這是不少業(yè)務(wù)開發(fā)者對自己工作內(nèi)容，做出的“哲學(xué)級別”總結(jié)，不乏調(diào)侃和乏味之意。實際上，過來人都清楚，這和業(yè)務(wù)開發(fā)面臨的復(fù)雜性和挑戰(zhàn)不在一個層次。
一般情況下，互聯(lián)網(wǎng)核心業(yè)務(wù)可以大體分為兩類，其一是基礎(chǔ)功能性業(yè)務(wù)，其二是圍繞基礎(chǔ)功能，刺激增長類業(yè)務(wù)。以直播為例，可以分為：
核心功能類：如送禮打賞、PK連麥等互動消費業(yè)務(wù)。
增長類：通過精細(xì)化運營等方式，以刺激核心業(yè)務(wù)增長(消費)為核心目的，如營收活動。
業(yè)務(wù)開發(fā)的第一挑戰(zhàn)在于決策與實施的割裂，決策端和實施端是完全不同的兩撥人，在關(guān)注點、信息量、職業(yè)技能、工作方式等方面差異較大，在軟件旺盛的迭代協(xié)作之下，保障邊際生產(chǎn)力是個難點。
在此基礎(chǔ)上，核心功能類業(yè)務(wù)很考驗“第一個程序員”，業(yè)務(wù)迭代就像為飛行中的火箭更換零件，更難的在于下次要怎么換，目前還不一定清楚。
增長類業(yè)務(wù)不以“換發(fā)動機(jī)”這種艱巨場景為主，但基于刺激增長的目的，其在迭代節(jié)奏和開發(fā)量方面讓人望而生畏，基本上是：上線時間已定、套路又變了、時間不多了、不能出問題、下一個需求已經(jīng)來了···
就規(guī)模和節(jié)奏而言，有人奔潰有人跑路，也正是這樣，當(dāng)越過山丘后，才發(fā)現(xiàn)這段路更接近工程的本質(zhì)。
本文，我們基于團(tuán)隊在營收活動業(yè)務(wù)中的實踐經(jīng)驗，探討如何在快節(jié)奏、復(fù)雜靈活、工作量大的增長類業(yè)務(wù)中，保證交付生產(chǎn)力和交付質(zhì)量。
營收活動簡介
在開始之前有必要介紹下營收活動業(yè)務(wù)。作為刺激消費為最終目的的業(yè)務(wù)，基本上有兩個特點：
聯(lián)動各方資源(如公會)，綁定節(jié)日或時間節(jié)點，如春節(jié)活動、七月活動等。頻率高，倒排期上線
業(yè)務(wù)套路花樣百變，聯(lián)動平臺幾乎所有業(yè)務(wù)，巨量的細(xì)節(jié)和邏輯，高負(fù)荷開發(fā)量，歷史上單活動MR普遍在6000+行
以Bilibili Live Star活動為例，記得我第一次打開需求文檔想了解下，一直翻頁翻了好久沒到底，后面放棄了，當(dāng)時想這是什么需求。
后來我真的負(fù)責(zé)這塊業(yè)務(wù)，逐漸發(fā)現(xiàn)這是個長鏈條協(xié)作項目，流程走到研發(fā)時的訴求是，通過技術(shù)手段將策劃方案真正落地。概括一下：
對于平臺來講，是一次基于天時地利人和的周密策劃
對于主播來講，是一場一展身手有機(jī)會揚名立萬的競賽
對于用戶來講，是一次有新意能得到好處的社交游戲
用一個簡單的模型表達(dá)可以類似下圖：
痛苦的錘煉
活動業(yè)務(wù)發(fā)展經(jīng)歷了幾個階段，業(yè)務(wù)特點在于邏輯量大、細(xì)節(jié)多、節(jié)奏快、穩(wěn)定性要求高?？偨Y(jié)下來就是整體復(fù)雜度較高，且需要趕排期節(jié)奏，僅依靠橫向加人效果有限，所以第一個階段 Superman 模式起到主要作用。
到了第二階段，由于一階段積累的基建歷史債務(wù)比較重，已經(jīng)無法繼續(xù)承接當(dāng)前階段的業(yè)務(wù)，再加上新同學(xué)不理解老的基建邏輯，導(dǎo)致線上變更評估不足造成生產(chǎn)事故。同時活動屬于上層業(yè)務(wù)，對主播端、用戶端、數(shù)據(jù)端、賬號、長連接等其他端存在重度依賴，每次開發(fā)功能都需要跟各類系統(tǒng)打交道，基本上屬于活動聯(lián)動一切，依賴鏈條既復(fù)雜又多，一旦出了問題，解決起來也是相當(dāng)痛苦。
快節(jié)奏和高復(fù)雜度，讓二代 Superman 的負(fù)重前行持續(xù)加碼，線上bug不時光顧，問題反饋一波未平一波又起：
有些問題只影響顯示，略有慶幸；
發(fā)錯獎勵，得趁用戶/主播半夜熟睡悄悄回收
分?jǐn)?shù)排名錯誤，連夜修復(fù)，可能在睡夢中繼續(xù)被電話叫醒
平臺資損，老板也不能次次兜底···
隨著營收壓力增大節(jié)奏進(jìn)一步提速，規(guī)模效應(yīng)逐步放大問題。在不斷解決歷史問題同時，仍然是小問題不斷、大問題隨機(jī)。逐漸影響用戶體驗，拖慢平臺運營節(jié)奏，壓力像水一樣全方位滲透了過來。“xxx又出了一個bug，導(dǎo)致了xxx問題”，會變成矚目的話題。
客觀來看，活動幾十個賽道，疊加多個階段晉級，數(shù)十個榜單和任務(wù)，各種花樣玩法，一大堆異步腳本，顯示和觸達(dá)細(xì)節(jié)等等，case成千上萬，確實難以做到完全覆蓋。究竟有沒有一種可能，讓我們擺脫這種困境？
技術(shù)視角的思考
自從開始用golang簡潔的并發(fā)功能，我每隔一段時間就會犯閉包問題，每次發(fā)現(xiàn)后的捶胸頓足沒有讓我成為superman，直到代碼Linter檢測的出現(xiàn)，這個問題才得到了階段性杜絕。實際上好多問題核心并不一定在人的能力或態(tài)度上。
回到活動面臨的困境，最根本問題實際上有三個。
其一，從宏觀角度上看，是依賴了人，去對抗大規(guī)模的本質(zhì)復(fù)雜度。
活動增長類業(yè)務(wù)根本特點是：1.規(guī)模大，2. 時間資源有限。當(dāng)開發(fā)量大細(xì)節(jié)多，而難有充足的時間開發(fā)測試時，出現(xiàn)各式各樣的問題是必然的。即使是經(jīng)驗豐富，犯過各式各樣問題的supereman，一旦量變引起質(zhì)變，或者困了乏了，出問題也是不可避免的。從基本規(guī)律上看，人是不可靠的，寫bug是大概率事件，特別是疊加上規(guī)模這個緯度。
其二，從技術(shù)建設(shè)的角度上看，是技術(shù)系統(tǒng)在標(biāo)準(zhǔn)化和數(shù)字化程度不夠，未能有效收斂邊際成本。
系統(tǒng)復(fù)用的思路大家都能想到，以往技術(shù)上也做了不少的嘗試，而面對套路不定花樣靈活的業(yè)務(wù)策略時，不少抽象出的系統(tǒng)很快就用不上了，在一段時間里，技術(shù)的認(rèn)知是活動不可抽象，因為未來不可預(yù)知。實際上大量的需求肯定有一定程度的相似度，當(dāng)某個功能無法復(fù)用時，大概率也只是部分不能用。
其三，從研發(fā)模式角度看， 是技術(shù)生產(chǎn)力模式未能領(lǐng)先業(yè)務(wù)發(fā)展周期。
當(dāng)上游業(yè)務(wù)開始提升節(jié)奏時，基本上是將認(rèn)為成熟的套路開始大量套用，相似度開始逐步增加。此時業(yè)務(wù)階段開始從發(fā)展期開始向平臺期過渡，沿著驗證期->?發(fā)展期->?平臺期->衰退期鏈條發(fā)展，技術(shù)Leader的重要職責(zé)之一就是提前識別并做出調(diào)整，不能以驗證期的打法應(yīng)對成熟期的業(yè)務(wù)節(jié)奏。
不管是在什么周期，增長類業(yè)務(wù)要保障效率和質(zhì)量，都需要讓系統(tǒng)能具備一定的復(fù)用性，讓以往的歷史沉淀能降低邊際成本，面對規(guī)模問題的解決方案就是控制規(guī)模效應(yīng)。
問題的挑戰(zhàn)在于，復(fù)用和靈活性or變化之間有一定的矛盾，有時不好兼顧。這個問題在制造業(yè)也有解決思路，當(dāng)某類產(chǎn)品要做迭代換新，而生產(chǎn)線已經(jīng)物理級別成型了怎么辦呢？打碎了全部重建成本極高，而且整個過程還會不斷反復(fù)。
為了最大成本提升復(fù)用，制造業(yè)中提出了“柔性生產(chǎn)線”的思路，簡單講就是講基礎(chǔ)能力模塊化到最細(xì)粒度，然后基于特定需求做生產(chǎn)線模塊化組裝，當(dāng)需求變化時，只變更對應(yīng)的模塊即可。
這種方法在軟件工程領(lǐng)域不用多說，實際上業(yè)務(wù)迭代也會潛移默化的往這個方向嘗試。但由于抽象粒度不夠細(xì)，組合靈活度不高，導(dǎo)致靈活性較差深陷重復(fù)開發(fā)的泥潭。我們要做的是及時識別到這個問題，并大力改進(jìn)即可。
積木式開發(fā)
對于比較靈活多變的業(yè)務(wù)來講，要降低本質(zhì)復(fù)雜度，需要關(guān)注不變的，并識別變化的部分，積木式開發(fā)主要從四個方面入手：
抽象基礎(chǔ)不變的能力，逐層構(gòu)建業(yè)務(wù)，最大可能提升復(fù)用
流程SOP，對特定流程做標(biāo)準(zhǔn)化表達(dá)，屏蔽細(xì)節(jié)
自動化。通過工具解放人力
模塊SDK化。提升最后一公里的復(fù)用
積木式架構(gòu)
熟悉動態(tài)規(guī)劃算法的人都知道，有一種解法叫：自底向上，識別最基礎(chǔ)模式，從底部往上構(gòu)建。
回顧營收活動花樣百出的套路和玩法雖然非常多，但這里面依賴的底層不變的能力肯定是有限集，柔性生產(chǎn)的過程分為三個層次：
沉淀不變的能力(基于活動業(yè)務(wù)場景)
搭積木組合常用的功能(沉淀常用的模式-直接復(fù)用)
自定義組合&定制，應(yīng)對變化
簡單示意圖如下：
基礎(chǔ)層：以數(shù)值為例，uid, score_id, extend, num, expire ，通過這幾個字段，可以存放任意維度的積分，并提供強(qiáng)一致性發(fā)放、扣減、流水記錄、余額讀取等能力，為抽獎、兌換、玩法等復(fù)用。
積木層：以晉級為例，從榜單、任務(wù)等拉取符合條件的對象，自動報名，實現(xiàn)滿足條件的自動晉級。這一層會逐步沉淀常用的模式到后臺，可直接創(chuàng)建勾選復(fù)用。
定制組合層：以自動加分為例，這里套路多變，常用模式一般滿足不了時，可以在此實現(xiàn)定制邏輯。當(dāng)需要干預(yù)特定邏輯時，填寫特定path的接口地址即可，可按需實現(xiàn)鉤子。樣例如下：
積木式架構(gòu)達(dá)成了以下幾個結(jié)果：
基礎(chǔ)層：沉淀基礎(chǔ)能力，屏蔽了底層系統(tǒng)的復(fù)雜性，并提供靈活組合的空間
積木層：最大程度實現(xiàn)復(fù)用，常用的模式逐步沉淀在后臺，勾選即可使用。原來寫大量代碼并測試，現(xiàn)在只需創(chuàng)建配置。并以此不斷向業(yè)務(wù)上游推銷，以效率成績倒推更進(jìn)一步的邏輯簡化和標(biāo)準(zhǔn)化
定制層：最大情況應(yīng)對變化。當(dāng)沉淀的能力無法完整滿足時，可以實現(xiàn)定制接口干預(yù)邏輯，以最小的開發(fā)量實現(xiàn)整體復(fù)用。當(dāng)新花樣出來時，可以先在定制層實現(xiàn)，驗證后沉淀到積木層
流程SOP
在解決復(fù)用之后，如何利用積木體系實現(xiàn)需求，并在生產(chǎn)流程中保證質(zhì)量變成第二塊硬骨頭。基于積木式系統(tǒng)實現(xiàn)活動時，代碼開發(fā)量變少了，但配置量迅速上升，中大型活動配置量可在400+以上，在這個過程中保證研發(fā)質(zhì)量并不是一件容易的事情。
基于此，我們基于SOP的思想定義了配置生產(chǎn)流程，保證線上線下配置一樣，消滅環(huán)境差異。即先在線上創(chuàng)建配置，并推動各個業(yè)務(wù)后臺實現(xiàn)配置導(dǎo)出能力，將線上配置一模一樣copy到測試環(huán)境，交付給測試跑通。
預(yù)演是交付的最后一公里，基于活動廣泛的依賴，在線上做冒煙式的預(yù)演必不可少，這個過程很必要，但也導(dǎo)致不少問題。預(yù)演過程是在線上提前將活動開啟，這個過程有幾個痛點：
調(diào)整線上配置，這可能涉及大量配置修改，完了然后回滾，很容易漏
不能影響線上，也不能被線上流量影響，需要穩(wěn)定的黑白名單能力
數(shù)據(jù)污染，經(jīng)典的例子是預(yù)演時爆了一個一等獎，真到了開獎時刻卻開不出來了。每次需要很小心清理數(shù)據(jù)
線上配置檢查review，因為量大也擔(dān)心出問題，這個過程效率較低
歷史上因為預(yù)演出過不少問題，而且很多是重復(fù)發(fā)生，很依賴人的細(xì)心和運氣?；谝郧邦A(yù)演過程粗獷的操作，引導(dǎo)SOP的預(yù)演系統(tǒng)項目應(yīng)運而生，基本目標(biāo)是：提前在線上開啟活動，但從理論上避免對線上造成影響，解放體力和心智。
預(yù)演系統(tǒng)定義了標(biāo)準(zhǔn)，強(qiáng)制了各個模塊配置關(guān)聯(lián)活動，借此實現(xiàn)統(tǒng)一時間Hack、預(yù)演黑白名單、流量標(biāo)記、配置聚集，通過預(yù)演后臺管控操作功能自動生效，針對性解決了預(yù)演過程中的痛點，將預(yù)演過程退化成簡單無顧慮的簡單操作。
自動化
在消滅細(xì)節(jié)的過程中，通過自動化工具解放了大量人肉操作。最典型的就是獎勵配置自動檢查和代碼自動生成。
每個活動獎勵數(shù)量一般幾十上百，靠人肉檢查獎勵是否正常非常繁瑣且時有紕漏，自動檢測發(fā)獎可實現(xiàn)一鍵檢測，顯示失敗原因，效率和質(zhì)量有了革命性提升。
為了進(jìn)一步解放開發(fā)心智，活動標(biāo)準(zhǔn)化了一套模板方法，每個活動實際上都是一個新的Handler，實現(xiàn)了模板的所有接口，通過活動ID映射。
以往新增活動時，依靠人肉去老代碼中拷貝過來再改，一個文件幾千行笨重又繁瑣，找代碼、模塊管理都不方便，有時需要為預(yù)演注入的代碼經(jīng)常忘記或者寫錯，依賴人的細(xì)心。
對此我們利用golang text/template 開發(fā)了一套代碼生成工具，可以一鍵按照模塊創(chuàng)建文件，并自動填充相關(guān)代碼。便捷實現(xiàn)模塊化、代碼自動生成、自動掛載、自動注入代碼等等。很絲滑地將開發(fā)從繁瑣細(xì)節(jié)中解放了出來。
代碼模塊化
有不少功能很難抽象到后臺，例如一些非標(biāo)的腳本，或者變動較大的玩法代碼，這種較難實現(xiàn)系統(tǒng)級復(fù)用，一般在定制組合層通過函數(shù)封裝起來，重復(fù)開發(fā)較為明顯。
代碼生成工具間接引導(dǎo)了最后一公里的代碼復(fù)用，有時候某個功能已經(jīng)封裝過了，但不知道的人可能會重復(fù)開發(fā)。這些定制性強(qiáng)很難標(biāo)準(zhǔn)化的代碼模塊，工具可以把封裝過的代碼自動填在對應(yīng)的方法里，復(fù)用的時候只需要簡單改改即可，不需要找半天然后復(fù)制過來。
實踐案例
以BLS全站賽活動案例，看看如何應(yīng)用積木式開發(fā)，這個過程大致分為以下幾步：
1.技術(shù)方案構(gòu)思，基于當(dāng)前需求，思考如何使用已有的業(yè)務(wù)基建能力實現(xiàn)，并識別變化和需要定制開發(fā)的部分。
2.配置創(chuàng)建(線上)?；诋?dāng)前能復(fù)用的部分，在基礎(chǔ)層和積木層的服務(wù)后臺創(chuàng)建配置，按方案串聯(lián)模塊。這個過程在落地技術(shù)方案，復(fù)用已有能力。（原來重復(fù)開發(fā)，現(xiàn)在去各個系統(tǒng)后臺創(chuàng)建配置&串聯(lián)）
3.定制邏輯開發(fā)。這部分要寫代碼，主要是兩部分：
其一是，一次性定制邏輯鉤子(上文提到的path)。如有榜單特殊加分邏輯。例如xx主播在xx條件下實現(xiàn)xx方式的積分加倍，并有xx限制。提供給積木系統(tǒng)自動調(diào)用，會帶上相關(guān)ID及上下文。
其二是，新業(yè)務(wù)邏輯 or (新花樣)只能復(fù)用部分模塊。新寫代碼并串聯(lián)能復(fù)用的模塊。復(fù)用的模塊需要創(chuàng)建配置，并持有配置ID調(diào)用。
4.交付測試，利用“測試即線上”的配置思想，將線上配置原樣復(fù)制到測試環(huán)境完全跑通，一方面節(jié)約了配置時間，同時也杜絕了配置不一致帶來的風(fēng)險，活動團(tuán)隊提供了一鍵同步配置的工具（ID及配置內(nèi)容一致）。
5.預(yù)演 & 上線，基于預(yù)演系統(tǒng)及預(yù)演SOP，通過注入預(yù)演時間達(dá)到靈活控制時態(tài)的效果，同時也支持了預(yù)演賬號隔離，防止預(yù)演過程中對線上造成影響，在線上試用后交付。
以榜單特殊加分定制邏輯為切入點，整個系統(tǒng)調(diào)用鏈路示意圖如下：
新增的開發(fā)工作量僅有兩部分，灰色部分表示創(chuàng)建配置，并在后臺進(jìn)行邏輯關(guān)聯(lián)，只有配置工作量，高度復(fù)用；深色部分表示定制的開發(fā)代碼，新寫邏輯、部分復(fù)用代碼、復(fù)用sdk，僅需關(guān)注增量業(yè)務(wù)邏輯。
效果
積木式開發(fā)這套模式，在實現(xiàn)一定程度的系統(tǒng)復(fù)用情況下，也保留了靈活的自定義空間。復(fù)雜通用的能力，通過服務(wù)或SDK沉淀，每次新增的代碼更多的是模塊串聯(lián)組合，或者某個小流程的邏輯定制。開發(fā)能更專注于需求差異化的地方，系統(tǒng)串聯(lián)的代碼都相對簡單，整體上大幅度降低了需求實現(xiàn)的難度，降低了開發(fā)量。開發(fā)量少測試量也自然變少，人力資源能投入到更重要的部分。
同時，在常用模式后臺化后，大量細(xì)節(jié)被封裝，原來開發(fā)要不斷關(guān)注細(xì)節(jié)，例如?if xx == yy 寫成 if xx !=yy?或一級分區(qū)和二級分區(qū)搞反?等是輕而易舉的事，現(xiàn)在關(guān)注的更多是邏輯組合、模式和選項。疊加流程SOP，本質(zhì)復(fù)雜度大幅降低。
中小型活動一般一個人就可以并發(fā)一個，大型活動一個半人也能搞定，這在以前是兩三個人加班加點還可能出一堆問題。如今整個過程相對輕松，且線上問題逐漸消失。在從superMan模式往積木式架構(gòu)切換的過程中，由于人力緊張，每次都掐點跟著活動上線系統(tǒng)，過程緊張辛苦。但回頭看，整個過程中效率和質(zhì)量呈螺旋上升的態(tài)勢，加班和心理壓力呈螺旋下降態(tài)勢。
通過交付數(shù)據(jù)來看：2021年H2累計交付21場定制活動，到2022年H2提升至41場，人力沒變的情況下整體交付量提升一倍，效率顯著提高；同時質(zhì)量數(shù)據(jù)也大幅提升，單活動的平均bug數(shù)較原先降低了33%，線上問題也明顯下降，原來經(jīng)常一邊開發(fā)新需求，一邊處理線上問題，現(xiàn)在精力基本都在新需求上。
時至今日，雖然大幅改觀，實際上仍然有一些地方可以進(jìn)一步標(biāo)準(zhǔn)化數(shù)字化，靠后的骨頭雖然難啃，也在不斷進(jìn)行中。
總結(jié)
縱觀互聯(lián)網(wǎng)業(yè)務(wù)開發(fā)，基本上是在做以下幾件事，并持續(xù)優(yōu)化：
能不能做(實現(xiàn))，技術(shù)能力
做的快不快，交付效率
做的質(zhì)量好不好，交付質(zhì)量
資源消耗是否足夠低，成本
本文從增長類業(yè)務(wù)出發(fā)，結(jié)合營收活動團(tuán)隊的實戰(zhàn)經(jīng)驗，探討如何在大規(guī)模、快節(jié)奏情況下實現(xiàn)優(yōu)質(zhì)的交付效率和交付質(zhì)量。
效率
從工程的角度來講，要實現(xiàn)高交付效率，只有提升復(fù)用率這一條路。但面對靈活多變的業(yè)務(wù)場景，復(fù)用會變得困難。如何結(jié)合實際業(yè)務(wù)場景，在靈活和復(fù)用之間找到恰當(dāng)?shù)钠胶?，則是問題的關(guān)鍵。
在業(yè)務(wù)高頻高壓的不斷毒打中，我們主動而又冥冥之中走上了積木式開發(fā)這條路，從不變的東西出發(fā)，逐層構(gòu)建應(yīng)用，通過開放鉤子接口，定制變化部分實現(xiàn)最大靈活性。
這背后實際上在對業(yè)務(wù)概念持續(xù)不斷地做數(shù)字化、標(biāo)準(zhǔn)化，最終實現(xiàn)可配置、可組合、可串聯(lián)管控。
質(zhì)量
在解決復(fù)用之后，我們基于SOP的思想定義了配置生產(chǎn)流程、抽象預(yù)演流程、代碼創(chuàng)建、配置檢查等等，進(jìn)一步屏蔽人需要關(guān)注的細(xì)節(jié)。
一切重復(fù)的流程，在不斷變得成熟后都會演變成SOP，基礎(chǔ)能力的黑盒化對人屏蔽了細(xì)節(jié)，并在標(biāo)準(zhǔn)化和規(guī)范化中引導(dǎo)高質(zhì)量的結(jié)果，這在各行各業(yè)是基本規(guī)律，互聯(lián)網(wǎng)也不例外。
回頭看這一路，很慶幸在艱巨的時刻加入營收活動，并有幸引領(lǐng)了團(tuán)隊越過山丘，和伙計們一起歷經(jīng)毒打并最終站上了更高的山峰。
謹(jǐn)以此文獻(xiàn)給為營收活動付出汗水的所有伙計，也希望技術(shù)人都超越“CURD”的視野，在技術(shù)創(chuàng)造價值的過程中不斷攻城略地。
參考鏈接
[1]?https://live.bilibili.com/activity/live-activity-full/full-next/index.html?is_live_full_webview=1&;app_name=bls_winter_2022&is_live_webview=1#/popularity
