背景
SRE（Site Reliability Engineering）是Google于2003年提出的概念，將軟件研發(fā)引入運(yùn)維工作?，F(xiàn)在漸漸已經(jīng)成為各大互聯(lián)網(wǎng)公司技術(shù)團(tuán)隊(duì)的標(biāo)配。
美團(tuán)點(diǎn)評(píng)作為綜合性多業(yè)務(wù)的互聯(lián)網(wǎng)+生活服務(wù)平臺(tái)，覆蓋“吃住行游購?qiáng)?rdquo;各個(gè)領(lǐng)域，SRE就會(huì)面臨一些特殊的挑戰(zhàn)。
業(yè)務(wù)量的飛速增長，機(jī)器數(shù)量劇增，導(dǎo)致人工維護(hù)成本增大；而交易額的增長，對(duì)SLA的要求也不斷提高。與此同時(shí)，一些新業(yè)務(wù)會(huì)面臨大流量沖擊，資源調(diào)度的挑戰(zhàn)也隨之增大。 業(yè)務(wù)類型復(fù)雜多樣、業(yè)務(wù)模型千差萬別，對(duì)應(yīng)的技術(shù)方案也多種多樣，因此SRE的整體維護(hù)成本大大提高。
根據(jù)上述挑戰(zhàn)，我們需要制定相應(yīng)的解決策略，策略原則主要聚焦在以下三點(diǎn)：
1.穩(wěn)定，這也是SRE工作的核心。 效率，包括云主機(jī)交付效率，也包括我們自己內(nèi)部的一些系統(tǒng)效率。 成本，用最少的機(jī)器提供最優(yōu)質(zhì)的服務(wù)。
2.在此原則的基礎(chǔ)上，我們開始了對(duì)SRE進(jìn)行的一系列改進(jìn)。
3.SRE演進(jìn)之路 手工時(shí)代
最早期，我們前端是4層負(fù)載均衡，靜態(tài)資源通過Varnish/Squid緩存，動(dòng)態(tài)請(qǐng)求跑在LAMP架構(gòu)下。這個(gè)時(shí)候機(jī)器很少，需要的流程很少，也沒有區(qū)分應(yīng)用運(yùn)維、系統(tǒng)運(yùn)維之類的。運(yùn)維人員也很少，網(wǎng)絡(luò)、機(jī)器和服務(wù)都要負(fù)責(zé)。運(yùn)維的工作大部分都是靠手工，其實(shí)當(dāng)時(shí)還沒有成型的運(yùn)維系統(tǒng)，現(xiàn)在很多初創(chuàng)公司都是這種架構(gòu)。
云基礎(chǔ)設(shè)施
隨著業(yè)務(wù)的發(fā)展，我們的架構(gòu)也做出了適當(dāng)?shù)恼{(diào)整。尤其是在步入移動(dòng)時(shí)代以后，移動(dòng)的流量比重越來越大。接入層不只是Web資源，還包含了很多API接口的服務(wù)。后端的開發(fā)語言也不再局限于PHP，根據(jù)服務(wù)需求引入了Java、Python、C++等，整個(gè)業(yè)務(wù)架構(gòu)開始向微服務(wù)化變遷。伴隨業(yè)務(wù)架構(gòu)的變化，底層的基礎(chǔ)架構(gòu)也隨之改變。最大的變化是，2014年中的時(shí)候，所有的業(yè)務(wù)已經(jīng)都跑在了云上，如下圖所示。
跑在云上的一個(gè)好處是把底層主機(jī)和網(wǎng)絡(luò)抽象化，相當(dāng)于云平臺(tái)將主機(jī)創(chuàng)建、網(wǎng)絡(luò)策略修改等封裝到相應(yīng)的系統(tǒng)內(nèi)，對(duì)用戶提供統(tǒng)一的平臺(tái)接口。我們?cè)谧鼍S護(hù)的時(shí)候，就能把之前很復(fù)雜的流程串連起來。也是在此時(shí)，SRE團(tuán)隊(duì)初步成立，我們對(duì)整個(gè)運(yùn)維相關(guān)的工作做了拆分。云計(jì)算部分（由美團(tuán)云負(fù)責(zé)）主要負(fù)責(zé)主機(jī)、網(wǎng)絡(luò)，還有系統(tǒng)相關(guān)的；SRE對(duì)接業(yè)務(wù)側(cè)，負(fù)責(zé)機(jī)器的環(huán)境、業(yè)務(wù)側(cè)的架構(gòu)優(yōu)化以及業(yè)務(wù)側(cè)相關(guān)問題的處理。
問題＆解決方案
接下來介紹一下我們?cè)谧鲈苹A(chǔ)建設(shè)的過程中，遇到的問題和一些解決方案。
如上圖所示，首先是資源隔離的問題，因?yàn)檫@個(gè)問題，造成過幾次故障。我們線上VM的CPU、網(wǎng)卡都是共享的，有一次，壓測的流量很高，把主機(jī)網(wǎng)卡的帶寬基本上都占光了（當(dāng)時(shí)的主機(jī)大部分都是千兆的，很容易打滿），同宿主機(jī)的資源都被它爭搶了，其它VM上部署的服務(wù)的響時(shí)間變得很大，導(dǎo)致當(dāng)時(shí)我們買單的一個(gè)服務(wù)（買單的VM和壓測的VM部署在了同一個(gè)宿主上）直接掛掉了。
針對(duì)這個(gè)問題，我們做了兩點(diǎn)，一個(gè)是對(duì)所有的網(wǎng)絡(luò)資源都做了隔離，針對(duì)每個(gè)VM作相應(yīng)的配額，另外一個(gè)是針對(duì)業(yè)務(wù)特性將宿主集群做了拆分。離線業(yè)務(wù)，它不考慮CPU的競爭，各個(gè)業(yè)務(wù)對(duì)于所部署服務(wù)的具體響應(yīng)時(shí)間不是很關(guān)注，只要能在一個(gè)允許的時(shí)間段內(nèi)把業(yè)務(wù)跑完就可以了，我們把這些服務(wù)單獨(dú)的放在了一個(gè)離線集群。在線業(yè)務(wù)，根據(jù)不同業(yè)務(wù)的重要程度，又劃分成了多個(gè)小集群。
第二個(gè)問題就是VM打散，這個(gè)問題初期的時(shí)候暴露得并不是很明顯，當(dāng)時(shí)整個(gè)線上的業(yè)務(wù)還沒有做細(xì)致的服務(wù)化拆分，服務(wù)都部署在一個(gè)大集群內(nèi)，這種情況下即使VM沒有打散（同一個(gè)服務(wù)的多個(gè)VM在同一個(gè)宿主），某一個(gè)宿主掛掉，影響也不是很大。但是隨著業(yè)務(wù)的變化發(fā)展，再做服務(wù)化拆分之后，線上的服務(wù)基本上沒有幾百臺(tái)做成一個(gè)大集群的情況，都是十幾臺(tái)，或者幾十臺(tái)這種小集群。如果我們有一個(gè)10臺(tái)VM的服務(wù)，其中5臺(tái)在一個(gè)宿主上，那么這個(gè)宿主一旦掛掉，服務(wù)整體的承載能力就砍掉了一半，風(fēng)險(xiǎn)很高，高峰期如果掉一半，這個(gè)業(yè)務(wù)就癱瘓不可用了。針對(duì)這個(gè)問題，SRE團(tuán)隊(duì)跟云計(jì)算的同學(xué)做了一個(gè)持續(xù)了半年多的優(yōu)化，將VM打散率控制到了90%以上，最終在同一個(gè)宿主上，同一個(gè)服務(wù)，不會(huì)多于兩臺(tái)VM。