血淚總結！創業公司CTO要避免哪些坑？

對於想做 CTO 的人，或者正在做 CTO 的人，或者做技術管理的人而言，技術的錘煉和知識的提升非常重要。本文作者將向大家講述創業中踩過的那些坑和他們的血淚總結。

先讓我從印象最深的一次宕機講起。有一天，有一台機器的容器掛了，我對技術人員說，你把機器重啟一下吧！然後他就去了。結果沒幾秒鍾，突然收到報警。我問那位同事，你做了什麼？他反問，你不是讓我重啟服務器嗎？

當時我簡直要崩潰了，我隻是讓他把服務重啟了，沒想到他把服務器給重啟了！幸虧運氣好，重啟服務器沒有異常，如果重啟失敗，那意味著所有係統全部掛掉。

所以，作為技術管理者，

運維是企業中非常忙碌的一個職位。事實上，在創業公司，哪裏有專門的運維人員？全是技術人員身兼百職。這樣的結果往往是一團糟。

我們也是從這樣的常態中走出來的。當時沒有資金請人專門做運維，什麼事情全是自己內部消化。後來，技術團隊慢慢用 JKS 做管理，然後線上自己搭建服務器，發布係統，最終實現多線條發布。當我們逐漸將發布係統控製好之後，我們決定成立專門的運維部門和測試部門。

當時有很多同事不理解，我就和他們講述了上文我所親身遭遇的那個宕機事件。我告訴他們，當運維對於線上數據中心或者是雲端的所有係統，不是全權把握的時候，終有一天你們會後悔，這就和我們後期把服務器重啟是一個道理。

我們經常遇到這樣一個場景：業務部門的同事反饋用戶投訴係統有 Bug，技術部門的同事收到投訴後，開始檢查係統，如果有問題，那就趕緊修改，盡快上線。

如今，這個流程已經不能滿足監控係統的需求了。

這對前端技術人員提出了挑戰，要把所有的業務調整成自動化的腳本，定期地自動運營。具體實現是在前端設立一些機製，每隔一段時間去自動化地進行全路徑的測試，把點擊、下單、注冊這些流程全部都走一遍，每隔一段時間就重複操作一遍，作為一種預防機製，這也能發現一些問題。

談及架構師，我認為架構師的第一個角色是醫生，首要職責是看病。我們可以把業務當成病毒，業務這一病毒會感染係統，那麼架構師需要根據病情開藥方，

架構師要做的第二件事情是著眼未來，像醫生一樣不僅要治病，更要預防患者再次生病。所有係統的方向，在滿足業務的同時，要稍微往前麵走半年到一年的時間，對於創業公司和中小型公司，提前半年的架構已經很好了。

在架構 IT 係統時，我的方法是分配出 20% 的人力，在技術架構上實現超前部署。

蘋果應用商店對重應用的審核非常嚴格，我們提交 APP 之後，一般3天就通過審核。隨著業務的發展，我們在 2015 年發布了 14 個升級版本，平均不到一個月就需要升級一次。

為此，我給蘋果寫了 10 封加急郵件。最後，蘋果公司給我發了一封郵件，提醒這樣的行為非常不妥，建議我們先自查代碼，以後再遇到這樣頻繁的升級，審核將無法通過。

原因是我們將太多核心的功能放在 APP 中了。現在，我們不再采用這種做法，我們將粗顆粒度的代碼寫在 API 中，中間設立 ISC 框架進行多元調用，從而幫助 APP 端實現更多的功能。

有需求的開發者通過下單，將數據傳輸進來，我們在內部做拆分，做數據的聚合，然後再聚合下傳、拆分，數據清晰，最後再聚合，再傳過去。通過內部的優化，我們可以監控這些數據，實現更好地調用。

關於數據庫的經驗分享，我要求數據中心的管理人員，每個禮拜的固定時間要進機房巡檢，是真的去人為地一台台巡檢，並把這件事當做日常的工作之一。

這方麵我也是吃虧長見識，公司的數據存儲量不大，平均一個小時備份一次，當時出了一次意外，有一小時的數據丟失了，最終找到硬盤公司，花了幾萬元才把數據恢複出來，重新再合並回去。

慢慢的，公司架構就演變成現在這樣。在架構改變的過程中，所有的管理層，所有的技術負責人，對於整個團隊的技術方向要有一定把控，要去關注他們用的是什麼技術。

“薅羊毛”這個詞大家都不陌生，如何抵禦“羊毛黨”的攻擊呢？

• 我們公司是做食品的平台，“羊毛黨”的目光都鎖定在那些方便流通轉賣的商品上，例如五糧液、品牌的大米、油這幾類。
  
• 從異常行為中發現端倪，從而阻止“羊毛黨”的攻擊。
  
• 可以借鑒騰訊和阿裏的係統，它分為兩個等級，其中第一個等級使用驗證碼就可以。通過驗證碼，做一些簡單的人工判斷、人工學習，例如通過頁麵拖動的時間、停頓、失誤率來判斷出這個注冊對象是人還是機器。像騰訊、阿裏這樣的公司，有一套完整的數據庫，通過對網站注冊用戶的一些基本資料的判斷，將用戶分成三個等級：可信、可疑和嚴重。然後，根據不同人的行為，做不同的風控體係，例如被歸為可疑的用戶，會在下單、充值、注冊、加購物車、刷新等處設置關卡，每個環節都把風控體係做好。
  
