1、【平臺(tái)篇】運(yùn)維平臺(tái)之能力管理系統(tǒng)建設(shè)能力管理的建設(shè)就是數(shù)據(jù)化IT服務(wù)的能力！能力管理(Capacity Management)應(yīng)該是ITIL里面一個(gè)非常重要的概念，有些人叫容量管理，但我還是覺得能力管理更好一些，能力直接的理解就是我們能做什么？還有多少能力冗余？讓我們來看看ITIL的概念解釋，指在成本和業(yè)務(wù)需求的雙重約束下，通過配置合理的服務(wù)能力使組織的IT資源發(fā)揮最大效能的服務(wù)管理流程，ITIL給到的流程圖如下：從上圖的中間部分可以看到三大子流程，業(yè)務(wù)能力管理、服務(wù)能力管理和資源能力管理。對(duì)于以上的圖中從輸入和輸出側(cè)還可以看到很多的概念，如果真的要是對(duì)照到我們的日常的運(yùn)維中，理解這些概念都需

2、要很長時(shí)間。那么在我的討論中，我不會(huì)讓大家去先理解這些概念性的東西，結(jié)合互聯(lián)網(wǎng)運(yùn)維的實(shí)際，構(gòu)建相應(yīng)的能力系統(tǒng)。一、前言在講能力系統(tǒng)之前，有些概念還是要和大家達(dá)成一致，這樣有利于后續(xù)的進(jìn)一步探討。第一、系統(tǒng)的分層化理解在之前的【運(yùn)維的本質(zhì)-可視化】和【運(yùn)維自動(dòng)化平臺(tái)的深度解碼】中都出現(xiàn)過對(duì)數(shù)據(jù)或者平臺(tái)的一種分層化理解。個(gè)人覺得這種分層的理解特別重要，能夠讓你很快的找到你要做什么。那么同樣對(duì)于能力系統(tǒng)建設(shè)來說，可以套用之前的模型，給出一個(gè)分層化的歸類，其中越往上能力的建設(shè)難度越大，在具體的項(xiàng)目過程中，考慮到建設(shè)的成本和帶來的收益，有一些能力建設(shè)可以舍棄。第二、CMDB的核心作用此時(shí)CMDB的核心作

3、用就來了，CMDB系統(tǒng)一定要把資源和IT服務(wù)的關(guān)聯(lián)關(guān)系建設(shè)起來，并且要以一種合理的方式。這個(gè)地方重要的幾個(gè)關(guān)系有：1、服務(wù)器和應(yīng)用的關(guān)系。這個(gè)關(guān)系可以幫忙在后續(xù)做資源服務(wù)能力建設(shè)的時(shí)候，自動(dòng)化的構(gòu)建面向業(yè)務(wù)（應(yīng)用）的服務(wù)能力展現(xiàn)。經(jīng)驗(yàn)告訴我們，此時(shí)要非常注意，對(duì)于一個(gè)大型的互聯(lián)網(wǎng)業(yè)務(wù)來說，應(yīng)用最好以樹的結(jié)構(gòu)存在，否則沒法表達(dá)復(fù)雜的業(yè)務(wù)關(guān)系，其次一個(gè)服務(wù)器可能和多個(gè)應(yīng)用有關(guān)聯(lián)，需要支持一對(duì)多的關(guān)系表達(dá)。之前早期的YY資產(chǎn)系統(tǒng)就用的一級(jí)結(jié)構(gòu)表達(dá)且只能一對(duì)一，最后整個(gè)服務(wù)器和應(yīng)用之間的關(guān)系根本沒法維護(hù)，根本就不可用。服務(wù)器和業(yè)務(wù)的合理結(jié)構(gòu)圖如下：另外CMDB還需要提供一個(gè)基礎(chǔ)的CMDB業(yè)務(wù)分類的管理

