餓了麼“短平快”創新專案的架構取捨之道
（點選“ 此處 ”可獲取史海峰演講完整PPT）
講師介紹
史海峰， 餓了麼高階總監 ，曾在神州數碼、亞信聯創長期從事電信行業業務支撐系統整合工作，參與移動、聯通多個專案，具有豐富的大型業務系統研發實施經驗。曾在噹噹負責總體架構規劃、技術規範制定和技術預研推廣，並負責技術委員會組織管理工作，發掘最佳實踐、推動技術革新，組織內外部技術交流。 負責餓了麼技術創新部，2017年推出NOW無人貨架，切入新零售風口。
大家好，我今天的分享主題是“從0到1：創新專案架構取捨之道”。大概一兩年前，餓了麼的CTO在會上問大家，你們覺得像餓了麼這樣級別的網際網路公司，最重要的資產是什麼？作為一個技術領導者，有沒有考慮過這個問題？到底是資料、程式碼、客戶、人才、系統？其實到最後會發現每一種資產都很重要，還有創新能力也非常重要。
我今天也會提到一些這方面的考慮，主要內容是以下四點：
-
創新專案從0到1架構演進策略：一個專案從0到1，你要上來就搭個大的架構還是慢慢來？顧慮是對手可能比你還敏捷，中間有很多環節顧不上，別人上的我也要上，那怎麼辦？
-
成熟技術體系中如何快速創新：餓了麼這麼大一個公司，已經擁有成熟的體系，如果想做一些創新，怎麼才能實現？
-
敏捷迭代中的技術債如何償還？
-
技術怎麼與創新業務齊頭並進？這兩點都圍繞技術問題展開，情況是開始可能技術不夠成熟，後面功能越來越豐富，資料越來越多， 是不是可以做技術驅動業務的事情？
一、案例引入
我們用一個案例來分析：去年餓了麼做了無人貨架這個業務，無人貨架是2017年新零售行業的一個風口，很多公司的辦公室裡面都有。去年的9月份開始，到現在不足一年，所以還有很大的發展空間。它的作用是放在辦公室裡面，如果你餓了，想吃點什麼喝點什麼，走過去掃碼就可以。
為什麼它是新零售的風口？跟你在路邊買水果直接掃碼有什麼區別？我們展開來講:
-
無人貨架模式定位在辦公室裡，這是一個封閉的公共空間。如果想吃飯可以叫餓了麼，但是想吃點零食或者喝點水，無人貨架三十秒之內就可以拿到手，而且不用考慮我什麼時候去買去囤，因為隨時都可以。
-
貨架面對空間裡這麼多的人，核心問題是怎樣最大程度地滿足需求，以及在此基礎上是否能給一些新的口味。甚至再進一步，在這些流量上能不能做一些拓展，架子上沒有的東西是不是也可以賣，比如新鮮水果。很多公司可以看到有冷櫃和熱櫃，熱櫃負責保溫的，標準化的場景是可以熱乎著吃，放個豆漿、包子等。所以無人貨架是一個很好的零售業務場景。
-
我們可以對接企業的需求，比如老闆看大家挺累，我們來喝個下午茶，買光架子上的零食水果，大家隨便吃也沒多少錢。所以這個模式有很多展開空間，未來行業裡，會有更多的玩法。
二、創新專案從0到1架構演進策略
去年8月6日業務團隊提出要試水專案的時候，我們知道一些創業公司做的風生水起，甚至一些大公司比如京東、順豐、蘇寧都已經開始進入這個領域，包括後來的獵豹。這個業務上我們是後來者，後發優勢就是你知道別人是怎麼做的，但面臨的壓力也很大。試水期間（8月6 日 ~23 日 ），我們做了商品調研、業務場景調研，也提了一些解決方案，跨部門協作開發，還做了Demo在公司裡試用。
9月6日無人貨架專案立項；9月20日V1.0.0產品正式上線。整個過程看起來還比較順利，業務總體反饋也都比較好。但是當時這個專案沒有任何後端體系，比如營銷後臺、運營後臺、供應鏈等，就是業務團隊去買一堆貨，自己往上面放，這種模式完全不可控，不具備擴充套件性。
11月20 日 ，我們打通了餓了麼當時原有的供應鏈系統。到今年3月5 日 ，對接餓了麼新零售地網供應鏈系統，採購倉儲物流這些都打通了。CRM、預售、拼團、鮮食等都是今年上半年我們做的一些拓展嘗試，下一步也會做智慧貨櫃。
三、成熟技術體系中如何快速創新？
我們說一下成熟體系和創業公司的區別是什麼。
餓了麼擁有一個大型、成熟、彈性、多活的技術體系。日訂單量千萬級別，整個技術團隊上千人，系統指標要求很高，所以基礎設施必須完善，不可能靠人力天天操作；架構設計有嚴格的評審機制和一套規範的操作流程。2017年餓了麼做了一個行業比較牛的“異地多活”，在兩個機房之間可以排程流量，並做日常演練。最後就是容器化、混合雲、計算力外賣等，這些關鍵詞大家可以網搜一些文章瞭解一下。面對這樣的體系，我們剛才說的無人貨架這種短平快小專案如何應對？
分析一下其中優劣：
-
首先要求一定是快，而且需求可能變。今天這麼玩，明天一拍腦袋那麼玩，即敏捷迭代，快速試錯，靈活響應。你不能跟他說你能不能有點譜，因為大家都不知道該怎麼玩。那優勢在於餓了麼有非常完善的機制，高水平人才充足，比如我們想成立一個團隊，拉起來很容易。業務立項會分到某一個技術團隊，前後端測試、專案管理等的磨合過程中，團隊配合度已經很好。不必從0到1建設一個新的產品技術團隊。
-
但是劣勢就是我們有太多條條框框，由於餓了麼體系很大，架構規範嚴格，不可能自己再做一套使用者體系，不可能自己做支付，一定得對接公司的。那就得跨團隊溝通。做這樣一個試水的創新專案，跟公司整體專案的級別一定是不匹配的。有時就是需要去刷臉，才能把這些提上去。
-
最後，如果我們今天資料出了一個bug，想把資料修 一下，不行。按照嚴格的操作流程，這個事情不能你去操作；而且要進行評估：風險有多大，一次要多少條，會不會對效能有影響。這個時候可能業務團隊已經忍不了，所以其實是優勢劣勢並存的。
我們要把這個事情做成的話應該怎麼辦？首先得有一支能打的團隊：召之即來、來之能戰、戰之必勝。我們搞的是一個獨立的專案，全新的系統，但是所有參與專案的人，都是從各個團隊拉過來的。 團隊都坐在一起，在“小黑屋”裡，環境相對來說封閉，能更專心，更高效，更團結一心。 以創業的狀態進行，把所有的任務都排好然後開始開發，最後所有的任務都是完成狀態。
上帝用七天創造了世界，我們最終用六天把這個專案做好了。期間有什麼事情？除了剛才講的攢人，還有對架構的取捨。
-
微服務： 雖說一開始沒有那麼多要拆分的微服務，但是畢竟是網際網路主流架構，要把系統做得特別靈活，為了能拓展。但也不需要考慮那麼遠，所以有考慮，以後再說；
-
技術棧： 餓了麼現成的拿過來用，大家都熟，再選擇其他技術棧是不太可能的；
-
自有的IDC： 很多創業公司都是在阿里雲上做起來的，我們當時也考慮說是不是乾脆找個阿里雲。阿里雲都在自己手裡頭，想怎麼玩怎麼玩，不用關心公司的條條框框。但是最後想了一下，還是要用自己的系統。因為比如你要跟公司的使用者系統、公司的使用者系統、支付系統打通，你不能說我外掛一下，除非自己做。不能自己再做一套基礎的體系，成本太高了。跟很多創業公司不同，他們往往資料庫只有一個，反正使用者資料少，能活著就行，但我們在一個體系裡面，這些技術是現成的，我們要用；
-
異地多活： 有沒有必要呢？有必要，但是暫時可以繞過。因為我們一般切換服務的時候是在晚上，是有人在辦公室甚至熬夜到兩三點鐘會用無人貨架，但是畢竟不是常態。我們先不考慮多活，因為實現多活更復雜；
-
中介軟體： 一定是公司現成的，包括資料庫的中介軟體，資料的備份等；
-
測試環境： 也是公司現成的，同上；
-
持續部署： 需要知道誰發了什麼版本，而且要有工具想回滾就能回滾；
-
容器化： 暫不考慮， 我們直接來臺虛擬機器當成裸機來用也OK，容器化有更高的技術複雜度，我們現在只要做一個簡單的業務跑起來；
-
日誌監控：日誌監控這個體系是公司現成的，對當前的業務有很大幫助。當時我辦公室的電視上接了個監控檢視，有天早上一看，業務量爆增，我說這一定有問題，查了一下發現有人在爬我們的資料，這種情況如果沒有監控，你根本就不知道。
四、敏捷迭代中的技術債如何償還？
同樣的我們欠了很多債，下面分析一下：
-
業務層： 包括一開始只是設定價格就進行銷售，沒有做營銷、促銷，運營的策略等。 比如說在不同架子的相同的位置上擺不同的貨，這些都是後來做的，一開始沒有考慮，都是放上去就OK。供應鏈，業務級的監控，許可權（運營、業務操作等這些許可權），一開始也沒有做那麼多，是後來補上的；
-
應用層： 反爬、埋點、快取、搜尋、多活等這些也是這樣。多活，剛才說了，影響不大但是是有影響的；
-
資料層： 我們一開始對使用者的行為資料沒有埋點收集（比如，他進來瀏覽了多少東西然後跳出了，或者他點了什麼是不是失敗的），當時沒有考慮那麼多。但畢竟有個基礎的東西在，比如最後一個爬蟲，我們做好了也可以爬別人，看看其他公司的怎麼樣；
-
系統層： 容器化暫時不用。
對於現在這個架構，我們做的取捨其實是一種選擇，以最快滿足業務上線，具備基本功能為目標，而不是一拍板就定了。
五、技術怎麼與創新業務齊頭並進？
再往下延伸，要考慮幾個問題：
-
調整策略，從突擊隊到正規軍： 現在我們已經有上萬的點位，已經有穩定的業務，那後面如果想怎麼著就怎麼著，想怎麼變就怎麼變，想怎麼玩就怎麼玩，想怎麼抓資料就抓資料，這個一定是有風險的。一開始，從0到1搞起來，這個階段有點損失沒關係。但是一旦業務、技術、運營都是穩定團隊的話，就需要轉換你的戰略。不再用突擊，要用正規軍的方法；
-
控制節奏，提高協同效率： 我們會調整我們專案的結構，提高協同的效率，大家提前做溝通，做一些規劃；
-
合理分配資源，償還技術債；
-
架構規劃，模組拆分；
-
沉澱資料，智慧運營： 把這些資料收集起來，一個業務沒準兩三年以後能有更大的市場，那這些資料沉下來就是有價值的。比如前兩天餓了麼就在準備重啟一個去年被停掉的專案，那個專案之前運行了大概兩年，一旦老闆決定重啟，我們所有的程式碼、資料都還在，可以隨時使用。不過要想重啟，可能最大的問題是人，就是原來那些人去做其他專案了，有多少人還留在這個團隊都不好說。但資料程式碼的資產都還在，很快就能拉起來；
-
做減法，保持架構健康度： 之前做這麼多需求，業務團隊有這麼多想法，現在都還有用嗎？不見得。很可能一個東西上來之後發現使用者不買賬，但它還是系統的一部分，依然天天執行著，還要考慮他的運維等，這時候做減法更能保持架構的健康度。
六、總結
所以總結一下：在風口創新裡面，快一定是第一位，天下武功唯快不破。既然技術要去支援業務，那絕對不能拖後腿；但從0到1並不需要想那麼多，以MVP為第一目標，不追求技術先進、架構完美。
還有，既然我們是一個比較成熟的體系，而且相對來說更有經驗，那麼我們要適度地前瞻一些。把產品、把架構設計得稍微好一點、靈活一點，將來拓展就不用改太多，不用推翻了就要重來，然後針對不同階段、不同策略，適時做一些調整。
最後，技術上，先支援業務，深入理解業務，再驅動業務。一開始業務人員讓你幹什麼你就幹什麼。 接下來你還要深入理解，然後才能和業務的同學平等對話。如果業務是比較輕量級，2C的，這種情況下大家要互相溝通。如果你已經做的量級非常大，可能從業務、從運營的角度來講，難以瞭解全國情況，比如我們做的O2O，基於地理位置不同，各地都不太一樣。全國各地業務什麼特點這都不好說，需要有一個強大的體系把資料收集起來，去做資料分析，去做策略指導業務，而不是靠一個人即興的想法。所以我們要做到更好，就需要更多的資料，根據這些資料來分析使用者，可以去看我們業務的趨勢，能做一些更好的指導，接下來可能成為用技術驅動業務。不是說用人員驅動業務，而是一套比較大的系統，這個系統能夠驅動業務，把公司業務能力固化在體系裡。
最近一個在政府單位工作的同學和我聊起創新，創新很重要，但更重要的是有沒有一個合理的體系，換句話說就是不能指望某個人力挽狂瀾，不是一個有志之士想激發創新，就能創新。要靠一個公司或者一個組織，要有活力，要能保證多樣性，要能夠實時變化，這需要一套體系。所以在座的各位手裡都有那麼多資料，希望我們可以給後面的人留存更多的資產，能給我們後面的業務給予指導和幫助。
Q & A
Q1： 快速迭代的時候，你的時間有限，像這種時間控制裡面有什麼東西？
A1： 沒有更多的選擇，但是一旦你迭代的節奏調整過來，每個迭代多少大家都是有數的，而且一個比較好的團隊有這個優勢，開發一定要自測。
Q2： 貨架的資料是從哪些維度進行收集？
A2： 比如登入網站，或者開啟一個APP，你是在什麼樣的環境下（4G、3G、WiFi還是其他的），還有比如你使用什麼樣的手機、登入進來之後你先點了什麼，這些都是可以記錄的。最常見的， 如果你前面的頁面做得不那麼友好，可能使用者找不到他想要的東西，因為手機螢幕很小，需要翻頁，那麼怎麼翻是合理的？一定是按照貨架上的順序嗎？ 不見得。一開始大家都在乎貨架上的順序，從上到下第一層、第二層、第三層、第四層，但是我可能上來就想拿最底層的。或者說如果有促銷，那把促銷的東西放在最上面，讓人看到，給他引導。這些東西可以通過你的佈局操作，但前提是有資料，你才能進行設計，不然你不知道他是不是按照你預想的來做。