談談技術和成本

來源 | Forrest 隨想錄（ ID：forrest_thinking ）

因為最近我們內部也在實施成本優化和管控的事情，再加上之前寫文章對一些技術和成本效率問題上的一些總結，發現這個事情還有點意思，是值得反覆思考和玩味的一個問題，所以簡單分享下感受。

先說幾個我經歷過的，挺有意思的案例：

第一個，資料庫FIO卡的使用，我15年初到蘑菇街，當時蘑菇街還沒有專職DBA，是其他幾位運維工程師兼職維護，X86架構+MySql水平叢集，因為之前維護的運營商的系統，都是小機+Oracle RAC叢集+高階SSD儲存，同時配備非常專業的廠家售後服務團隊，所以很難想象這麼幾個非專業DBA是怎麼玩轉這麼複雜的電商體系下的資料庫的。

當時， 最讓我好奇的問題是 ，之前我們經常會遇到一條爛SQL就可以搞掛整個Oracle叢集的事情，SQL調優是一項非常專業的技能，有時得請專業的原廠服務或經驗豐富的DBA搞定，一般的人是根本玩不轉的，即使是這樣，也是整天被這種爛SQL搞的很頭疼。但是，到了蘑菇街，我發現貌似這類的問題好像基本沒有。

後來，我仔細去了解才知道，當時蘑菇街使用了Fusion-io卡，超高速的快閃記憶體裝置，效能非常好，當然，也非常的貴，比當時的SSD要貴好幾倍。所以一般的SQL語句只要不是太爛，一般都不會導致嚴重效能問題。當然，優化餘地還是很大，只是這個問題在那個階段變得不是那麼阻塞了而已，其實這個債，早晚是要還的。

那個時候，我的第一反應是， 靠，這麼特麼土豪，運營商都不捨得買這麼好的儲存卡，蘑菇街一買就是10幾塊，我特麼加入這麼土豪的公司，這個選擇沒有錯。

但是後來，我跟團隊同事聊下來，發現這裏面的邏輯是這樣的，一開我們用的也是主機上的SATA盤，後來換到SAS，業務量不大，一切都好說，但是業務量上來了，同樣也是各種DB效能問題。

但是， 當時我們實在是招不到，其實是吸引不到，好的MySql工程師（優秀的DBA人才一直很緊缺） ，再加上又是開源產品，也沒有所謂的原廠服務，出了問題就得自己上，誰也依賴不了。

所以，越往後越發現，團隊投入的人力上的精力和成本就越來越高，但是還沒有效果，所以索性嘗試了FIO，沒想到問題就極大的緩解了，這樣人力上就得到極大的解放，也可以去做其他的事情。

看上去貌似花了很多成本，但是帶來的收益確是不可言語的，這個算是 典型的硬體升級帶來的成本優化，在某些階段，直接減少了甚至取代了專業人力投入。

作為對比，這裏還有個有意思的小插曲，有一次，我們跟網易的DBA團隊交流，我們僅有的3個DBA過去，沒想到對方一屋子2、30個DBA在等著，他們也很詫異，你們怎麼就這麼幾個人，問的最頻繁的一個問題就是，平時你們不做SQL和儲存效能優化嗎？當他們聽到我們使用了FIO卡之後，一群人也是羨慕的了不得，土豪土豪。。。。

後來一聊，才知道，網易內部一直在推行嚴格的成本控制，資料庫使用的都是自己的內部的雲主機+SATA/SAS的儲存，不允許隨便使用高階儲存，所以SQL的優化，以及儲存效能優化，就需要投入非常大的人力。當然，這樣的極端情況下，網易DBA團隊的技術能力也是被磨練的非常突出，溝通下來，技術能力比我們還是要高出很多。

講到這裏，問個問題，網易如果全部都採用了FIO，是不是也可以節省很多人力呢？他們這麼摳門不讓使用高效能儲存，投入了這麼的專家級的人力，成本是不是消耗更高呢？

這個問題，大家還是自己琢磨下。

第二個，微服務架構的實行，算是上面的延續，我15年到蘑菇街的時候，整個技術棧還是以PHP為主，單體巨石工程+分層架構，後來因為耦合性強導致開發效率下降，所以轉向了非常流行的服務化架構，技術棧轉到了JAVA上，關於這一點我前面的文章分享過很多次，這裏就不贅述了。

還是談談先進技術的引入，服務化，說的洋氣一點就是我們現在無時無刻不再講的微服務，實行這樣的架構之後，在業務響應上，需求分解上，以及組織架構和職責的明確上，確實要比之前清晰很多，對業務的支援和響應速度也大幅提升。

但是，我想說的是，這些仍然是有代價的， 微服務引入之後，應用多了，管理複雜了，你會發現，微服務引入後，如果沒有周邊配套的效率和穩定性保障體系，是壓根玩不轉的，為此我們專門成立了平臺技術部，下設中介軟體、穩定性、運維以及虛擬化等團隊，招聘了大量的級別較高的專業人才，就是爲了專門支撐這樣的體系架構。

