[[392933]]

本文轉載自微信公眾號「碼磚雜役」，作者我不想種地 。轉載本文請聯(lián)系碼磚雜役公眾號。

軟件測試有句名言：測試只能證明缺陷的存在，而不能證明產品沒有缺陷。

為了保障安全，我們引入規(guī)范和流程，小心翼翼設計編碼，如履薄冰測試發(fā)布，軟件的結構和實現(xiàn)非常大的比重服務于穩(wěn)定性，然而，縱使我們窮盡所能，也只能最大限度減少故障，而終究無法徹底消除故障。

企業(yè)為了保障交付和運營質量，往往會設置安全標準，制定事故懲罰規(guī)則，而這加劇了交付效率和系統(tǒng)安全的沖突。軟件工程師搖身一變成了跟外科醫(yī)生一樣的高危行業(yè)從業(yè)者，我們被灌輸了很多跟安全生產相關的知識，我們的認知被教育成某個樣子，我們對于線上故障的觀念根深蒂固而又深信不疑。

筆者在網游和互聯(lián)網大廠工作過，它們對于線上故障有著截然不同的態(tài)度，這些不同對我造成了強烈的沖擊，可以說我剛被教育成某個樣子，等換了一份工作，又被教育成另一個樣子，所以，我的認知在不斷變化，而這些經歷和變化使我相比別人有更多的思考和感悟。

如果說對于這個話題，我跟剛參加工作時有什么不同，那就是我逐漸意識到事情沒有絕對，意識到我的認知不一定正確，而這或許是通往正確的道路。

所以，我把所見所感記錄下來，力求客觀呈現(xiàn)原貌，既不是要主張什么，也不是要批評什么，因為，相比于觀點，事實才是更重要的，我更愿意傾聽大家的觀點。

一、網絡游戲

我讀研的時候在某狐做實習，在當時，某狐就是大廠，后來火狐工作室獨立上市，對，就是納市上市的CY。

我在《TLBB》做了一年半的游戲開發(fā)，這款游戲當時非常成功，PCU超80萬，為公司貢獻超過90%的營收。

TLBB通過流程管理軟件管理需求和缺陷，這在當時非常先進。

策劃提需求寫文檔，程序開發(fā)功能，提測，然后流程流轉到測試那里。

測試的考核按BUG計件，而提測后的BUG數(shù)也會影響程序績效。這樣的制度設計能確保程序提測前做充分自測，從而去降低缺陷數(shù)，程序是功能的開發(fā)者，是白盒測試的最佳實施者，他似乎有一種天然的感知，預感那里會有可能出現(xiàn)問題，而且為了方便自測，他會想法設法去開發(fā)一些輔助測試功能，這又會提升測試的效率。

而測試為了績效，也會竭盡所能去查找缺陷。但這個制度的一個副作用就是程序和測試關系經常很緊張，程序覺得地位不高，經常被測試干。

CTO為TLBB服務器制定了幾條制度：

1. 簡單至上，設計上直來直去，不過度設計;編碼上不準用模板、不準用STL、不讓用C++高級特性(比如異常、placement new等)。

2. 注重防御，安全優(yōu)先于效率，任何一個函數(shù)都嵌入ENTER_FUNCTION和LEAVE_FUNCTION宏，多判斷多檢查，盡量不崩。

這種設計獲得的一個顯著好處就是項目代碼簡單，門檻不高，應屆畢業(yè)兩禮拜就能愉快上手，壞處就是程序性能不高，開發(fā)者天天跟數(shù)組和指針打交道，技術提不高，以致工作一年多之后發(fā)現(xiàn)看不懂開源項目，感覺自己是個智障。

游戲要求快速迭代，每周都會發(fā)版本，所以，從特征分支往主干merge代碼有時間窗口，窗口關閉期內只能fix bug，新人前半年提交代碼，會有人做review，相當于給兒童自行車后輪裝2個支撐輪，之后便能自主提交，至于靜態(tài)掃描、代碼門禁，不好意思，沒聽過。得益于良好的制度設計和測試環(huán)節(jié)，TLBB服務器總體平穩(wěn)，小問題偶發(fā)。

公司對線上故障有定級，但公司不怎么講，所以大家感覺也不怎么強，要是某個程序不開眼捅了簍子，考核會受一些影響，次數(shù)多了，便會被貼不靠譜的標簽，只能專業(yè)打雜。

后面我去了WMSJ，這個公司是幾個清華學生做起來的。

07年，《WMSJ》憑借在3D上的卓越表現(xiàn)驚艷問世，隨后又連續(xù)推出幾款不錯的游戲，成立三年便赴納市上市了。