4、能力。這個(gè)業(yè)務(wù)分類不能太深，不建議超過四級(jí)；其次業(yè)務(wù)分類樹最好統(tǒng)一級(jí)別，這樣更容易管理規(guī)范化，人太隨意，隨意之后會(huì)影響其他系統(tǒng)數(shù)據(jù)的準(zhǔn)確性。當(dāng)前我們的業(yè)務(wù)分類示例如下：2、服務(wù)器和組件的關(guān)系這份數(shù)據(jù)主要是來源于持續(xù)部署系統(tǒng)的數(shù)據(jù)沉淀，持續(xù)部署系統(tǒng)把某個(gè)包部署到哪些服務(wù)器上，需要通過CMDB接口把關(guān)系沉淀到CMDB中，因?yàn)楹芏嗉夹g(shù)指標(biāo)是包關(guān)聯(lián)的。它對(duì)于后續(xù)自動(dòng)化管理接口服務(wù)能力和應(yīng)用服務(wù)能力起著至關(guān)重要的作用，能夠打通數(shù)據(jù)之間的關(guān)系。第三、能力基準(zhǔn)-高負(fù)載、低負(fù)載對(duì)于不同的業(yè)務(wù)(應(yīng)用)來說，甚至是應(yīng)用內(nèi)不同的功能模塊，能力高低標(biāo)準(zhǔn)是不同的，主要是和業(yè)務(wù)的需要相關(guān)性能大。比如說對(duì)于核心業(yè)務(wù)來說，可

5、能能力標(biāo)準(zhǔn)設(shè)定在一個(gè)很低的水平，考慮突發(fā)業(yè)務(wù)的需要；而對(duì)于一個(gè)平穩(wěn)期的服務(wù)來說，可能能力標(biāo)準(zhǔn)就會(huì)設(shè)置得高一些，比如說80%，因?yàn)闃I(yè)務(wù)本身沒有太大的變化。對(duì)于負(fù)載偏高的資源、接口或者服務(wù)，我們稱之為高負(fù)載或高負(fù)荷；反之稱之為低負(fù)載或低負(fù)荷。此負(fù)載不是系統(tǒng)的Load Average。二、分層的能力系統(tǒng)建設(shè)第一、資源服務(wù)能力網(wǎng)絡(luò)的服務(wù)能力很好計(jì)算，就是考慮上下行的帶寬能力。那么和應(yīng)用關(guān)聯(lián)最大的就是服務(wù)器的資源服務(wù)能力，并且也是變化最頻繁的一塊能力。對(duì)于一個(gè)服務(wù)器來說，它能提供的資源只有四類：CPU計(jì)算資源、內(nèi)存資源、磁盤的IO資源和網(wǎng)絡(luò)IO資源，除了這四類資源，別無其他。所以大家在做能力系統(tǒng)建設(shè)的時(shí)

