背景

SRE（Site Reliability Engineering）是Google于2003年提出的概念，將軟件研發引入運維工作?，F在漸漸已經成為各大互聯網公司技術團隊的標配。

美團點評作為綜合性多業務的互聯網+生活服務平臺，覆蓋“吃住行游購娛”各個領域，SRE就會面臨一些特殊的挑戰。

業務量的飛速增長，機器數量劇增，導致人工維護成本增大；而交易額的增長，對SLA的要求也不斷提高。與此同時，一些新業務會面臨大流量沖擊，資源調度的挑戰也隨之增大。

業務類型復雜多樣、業務模型千差萬別，對應的技術方案也多種多樣，因此SRE的整體維護成本大大提高。

根據上述挑戰，我們需要制定相應的解決策略，策略原則主要聚焦在以下三點：

穩定，這也是SRE工作的核心。

效率，包括云主機交付效率，也包括我們自己內部的一些系統效率。

成本，用最少的機器提供最優質的服務。

在此原則的基礎上，我們開始了對SRE進行的一系列改進。

SRE演進之路

手工時代

最早期，我們前端是4層負載均衡，靜態資源通過Varnish/Squid緩存，動態請求跑在LAMP架構下。這個時候機器很少，需要的流程很少，也沒有區分應用運維、系統運維之類的。運維人員也很少，網絡、機器和服務都要負責。運維的工作大部分都是靠手工，其實當時還沒有成型的運維系統，現在很多初創公司都是這種架構。

云基礎設施

隨著業務的發展，我們的架構也做出了適當的調整。尤其是在步入移動時代以后，移動的流量比重越來越大。接入層不只是Web資源，還包含了很多API接口的服務。后端的開發語言也不再局限于PHP，根據服務需求引入了Java、Python、C++等，整個業務架構開始向微服務化變遷。伴隨業務架構的變化，底層的基礎架構也隨之改變。最大的變化是，2014年中的時候，所有的業務已經都跑在了云上，如下圖所示。

跑在云上的一個好處是把底層主機和網絡抽象化，相當于云平臺將主機創建、網絡策略修改等封裝到相應的系統內，對用戶提供統一的平臺接口。我們在做維護的時候，就能把之前很復雜的流程串連起來。也是在此時，SRE團隊初步成立，我們對整個運維相關的工作做了拆分。云計算部分（由美團云負責）主要負責主機、網絡，還有系統相關的；SRE對接業務側，負責機器的環境、業務側的架構優化以及業務側相關問題的處理。

問題＆解決方案

接下來介紹一下我們在做云基礎建設的過程中，遇到的問題和一些解決方案。

如上圖所示，首先是資源隔離的問題，因為這個問題，造成過幾次故障。我們線上VM的CPU、網卡都是共享的，有一次，壓測的流量很高，把主機網卡的帶寬基本上都占光了（當時的主機大部分都是千兆的，很容易打滿），同宿主機的資源都被它爭搶了，其它VM上部署的服務的響時間變得很大，導致當時我們買單的一個服務（買單的VM和壓測的VM部署在了同一個宿主上）直接掛掉了。

針對這個問題，我們做了兩點，一個是對所有的網絡資源都做了隔離，針對每個VM作相應的配額，另外一個是針對業務特性將宿主集群做了拆分。離線業務，它不考慮CPU的競爭，各個業務對于所部署服務的具體響應時間不是很關注，只要能在一個允許的時間段內把業務跑完就可以了，我們把這些服務單獨的放在了一個離線集群。在線業務，根據不同業務的重要程度，又劃分成了多個小集群。

第二個問題就是VM打散，這個問題初期的時候暴露得并不是很明顯，當時整個線上的業務還沒有做細致的服務化拆分，服務都部署在一個大集群內，這種情況下即使VM沒有打散（同一個服務的多個VM在同一個宿主），某一個宿主掛掉，影響也不是很大。但是隨著業務的變化發展，再做服務化拆分之后，線上的服務基本上沒有幾百臺做成一個大集群的情況，都是十幾臺，或者幾十臺這種小集群。

