曾憲成

 

　　順豐科技互聯(lián)網(wǎng)團隊負責人

 

　　本文將通過上述幾個方面來分享順豐科技這幾年來在運維領域的做法和遇到的問題以及解決方案。

 

 

　　我們先從數(shù)字化轉(zhuǎn)型說起，這幾年整個行業(yè)或者整個大的環(huán)境上都在談數(shù)字化。什么是數(shù)字化？在我來看，數(shù)字化就是一個企業(yè)的轉(zhuǎn)型，可能會帶來更快的效率，也會帶來用戶更好的體驗。順豐在前幾年就在做數(shù)字化的轉(zhuǎn)型。

 

　　順豐收件派件下單，這是大家用得比較多的。這后面有很多的環(huán)節(jié)，包括分點部、陸運、中轉(zhuǎn)、航空，這是物理上的路徑。

 

　　數(shù)據(jù)流更加復雜，有任務分發(fā)、路由分發(fā)和運單生成以及分發(fā)等等。我們這幾年在做的事情就是把這些東西全部數(shù)字化和線上化，這些做好會對后續(xù)的路徑規(guī)劃、收派規(guī)劃做優(yōu)化。在人力成本上和運輸成本上會有很大的節(jié)省。

 

　　大家有沒有留意到，在2017年之前所有用順豐寄快遞時，都會給你一張紙?zhí)罴呢泦?。?017年以后有變化了，順豐做了一個融合項目，把所有紙質(zhì)面單全部線上化，這就是現(xiàn)在所有的下單全部是掃二維碼。

 

　　這是業(yè)務發(fā)展趨勢，從3月份到5月份是慢慢推廣試運行的階段，5到9月份的時候我們進行了全網(wǎng)快速的推廣，把紙質(zhì)面單全部替換掉，經(jīng)過大半年的時間，現(xiàn)在順豐所有的單量全部是線上化和電子化，到12月份該項目完結(jié)。對于整個項目來看是非常成功的，業(yè)務量也是一直漲。但是，這背后真的是這樣一帆風順的嗎？3月份到10月份我們遇到很多問題，心里有苦不能說。

 

 

　　上面這張圖是拔河，這里面有很多人，類似于我們很多不同的崗位在一個項目當中或者在一個企業(yè)當中，運維、開發(fā)、產(chǎn)品、業(yè)務、推廣，想把一件事情做好，第一件事情要做的就是目標一定要統(tǒng)一。

 

　　業(yè)務。我們所有的都是都是為業(yè)務服務，給公司創(chuàng)造價值。如果一個做技術的人不了解業(yè)務，如何談對公司創(chuàng)造價值。第一必須要了解業(yè)務，用業(yè)務的視角考慮問題，用業(yè)務的語言進行溝通。轉(zhuǎn)變視角，把純技術化的語言從業(yè)務視角跟項目團隊溝通，這樣大家能夠站在同一維度上考慮問題。

 

　　運維要拋棄執(zhí)行團隊的概念。運維團隊不是執(zhí)行團隊，不要把自己定位為一個執(zhí)行團隊，執(zhí)行團隊就是do，但它只是do，我們不是do這個動作，我們必須在整個核心價值鏈當中產(chǎn)生最大的價值。比如基礎架構(gòu)的評估、成本和安全上面花工夫，把這些價值體現(xiàn)出來。

 

　　關于成功。從不同的維度上看，成功會有很多個定義，以項目的角度來看，成功就是指這個項目是否成功。當公司相對大一點以后，會分很多個部門，每一個部門都有KPI，都要背一些指標，會導致大家的立場就不同了，出發(fā)視角也不同了。

 

　　因此以項目的維度來看，項目成功了我們就成功了。很多時候我們要打破一些部門墻，站在不同的視角或者把自己拔高到另外一個視角上去考慮問題。

 

 

　　流程。順豐在前幾年是比較重的體系，在流程上面會非常繁鎖。一個審批需要找N個人，打N個電話說很多事情，時效很低下。因此需要在流程上進行一些優(yōu)化，不然整個項目進度會拖慢。

 

