本文來自聽云客戶投稿
之前攜程DOWN機的事件在業(yè)界鬧得沸沸揚揚，很多人都在總結(jié)分析。其實對此我也有一些個人看法：關(guān)于IT系統(tǒng)運維/關(guān)于異地災(zāi)備/關(guān)于私有云。本人正好在三種階段和規(guī)模的互聯(lián)網(wǎng)電商公司都工作過：
在業(yè)界比較知名的互聯(lián)網(wǎng)電商公司從事過一些基礎(chǔ)的工作
參與過比較早期的創(chuàng)業(yè)團隊(其所有的程序甚至都部署依賴在別人的公有云端)
同時也在處于這兩者中間狀態(tài)的電商公司工作過。
這三段經(jīng)歷讓我發(fā)現(xiàn)一些共性的問題，借此機會分享出來。
我發(fā)現(xiàn)，不論那些公司的老板或CTO自己有沒有意識到，目前幾乎所有的互聯(lián)網(wǎng)電商公司的技術(shù)架構(gòu)演化都在走著一條殊途同歸的路：從基礎(chǔ)工具(開發(fā)/測試/部署/監(jiān)控/運維)，到運維自動化/虛擬化，最終到私有云（實現(xiàn)彈性計算等）！ 只是不同的公司處于這條路上的不同階段而已。即便是我前面參與那家創(chuàng)業(yè)公司，也開始走上這條路，只是他們的階段不同。
很多公司的問題并不是沒有找到一個更牛的框架或技術(shù)來“一招制敵”，而是目前業(yè)界解決各個領(lǐng)域問題的框架或技術(shù)工具太多了。所以問題反而變成是采用的語言/技術(shù)和方案太多，整個公司研發(fā)體系都缺乏對這些多樣性語言的優(yōu)缺點的統(tǒng)一的/清晰的認(rèn)識，并制定出解決方案。從而造成很多附加的問題，以及過高的管理及維護成本。
舉個例子：我曾經(jīng)聽一個公司研發(fā)主管向其技術(shù)管理層匯報其私下采用Node.js的原因，就一句話：“Node.js性能高”。而技術(shù)管理層也沒有做任何的深究，相當(dāng)于默認(rèn)了其以后在任何其他場景可以隨意采用的可能性。這里我沒有任何貶低Node.js的意思，只是針對這樣的決策方式?？陀^的說，Node.js具有“適用于高并發(fā)、I/O密集、少量業(yè)務(wù)邏輯的場景”，但其也有一定的缺陷以及不適用的場景。在決定采用該語言前技術(shù)團隊一定要對于其缺點以及不適合應(yīng)用的場景具有充分的認(rèn)識。并基于此要求團隊拿出相應(yīng)的解決方案，進行嚴(yán)格把關(guān)：
異步編程帶來的往往是到處callback（回調(diào)函數(shù)），代碼不夠優(yōu)雅/可閱讀性、可維護性差 ；這個時候技術(shù)管理層需要考慮：如何通過一些第三方的方法來彌補這些缺點；
針對Node.js的DEBUG不方便，錯誤沒有STACKTRACE是否統(tǒng)一采用類似WEBSTORM這樣的JS開發(fā)IDE；
Node.js不適合CPU密集型應(yīng)用(將導(dǎo)致CPU時間片長時間不能釋放)
從技術(shù)管理層面需要考慮： 如何規(guī)范程序員不去用Node.js來寫真正復(fù)雜的業(yè)務(wù)邏輯？或者說寫著寫著就寫出復(fù)雜的業(yè)務(wù)邏輯。是否應(yīng)該統(tǒng)一規(guī)范為：采用Java來實現(xiàn)真正的業(yè)務(wù)邏輯，通過JSON API暴露給Node.js調(diào)用。而Node.js只做請求轉(zhuǎn)發(fā)，將其異步調(diào)用的優(yōu)勢發(fā)揮到最好；
一般來講，技術(shù)人員更關(guān)注于技術(shù)本身、關(guān)注于自己的興趣、關(guān)注于自己使用某個技術(shù)后的個人成長， 這本身無可厚非。但問題在于很多公司的技術(shù)管理層缺乏對采用某種技術(shù)的推廣實施成本，以及實施風(fēng)險的考量！同時還疏于對于技術(shù)帶來的結(jié)果的關(guān)注和追問。再加上很多技術(shù)人員普遍不具備結(jié)果導(dǎo)向的心態(tài)(以'技術(shù)本身牛不牛'為導(dǎo)向的技術(shù)人員倒是大有人在)。這就會帶來很多業(yè)務(wù)以外的額外的‘技術(shù)問題’，系統(tǒng)不穩(wěn)定/采用技術(shù)/框架/依賴性太多，造成問題的排查和定位的困難/修改維護的困難等等。很多時候CEO不理解：“為什么這么一個小修改需要這么多的時間？”答案是：因為你的系統(tǒng)的技術(shù)架構(gòu)已經(jīng)在你'不懂'或不在意的情況下，通過很多技術(shù)人員的‘努力’，'悄悄的'變得遠超出你想象的復(fù)雜。那種‘重量級’、那種‘高技術(shù)含量’已經(jīng)成為你的創(chuàng)業(yè)團隊“無法承受之重”了！好吧，這個時候你也不能發(fā)火，你還必須得忍著。因為技術(shù)人員他們也很努力的在辛苦加班阿。OMG，我可憐的CEO啊。
通常，技術(shù)人員都更傾向于去做那些高精尖，聽起來高大上的東西。從而忽略那些臟活/累活。例如：對于虛擬化（KVM/LXC/Docker等）的全方位使用、自動化彈性擴容/縮容、一鍵災(zāi)備切換，這樣“高端”的東西要想取得成效，必須配合有很多基礎(chǔ)的工作，有很多臟活累活要先干好。 那么，什么算是臟活累活？
改變程序員不恰當(dāng)?shù)木幋a習(xí)慣，比如：喜歡將用戶名和密碼、URL、各種其他配置等硬編碼在程序中。你必須要求他們將配置參數(shù)放在固定的位置，甚至于提供統(tǒng)一的配置管理系統(tǒng)和服務(wù)。才能實現(xiàn)更好的配置管理，實現(xiàn)所謂的‘自動化部署’;
對應(yīng)用系統(tǒng)的改造: 為實現(xiàn)‘跨機房雙活’這樣的目標(biāo)，應(yīng)用本身應(yīng)該是'無狀態(tài)化的'。為實現(xiàn)在異地機房程序的快速'恢復(fù)'，必須降低各種依賴：IP依賴、服務(wù)依賴。為此，有必要提供內(nèi)部統(tǒng)一的DNS系統(tǒng)，將IP依賴改造為域名依賴。提供服務(wù)治理系統(tǒng)，將跨語言、跨協(xié)議的服務(wù)進行統(tǒng)一的管理；
對于研發(fā)/運維人員進行虛擬化基礎(chǔ)技術(shù)培訓(xùn)，包括虛擬化對于資源的處理，對于基礎(chǔ)的安全性/隔離性等方面的培訓(xùn);
對于消息服務(wù)/緩存服務(wù)/數(shù)據(jù)庫服務(wù)這些‘有狀態(tài)’的服務(wù)，采用專有的跨機房雙活的集群方案、同步策略以適應(yīng)異地災(zāi)備機房的一鍵切換，以此來保證該種情況下的數(shù)據(jù)一致性/消息不丟失/緩存的有效性;
對于基礎(chǔ)的統(tǒng)一監(jiān)控的推廣，以及對虛擬機基礎(chǔ)監(jiān)控，虛擬機中的應(yīng)用監(jiān)控/服務(wù)的監(jiān)控等;(必須有一套合理的機制能預(yù)見或者說即時的‘計算’出某服務(wù)的‘負(fù)載’情況，才能實現(xiàn)彈性計算所謂的“自動擴容/自動縮容”)
對于基礎(chǔ)的‘編譯打包’‘自動部署’的推廣使用，對于類似統(tǒng)一日志傳輸這樣的基礎(chǔ)設(shè)施的建設(shè)和推廣;
建立構(gòu)建和測試的標(biāo)準(zhǔn)化流程；
以上這些工作本身的技術(shù)含量有高有低，聽起來也不像什么“高端大氣”的工作。但是很多大型互聯(lián)網(wǎng)公司看似只有一個簡單的網(wǎng)站/一個APP，在后端動輒有數(shù)十上百甚至上千個獨立運行的程序，很多程序又在不同的主機上部署了多個實例，成百上千的服務(wù)器。需要推動相關(guān)的研發(fā)負(fù)責(zé)人在不影響業(yè)務(wù)快速迭代的同時去實施這些優(yōu)化、實施這些基礎(chǔ)工具、實施這些流程/規(guī)范?；诖?，我將以上這些工作稱之為“臟活/累活”。當(dāng)這些“臟活/累活”以及基礎(chǔ)的自動化工具和流程規(guī)范實施到位后。所謂的‘彈性計算/異地災(zāi)備/高可用/私有云’其實是自然而然水到渠成的事情 ;
技術(shù)架構(gòu)的優(yōu)化
確定公司統(tǒng)一的架構(gòu)原則，類似全面服務(wù)化、URL規(guī)范、配置原則等等；
SLA體系的建立
通過實施內(nèi)部專用的'業(yè)務(wù)監(jiān)控'以及配合一些外部專業(yè)的監(jiān)控產(chǎn)品，讓每個系統(tǒng)或每個服務(wù)的整體服務(wù)水平透明化。并且使得各系統(tǒng)之間/各服務(wù)之間可用性的橫向?qū)Ρ茸兊每赡?。透明化將為管理層的監(jiān)管/考核提供更好的手段和依據(jù)。最終有利于全公司所有系統(tǒng)SLA(服務(wù)水平)的提升; 同時，通過更好的實時監(jiān)控推廣監(jiān)控來提升事故出現(xiàn)以前的預(yù)判能力，及事故出現(xiàn)后的更好的曝光和及時的處理；
筆者所在的公司采用聽云的專業(yè)監(jiān)控產(chǎn)品：network、移動監(jiān)控等，通過在監(jiān)控產(chǎn)品后臺配置合理的監(jiān)控報警策略也幫助我們及時的發(fā)現(xiàn)問題。
聽云發(fā)送給運維/研發(fā)的報警郵件
工具系統(tǒng)的建設(shè)/推廣
通過自動部署、統(tǒng)一配置管理等系統(tǒng)的實施：讓運維從繁重的上線工作中解脫出來，有時間從事更多的保障硬件/交換機/災(zāi)備/機房高可用等事項；自動部署系統(tǒng)提升上線效率的同時提升線上操作安全性，進一步降低上線造成的事故幾率。通過內(nèi)部DNS系統(tǒng)以及服務(wù)治理的上線實施以降低運維線上IP依賴、提升服務(wù)的規(guī)范性及可管理性，以及快速“恢復(fù)”的能力；
規(guī)范體系的建設(shè)
流程/規(guī)范的建設(shè)應(yīng)該是伴隨著工具系統(tǒng)的建設(shè)，相輔相成。借助工具系統(tǒng)的推廣來推行流程規(guī)范的落實，通過流程規(guī)范的落實反過來加強和優(yōu)化工具系統(tǒng)的建設(shè);讓工具系統(tǒng)的方便性就像互聯(lián)網(wǎng)產(chǎn)品一樣吸引住研發(fā)。通過這種使用的粘性反過來加強流程規(guī)范的推行！
工具系統(tǒng)和流程規(guī)范之間的關(guān)系，以及最終走向私有云的路線
有人說：針對一家業(yè)務(wù)高速發(fā)展中的互聯(lián)網(wǎng)公司的基礎(chǔ)架構(gòu)的改造無異于是“為一輛高速行駛中的賽車更換輪胎，車輛本身還不能停”。而我個人更欣賞“磨刀不誤砍柴工”，當(dāng)你的業(yè)務(wù)跑了一段時間發(fā)現(xiàn)系統(tǒng)負(fù)載過高，你自然要去改造你的某些基礎(chǔ)架構(gòu)以帶來更好的響應(yīng)能力。自然要去實施一些基礎(chǔ)的自動化工具，以便更好的監(jiān)控和改進系統(tǒng)以及更高效和可靠的部署。并且推出一些跟當(dāng)前團隊技術(shù)能力和‘自動化工具’相匹配的“流程/規(guī)范”。這種做法是一種漸進式的演變和優(yōu)化，不會對業(yè)務(wù)的運行本身帶來太大的風(fēng)險。也不需要暫停業(yè)務(wù)；
相反，我們?nèi)绻驗橛龅侥承┘夹g(shù)問題，下了一個決心采用了一些更“高端”的做法嘗試‘永遠’解決該問題。最后會發(fā)現(xiàn)新采用的技術(shù)引入的新問題，付出的成本比原問題本身更嚴(yán)重。
以上想法，分享給各位老板/技術(shù)總監(jiān)/技術(shù)人員。共勉之！