所以，單純看基礎平臺人力投入成本，增加了很多，這還沒有算業務研發上人力的增加。

另外一點， 從資源成本上，我大致對比過，因為應用數量的增加，以及容量評估手段不夠精確，在資源上我們的浪費和閒置還是非常嚴重的，直到當前 。

作個對比，我之前在運營商支援的一個閱讀類網際網路專案，13年左右，每日就有6、7億的PV、2000w+的交易訂購筆數，業務體量比蘑菇街要大一些，一直採用的是分層架構，資源規模上跟我15年到蘑菇街時是差不多的，但是後來我們實行了服務化之後，資源體量至少是之前的2-3倍，從每個應用使用的資源來看，看上去貌似都是合理的，最小化冗餘，業務量再小，也得雙機互備，雙機房就得4臺。但是整體來看，資源浪費和閒置就是非常嚴重。

這裏其實會暗含著整體架構設計上的問題，業務架構師水平不一樣，業務領域劃分和應用拆分體現出來的架構合理性，以及對資源成本消耗的合理性都是不一樣的。

接第一個問題，因為業務體量和資料量的高速增長，分散式資料的架構被廣泛採用，大量的分庫分表，資料庫例項的數量大幅增加，如果還是都以FIO卡為標配，成本直線上升。

所以，到了這個階段，從成本角度，我們 引入先進技術架構後：

• 成本是降低了，還是升高了？
• 如果是升高了，為什麼還要這樣做？
• 成本上升，我們應該怎麼控制 ？

這個階段，成本所面對的問題，又不一樣了，該怎麼辦？

第三個，業務上雲，我之前在極客時間專欄文章中提到過的，我們為什麼要選擇上雲，單單是因為資源的成本問題嗎？其實不是，我們測算過，上雲之後，單純從顯性的資源成本角度來看，雲是不會比自建或自運維的IDC機房模式便宜的，反而會更貴。

但是為什麼還會這樣做，具體原因我就不贅述了，大家可以直接看我極客時間裏的文章，裏面有非常綜合性的考慮。

第四個，技術開源，以業務為導向的公司，玩內部技術的開源是否有必要？是否划算？這個也是個很有意思的事情，後面專門寫篇文章分享下我的觀點。

稍作總結，技術和成本這個東西，是緊密，且複雜相關的，真的不是一兩句話能夠講的清楚的，是個需要全域性思考的東西。同時，特別重要的一點， 一旦把角度切換到成本角度，你就會發現:

1、成本有顯性的，也有隱性的，且，往往我們看不到的隱性成本是更高的，所以成本控制和優化，有時候是取決於我們對隱性成本的發掘和控制，有時候可能我們都意識不到。

2、技術不是唯一的手段，說的直白的一點，有時候，在某些情況下，技術都不見得好使，而且越從技術角度出發，反而成本可能會更高，搞的更復雜，這個我暫且不表，後面再專門寫。

3、技術手段不是唯一的，但是到了一定體量和複雜度之後，是最重要，且是決定性的手段，後面專門寫。

4、不同階段，所面臨的成本問題不一樣，要區別對待，BAT管理成本的方式，不一定適合中小公司，一是學不來，二是技術水平也達不到。

最後先收住，給一些我的建議：

1、技術人員，特別是架構師，要有點全域性成本意識，我現在發現很多的架構師都在講技術上怎麼能夠更牛逼，更深入，但是實際中，很多架構師能夠考慮到效率維度，但是真的很少有架構師能做到從成本角度來考慮。

另外，我這裏強調是的全域性成本意識，不是區域性的，大家可以自己思考下。

當然，如果站到成本角度開始思考問題了，說明站的維度已經比較高了，所以，我前面一篇文章在講，技術也好，管理也好，不是二選一的關係，多考慮怎麼為團隊創造價值，其實成本就是很重要的一塊，這個絕對是技術VP、CTO、還有CEO做夢都想搞定的事情，站得層面越高，考慮的越全域性，個人價值就越高，格局就越不一樣。其實架構師到了一定程度，拼的就是不是技術深淺和技術高低了。

大家可以看看BAT這樣的大廠，每年的技術大獎，有絕大部分都是被成本優化類的專案給拿走了。

2、貼著業務走，重要的是把技術利用好，而不是把技術研究好，這一點尤其是對於業務導向的公司，比如蘑菇街這樣的公司，比如我們提到的雲、資料庫上的FIO，還有當前技術門檻較高，對資料積累要求很高的AI和機器學習等產品，這些我認為要充分利用起硬體發展和大廠多年積累和打磨出來的技術紅利，而不是投入大量的專業人才、時間和寶貴的精力去從頭研究，去重複造輪子。

說的現實一點，即使自己做，不見得比別人做的好，做到一定程度，基本就停滯不前了，這不是技術和能力問題，畢竟BAT的業務體量和場景不是每家公司都能具備的。這種情況下不如選擇合作，我們也可以把精力聚焦到跟業務相關的研發上。

3、其實還有，我後面再補吧

囉囉嗦嗦，一不小心又寫長了，其實還沒寫透，後面再寫幾篇文章分享下吧。