如果我們有一個10臺VM的服務，其中5臺在一個宿主上，那么這個宿主一旦掛掉，服務整體的承載能力就砍掉了一半，風險很高，高峰期如果掉一半，這個業務就癱瘓不可用了。針對這個問題，SRE團隊跟云計算的同學做了一個持續了半年多的優化，將VM打散率控制到了90%以上，最終在同一個宿主上，同一個服務，不會多于兩臺VM。

第三個問題，完善調度成功率。經過SRE和云計算同學的合作努力，現在的成功率已經達到了3個9左右。

云計算基礎設施架構

上圖是我們云計算基礎設施網絡相關的架構圖，可以看到上面是公網的入口，流量接入大部分都是走的BGP鏈路。往下是多機房間的高速專線，專線的穩定性經歷了線上大規模業務的校驗，像外賣、團購、酒旅等，都是做多機房部署的。

另外就是高冗余的網絡架構，基本上每個節點都有一個冗余設備，能保證在其中一臺設備出現問題的時候，整個流量不受影響。入口和出口接入了一些自研的組件，像MGW、NAT等，使我們對流量的管控變的更靈活。

美團點評應該是美團云最大的用戶，美團云能給美團點評帶來的收益有完善的API支持、高度定制化資源的隔離、調度機制，還有多機房光纖直連以及較高的資源利用率。

運維自動化

隨著訂單量和機器數的高速增長，為了更高效的運維，我們不得不往自動化的方向發展。

在自動化演進的過程中，我們總結出了自己的一套方法論。

復雜的事情簡單化。比如引入云平臺，基礎設備管理都通過云平臺的系統來做，把底層相關的東西全部封裝，最終暴露給我們的就是接口或Web界面。

簡單的事情標準化。如果你想做流程或者自動化，沒有一個統一標準的話，你要考慮的點就會很多。所以我們在主機、域名等資源的命名、系統基礎環境、上下線操作等方面，出了很多的標準，這些標準經歷線上的實踐打磨最終形成統一的規范。等標準都成型之后，我們再引入流程，比如創建一些機器，我會列出需要的操作，然后根據標準來做SOP，先流程化再自動化。我們通過代碼把手工的工作釋放掉，最終達到了一個自動化的水準。

這是服務樹，它包括線上的云主機、服務及服務負責人的映射關系，根據不同的層級做一個樹形的展示。它將多個周邊系統進行打通，因為上面有標簽，通過這個標簽能識別唯一的服務。目前我們打通的系統有配制管理系統、容量系統、監控平臺等，還包括線上主機的登錄權限。

另外最新的一個成本核算，服務樹也已經打通，通過服務樹的節點，只需要進行簡單的操作，就能看到每個事業群的成本情況。

上圖是我們創建機器的一個簡單流程，首先由技術人員發起流程，然后到流程中心，流程中心從服務樹獲取服務的基礎信息，然后將信息發送到運維平臺，運維平臺根據這些信息去云平臺創建機器。

之后云平臺會返回到運維平臺，運維平臺將創建好的機器加到流程中心提供的服務節點下，同時調用配置管理系統對機器進行環境初始化，初始化完成后會自動添加基礎監控信息。之后調用部署系統，對服務進行部署。部署之后，服務根據它的服務的標簽，最終注冊到服務治理平臺，然后就能提供線上服務了。相當于只要技術人員發起，整個流程都是能自動完成的。

自動化這塊就簡單介紹這些，下面介紹一下目前的現狀。

數據運營

如上圖所示，現如今公司規模變得很大，我們對此做了一些相應的拆分，圖中紅色的部分全部由云平臺來負責，從最初的接入層到底層的一些基礎設施，比如機房、網絡、主機，全部由云平臺來封裝。中間又拆封了一層，這一層是由SRE來負責。

現在流程系統已經做得比較完善了，接下來我們新的探索目標就是數據運營這塊。首先是故障管理，針對線上故障做一個統一管理，包括故障發生的時間、起因、負責人，根據它的嚴重程度，分為不同的故障等級。我們也會針對故障的后續改進持續跟進優化，保證每一個TODO都能落實。

另外一點，通過故障平臺我們對所有的故障進行匯總，系統能根據匯總的信息對不同的故障進行分類，也能總結出我們線上不同故障類型的占比，進而做一些定點的突破。