那時候CHI老板意氣風發(fā)，千金買馬骨，給應屆生開出了1萬5-1萬8的高薪，哪年校招我碰上了，但是他們要求很高，我一面就陣亡，我另一個研究生同學去霸面被轟了出來。

這家公司的第一代程序員水平很高，至今我仍然認為是我工作中接觸到最才華橫溢的程序員，從客戶端引擎到UI到數(shù)據(jù)庫，整個游戲前后端+引擎，全部自研。因我做服務器，所以無法評價引擎、客戶端技術。

光論服務器，它們的技術水平是很高的，當我在CY的時候，大家一直在Y，WM的大世界(無縫地圖)到底是怎么做的呢?TLBB是分片地圖，當我看完WMSJ服務器的代碼，我被震撼了，那是一個非常精巧的設計，后來大熱的BigWorld引擎在服務器設計上跟WM有共通之處。

相比TLBB，WMSJ完全是無規(guī)則的，沒有任何明文規(guī)定禁止做什么，應該怎么做，只要編譯能通過，運行不報錯，就哦了。編碼規(guī)范?交叉review?不需要的，代碼門禁?封版?不存在的，線上故障處罰?沒有的事。

但入職后一個半月，我除了看代碼，沒有任何工作要做，我一度懷疑領導對我有看法，借老婆生小孩的機會請1個月假表達不滿，領導問我為何請這么長的假，我說反正也沒事干，領導說，你沒看新來的那個清華畢業(yè)生已經氣定神閑的看了2個多月代碼了嗎?讓我淡定，組織馬上就有任務安排給我了。

通過這個項目，我學會到epoll模型、學會了多線程、學會了通過消息機制解耦、學會了COW、學會了lazy evaluation、學會了真正的OOP和GP(做抽象、泛化和擴展性)。

其中最大的思維碰撞來自于容錯，之前TLBB的編碼會做大量的容錯處理，比如簡單的get函數(shù)也會有enter_function/leave_function宏，會對指針判空，參數(shù)做合法性校驗，會對返回值做檢查，會log error等，大量的容錯代碼淹沒了功能代碼，導致完成同樣的功能，需要多得多的代碼。

但WMSJ的做法截然相反，它廣泛的使用斷言，函數(shù)專注于功能邏輯，對調用者有期望，如果不符合要求，不叨逼，直接崩，風格很硬朗，代碼很緊湊。

我工作以來接受的教育不是這樣的，這讓我困惑，我找到了GameServer的主要開發(fā)者C總(技術VP、清華畢業(yè)的，他一個人寫了超過60%的代碼)，公認的WMSJ最強架構師(不是我封的)。

我說：“TL服務器的風格是面向失敗編程，能不崩就不崩，這樣，程序才能有足夠的韌性。WM服務器這樣做不對吧!”

C總回答：“不是這樣的，容錯不是越多檢查越多日志越好，核查只應該在邊界進行，函數(shù)的實現(xiàn)者和調用者遵從某種契約，過多的防御并不能體現(xiàn)面向失敗編程的思想，也不利于構建健壯的程序。崩會及早暴露問題，該崩不崩只會把錯誤埋得更深，導致缺陷更難定位，最終程序會變成藏污納垢的混亂場，從而變得更加脆弱。”

“依賴假設，在代碼被修改后，容易引起問題，線上故障是應該極力避免的。”我當時的認知沒法接受他的解釋，而是嘗試說服他。

C總說：“assert在編譯debug版本的時候起作用，而發(fā)布的時候，編譯的是release版本，這其實是內嚴外松，在開發(fā)階段及早暴露問題，上線之后才能更穩(wěn)定，而且你遵照這樣的規(guī)則編寫程序會更清晰健壯，你多看幾個開源項目就明白了。”

我當時被“你多看幾個開源就明白了”給噎住了，因為我當時確實沒看過什么開源項目，以致很多年以后，碰到同樣的辯論，我也會用同樣的一句話噎人。

WMSJ無規(guī)則，新人看一個月代碼，這些事情，我絲毫沒有夸張，所以，你看，雖然同為游戲公司(且為同種類型游戲MMORPG)，但TL和WM采取了截然不同的策略，且在當時都取得了成功。

當年做游戲的時候，我們的開發(fā)任務很重，一般服務器組也就5-7人，2年內要寫50萬行左右的C++代碼，4萬行C++每人年，這個工作量是很大的，所以，其實很難走很重的研發(fā)流程，可以說，嚴格按流程走，基本上游戲沒上線之前就死了。