　　組織架構(gòu)。在傳統(tǒng)行業(yè)，運維體系很大以后，會分成很多個個部門組織，比如基礎架構(gòu)會有中間件、有系統(tǒng)、有網(wǎng)絡、有存儲等等組，各個不同的專業(yè)組來負責專業(yè)領域，這時候就會面臨一個問題，以項目視角看，涉及到各領域在整個溝通上會非常麻煩，排查一個問題一個異?；蛘咭粋€故障，需要一堆人來搞定，效能上非常糟糕。

 

　　思維模式。運維跟開發(fā)的關系？是合作還是服務還是大家互相推諉的關系？這個我相信大家都是會碰到的問題。

 

　　在項目初期我們就遇到了上述三個問題。這里面涉及到的不僅是純技術上的，還涉及到一些組織架構(gòu)流程，這會動到很多人長期以來的一些工作方式，是最麻煩的一件事情。這件事情要怎么搞定？其實很簡單，就是你的老板。

 

　　很多搞技術方面的不是很擅長利用我們已有的資源，如果碰到上面的問題，能夠搞定的只有你的老板。你把你的老板搞定，老板可以給你很多的資源，才能把這件事情推動下去，不然只會卡殼在那。業(yè)務的壓力推著你，把事情升級到老板并且說服他，讓他幫你協(xié)調(diào)各種資源。

 

　　輕流程化。引入輕量級流程，減少很多的審批節(jié)點，并與工具相結(jié)合，讓整個通道順暢地跑起來。

 

　　全棧運維團隊。打破現(xiàn)有的以專業(yè)組劃分打造全棧運維團隊，擁有所有的操作權(quán)限和操作職能，統(tǒng)一的對整個故障、問題和事件負責。會以整個視角考慮問題，打破部門墻和專業(yè)墻，組織扁平化。

 

　　思維轉(zhuǎn)變。就是運維與開發(fā)的關系應該是一個合作的關系，而不是一個服務層面的關系，兩者的地位是平等的而且目標是一直的。因此，我們的專業(yè)能力必須要得到很大的加強，與開發(fā)和產(chǎn)品做無邊界的合作，才能在項目中產(chǎn)生最大的價值。

 

 

　　爆發(fā)期也就是6月到9月份的時候，業(yè)務量從最開始的100萬爆發(fā)到800萬甚至1000萬。這過程會出現(xiàn)很多問題，如性能問題，詭異的問題頻現(xiàn)。在項目上前期是快速推廣和試錯，會忽略或者不太考慮一些技術上的風險，會留下有很多的技術債，這在整個業(yè)務量增長起來后頻發(fā)的暴露出來。

 

　　隨著整個業(yè)務上的強制往上堆和業(yè)務量的持續(xù)增長，壓力會傳導到研發(fā)和運維，如果經(jīng)常出現(xiàn)故障，每個層面面對的壓力非常大。

 

　　工程師文化就是專業(yè)、高效、開放、技術和擔當，而且一定要認為這事我們是可以做到的。

 

　　彈性是我們的一個救命稻草，隨著業(yè)務量的增長彈性化擴展。彈性會分兩個架構(gòu)：一個是應用架構(gòu)，另一個是基礎架構(gòu)。應用架構(gòu)偏研發(fā)多一點，基礎架構(gòu)偏運維多一點。

 

　　應用架構(gòu)：

 

　　第一個是無狀態(tài)，就是集群上所有的東西都不要有任何用戶的信息。

 

　　第二個是單點，單點問題就是木桶原理，一個木桶里能裝多少水，不是取決于最長的板，而是取決于最短的板。

 

　　第三個是分布式，分布式就是為了方便擴容。

 

　　第四個是是橫向擴容，整個系統(tǒng)架構(gòu)是必須要支持橫向擴容。最麻煩的點在于數(shù)據(jù)庫，一般的作法就是大表拆小表，大庫拆小庫，小庫之間怎么分沒有標準的做法，要根據(jù)本身公司的業(yè)務形態(tài)，比如根據(jù)程式，根據(jù)用戶ID等等。數(shù)據(jù)庫方案最好前期就實現(xiàn)，后期再做對數(shù)據(jù)的遷移會非常痛苦。

 

