文|飛林沙

這篇本應(yīng)在一周前產(chǎn)出的年底總結(jié)被拖延癥拖到了現(xiàn)在，上午和同事去深大校園里逛了兩個小時，看著學生們悠閑地背著書包走在去往自習室、圖書館的路上，不禁感嘆原來自己已經(jīng)畢業(yè)了六年時間。六年來，我從最初的Web開發(fā)人員接觸到一些服務(wù)端開發(fā)，然后莫名其妙成為了業(yè)界最火熱的大數(shù)據(jù)工程師、數(shù)據(jù)科學家。在職責上，從單槍匹馬搞定所有事兒，到帶領(lǐng)十幾人的數(shù)據(jù)團隊去做一個領(lǐng)域的探索，再到帶領(lǐng)幾十人的部門去做實驗產(chǎn)品嘗試，再到現(xiàn)在作為CTO跟著百人的產(chǎn)品研發(fā)團隊高速奔跑，看著公司一年時間完成近十倍的增長?；貞浄N種，恍若云煙。

回頭看過去的2015，也許是入職了一個和之前不一樣的企業(yè)，也許是接觸到了與之前不同的人，也許是背負了無法與往日相比的壓力。所以我嘗試著將一些想法寫出來，沒有主題，沒有主次，想到哪兒寫到哪兒。

1.企業(yè)級服務(wù)公司的思考

今年最大的變化，是我第一次從一個互聯(lián)網(wǎng)行業(yè)進入了一個企業(yè)級服務(wù)市場，經(jīng)過一年的適應(yīng)和思考，讓我對企業(yè)級服務(wù)市場有了更多新的看法。那我就先來說下我眼中的企業(yè)級服務(wù)吧。眾所周知，企業(yè)級市場與互聯(lián)網(wǎng)公司的發(fā)展不同，他與當前創(chuàng)業(yè)環(huán)境、公司資金等息息相關(guān)，我們回憶一下《創(chuàng)業(yè)維艱》就知道在差的資本環(huán)境下，一個企業(yè)級服務(wù)公司有多難生存下去。

企業(yè)級服務(wù)的公司到底如何做利潤，如何做大是我最近一年一直思考的問題。先從最基本說起，企業(yè)從最基本的訴求來說為什么使用云服務(wù)，例如企業(yè)為什么要使用阿里云、七牛等等，根源無外乎：1. 動態(tài)擴展能力 2. 低人員技術(shù)成本 3. 不需要去做臟活累活。歸根結(jié)底的說就是企業(yè)認為做這些事情的ROI不如交給云服務(wù)公司的ROI高，例如把圖片存儲在我自己這兒每年需要耗費100W的機器成本+20W的人員維護成本，穩(wěn)定性可以達到99.9%，那作為一個理智的技術(shù)決策者，一定會要求廠商用100W的計算解決問題，并且穩(wěn)定性不可以低于99.9%。那我們這個時候把視角從客戶視角切回到云服務(wù)廠商視角，那我們要如何才能賺錢呢？

A.寄望于客戶的水平在平均線以下，例如改造XMPP，業(yè)界的平均水平是2個人月的水平，但是很多客戶需要10個人月，這樣相當于賺了8個人月的錢。但是這其實是一種極爛的做法。具體會在下文中有所表述。

B.動態(tài)擴展能力。這一點是客戶使用很多云服務(wù)的理由，那么如何通過資源的合理規(guī)劃在這方面去賺錢呢？我倒是有些思路，但是從目前來看還需要較長的路要去走。舉個簡單的例子，假設(shè)說每次某電商網(wǎng)站雙11搶購時都需要1000臺服務(wù)器才能滿足需求，也就是說不采用云服務(wù)至少需要1億左右的預算，但是其實大部分時間其實只需要10臺服務(wù)器就足夠了，于是想辦法降低服務(wù)器閑置率就是我們可以賺的錢。但是目前的云服務(wù)廠商(我視野范圍內(nèi)的)還無法做到這一點。假設(shè)說淘寶、京東、唯品會同時使用了我的云服務(wù)，也就意味著我需要準備 淘寶+京東+唯品會三家的機器總和，如果他們每一家的機器閑置率是90%，那我也同樣是90%。所以真正想做到這一點需要的是對客戶進行明確的劃分，通過不同的客戶策略組合從而提高機器閑置率，例如構(gòu)建淘寶(雙11)+亞馬遜(黑色星期五)這樣的組合，把機器的閑置率從90%降低到70%。這是一個很理想的情況，在實操中會遇到很多的困難，在下文中我會再次提及。

