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

[[193341]]  

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

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

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

必須百分百確保系統(tǒng)可控

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

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

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

預(yù)先感知漏洞所在

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

如今，這個流程已經(jīng)不能滿足監(jiān)控系統(tǒng)的需求了。監(jiān)控系統(tǒng)的新需求是先于業(yè)務(wù)，先于客戶知道漏洞存在于何處。

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

像醫(yī)生一樣給系統(tǒng)聽診

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

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

在架構(gòu) IT 系統(tǒng)時，系統(tǒng)必須要有冗余，架構(gòu)的冗余、設(shè)備的冗余、技術(shù)的冗余，包括人力上都要稍微的冗余，而不是所有的技術(shù)人員都投入在業(yè)務(wù)上。我的方法是分配出 20% 的人力，在技術(shù)架構(gòu)上實現(xiàn)超前部署。 

別把太多核心內(nèi)容放在 APP 里

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

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

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

有需求的開發(fā)者通過下單，將數(shù)據(jù)傳輸進來，我們在內(nèi)部做拆分，做數(shù)據(jù)的聚合，然后再聚合下傳、拆分，數(shù)據(jù)清晰，最后再聚合，再傳過去。通過內(nèi)部的優(yōu)化，我們可以監(jiān)控這些數(shù)據(jù)，實現(xiàn)更好地調(diào)用。

要重視數(shù)據(jù)庫

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

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

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

風控“四道關(guān)”，拒絕“羊毛黨”

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

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

• 其次，做好業(yè)務(wù)溝通與貨物物流的工作。從異常行為中發(fā)現(xiàn)端倪，從而阻止“羊毛黨”的攻擊。

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

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

• 最后，客服體系也是風控的重要環(huán)節(jié)。我認為風控最后落地的關(guān)鍵不在技術(shù)，而是客服。因為客服體系可以根據(jù)訂單來判斷用戶是否存在異常。  

技術(shù)是業(yè)務(wù)的追隨者

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

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

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

決策

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

重視雙向溝通才能共贏

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

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

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

技術(shù)至上?NO!

企業(yè)技術(shù)體系的構(gòu)建，絕對不要堅持“技術(shù)至上”原則。因為技術(shù)的構(gòu)建離不開業(yè)務(wù)的發(fā)展，構(gòu)建的目的也是為了更好地實現(xiàn)業(yè)務(wù)的升值。

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

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

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

控制技術(shù)的求知欲

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

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

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

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

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

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

千萬不要選擇外包服務(wù)

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

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

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

談?wù)務(wù)腥诉@件事

在創(chuàng)業(yè)初期，如何解決招人的難題？

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

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

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

后來，公司業(yè)務(wù)慢慢有了起色，IT 系統(tǒng)開始跟不上業(yè)務(wù)的發(fā)展節(jié)奏。在這樣的情況下，我們只能逐步解耦做 SOA，先把框架搭建起來，然后一點點調(diào)整。

我的經(jīng)驗是，即便是在初期，也要堅持自己的IT規(guī)劃和思路，定期地對系統(tǒng)進行抽檢，確保跟進業(yè)務(wù)路線，這是非常重要的事情。

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

[[193342]]

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

 

 

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】