• 我認為風控最後落地的關鍵不在技術，而是客服。因為客服體係可以根據訂單來判斷用戶是否存在異常。 
  

我曾經親身體驗過，當時團隊的一位技術同事做了一個功能，他自己認為開發的非常好，可以大大提高倉庫工作人員的效率。我去倉庫幹了一個禮拜，回來之後，針對他提的功能改了 40 多處。

當客服接到用戶投訴，技術要可以實現將一係列的用戶行為記錄在案，留存證據。

請記住，沒有一家公司技術能滿足業務需求。如果一家公司宣稱技術能滿足業務需求，我會認為這個公司前途慘淡。因為

CTO 在管理過程中時刻需要做決策，從管理層角度看問題做判斷，一方麵是由過去的經驗輔助決策，另一方麵是從公司整體出發，決策更有全局觀。

相信很多時候，技術管理者都會遭遇這樣的問題，比如 CEO 一個電話要求 CTO 某項目一個月上線。這是領導做出某項決策，沒有給技術人員留出足夠的準備時間的情況，屬於典型的缺乏溝通意識。

當時我和 CEO 溝通，或許我可以用一個月的時間做出一套係統，但是這套係統是否能讓雙方滿意，是否能達到預期？這都存在風險。我請他以後有新的想法，要提前和技術人員溝通，不要等到已經做出決定了再告訴技術人員，因為這樣會讓技術人員非常被動，也讓項目實施徒增很多困難。

技術團隊還會經常聽到的話：“這有很難嗎？應該幾天就可以完成吧？為什麼這個這麼慢啊，兩天時間還搞不定嗎”這些話在創業初期不絕於耳，因為你不能要求每一位老板都懂技術，所以你隻能妥協，通過團隊的努力，盡可能快地實現領導下達的目標。

企業技術體係的構建，絕對不要堅持“技術至上”原則。因為技術的構建離不開業務的發展，

還是用上文中與 CEO 的溝通作為例子，當時隻有一個月的時間，我無奈之下做出了一個非常錯誤的決定：把現有 IT 係統拆分，拷貝了一套出來，在此基礎上修改，重建了一條分支。這也意味著，技術內部存在兩套係統，各自有獨立的服務器、獨立的係統、獨立的數據監測。

這個解決辦法的確滿足了業務的需求，但很快更多的問題暴露了出來：無論從財務層麵、報告層麵還是公司結構層麵，都需要將這兩套獨立係統再度融合在一起。

通過這個慘痛的教訓，我想告訴大家：

我曾經看到過非常好的技術，覺得非常好用，結果該技術沒有形成生態，沒有技術的中文文檔，沒有論壇支持，連人才都找不到。這時，請一定控製技術的欲望，

在創業發展後期，肯定是用所有語言的所長，用所有工具的所長，去解決技術遇到的問題。我認為，沒有最好的語言，隻有最適合的語言。但

現在我也在挖掘更多的能力，希望減少人力重複的工作，目的也是為了。這是一個非常現實的問題，因為在公司成本中，往往人力成本是最貴的。從領導角度考慮就會思索，能不能將幾千萬的工資降低，去做別的更有價值的事情。

在創業的初期階段，我選擇用服務商去為公司招人，做安全測試時，我也決定花錢請外麵的公司對我們做滲透測試，之所以這麼做，是因為我認為公司初期所有的資源都應該為業務鋪路，這是我的做事原則。在當然，盲目去支撐也不對。

我們目前在做私有雲，但是我不準備在這件事上花過多的精力，我要用最輕的方法做私有雲，讓專業的雲廠商去實現我們的訴求。

如何幫助業務做得更好？傳統上看，工程代碼耦合程度相當高，我認為，如旁支的檢測、安全檢查，但是

我們公司創業最初的係統是外包給供應商做的，可他們做了一件令我覺得不可思議的事情：為了把核心代碼加入係統中，他們把所有的邏輯都寫在了同一層裏麵，不管邏輯是否通順，甚至也不管該不該寫在其中，全部一股腦寫進去，然後把這個包加密了。

當我把源代碼購買來解密了這個包之後，那一瞬間我就想把係統推翻重做！這已經談不上什麼耦合關係了，儼然是打斷骨頭連著筋的狀態，最後沒有辦法，我們自己一點點做解耦。

在創業初期，如何解決招人的難題？

我的回答是，看論壇中的學生，有沒有符合要求的人。還可以讓這些人推薦他們身邊的好友，不管是畢業的、應屆的、沒畢業的，隻要是人才，通通招進來。

坦白說，我創業初期的成員就是靠這個辦法招來的，畢竟在公司初創時期，沒有品牌效益，沒有資金，前途和“錢途”都無法許諾，隻能通過這樣的方式去招人。

值得一提的是，通過我這樣的方法招來的員工，職場經驗如同一張白紙，他們沒有見過世麵，也並不知道該做什麼。大部分人技術都停留在理論知識，寫過一些小程序，並不了解什麼是開發，什麼是資產。這樣的結果就是公司的係統質量令人堪憂。

後來，公司業務慢慢有了起色，IT 係統開始跟不上業務的發展節奏。在這樣的情況下，我們隻能逐步解耦做 SOA，先把框架搭建起來，然後一點點調整。

我的經驗是，