C.承包臟活累活。這一點其實是國內(nèi)大部分云服務(wù)廠商賺錢的主要途徑，幫你把麻煩的事兒給做了，比如你懶著去做個統(tǒng)計后臺，我?guī)湍愀懔?；你懶著去搭個Docker服務(wù)，我?guī)湍愦詈茫荒銘兄プ霭踩呗?，我?guī)湍阕隽恕５腔貧w到我們上面說的ROI的問題，這必然會導致利潤率極低，這并不符合互聯(lián)網(wǎng)企業(yè)高利潤率的模式，而基本純粹屬于外包公司了。這并不應(yīng)該成本云服務(wù)廠商的立足之本。

D.通用方案的快速復制。這個和過去的ERP公司很類似，做出標準產(chǎn)品，然后去兜售給各個客戶。和上面的點一樣，這也是現(xiàn)在云服務(wù)廠商的立足之本?？墒钱斘覀兓貞浺幌翬RP時代的企業(yè)的賺錢方式，我沒太聽說哪一家是通過把一個通用性軟件賣給客戶然后就能賺到大錢的，基本賺錢的費用都是在定制化、后續(xù)維護費用。但是定制化的成本其實又回到了上文的ROI上，不再贅述。此外，還有一點ERP軟件的賺錢方式，就是扎根于某一特定領(lǐng)域，例如用友金蝶的財務(wù)軟件等，這似乎又與如今的云服務(wù)廠商發(fā)展路線相悖。所以這聽上去很美，卻依然是一個低利潤的事情。

從上面四點來看，只有第二點才是值得去發(fā)展的路，先記在這里。

2.云服務(wù)和大數(shù)據(jù)

在過去一年無數(shù)次的采訪和演講中，我都努力在講一個概念，就是云服務(wù)和大數(shù)據(jù)的結(jié)合。只有平臺級產(chǎn)品才有大數(shù)據(jù)的理論，我也不厭其煩的反復提及。那么相比于傳統(tǒng)“云平臺”的低利潤外，大數(shù)據(jù)所產(chǎn)生的高利潤率似乎更讓人幻想。相比于機器學習，數(shù)據(jù)挖掘這些技術(shù)而言，更困難的還是數(shù)據(jù)如何才能產(chǎn)生商業(yè)價值。在過去的一年里，我們做了各種各樣的嘗試，取得了一些小的成果，也對未來的方向有了一些更清晰的認識。

談到數(shù)據(jù)變現(xiàn)時，我們需要做更多的產(chǎn)品和商業(yè)層面的思考，在這些上面，我走了太多的彎路：

A.我們更應(yīng)該清晰地識別出哪些業(yè)務(wù)是需要數(shù)據(jù)的？

我們到底是在拿著數(shù)據(jù)去找業(yè)務(wù)，還是在用業(yè)務(wù)來倒推數(shù)據(jù)的價值。如何識別是否在拿著錘子找釘子，我有一個特別簡單的方法供參考，一個方案需要Rule-based來解決問題，還是需要通過Machine Learning來解決問題。我們想下什么樣的方案是沒辦法通過Rule-based無法解決的問題。例如Uber希望通過大量的數(shù)據(jù)行為來緩解交通堵塞，這不是rule-based可以解決的問題。抽象來說，大數(shù)據(jù)的真正價值是通過海量實時多樣的數(shù)據(jù)，通過機器學習訓練出最適合的模型，這個模型抽象了人類幾乎不可能完成的復雜規(guī)則引擎，而深度學習在大數(shù)據(jù)時代的流行很大程度上也是因為其對大量特征的組合再加工，這也可以看做是數(shù)據(jù)多樣化的必然產(chǎn)物。

B.這些數(shù)據(jù)引入前和引入后到底能產(chǎn)生多少額外價值？

因為這個取決于企業(yè)到底愿意為數(shù)據(jù)服務(wù)買多少的單。例如互聯(lián)網(wǎng)金融公司希望利用大量的數(shù)據(jù)去做征信模型，但是當引入新的因素變量時，哪怕讓準確率有1%的提升，都會產(chǎn)生極大的經(jīng)濟價值。

C.實時數(shù)據(jù)能產(chǎn)生多少的價值？

實時數(shù)據(jù)意味著合作的長久性，例如對于音樂推薦產(chǎn)品來說，如果提供的數(shù)據(jù)只是三年前的數(shù)據(jù)，那么數(shù)據(jù)效果會極差，所以這樣就保證了公司必須不斷使用實時的數(shù)據(jù)方案來滿足需求。

以上幾點其實決定了你要為哪些行業(yè)提供數(shù)據(jù)解決方案，最初的時候我的想法依然是停留在互聯(lián)網(wǎng)公司上，希望能夠利用平臺上多樣化的大數(shù)據(jù)去幫助互聯(lián)網(wǎng)公司精細化運營，例如優(yōu)化推送方案，優(yōu)化推薦內(nèi)容，但是現(xiàn)實告訴我這條路還走不通，問題就在于A和B兩點，規(guī)則引擎可以解決問題&引入多樣化數(shù)據(jù)后產(chǎn)生的經(jīng)濟價值略低。這也是在未來一年甚至幾年內(nèi)需要持續(xù)思考的問題，但是這條路是被判死刑的么？我是否認的。 另外，在上一節(jié)中，我為何說寄望于客戶的水平在平均線以下去賺錢不現(xiàn)實，這就引出了下一個話題，關(guān)于創(chuàng)業(yè)。