6、候，有時(shí)候會(huì)把load average考慮進(jìn)來，非常的不合適，有點(diǎn)本末倒置的感覺。1、服務(wù)器的能力計(jì)算方法f(x)=max(cpu能力、內(nèi)存能力、網(wǎng)絡(luò)能力、IO能力）。CPU能力的計(jì)算公式：直接使用cpu的使用率作為能力使用情況，最好把單CPU的使用率也納入基準(zhǔn)，而不僅僅是匯總的CPU，這個(gè)地方可以發(fā)現(xiàn)那些資源使用不均衡的情況，特別是一些單進(jìn)程的daemon程序。內(nèi)存能力的計(jì)算公式：其實(shí)把內(nèi)存納入計(jì)算是不合適的，對(duì)于很多服務(wù)來說，內(nèi)存要么不夠，要么多余。對(duì)于不夠的情況，應(yīng)該納入到監(jiān)控范疇去發(fā)現(xiàn)問題，通過服務(wù)遷移或者優(yōu)化來解決問題。所以這個(gè)地方可以忽略。網(wǎng)絡(luò)能力的計(jì)算公式：對(duì)于大部分應(yīng)用來說網(wǎng)絡(luò)

7、IO都是足夠的，但不排除幾類業(yè)務(wù)場(chǎng)景，是典型的網(wǎng)絡(luò)IO敏感性的。比如說緩存類的、圖片類、存儲(chǔ)類，還有一種小數(shù)據(jù)包類的服務(wù)。對(duì)于以流量為主要考察維度的能力來說，可以直接把網(wǎng)卡的理想能力作為基準(zhǔn)（千兆網(wǎng)卡），用直接的業(yè)務(wù)流量和他作除；把包量作為能力維度來說，可以設(shè)定一個(gè)包量的基準(zhǔn)，比如說負(fù)載均衡轉(zhuǎn)發(fā)類的設(shè)備。最終都獲取到服務(wù)器網(wǎng)絡(luò)的一個(gè)能力使用率。磁盤能力的計(jì)算公式：磁盤能力也直接取磁盤的util的指標(biāo)，不要IO的讀寫次數(shù)那類指標(biāo)，看IO是否繁忙就可以直接用Util或者IOWait這個(gè)指標(biāo)來計(jì)算。有了以上四塊的資源能力（百分比），我們可以直接取以上四類指標(biāo)中的最大值作為這個(gè)服務(wù)器當(dāng)前的能力情況。對(duì)

8、于一個(gè)服務(wù)器來說，能力最終會(huì)轉(zhuǎn)換成一個(gè)百分比指標(biāo)（負(fù)載），然后和我們?cè)O(shè)定的能力基準(zhǔn)（高、低）進(jìn)行對(duì)比。如果低于某個(gè)水平，則認(rèn)為服務(wù)資源使用不充分；如果高于某個(gè)基準(zhǔn)值，此時(shí)則認(rèn)為服務(wù)器資源的能力無法支撐業(yè)務(wù)的進(jìn)一步發(fā)展。舉個(gè)實(shí)際的例子：在具體的容量系統(tǒng)中，可以提供一個(gè)界面來設(shè)置這個(gè)容量計(jì)算策略和基準(zhǔn)。如下：2、面向應(yīng)用的能力計(jì)算（以游戲中心為例）有兩種業(yè)務(wù)分類策略會(huì)對(duì)容量管理有一定的影響。如下：A、一級(jí)業(yè)務(wù)分類策略B、多級(jí)業(yè)務(wù)分類策略第一種策略，缺少一個(gè)層級(jí)關(guān)系，很難對(duì)容量管理進(jìn)行歸類分析；其次更扁平化的統(tǒng)計(jì)，會(huì)導(dǎo)致數(shù)據(jù)更加的被平均化掉，導(dǎo)致數(shù)據(jù)失真。對(duì)于一級(jí)、二級(jí)的業(yè)務(wù)負(fù)載情況，大家也可以結(jié)合

9、自己的項(xiàng)目情況，算法不一定要選擇平均算法。比如說上圖中管理服務(wù)底下有2臺(tái)服務(wù)器，打包服務(wù)底下只有1臺(tái)設(shè)備，此時(shí)如果計(jì)算游戲包的業(yè)務(wù)負(fù)載，我覺得可以用權(quán)重方法。讓管理服務(wù)的權(quán)重為2，打包服務(wù)的權(quán)重是1，乘以各自的業(yè)務(wù)負(fù)載，最終可以得出游戲包的業(yè)務(wù)負(fù)載。同樣，更上一層，也可以采用這個(gè)方法。簡(jiǎn)單的取權(quán)重的方法，就是把其底下的服務(wù)器數(shù)量作為權(quán)重值。最終系統(tǒng)能夠以上的設(shè)置進(jìn)行計(jì)算，也根據(jù)應(yīng)用的層級(jí)關(guān)系，實(shí)現(xiàn)如下的各級(jí)別的數(shù)據(jù)圖表，達(dá)到輔助運(yùn)維的目的。如下：第二、架構(gòu)服務(wù)能力對(duì)于一個(gè)標(biāo)準(zhǔn)化的服務(wù)架構(gòu)來說，里面提供很多種標(biāo)準(zhǔn)化的組件，這些組件肯定有著基準(zhǔn)的能力，比如說前端web組件、分布式存儲(chǔ)mysql、分