　　基礎架構(gòu)：

 

　　左邊這個圖是大體一個草圖，用戶端的請求過來會經(jīng)過多種鏈路，如防火墻、網(wǎng)關負載均衡器、數(shù)據(jù)庫等等。這一串長的鏈路要支持橫向和快速擴容。橫向涉及到技術標準的選型，快速是考驗技術架構(gòu)能力，在做推廣的時候，服務器可能從一百臺擴到上千臺，能不能快速地交付還是需要人工去搞定，這就是快速。

 

　　這是我們內(nèi)部做的一個運維平臺叫做維石。這里我們把很多資源分成很多層，最底下一層是硬件的，上一層就是虛擬化層，再到上面一層是一些組件層，專業(yè)組會把自己的組件層做成很多服務，再以編排的形式把它們?nèi)看?lián)起來，對外做交付，使得我們一些技術資源的申請可以很方便地實施。

 

　　發(fā)布版本就涉及到灰度，很多敏捷迭代，會有一堆試錯的在里面，版本上線非常頻繁，我們的系統(tǒng)必須要支持灰度。

 

　　對于業(yè)務有一個新的功能，灰度可以先切個10%或者5%的流量過去試用下。對于運維層考慮的東西更直觀，切5%的流量和10%流量的時候，服務器的CPU負載有沒有變化，如果流量切到20%，數(shù)據(jù)庫的QPS比以前翻了20%到30%，可以立馬發(fā)現(xiàn)問題并去解決。灰度的作用是給業(yè)務層試錯，也給IT層留下了很大的空間去保證試錯，如果出現(xiàn)問題我們能夠快速地把流量切換回來。

 

　　右邊是一些灰度切換的規(guī)則，我們需要根據(jù)環(huán)境來切換、根據(jù)某個系統(tǒng)來切換，根據(jù)UIL服務串或者版本號來切換，規(guī)則做得越細，切換的力度就會越細，比較更加有保障。

 

　　服務保護一般有三種模式：限流、熔斷和隔離。

 

　　限流的概念就是當流量爆增，導致整體應用響應緩慢的時候需要做控制，把一些多余的請求或者無關緊要的請求過濾掉，雖然對用戶體驗不好，但是至少可以保證整體的系統(tǒng)穩(wěn)定性。限流負載上面會有這個功能，也可以在自己的網(wǎng)關上實現(xiàn)。

 

　　熔斷，現(xiàn)在都在談微服務，各個模塊拆得很細，必然造成很多東西不可控，一旦某個版本有問題就會導致掛掉，通過熔斷服務在掛掉的時候不去請求直接返回，類似于降級。

 

　　隔離，在以前的做法會在一個大的線程池當中搞定所有事情，一旦某一類的請求出現(xiàn)問題會把整個線程池打爆。隔離就是把一個大的線程池拆開，不同類型的請求使用不同的線程池，每種類型的請求互不影響。

 

　　監(jiān)控分兩個維度：一個是基礎架構(gòu)，一個是業(yè)務監(jiān)控。

 

　　基礎架構(gòu)的維度，如服務器的CPU、IO、MEM等，如果涉及到全國性的，還會用到一些波測的軟件，包括APM。要做得更細的話，監(jiān)控每一個方法服務調(diào)用的次數(shù)等等。

 

　　業(yè)務監(jiān)控，基礎架構(gòu)的監(jiān)控指標正常不代表業(yè)務上是正常的，業(yè)務監(jiān)控必可可少，每一個關鍵核心鏈路上的服務請求，響應碼，響應時間，都要定一個閾值，超過了觸發(fā)報警，依據(jù)這些監(jiān)控數(shù)據(jù)，通過算法做趨勢或者預測預警，比如容量的預估。還有埋點，對整個鏈路進行完整輸出便于問題定位。最后是業(yè)務鏈路，現(xiàn)有的系統(tǒng)都是互相之間調(diào)來調(diào)去，某一個系統(tǒng)出現(xiàn)問題，可能會影響到周邊的業(yè)務，因此我們需要一個完整鏈路全景圖。

 

