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

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

業務量的飛速增長，機器數量劇增，導致人工維護成本增大；而交易額的增長，對SLA的要求也不斷提高。與此同時，一些新業務會面臨大流量沖擊，資源調度的挑戰也隨之增大。 業務類型復雜多樣、業務模型千差萬別，對應的技術方案也多種多樣，因此SRE的整體維護成本大大提高。

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

1.穩定，這也是SRE工作的核心。 效率，包括云主機交付效率，也包括我們自己內部的一些系統效率。 成本，用最少的機器提供最優質的服務。

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

3.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左右。

云計算基礎設施架構