10、布式redis cache的能力等等，這部分的能力基準(zhǔn)可以做到和業(yè)務(wù)無關(guān)，來自于組件的性能測(cè)試基準(zhǔn)。這個(gè)性能測(cè)試基準(zhǔn)再結(jié)合業(yè)務(wù)使用模型，大致評(píng)估出架構(gòu)服務(wù)在當(dāng)前業(yè)務(wù)下的處理能力。這個(gè)很有意義，特別是在業(yè)務(wù)上線之前，一定要明確業(yè)務(wù)的需求和業(yè)務(wù)特點(diǎn)，把他們作為組件需求的標(biāo)準(zhǔn)輸入，運(yùn)維就可以準(zhǔn)確的評(píng)估資源需求。通常我們可以見到前端web組件的ab測(cè)試情況，分布式cache在不同數(shù)據(jù)大小下的Get/Set情況，Mysql的OLTP性能測(cè)試TPCC情況等等。示例如下：第三、接口服務(wù)能力接口有點(diǎn)類似于現(xiàn)在的一個(gè)通行概念：微服務(wù)，從架構(gòu)層來說，這塊屬于邏輯層的范疇。它在大部分的場(chǎng)景下，不能構(gòu)成一個(gè)完整的用例

11、，提供的是一種數(shù)據(jù)的讀寫能力、鑒權(quán)能力等等。一個(gè)接口提供的服務(wù)能力，是影響上層應(yīng)用服務(wù)能力的重要因素。在目前大部分的技術(shù)架構(gòu)中，這塊能力的獲取都存在著實(shí)現(xiàn)難點(diǎn)，1、源于各自實(shí)現(xiàn)協(xié)議不一。如果在一個(gè)基于標(biāo)準(zhǔn)化接口協(xié)議的實(shí)現(xiàn)中，接口的能力評(píng)估就非常簡(jiǎn)單，可以依賴統(tǒng)一的壓力測(cè)試框架實(shí)現(xiàn)；2、源于接口太多，實(shí)現(xiàn)起來成本也非常的高。因此在當(dāng)前的情況下，不建議去把這塊的接口服務(wù)能力建設(shè)作為重點(diǎn)。第四、應(yīng)用服務(wù)能力應(yīng)用服務(wù)是用戶側(cè)能直接感受到功能或者服務(wù)，比如說游戲中的支付、登陸、領(lǐng)取禮包等等，對(duì)他們的能力的評(píng)估非常關(guān)鍵，是后續(xù)的系統(tǒng)規(guī)劃、性能優(yōu)化、擴(kuò)容變更的參考數(shù)據(jù)，甚至是自動(dòng)化調(diào)度。幸運(yùn)的是，因?yàn)橐峁?/p>

12、給web端或者app端調(diào)用，目前這塊基本上都是HTTP的實(shí)現(xiàn)，這就給給我們獲取應(yīng)用服務(wù)能力提供了一些標(biāo)準(zhǔn)化的實(shí)現(xiàn)。對(duì)于HTTP類應(yīng)用服務(wù)的能力只用關(guān)注兩個(gè)指標(biāo)即可，千萬不要雜糅太多其他的指標(biāo)：1、吞吐量（throughout）。其實(shí)就是每秒能處理的請(qǐng)求數(shù)TPS，延時(shí)越小，吞吐量可以越高。2、延時(shí)（lantency）。是我們接受的業(yè)務(wù)性能延時(shí)是多少？對(duì)于web網(wǎng)站來說，PC端，一般都是1s，移動(dòng)端2-3s左右。不過在移動(dòng)端下，google的挑戰(zhàn)的目標(biāo)也是1s。有了這個(gè)基準(zhǔn)，這個(gè)時(shí)候就可以把不達(dá)標(biāo)的比率計(jì)算出來。其他的指標(biāo)都是基于兩個(gè)核心指標(biāo)下的系統(tǒng)表現(xiàn)，比如說負(fù)載、jvm GC情況、IOPS等等