3.關(guān)于創(chuàng)業(yè)

最近的一年時間里，我接觸了大量的創(chuàng)業(yè)者，他們會咨詢各種各樣的問題，在這里我簡單談下我的一些看法：

A.世界一定在朝著好的方向發(fā)展。任何一個顛覆性的創(chuàng)業(yè)想法一定有著缺陷，或許是因為政策，或許是因為習慣，或許是因為大眾的水平。所以在面對著很多“不靠譜”想法的時候，我更愿意去思考這個應(yīng)該在什么時候去做才比較合適。例如我有個朋友，一直想做一個時尚類的APP，用他的話說，大部分中國人的審美太“淘寶”風了。我認為這個出發(fā)點是好的，并且在國外已經(jīng)有很多成功的案例，我們也相信大眾的審美必然從“淘寶風”轉(zhuǎn)為“個性化”，只是這個時機應(yīng)該是什么時候更合適的問題。所以我并不認同基于“丑陋”的一面去創(chuàng)業(yè)，例如在用戶不知情的時候推送廣告，例如所謂的“利用人性”，再例如朋友圈的小紅點。

B.曾經(jīng)我一直認為創(chuàng)業(yè)就是解決用戶的某個痛點需求，現(xiàn)在我更認為創(chuàng)業(yè)其實是在一個大環(huán)境下基于上下文去解決一個大家嘗試解決很多次的問題，說的更大一點，真正的創(chuàng)業(yè)解決的是補全生態(tài)鏈。仍然以上述的時尚類APP為例，做成一個時尚應(yīng)用，要保證的是買家用戶審美水平的提高，賣家設(shè)計水平的提高，供應(yīng)鏈的資源充足，獨立設(shè)計師與買家之間的糾紛解決等一系列問題。這絕不僅僅是一個APP所能解決的，這個APP的成功應(yīng)該僅僅是補全其中的一環(huán)，并且在這一環(huán)做到最佳的體驗。

那么如何去甄別呢？

A.對標法。這個是投資人最常用的做法：國外有沒有類似的產(chǎn)品，國內(nèi)有沒有類似的產(chǎn)品，他們?yōu)槭裁礇]有成功，你是怎么解決這些問題的？這種方式簡單粗暴，但是只能看到問題，不能解決問題，而且極容易陷入創(chuàng)新的死胡同。

B.鏈條整理法。既然我上文說到了創(chuàng)業(yè)其實是補全生態(tài)鏈，那么請先劃出這個產(chǎn)品的成功需要依賴于哪些條件，也就是他的鏈條上下游分別是什么，例如“大眾審美的提高”等。這些依賴的條件是否已經(jīng)得到解決，是怎么解決的？在你的產(chǎn)品出現(xiàn)前，鏈條的這部分是如何被填補的，這個方案有什么瓶頸？這個瓶頸是在他的上下游還是自己本身？ 另外，因為創(chuàng)業(yè)產(chǎn)品的發(fā)展絕不僅僅是自身體驗的完善，規(guī)模的擴大，更大的程度上還是取決于整個生態(tài)鏈的進步，所以要進一步地去問自己，這個鏈條上除了我的環(huán)節(jié)，其他環(huán)節(jié)發(fā)展如何，他們的增長曲線預計會是什么樣？

更愿意從大局，而非產(chǎn)品本身去看待問題也許是我這一年的一個進步。

4.對于迭代的再次思考

互聯(lián)網(wǎng)公司多年的經(jīng)驗，在我腦子里固化了小步快跑，敏捷迭代的思想，而這讓我來到極光之后非常的不適應(yīng)。強調(diào)設(shè)計，強調(diào)文檔，對于質(zhì)量的控制，強調(diào)穩(wěn)定，這在我之前的經(jīng)歷里是沒有的，甚至是相違背的。

在敏捷迭代模型中，做法是需求->設(shè)計->編碼->測試->設(shè)計->編碼->重構(gòu)，如此往復。但是這個模型在執(zhí)行過中出現(xiàn)了太多的問題，從客戶端而言，設(shè)計的不穩(wěn)定必然會導致API頻繁發(fā)生變化，而且SDK的更新版本往往都是取決于開發(fā)者本身。對于一個APP而言，應(yīng)用的一個Bug可能只會帶一個版本，而對于SDK而言，由于多了開發(fā)者的這一環(huán)，所以這注定是無法敏捷的。從服務(wù)端而言，設(shè)計的失誤會導致大批量的服務(wù)受影響，并且服務(wù)端的數(shù)據(jù)問題又將持續(xù)被困擾很久。那是不是意味著敏捷迭代注定和企業(yè)級開發(fā)無緣呢？