在故障管理之后，我們又做了一些數據挖掘相關的工作，在初期，我們運維的數據主要來自于監控平臺或者是業務主動上報，而在現在這個階段，我們會主動挖掘一些信息，比如線上服務的請求量、響應時間等來做一些定向的分析。

職責&使命

如上圖所示，我們的使命從最開始的變更與救火，到現在已經逐漸轉變為防火與驅動變革。通過數據運營，我們能反向的驅動業務。工作核心是穩定性，這一點一直沒變。

我們可以把運維理解為運營維護，運營是指通過經驗積累、數據分析，推動整體服務質量的改進；維護是針對線上的服務，還有業務的需求，我們能夠用專業的技術來滿足他們。

下面講一下在穩定性保障方面的實踐。

業務穩定性保障實踐

故障起因&實例

首先，我們來總結下故障的起因，同時舉一些例子來說明具體的情況。

①?變更。美團點評線上服務的日常發版超過300次，另外還有一些運維的基礎變更，包括網絡、服務組件等。舉個例子，線下做變更的時候，我們寫一個簡單的Nginx配置，如下圖所示。

它和線上寫的配置，在紅色部分的順序發生了變化，如果rewrite的指令在set指令之后，可以生效，結果符合預期。當我們把rewrite指令前置后，break指令會被先執行，會結束整個重寫過程，rewrite之后的set就不執行了，導致配置上線之后，Nginx找不到后端的服務，整個線上的服務就崩潰了。如果做好充分的灰度，我們就能及時發現問題并解決，但是我們在上線的過程中缺少了灰度過程。事實上，標準的SOP（標準操作程序）應該是上圖中的五步，但是負責變更的同學想當然也好，或者是粗心大意也好，在線下測試以后沒有發現異常，就直接全量上線了，最終釀成大禍。

②?容量。一些大的節假日或者秒殺搶購都會帶來大流量，異常流量攻擊或者爬蟲抓取也會帶來流量突增。如下圖所示，這是貓眼發生的一次較大的事故，這個故障主要的原因是最底層的、最后端的服務容量不到位，在流量發生大的變化的時候它沒撐住，關鍵的服務峰值上漲5倍，DAU相交元旦（前一個歷史峰值）漲了一倍。

主要是兩個問題導致的，一個是我們對于大的活動評估不準確，還有一個是它的容量不對等。相當于前端的應用評估是可以撐住的，但是后面的底層沒有撐住，前端的流量都打到后端，后端撐不住，整個服務就掛了。由此，我們至少要做到兩點，第一要知己，了解自身能承載的容量情況，這點我們可以通過壓測或者一些歷史數據的參考獲取到這個容量。第二要知彼，準確知道前端過來的流量究竟有多大，可以通過運營和技術的聯動，在出現一些大的活動或者大的節假日的時候，通過他們的容量評估和歷史數據做出相應的判斷，進而做一些容量的準備；另外，要了解下游系統的容量水位，一旦低于本服務的容量，我們就要做好限流，并且提醒下游服務做相應的容量匹配。

③?隱患。隱患主要針對系統設計存在的一些缺陷，還有一些組件的交叉調用、關鍵報警的缺失、鏈路容量不對稱等。這類問題是比較難發現的，需要我們深入進行研究。這方面的實例我們可以看下下面這個圖，沒有操作之前，它的數據包是沿著綠色的線走的，做了操作之后，部分數據包就沿著紅色走了。變更前后的主要影響是，紅色鏈路的數據包session發生了變化，因為最初的時候session在IMGW1上，在鏈路發生變化后，對于TCP有狀態的連接，再往后就找不到它后端了，數據包沒辦法發送過去，這時候數據就丟失掉了，無法連接數據庫，這個業務就掛掉了。

不過業務層在設計架構之初，應該考慮到網絡不穩定的情況。針對上面的隱患，大概有三個方法。

第一個就是做全鏈路的演習，模擬一個真實的場景，經過模擬演習，還是多多少少能暴露出來一些問題。我們可以針對這些問題，去完善我們的故障預案、修復線上漏洞，做演習的時候也能驗證我們的報警系統是否正常運轉。