13、。而這些指標(biāo)是為了讓我們看到系統(tǒng)性能上不去的問題原因可能在哪兒，比如說讀寫磁盤頻繁、SWAP交換頻繁、內(nèi)存不足等等。傳統(tǒng)的性能測(cè)試方法獲取到的性能基準(zhǔn)是不準(zhǔn)確的，因?yàn)闆]有模擬真正現(xiàn)網(wǎng)的用戶訪問請(qǐng)求分布情況（一個(gè)Webserver提供了十幾個(gè)服務(wù)），單純的壓測(cè)某個(gè)應(yīng)用服務(wù)功能獲取到的結(jié)果，并不能作為未來容量預(yù)估的真實(shí)參照。在這個(gè)地方提供幾種簡(jiǎn)單的方法：1、負(fù)載均衡器權(quán)重調(diào)整法這種方法適用于海量的環(huán)境，比如說之前我們維護(hù)農(nóng)牧場(chǎng)的時(shí)候，前端設(shè)備接近千臺(tái)的時(shí)候，我們就會(huì)用LVS調(diào)整權(quán)重的方式，在一個(gè)LVS RS池中，把某個(gè)RS的權(quán)重不斷調(diào)整增大，最后不斷去觀測(cè)吞吐量和延時(shí)的表現(xiàn)，但達(dá)到設(shè)定的基準(zhǔn)的時(shí)候

14、，此時(shí)把當(dāng)時(shí)的請(qǐng)求情況記錄下來，作為未來容量的基準(zhǔn)。2、Tcpcopy模擬法Tcpcopy 是由網(wǎng)易技術(shù)部于 2011 年 9 月開源的一個(gè)項(xiàng)目。它應(yīng)該是獲取能力數(shù)據(jù)成本最低的一個(gè)方法，因此強(qiáng)烈的推薦。Tcpcopy可以將線上的流量直接導(dǎo)入到測(cè)試環(huán)境，達(dá)到實(shí)時(shí)的模擬線上的目的，還可以放大生產(chǎn)導(dǎo)入過來的流量，具體的資料大家可以網(wǎng)上找找。目前我們這邊的測(cè)試組搭建了核心業(yè)務(wù)的Tcpcopy環(huán)境，這種環(huán)境能帶來很多好處，比如說構(gòu)建自動(dòng)化測(cè)試用例、現(xiàn)網(wǎng)服務(wù)的自動(dòng)化測(cè)試回歸等等。三、能力管理的場(chǎng)景化應(yīng)用第一、成本優(yōu)化這是最核心和最直接的驅(qū)動(dòng)力，特別對(duì)于運(yùn)維的成本控制職能來說。通過能力系統(tǒng)，可以發(fā)現(xiàn)當(dāng)前資源

