本節書摘來異步社群《大型網站伺服器容量規劃》一書中的第3章，第3.1節，作者： 鄭鋼 責編： 張濤，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
回歸方程是統計學裡面的知識，是一種應用數學，通常屬于數學專業同學研究的方向，運維人員很少用這種方法評估系統容量。下面花點時間引出回歸方程在伺服器容量規劃中的應用，這也是本書介紹的重點。
容量規劃的關鍵就是找出系統可承載的最大壓力，然後根據極限壓力再做部署規劃，話說的容易，其實這往往是最困難的部分，因為它不像杯子那種容器，其容量是很直覺的、可以提前确定。而伺服器的性能是不好估量的，看不到摸不着，其容量隻能通過實際測試才能得到。再說，我們所運維的系統可是由數以千計的機器組成的，這麼多機器對系統的容量都起到決定性的作用，而且大多數情況下各個機器的性能是不一緻的，一台機器的容量資料不能作為其他機器的标準，總之各伺服器都有自己的極限容量。就像電池一樣，有的電池容量較大，2600毫安，有的容量較小，2000毫安，是以，它們各自的續航時間是不同的。
容量評估就是用現在的資料預估未來的變化，用什麼方法來預估呢？在正式回答之前，咱們還是用資料說話，先看幾張監控圖，也許大家就明白是怎麼回事了，如圖3.3所示。
圖3.3中顯示的是流量與整體cpu_idle之間的關系，上面的access_log_pv是每分鐘的通路日志，下面的cpu_idle是每分鐘的cpu_idle，大體趨勢上這兩張圖是對稱的，這兩張圖表明：通路量越大，cpu使用率就越高。其實不說大家也會這麼想，通路量越大，相應的cpu使用率當然就越高了。其實這是在正常時的情況，在某些情況下，通路量越大，cpu使用率越低，您信不？後面我們再講。
下面再看圖3.4，這是流量與流量之間的對比，注意并不是流量與cpu使用率。
一般的網站都會有前端子產品和後端子產品，前端子產品則是實際的流量通路入口，圖3.4中的下圖lighttped_log是入口子產品的通路日志，上面的圖front_ms_log則是後端子產品的通路日志，這兩個日志的時間統計粒度是一樣的，都是每分鐘内的通路量。front_ms_log每分鐘是15個左右，lighttped_log大概是每分鐘1000個，雖然這兩個日志數量級差别很大，但它們在總體上的趨勢是一樣的，front_ms_log随lighttpd_log的變化趨勢而變化，是以，這兩張圖中的曲線依然相似。
以上的兩張大圖雖然一定程度上說明了問題，但似乎還不夠明顯，畢竟它們展現的是入口流量與整體cpu的關系或前後端子產品的流量關系，也就是監控粒度是整體。下面再看圖3.5，這裡的監控粒度是子產品，也就是某個server，如nginx。
圖3.5中，front_ms.log是php-cgi的日志，php-cgi_proc_cpu是php-cgi的使用率，從圖3.5上看這兩者的關系确實明朗了很多，幾乎完全是一樣的趨勢。這是子產品pv與子產品消耗的cpu對比，針對的是子產品。另外說明一下，由于系統中任何一個子產品的cpu使用率、或者整機的cpu利用都是由其流量驅動的，入口流量又以一定的比例分流到後端，是以，幾乎是系統内的任意流量都與系統内的任意子產品cpu使用率之間保持某種關系，簡而言之，未必是子產品自身的流量與子產品自身的cpu使用率之間才呈現關聯關系，也許隻是這種關聯關系比較明顯而已。有關這一點可以通過監控圖來驗證，把所有機器、子產品的流量和cpu監控放到一起對比，會發現趨勢線是類似的。
從上面3個大圖來看，這些流量都是相關的，即保持某種依賴關系，流量越大，cpu消耗、後端流量等都跟着增加，如果把這一關系用函數y=f(x)來表示的話，其中的x表示流量，y便是cpu消耗或者後端流量等相關的因素，找出x與y的關系就是容量規劃設計的思想。以上圖中的監控資訊可以用來生成樣本資料，這種由已知的樣本去預估未來的變化趨勢，是典型的回歸應用，容量規劃的核心思想就是曲線拟合。