《大型網站伺服器容量規劃》一2.4 容量管理的目标與收益

本節書摘來異步社群《大型網站伺服器容量規劃》一書中的第2章，第2.4節，作者： 鄭鋼 責編： 張濤，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

雖然我們在qa那裡能夠擷取到各應用子產品的性能資料，但在新項目上線或原有基礎上擴容時，仍然需要每次重複評估服務穩定性，這說明我們在平時的工作中對服務系統的容量沒有很直覺的認識，對系統資源的可用率，我們需要量化。

為了讓大家更直覺地看到系統的已用率及剩餘可用率，在此展開容量管理相關的工作。容量管理的主要目标用于評估各叢集子產品目前及未來某流量下的容量狀态。

為友善陳述，我們這裡所說的容量管理是指伺服器容量管理。

容量管理的基本目标是以合理的硬體成本滿足業務需求。其實我們平時所做的很多工作都是在完成這一目标，比如開發人員改程序式算法，提升處理能力。運維人員根據業務類型，定制專用的伺服器。而我們的容量管理，從表面上看是在管理伺服器，其實容量管理一方面是節約硬體成本，另一方面節約了人力成本。

每季度在做預算時，這是公司全體技術人員頭痛的時候，雖說伺服器運維和開發人員關系不大，但按照以前的做法，運維人員需要向開發人員索取申請機器的理由，開發人員就要自圓其說地給出一套理由，而運維人員根據申請的機器數又要酌情删減，這樣才好向上面交待，大家都是走個“形式”。有了容量管理系統，我們可以用資料說話，要多少機器不是我們說了算，是業務“說”了算，這樣就可以使技術人員更加專心地投入工作。

容量管理還可以節約人力，這展現在服務擴容方面。擴容就是在叢集中增加結點，就意味着包括以下工作：

（1）服務環境部署；

（2）關聯子產品配置；

（3）同步定時任務；

（4）向資料中心注冊；

（5）向操作中心注冊；

（6）對内部系統的權限申請；

（7）代碼同步；

（8）資料同步；

（9）開啟服務；

（10）qa回歸測試；

（11）應用上線。

以上僅是增加一台結點時所做的基本工作，而且其中每一個環節都不能出錯。另外，向内部系統申請權限是要花時間成本的，通常需要一兩天的時間，這就意味着，為了應急突發事件引起的擴容，需要提前準備一些已申請權限的機器在備機池中，聽上去就感覺好累，這些都是運維人員的工作。

為減少盲目擴容時付出的人力成本，提前知道目前的系統還能支撐多久。比如在節假日時流量會增長，為保證服務穩定，隻好按經驗添加機器。

機房由于實體原因可能導緻不可用時，使用者将無法通路到服務。例如使用者在通路某網站時，突然該網站所在的機房出現了問題，不管是營運商的問題還是機房建設的問題，總之，為保證使用者的業務通路，必須将流量切換到其他機房或營運商上運作，這在之前，為了避免壓垮對方機房的伺服器，都是一點一點嘗試做的，如先切換5%的流量，觀察一會後，沒有問題，再切換10%的流量，之後再膽大點，切換20%的流量，這種循序漸進的切換方式，必然也會造成使用者的請求失敗，如果涉及金錢交易，對公司的損失想必是非常大的。有了容量系統，我們知道對方機房的容量後，這樣便可一次性地把流量切換過去。

另外，當系統服務過于備援時，為了節省資源，我們通常要在叢集中下架一些伺服器，這通常不是下架一兩台，少則十幾台，多則幾十台。下架機器并不是簡單地把伺服器關掉就行了，需要在上下遊通過各種配置，把下架的機器屏蔽掉，保證沒有流量才行。這通常牽扯到上遊服務，也需要申請，是以，下架伺服器既需要人工成本，也需要時間成本。萬一機器被下架的太多，可能随時重新擴容。有了容量管理系統，該下架多少台機器是通過計算得出的，沒有人工幹涉，可以讓運維人員更踏實。

最另人欣喜的是，容量規劃還可以幫我們找出子產品最大可正常處理的請求數。

子產品一般都有配置檔案，就拿php來說，其配置檔案php-fpm.conf中配置了php程序可處理的最大并發數，每個請求的最大執行時間等。之是以可以這樣配置，原因是php内部都有個“仲裁器”，由它來控制管理處理的請求，當請求逾時時，它會将請求“殺掉”。顯然，這部分被“殺掉”的請求已不屬于被正常處理的，容量規劃可以找到正常處理請求數的最大值。

總結，容量管理系統給我們帶來的收益如下。

（1）科學地評估系統所用的資源是否合理。

（2）科學地預測未來資源的增長，并進行合理的預算采購。

（3）運維人員以科學的方法對資源進行有效管理，這包括優化叢集中結點機器數量，預知服務可承載的最大壓力，預知系統何時性能燃盡等。