15、的負(fù)荷情況、接口及應(yīng)用服務(wù)的性能指標(biāo)，如果這些指標(biāo)偏低，都應(yīng)該去驅(qū)動(dòng)運(yùn)維、研發(fā)去進(jìn)行優(yōu)化。在資源的低負(fù)載層面，運(yùn)維承擔(dān)著首要的資源，需要進(jìn)行資源合并或者虛擬化進(jìn)行優(yōu)化；而對(duì)于接口及應(yīng)用服務(wù)的性能偏低，研發(fā)應(yīng)該牽頭去進(jìn)行優(yōu)化，運(yùn)維提供更多的數(shù)據(jù)（比如說APM）進(jìn)行協(xié)助，持續(xù)改進(jìn)。因此我也建議在一個(gè)規(guī)模不大的運(yùn)維IT環(huán)境中，由于成本優(yōu)化動(dòng)力不強(qiáng)，不要去著手能力系統(tǒng)的建設(shè)。第二、能力預(yù)測(cè)運(yùn)維經(jīng)常有月度、季度或者年度的資源采購計(jì)劃，此時(shí)借助能力系統(tǒng)的預(yù)測(cè)能力來做未來的資源評(píng)估，一則基于數(shù)據(jù)預(yù)測(cè)可以更科學(xué)，其次可以大大縮短評(píng)估的時(shí)間和人力成本。這塊的評(píng)估模型也不是太復(fù)雜，根據(jù)過往的歷史數(shù)據(jù)，做線性預(yù)測(cè)或

16、者指數(shù)平滑預(yù)測(cè)都可以。第三、變更優(yōu)化在很多業(yè)務(wù)場(chǎng)景下，高負(fù)荷是會(huì)影響到業(yè)務(wù)的正常使用，因此我們需要對(duì)高負(fù)荷的業(yè)務(wù)做資源的優(yōu)化，哪怕是擴(kuò)容或者服務(wù)調(diào)整等等。第四、自動(dòng)調(diào)度這個(gè)數(shù)據(jù)可以反向作用各類系統(tǒng)，比如說業(yè)務(wù)調(diào)度平臺(tái)，架構(gòu)服務(wù)平臺(tái)等等。當(dāng)發(fā)現(xiàn)資源或者應(yīng)用服務(wù)處于一個(gè)高負(fù)荷的情況，可以定制自動(dòng)化的調(diào)度策略做服務(wù)變更，實(shí)現(xiàn)了數(shù)據(jù)和自動(dòng)化的完美對(duì)接。四、能力系統(tǒng)的建設(shè)關(guān)注點(diǎn)第一、資源服務(wù)能力帶來收益最大，其次是應(yīng)用服務(wù)能力對(duì)于和應(yīng)用關(guān)聯(lián)的服務(wù)器資源高負(fù)荷能力優(yōu)化，能夠避免業(yè)務(wù)的異常；對(duì)于其低負(fù)荷的能力優(yōu)化，能夠帶來成本節(jié)省，都有直接的可見收益，并且是運(yùn)維能夠完全控制。對(duì)于應(yīng)用服務(wù)能力的優(yōu)化，由于需要研發(fā)、測(cè)試的配合，從能力的建設(shè)來說成本偏高了一點(diǎn)，而往往研發(fā)又會(huì)用產(chǎn)品的需求作為擋箭牌，回避這塊的優(yōu)化。因此我建議，這塊的優(yōu)化，如果要做，需要把應(yīng)用性能數(shù)據(jù)拿出來，直接告訴研發(fā)哪兒可以優(yōu)化，那么他們就會(huì)無法回避。第二、成本導(dǎo)向的驅(qū)動(dòng)力最大對(duì)于海量規(guī)模的互聯(lián)網(wǎng)業(yè)務(wù)來說，上萬臺(tái)設(shè)備，只要從能力維度優(yōu)化幾個(gè)點(diǎn)，都能帶來大量的成本節(jié)省。對(duì)于很多團(tuán)隊(duì)來說，成本的收益都是能直接感知到的。第三、跨團(tuán)隊(duì)的合作能力系統(tǒng)的建設(shè)不是運(yùn)維組一個(gè)人能完成，還需要測(cè)試的參與，更需要研發(fā)后續(xù)的優(yōu)化支持，只有團(tuán)隊(duì)之間的合作順暢，才能讓成本優(yōu)化、性能優(yōu)化變成大家日常關(guān)注點(diǎn)。在以上的討論中，我始終沒有把人的能力納入以及