但沒走流程并不意味游戲程序員技術差，恰恰相反，大劑量的編碼訓練，往往使得大家編碼水平較高，而且普遍很務實。

還有一個有意思的事情就是，我們曾經按照銀行系統(tǒng)的要求去搞數(shù)據(jù)庫，比如支持事務、支持回滾，發(fā)現(xiàn)既麻煩又別扭，直到有一天，我們頓悟，發(fā)現(xiàn)我們想多了，其實人最怕想多，也最容易想多，文科生一想多就容易出家，藝術家一想多就容易自殺，最終我們參考伯克利DB只用簡單的3千行C++就寫出一個Cache DB，其實它也夠用了。

做游戲的時候，另一個體會就是我們曾經在穩(wěn)定性設計上投入了很多精力，或者公司運營對穩(wěn)定性提出了較高的要求，我們曾堅信這些是必要的，直到有一天，我們發(fā)現(xiàn)，事情可能并非如此。

比如有個游戲在封測期間，一天晚上宕機十幾次，但瘋狂的玩家竟然一邊在論壇破口大罵，一邊癡心不改的等待重啟恢復，而統(tǒng)計數(shù)據(jù)表明，這款游戲的流失率很低，玩家好像真正在乎的只是游戲的趣味性，我們曾錯誤的以為穩(wěn)定性是留存的大敵。

另一個例子是，某游戲因為程序缺陷，漏洞被玩家利用，而這個事情暴露后，消息在論壇、網絡傳播，導致大量吃瓜和看熱鬧的新玩家涌入，一個漏洞變成一個很好的運營廣告，我們覺得出現(xiàn)故障，影響玩家體驗，再給玩家發(fā)補助，這只是不得已的補救，但調查發(fā)現(xiàn)，這竟然是玩家喜聞樂見的，能極大提升話題熱度和玩家活躍度。

二、互聯(lián)網

說完游戲經歷，說一下互聯(lián)網經歷。

我先后在TX和某里干過，先說說TX - WX，雖然WX的做法不代表整個TX公司的做法，但我覺得還是能反映一些問題，可供參考。

我在WX做過一段時間搜索的工程，就是WX 搜一搜，WX后臺的服務基本上都是基于svrkit框架開發(fā)的，svrkit是一個RPC框架(開源名phxRPC)，負載均衡、錯誤重試等框架都做了，基于該框架做應用只需要專注于業(yè)務邏輯。

當時WX搜索北京雖然有差不多60人，但絕大多數(shù)人都是做算法的，做工程的只有3個，2個做搜一搜，一個做看一看，我是其中一個。

要說TX怎么也是一個大廠了吧，按理說，研發(fā)流程應該也是很齊整，但坦白說，我們要上線一個應用真的沒有那么麻煩，我們甚至沒有專門的測試，我開發(fā)完一個功能，可能先灰度一臺機器，觀察5分鐘，撈log看看，沒有明顯異常，然后我就灰度1%的機器，再觀察1個小時，如果沒有問題，我就灰度10%，再觀察半個小時，如果還沒有問題，我就梭哈了。

你看，一個更新，整個流程2個小時就可以搞定，是不是很麻溜?

那要是有問題怎么辦呢?有問題，速度回滾，出故障，那就拉出來打板子，但這個板子其實一般不要命，有點自罰三杯的味道。

這個事，其實我一直不敢對外說，因為你這樣說出來，會覺得丟人，會覺得low，一點都不高大上，跟同行見了面都不好意思打招呼。

WX一個技術主管跟我說過，他經常因為線上事故被通報批評，但沒被罰過錢，有一次WX支付的故障，被大領導盤問，但即使這樣，WX也沒有想過通過加重流程去降低故障率。

他說這是WX的一個選擇，WX認為業(yè)務失去快速迭代能力是不能承受之重，雖然線上故障有時候也會造成嚴重的后果，但WX對線上故障的容忍度較高，穩(wěn)定性和敏捷性是矛盾的兩級，很難兼顧，WX傾向了敏捷。

可見，TX，或者說WX并不是不清楚穩(wěn)定生產的重要性，也不是不知道通過加重流程可以減少故障，只是在綜合各方因素后，他們選擇了保業(yè)務快速迭代，敏捷是互聯(lián)網的命根子，不能丟。

有人跟我講了另一個WX的故事，WX基本上在立項后幾個月后推出了，因為很匆忙，其實后臺有很多問題，比如內存泄漏，但他們沒有馬上選擇去解決這個問題(或者說正面剛)，他們選擇了繞過問題，在服務100次后，進程自動重啟，從而完美的解決了這個問題，這段代碼后來被一個實習生review出來，把100改成1000，性能提升了很多倍。