　　左邊是微服務化后的圖，單體應用根據(jù)某種業(yè)務規(guī)則拆分得很細，分布在不同的節(jié)點上，一個微服務可能幾百上千個節(jié)點，這時定位故障就困難了。我們需要鏈路追蹤和非常完備的日志系統(tǒng)，才能很好地處理問題。

 

　　對于微服務，有一些自己的觀點。第一個是拆分的規(guī)則，拆分沒做好好就會亂七八糟，最后就沒有規(guī)則了。第二個是做微服務化需要組織架構(gòu)的支撐，否則整個微服務化有點像打著技術的幌子，把簡單的事情做得復雜化。

 

　　任何系統(tǒng)是不能保證100%不出任何問題的，因此需要應急預案。在系統(tǒng)上做一些降級或者關閉的開關。在業(yè)務上最好也有線下的應急預案。

 

　　演練就是針對應急預案是否有效進行驗證。演練有兩種環(huán)境：一種是直接在生產(chǎn)環(huán)境做，另一種是以模擬環(huán)境做。不管何種環(huán)境要有真實現(xiàn)場的感覺，要給參加演練的人壓力。在演練的過程中也可以鍛煉人員能力。

 

　　業(yè)務有推廣的需求，但是，服務器是否能夠支撐的住并無把握，最簡單的辦法就是壓測。壓測分為三種情況：單接口壓測、生產(chǎn)流量回放和模擬流量回放。單接口壓測并不能準確的反應實際情況。

 

　　這時需要生產(chǎn)流量的回放，把生產(chǎn)上面的所有操作全部拉下來，通過回放工具，對整個的環(huán)境做一些壓測。回放工具必須要支持倍數(shù)上的回放，驗證業(yè)務預估的量進行檢測。也必須要支持能夠自己造數(shù)據(jù)，現(xiàn)有的生產(chǎn)上面的流量數(shù)據(jù)還是跟實際推廣時是有差別的。

 

　　最開始做雙活的目的有兩個：第一個是保證系統(tǒng)更加可靠，第二個是容災資源合理的利用起來避免浪費。做雙活最麻煩的一件事情是需要把整個大部分的請求或者某一個單元中的請求盡可能在同一個機房中解決。

 

　　跨機房的流量互串會出現(xiàn)問題，當某個機房宕掉了更加麻煩。還有Redis、DB等數(shù)據(jù)同步保證集群數(shù)據(jù)一致性的問題。通過kafka模塊，根據(jù)分流規(guī)則分流到對應的機房里。

 

　　以分流來說，我們必須支持用戶請求到前端就能夠做正常的分流操作。分流操作的做法是在APP或瀏覽器中，在http請求中打上城市代碼的標記，根據(jù)這個標記規(guī)則進行分流將流量轉(zhuǎn)發(fā)到對應的機房中。

 

　　這個圖是切換，如果某一個機房出現(xiàn)問題的話，我們在OPS平臺上做配置，將整個流量切換到其它機房。

 

 

　　運維的價值在哪里呢？

 

　　第一個質(zhì)量。質(zhì)量無非是一些可用率、故障數(shù)、平均故障時長和用戶滿意率，這是運維必須要達到的。

 

　　第二個成本。我們效果是拒絕浪費，有多個維度，資源是否得到充分合理的利用，容量評估是否數(shù)字化。流程是否與工具相結(jié)合。人力方面是否優(yōu)化，把重復的勞動想辦法替掉。

 

　　第三個效率。傳統(tǒng)型的運維要有所轉(zhuǎn)型，往IT運營方向轉(zhuǎn)型解決方案的提供者。另一個方向是往運維開發(fā)轉(zhuǎn)型，從重復勞動中解放出來。

 

　　第四個數(shù)據(jù)運營。運維人員是最了解整個公司的業(yè)務流程和數(shù)據(jù)模式的走勢，要做很多數(shù)據(jù)方面的分析，包括數(shù)據(jù)運營能力方面的體現(xiàn)，為公司創(chuàng)造更大的價值。

 

　　時刻關注新興技術發(fā)展，用于擁抱變化。