我更愿意認為企業(yè)級服務(wù)需要采取的是另外一種方式：

A.產(chǎn)品計劃不能迭代。對于云服務(wù)廠商而言，產(chǎn)品計劃最直觀就是反映到API如何設(shè)計，軟件如何做基本的分層架構(gòu)，服務(wù)端客戶端采用什么樣的分工方式。

B.整體設(shè)計不能迭代。這里指的整體設(shè)計是說針對產(chǎn)品需求，需要對接下來的技術(shù)整體方案有整體的設(shè)計，大到SDK和服務(wù)端的通訊協(xié)議，服務(wù)端的整體架構(gòu)方式，機架的分布，小到API的設(shè)計穩(wěn)定性，這些是必須要穩(wěn)定的。

C.設(shè)計方案需要迭代。當大的架構(gòu)模式確定后，小的設(shè)計方案我個人認為是值得迭代的，例如存儲方案到底使用MySQL還是PG，消息隊列到底使用RabbitMQ還是Kafka，不妨上線灰度測試，然后設(shè)計方案，由于真實環(huán)境和測試環(huán)境的差異性，這里需要評估壓力測試等的時間成本。

D.功能開發(fā)需要迭代。當我們理清上述的設(shè)計后，可以將產(chǎn)品和架構(gòu)的設(shè)計圖加以切分，根據(jù)聚類找到連通子圖，拆分迭代開發(fā)，如果A的效果不好，那么B自然無需繼續(xù)開發(fā)。

E.經(jīng)常重新Review設(shè)計。人非圣賢，即便再好的技術(shù)都無法保證設(shè)計的合理性，把不合理的設(shè)計扼殺在萌芽里，而不是等著他即將爆發(fā)的那一天。

5.數(shù)據(jù)的未來

隨著互聯(lián)網(wǎng)環(huán)境的逐漸成熟，任何企業(yè)無論是管理還是產(chǎn)品都必然走入精細化、數(shù)字化的層面，那么如何定義自己是一家大數(shù)據(jù)公司？并不是說我自己有著很多的數(shù)據(jù)，而是由數(shù)據(jù)來驅(qū)動整個公司的發(fā)展。

現(xiàn)在我看到的大多數(shù)公司基本都是在問我，我們現(xiàn)在有這么多的數(shù)據(jù)，我們可以做點什么？其實這個思路也許在以后會改成我們想做這個，那么我們需要哪些數(shù)據(jù)？從產(chǎn)品層面，例如我們需要做征信服務(wù)，那么我們都需要哪些數(shù)據(jù)，這些數(shù)據(jù)我需要怎么樣才能獲得？這是數(shù)據(jù)驅(qū)動開發(fā)的思路。 從運營層面，回到我在第一點所說，如果云服務(wù)公司的一大盈利點是通過對機器閑置率的調(diào)度優(yōu)化，那么是否應(yīng)該利用數(shù)據(jù)對銷售進行更加合理的驅(qū)動，這是數(shù)據(jù)驅(qū)動市場。從管理層面，我們?nèi)绾斡嬎阋粋€公司需要的最佳人數(shù)，如何評估每個人的績效，這自然是數(shù)據(jù)所決定的，這是數(shù)據(jù)驅(qū)動管理。

而這些，都是數(shù)據(jù)人員需要去探索和努力的路。

6.反思 & 提高

A.商業(yè)推動能力的不足。這算是我對自己最大的批評吧，在今年，其實有著太多的公司合作，但是我卻并沒有辦法去把握利益的平衡。

B.行業(yè)背景知識的不足。傳統(tǒng)企業(yè)知識的缺乏導致我沒辦法真正理解他們的架構(gòu)和需求，更沒辦法對方案進行包裝達到他們想要的結(jié)果。

C.抵御技術(shù)細節(jié)的誘惑。這是一個技術(shù)人員成長為管理人員的最大問題，抓全局而輕細節(jié)，畢竟時間和精力都有限，而回顧起來我還是浪費了太多時間。

希望新的一年會有所提高吧。

飛林沙：商品推薦算法&推薦解釋

重磅推薦：大數(shù)據(jù)工程師飛林沙的年終總結(jié)&算法數(shù)據(jù)的思考

需求與匹配 從數(shù)據(jù)挖掘角度看世紀佳緣推薦系統(tǒng)

End.

轉(zhuǎn)載請注明來自36大數(shù)據(jù)（36dsj.com)：36大數(shù)據(jù) » 飛林沙：企業(yè)級服務(wù)公司如何賺錢？只有平臺級產(chǎn)品才有大數(shù)據(jù)的理論