曾憲成
順豐科技互聯網團隊負責人
本文將通過上述幾個方面來分享順豐科技這幾年來在運維領域的做法和遇到的問題以及解決方案。
1.從數字化說起
我們先從數字化轉型說起，這幾年整個行業或者整個大的環境上都在談數字化。什么是數字化？在我來看，數字化就是一個企業的轉型，可能會帶來更快的效率，也會帶來用戶更好的體驗。順豐在前幾年就在做數字化的轉型。
順豐收件派件下單，這是大家用得比較多的。這后面有很多的環節，包括分點部、陸運、中轉、航空，這是物理上的路徑。
數據流更加復雜，有任務分發、路由分發和運單生成以及分發等等。我們這幾年在做的事情就是把這些東西全部數字化和線上化，這些做好會對后續的路徑規劃、收派規劃做優化。在人力成本上和運輸成本上會有很大的節省。
大家有沒有留意到，在2017年之前所有用順豐寄快遞時，都會給你一張紙填寄貨單。在2017年以后有變化了，順豐做了一個融合項目，把所有紙質面單全部線上化，這就是現在所有的下單全部是掃二維碼。
這是業務發展趨勢，從3月份到5月份是慢慢推廣試運行的階段，5到9月份的時候我們進行了全網快速的推廣，把紙質面單全部替換掉，經過大半年的時間，現在順豐所有的單量全部是線上化和電子化，到12月份該項目完結。對于整個項目來看是非常成功的，業務量也是一直漲。但是，這背后真的是這樣一帆風順的嗎？3月份到10月份我們遇到很多問題，心里有苦不能說。
2.開端—目標
上面這張圖是拔河，這里面有很多人，類似于我們很多不同的崗位在一個項目當中或者在一個企業當中，運維、開發、產品、業務、推廣，想把一件事情做好，第一件事情要做的就是目標一定要統一。
業務。我們所有的都是都是為業務服務，給公司創造價值。如果一個做技術的人不了解業務，如何談對公司創造價值。第一必須要了解業務，用業務的視角考慮問題，用業務的語言進行溝通。轉變視角，把純技術化的語言從業務視角跟項目團隊溝通，這樣大家能夠站在同一維度上考慮問題。
運維要拋棄執行團隊的概念。運維團隊不是執行團隊，不要把自己定位為一個執行團隊，執行團隊就是do，但它只是do，我們不是do這個動作，我們必須在整個核心價值鏈當中產生最大的價值。比如基礎架構的評估、成本和安全上面花工夫，把這些價值體現出來。
關于成功。從不同的維度上看，成功會有很多個定義，以項目的角度來看，成功就是指這個項目是否成功。當公司相對大一點以后，會分很多個部門，每一個部門都有KPI，都要背一些指標，會導致大家的立場就不同了，出發視角也不同了。
因此以項目的維度來看，項目成功了我們就成功了。很多時候我們要打破一些部門墻，站在不同的視角或者把自己拔高到另外一個視角上去考慮問題。
3.初期—效能
流程。順豐在前幾年是比較重的體系，在流程上面會非常繁鎖。一個審批需要找N個人，打N個電話說很多事情，時效很低下。因此需要在流程上進行一些優化，不然整個項目進度會拖慢。
組織架構。在傳統行業，運維體系很大以后，會分成很多個個部門組織，比如基礎架構會有中間件、有系統、有網絡、有存儲等等組，各個不同的專業組來負責專業領域，這時候就會面臨一個問題，以項目視角看，涉及到各領域在整個溝通上會非常麻煩，排查一個問題一個異常或者一個故障，需要一堆人來搞定，效能上非常糟糕。
思維模式。運維跟開發的關系？是合作還是服務還是大家互相推諉的關系？這個我相信大家都是會碰到的問題。
在項目初期我們就遇到了上述三個問題。這里面涉及到的不僅是純技術上的，還涉及到一些組織架構流程，這會動到很多人長期以來的一些工作方式，是最麻煩的一件事情。這件事情要怎么搞定？其實很簡單，就是你的老板。
很多搞技術方面的不是很擅長利用我們已有的資源，如果碰到上面的問題，能夠搞定的只有你的老板。你把你的老板搞定，老板可以給你很多的資源，才能把這件事情推動下去，不然只會卡殼在那。業務的壓力推著你，把事情升級到老板并且說服他，讓他幫你協調各種資源。
輕流程化。引入輕量級流程，減少很多的審批節點，并與工具相結合，讓整個通道順暢地跑起來。
全棧運維團隊。打破現有的以專業組劃分打造全棧運維團隊，擁有所有的操作權限和操作職能，統一的對整個故障、問題和事件負責。會以整個視角考慮問題，打破部門墻和專業墻，組織扁平化。
思維轉變。就是運維與開發的關系應該是一個合作的關系，而不是一個服務層面的關系，兩者的地位是平等的而且目標是一直的。因此，我們的專業能力必須要得到很大的加強，與開發和產品做無邊界的合作，才能在項目中產生最大的價值。
4.爆發期—穩定
爆發期也就是6月到9月份的時候，業務量從最開始的100萬爆發到800萬甚至1000萬。這過程會出現很多問題，如性能問題，詭異的問題頻現。在項目上前期是快速推廣和試錯，會忽略或者不太考慮一些技術上的風險，會留下有很多的技術債，這在整個業務量增長起來后頻發的暴露出來。
隨著整個業務上的強制往上堆和業務量的持續增長，壓力會傳導到研發和運維，如果經常出現故障，每個層面面對的壓力非常大。
工程師文化就是專業、高效、開放、技術和擔當，而且一定要認為這事我們是可以做到的。
彈性是我們的一個救命稻草，隨著業務量的增長彈性化擴展。彈性會分兩個架構：一個是應用架構，另一個是基礎架構。應用架構偏研發多一點，基礎架構偏運維多一點。
應用架構：
第一個是無狀態，就是集群上所有的東西都不要有任何用戶的信息。
第二個是單點，單點問題就是木桶原理，一個木桶里能裝多少水，不是取決于最長的板，而是取決于最短的板。
第三個是分布式，分布式就是為了方便擴容。
第四個是是橫向擴容，整個系統架構是必須要支持橫向擴容。最麻煩的點在于數據庫，一般的作法就是大表拆小表，大庫拆小庫，小庫之間怎么分沒有標準的做法，要根據本身公司的業務形態，比如根據程式，根據用戶ID等等。數據庫方案最好前期就實現，后期再做對數據的遷移會非常痛苦。
基礎架構：
左邊這個圖是大體一個草圖，用戶端的請求過來會經過多種鏈路，如防火墻、網關負載均衡器、數據庫等等。這一串長的鏈路要支持橫向和快速擴容。橫向涉及到技術標準的選型，快速是考驗技術架構能力，在做推廣的時候，服務器可能從一百臺擴到上千臺，能不能快速地交付還是需要人工去搞定，這就是快速。
這是我們內部做的一個運維平臺叫做維石。這里我們把很多資源分成很多層，最底下一層是硬件的，上一層就是虛擬化層，再到上面一層是一些組件層，專業組會把自己的組件層做成很多服務，再以編排的形式把它們全部串聯起來，對外做交付，使得我們一些技術資源的申請可以很方便地實施。
發布版本就涉及到灰度，很多敏捷迭代，會有一堆試錯的在里面，版本上線非常頻繁，我們的系統必須要支持灰度。
對于業務有一個新的功能，灰度可以先切個10%或者5%的流量過去試用下。對于運維層考慮的東西更直觀，切5%的流量和10%流量的時候，服務器的CPU負載有沒有變化，如果流量切到20%，數據庫的QPS比以前翻了20%到30%，可以立馬發現問題并去解決。灰度的作用是給業務層試錯，也給IT層留下了很大的空間去保證試錯，如果出現問題我們能夠快速地把流量切換回來。
右邊是一些灰度切換的規則，我們需要根據環境來切換、根據某個系統來切換，根據UIL服務串或者版本號來切換，規則做得越細，切換的力度就會越細，比較更加有保障。
服務保護一般有三種模式：限流、熔斷和隔離。
限流的概念就是當流量爆增，導致整體應用響應緩慢的時候需要做控制，把一些多余的請求或者無關緊要的請求過濾掉，雖然對用戶體驗不好，但是至少可以保證整體的系統穩定性。限流負載上面會有這個功能，也可以在自己的網關上實現。
熔斷，現在都在談微服務，各個模塊拆得很細，必然造成很多東西不可控，一旦某個版本有問題就會導致掛掉，通過熔斷服務在掛掉的時候不去請求直接返回，類似于降級。
隔離，在以前的做法會在一個大的線程池當中搞定所有事情，一旦某一類的請求出現問題會把整個線程池打爆。隔離就是把一個大的線程池拆開，不同類型的請求使用不同的線程池，每種類型的請求互不影響。
監控分兩個維度：一個是基礎架構，一個是業務監控。
基礎架構的維度，如服務器的CPU、IO、MEM等，如果涉及到全國性的，還會用到一些波測的軟件，包括APM。要做得更細的話，監控每一個方法服務調用的次數等等。
業務監控，基礎架構的監控指標正常不代表業務上是正常的，業務監控必可可少，每一個關鍵核心鏈路上的服務請求，響應碼，響應時間，都要定一個閾值，超過了觸發報警，依據這些監控數據，通過算法做趨勢或者預測預警，比如容量的預估。還有埋點，對整個鏈路進行完整輸出便于問題定位。最后是業務鏈路，現有的系統都是互相之間調來調去，某一個系統出現問題，可能會影響到周邊的業務，因此我們需要一個完整鏈路全景圖。
左邊是微服務化后的圖，單體應用根據某種業務規則拆分得很細，分布在不同的節點上，一個微服務可能幾百上千個節點，這時定位故障就困難了。我們需要鏈路追蹤和非常完備的日志系統，才能很好地處理問題。
對于微服務，有一些自己的觀點。第一個是拆分的規則，拆分沒做好好就會亂七八糟，最后就沒有規則了。第二個是做微服務化需要組織架構的支撐，否則整個微服務化有點像打著技術的幌子，把簡單的事情做得復雜化。
任何系統是不能保證100%不出任何問題的，因此需要應急預案。在系統上做一些降級或者關閉的開關。在業務上最好也有線下的應急預案。
演練就是針對應急預案是否有效進行驗證。演練有兩種環境：一種是直接在生產環境做，另一種是以模擬環境做。不管何種環境要有真實現場的感覺，要給參加演練的人壓力。在演練的過程中也可以鍛煉人員能力。
業務有推廣的需求，但是，服務器是否能夠支撐的住并無把握，最簡單的辦法就是壓測。壓測分為三種情況：單接口壓測、生產流量回放和模擬流量回放。單接口壓測并不能準確的反應實際情況。
這時需要生產流量的回放，把生產上面的所有操作全部拉下來，通過回放工具，對整個的環境做一些壓測。回放工具必須要支持倍數上的回放，驗證業務預估的量進行檢測。也必須要支持能夠自己造數據，現有的生產上面的流量數據還是跟實際推廣時是有差別的。
最開始做雙活的目的有兩個：第一個是保證系統更加可靠，第二個是容災資源合理的利用起來避免浪費。做雙活最麻煩的一件事情是需要把整個大部分的請求或者某一個單元中的請求盡可能在同一個機房中解決。
跨機房的流量互串會出現問題，當某個機房宕掉了更加麻煩。還有Redis、DB等數據同步保證集群數據一致性的問題。通過kafka模塊，根據分流規則分流到對應的機房里。
以分流來說，我們必須支持用戶請求到前端就能夠做正常的分流操作。分流操作的做法是在APP或瀏覽器中，在http請求中打上城市代碼的標記，根據這個標記規則進行分流將流量轉發到對應的機房中。
這個圖是切換，如果某一個機房出現問題的話，我們在OPS平臺上做配置，將整個流量切換到其它機房。
5.延續—價值
運維的價值在哪里呢？
第一個質量。質量無非是一些可用率、故障數、平均故障時長和用戶滿意率，這是運維必須要達到的。
第二個成本。我們效果是拒絕浪費，有多個維度，資源是否得到充分合理的利用，容量評估是否數字化。流程是否與工具相結合。人力方面是否優化，把重復的勞動想辦法替掉。
第三個效率。傳統型的運維要有所轉型，往IT運營方向轉型解決方案的提供者。另一個方向是往運維開發轉型，從重復勞動中解放出來。
第四個數據運營。運維人員是最了解整個公司的業務流程和數據模式的走勢，要做很多數據方面的分析，包括數據運營能力方面的體現，為公司創造更大的價值。
時刻關注新興技術發展，用于擁抱變化。