說到這里，很多人一定以為WX的技術很弱，WX工程很渣，這跟事實不符，大家可以去TX開源看看，里面有大量WX開源的項目，我認為那些優(yōu)秀的開源項目，是最好的證明。

再說說某里，某里則是完全另一番景象，某里行癲把穩(wěn)定性比喻成木桶的底板，如果穩(wěn)定性出問題，則滴水不留，所以，要求工程師在設計和開發(fā)軟件的時候，堅持底板思維。

某里的開發(fā)人員每年都要過安全生產的考試，每年618、雙11、雙12、春節(jié)、38節(jié)、甚至兩hui期間，TB都要提前很久封版，特別是雙11，至少1個半月封版，封版期間任何更新都要走特批，所以，留給開發(fā)的時間窗口其實非常非常短。

每年都會集中培訓安全生產常識，每年都會逐級開會強調安全生產重要性，安全生產大于天，這根神經絕不能松，都會提前做各種應急預案，假設XX情況出現(xiàn)要YY辦，制作成手冊，到時候出現(xiàn)異常，遵照執(zhí)行，這些事情耗費了大量的人力財力。

但實際情況就是99.999%沒用，完全是瞎忙活，大促期間都是集體出動，熬夜守班，再一起擺pos熬造型發(fā)朋友圈，你可能會說，這些是完全必要的，為的就是萬一出現(xiàn)萬一，有兜底方案，對，你說的對，這樣的邏輯沒人會不懂，某里人也是這么想的。

但任何事情都有一個度，這個度可視為一個平衡點，過猶不及，這是最樸素的道理。

為什么某里對安全生產這么看重，當然，首先，他們會從他們業(yè)務的特殊性進行一波分析，比如把TB自詡為國家基礎設施，跟水電煤氣一樣，從各個角度闡述極端重要性。

但其實，最根本的原因大家沒說，那就是誰出問題，誰3.25，而且還連坐，一出事基本上在，某里就沒法做下去，處罰很重，而且真的會處罰很高級別的領導。

所以，在安全生產的“大是大非”面前，沒人敢大意，沒人敢做違背流程挑戰(zhàn)zz正確的事情，結果上，某里的服務穩(wěn)定性是否比TX強，我不知道，但迭代效率上，肯定是慢了很多。

最有意思的是，如果你跟某里人(特別是老人)討論安全生產的問題，你會發(fā)現(xiàn)他們觀點出奇的一致，他們堅信安全生產責任大于天，應該堅持零容忍，越嚴越好，但事情是否真的應該這樣辦?我不知道，但至少同為互聯(lián)網的TX不是這樣，而TX的業(yè)務不也發(fā)展的好好的嗎?

我們很容易舉出業(yè)務特殊性，比如電商可以舉例說某個心臟病人因為網購救命藥下不了單導致喪命，如果你制造了這個bug，相當于間接殺人，是不是很嚇人?比如DD，它也可以這樣說，因為APP出問題，導致打車的女孩不能及時呼救，被強奸繼而被害，是不是也很恐怖?

其實這樣的例子，游戲行業(yè)也可以舉出來，比如某個孩子因為游戲卡副本，導致一怒之下，點了房子，導致滅門。

所以，沒必要用這樣的例子來強調業(yè)務的特殊性，因為是軟件還是要尊重軟件常識，回歸本質，但業(yè)務有沒有特殊性?有!而且我們必須正視。

比如電信業(yè)務，我們要把軟件部署到別人的數(shù)據(jù)中心，我們要更新別人機房的程序有很多限制，這個跟互聯(lián)網的軟件確實有很大的不同。

這對我們的軟件提出了更高的穩(wěn)定性要求，這是顯而易見的，但我們容易過于強調安全性，而忽視了對生產效率的影響，而對生產效率的副作用可能遠比我們任何一個人想象的都大。

JD大東子曾總結幾個商業(yè)成功的關鍵因素，其中之一，就是你可以做到更低的成本，或者做到更高的效率，所以，對于商業(yè)公司而言，生產效率，對應到軟件的開發(fā)效率，成本控制，其實遠比我們想象的重要，而我們卻容易掉進顧彼失此的陷阱。

小結

我前面說我會闡述事實，而非陳述觀點，很抱歉騙了你，其實完全沒有觀點的文章不值得寫，史書還有觀點呢，那筆者的觀點到底是什么呢?

在一個個經歷的故事里。