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

[[193341]]  

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

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

所以，作為技術管理者，一定要清楚地對下屬表達自己的意見，否則，一旦出現操作上的“歧義”，后患無窮。

必須百分百確保系統可控

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

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

當時有很多同事不理解，我就和他們講述了上文我所親身遭遇的那個宕機事件。我告訴他們，當運維對于線上數據中心或者是云端的所有系統，不是全權把握的時候，終有一天你們會后悔，這就和我們后期把服務器重啟是一個道理。當運維對數據中心哪怕存在一點點失控的細節，那都意味著漏洞的存在。 

預先感知漏洞所在

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

如今，這個流程已經不能滿足監控系統的需求了。監控系統的新需求是先于業務，先于客戶知道漏洞存在于何處。

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

像醫生一樣給系統聽診

談及架構師，我認為架構師的第一個角色是醫生，首要職責是看病。我們可以把業務當成病毒，業務這一病毒會感染系統，那么架構師需要根據病情開藥方，換一個新的思路去解決問題。

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

在架構 IT 系統時，系統必須要有冗余，架構的冗余、設備的冗余、技術的冗余，包括人力上都要稍微的冗余，而不是所有的技術人員都投入在業務上。我的方法是分配出 20% 的人力，在技術架構上實現超前部署。 

別把太多核心內容放在 APP 里

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

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

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

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

要重視數據庫

關于數據庫的經驗分享，首先是永遠不要忽視數據庫的重要性。我要求數據中心的管理人員，每個禮拜的固定時間要進機房巡檢，是真的去人為地一臺臺巡檢，并把這件事當做日常的工作之一。

第二點經驗之談是數據庫怎么備份都不嫌多。這方面我也是吃虧長見識，公司的數據存儲量不大，平均一個小時備份一次，當時出了一次意外，有一小時的數據丟失了，最終找到硬盤公司，花了幾萬元才把數據恢復出來，重新再合并回去。

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

風控“四道關”，拒絕“羊毛黨”

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

• 首先要設立一套標準的風控體系，對于價格的波動、促銷的波動、銷量的波動，都有控制手段。我們公司是做食品的平臺，“羊毛黨”的目光都鎖定在那些方便流通轉賣的商品上，例如五糧液、品牌的大米、油這幾類。

• 其次，做好業務溝通與貨物物流的工作。從異常行為中發現端倪，從而阻止“羊毛黨”的攻擊。

• 再次，建起第一道防線——注冊。可以借鑒騰訊和阿里的系統，它分為兩個等級，其中第一個等級使用驗證碼就可以。通過驗證碼，做一些簡單的人工判斷、人工學習，例如通過頁面拖動的時間、停頓、失誤率來判斷出這個注冊對象是人還是機器。

  像騰訊、阿里這樣的公司，有一套完整的數據庫，通過對網站注冊用戶的一些基本資料的判斷，將用戶分成三個等級：可信、可疑和嚴重。然后，根據不同人的行為，做不同的風控體系，例如被歸為可疑的用戶，會在下單、充值、注冊、加購物車、刷新等處設置關卡，每個環節都把風控體系做好。

• 最后，客服體系也是風控的重要環節。我認為風控最后落地的關鍵不在技術，而是客服。因為客服體系可以根據訂單來判斷用戶是否存在異常。  

技術是業務的追隨者

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

追責也是技術人員必須考慮的一個因素。當客服接到用戶投訴，技術要可以實現將一系列的用戶行為記錄在案，留存證據。其實以上這一切行為的根本目的就是要將產品與技術融入到一線，跟業務打成一片。

請記住，沒有一家公司技術能滿足業務需求。如果一家公司宣稱技術能滿足業務需求，我會認為這個公司前途慘淡。因為真的業務永遠在發展，技術永遠在追隨著業務發展的腳步，技術人員如何更好地去幫助業務成長，是首要考慮的事情。 

決策

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

重視雙向溝通才能共贏

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

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

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

技術至上?NO!

企業技術體系的構建，絕對不要堅持“技術至上”原則。因為技術的構建離不開業務的發展，構建的目的也是為了更好地實現業務的升值。

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

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

通過這個慘痛的教訓，我想告訴大家：不要追求技術至上，在變動技術架構之前，一定要和業務部門充分溝通，了解他們的需求，這樣做出來的系統才能貼合實際需求，而非空中樓閣。 

控制技術的求知欲

我曾經看到過非常好的技術，覺得非常好用，結果該技術沒有形成生態，沒有技術的中文文檔，沒有論壇支持，連人才都找不到。這時，請一定控制技術的欲望，尤其作為管理者，在項目的初期一定要控制技術的求知欲。

在創業發展后期，肯定是用所有語言的所長，用所有工具的所長，去解決技術遇到的問題。我認為，沒有最好的語言，只有最適合的語言。但在創業初期，我的建議是盡量統一語言，一方面是方便招人，另一方面也會降低技術運營成本。

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

將精力專注于更有價值的事上

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

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

千萬不要選擇外包服務

如何幫助業務做得更好？傳統上看，工程代碼耦合程度相當高，我認為工具性的內容可以通過外包服務實現，如旁支的檢測、安全檢查，但是系統層面的構建千萬不要選擇外包服務。

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

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

談談招人這件事

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

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

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

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

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

我的經驗是，即便是在初期，也要堅持自己的IT規劃和思路，定期地對系統進行抽檢，確保跟進業務路線，這是非常重要的事情。

作者：錢榮明
編輯：周雪、孫淑娟
本文選自《CTO說》

[[193342]]

錢榮明，曾創辦獵頭電商推推網，后就職于IBM，2012年加入本來生活，擔任產品技術中心副總經理，參與了整個體系的技術搭建，全面負責產品技術工作，包含產品技術運維測試BI等。

 

 

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】