第二個是SLA，對于服務定一個比較嚴格的穩定性指標，并針對這個指標持續不斷的優化。比如我們線上HTTP接入的服務，針對accesslog中的狀態碼和響應時間提煉出一個穩定性指標，這對于服務本身的穩定性情況，就多了一個可參考數值了。穩定性指標波動服務必然有問題，這時候我們就要針對它波動的點進行相應的分析，根據分析，最終能找到一些隱患。指標這塊，要做到用真正的數據來反饋出線上的穩定性。

第三個就是做故障的管理，每個故障都能找到問題，TODO能落實，各個故障的經驗總結，也能共享到多個業務線。

經驗總結

事故之前（比如標準SOP、容量評估、流量壓測）的核心就是要防范于未然。

事故之中的核心是快速止損，查找問題是一個相對來說難度比較大，也比較漫長的過程，因為這個時間是不可控的。但是如果我們提前有好的應急預案，就能達到快速的止損。此外，還要有服務的自我保護，還有一點，溝通也是很重要的。最開始出現問題的時候，其實是比較亂的，因為大家發現問題都很急，很多人都在問原因，這時候你問原因是沒有用的，因為大家大部分是不知道，知道的話就能給出解決方案了。所以這時候需要一個完善的溝通機制，正確的時間反饋正確的消息，反饋的原則是少說表面現象，盡量說一些對于問題定位或者是對于止損方面能夠有幫助的信息。

事故之后，像TODO落實、完善預案之類的，核心點就是吃一塹長一智，相同的問題不能發生第二次。

用戶體驗優化

首先從用戶端開始，用戶在訪問我們線上業務的時候，流量是從公網到私有云，再到Server。公網問題主要有網絡劫持、多運營商環境、不可控的公網鏈路等。對于Server的話，主要就是一些傳輸層的協議，或者應用層的協議的問題，目前大部分業務交互還是用的HTTP 1.0/1.1，其實HTTP這個協議也是需要改進的，它不太適合做頻繁的業務交互。

針對這些問題，我們都做了一些嘗試：

首先在公網接入這塊啟用BGP，我們現在已經做了自建的BGP網絡，不用再關心多運營商接入的問題。只需要采用BGP網絡，數據包在公網傳輸尋址的時候，就可以進行最優的選路了。

面對劫持問題，我們嘗試了HTTP DNS的方案，同時也在嘗試Shark，就是類似于公網鏈路加速，相當于我在用戶的近端部署一個Server，在App上嵌入SDK，用戶通過App發起的請求不用做DNS解析，而是先發到Shark（參考之前的博客“美團點評移動網絡優化實踐”）上，再由Shark與后端服務交互。目前通過多種手段的持續優化，劫持問題已經少了很多。

針對業務交互的協議，上線了SPDY協議，對于頻繁交互的業務提升還是很明顯的。目前正在測試HTTP 2.0，Server端對于HTTP 2.0的支持還存在少量bug，努力修復中，希望能早日用上

未來展望

首先技術上，目前我們自動化這塊做得比較好，還會持續做，下一步就是智能化。為什么要智能化呢？其實主要面臨到一個瓶頸點，有些問題是不能通過自動化解決的，比如說前面提到自動故障定位，它的決策性很強，需要很多步的決策，并不是通過程序就能直接搞定的。我們現在正在嘗試一些AI的算法，引入人工智能來做突破。

產品方面，我們現在做的所有工具，經過線上業務大規模的校驗，正在往產品化的方向發展，希望能把它做成成型的產品，放在美團云上，能給美團云的用戶提供服務。不只服務于我們自己，也服務于他人。

最后是技術架構，美團點評發展過程中一些疑難問題的解決方案，或者針對挑戰的經驗積累，經過線上大規模業務的校驗，最終能形成一些成熟的方案，它能為美團云上的用戶提供最前沿的技術參考。

云是大勢所趨，它能把很多底層的問題封裝起來，讓我們有更多精力去做更重要的事情。

原文發布時間為：2017-12-12

本文作者：普存

本文來自云棲社區合作伙伴“數據和云”，了解相關信息可以關注“數據和云”微信公眾號

總結

以上是生活随笔為你收集整理的云端的SRE发展与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。