在iaas層資源的自動擴縮可以有效地節省機器資源成本，比如在業務的低谷期可以將機器資源降下來，在業務高峰期可以自動擴容出來新機器。要支撐這樣彈性調配需要有幾個事情先要支援。
1. 基礎運維能力
即乙個應用的上線\下線可以做到全自動。以原子化服務的方式提供出來。比如輸入某個應用名稱+要擴容的機器數就會自動完成擴容操作。這個依賴一整個全自動運維鏈。從dns、vip、中介軟體、容器、軟體發布等等。這塊後續會單獨啟乙個專題來**一下。
2. 決策層能力
決策層更多的是應用資料 + 規則。類似於風控系統，執行一些規則如果滿足了條件就會觸發擴容或縮容操作。但決策層裡面要考慮的東西還是比較多的。比如可以依據定義閥值進行判斷的規則；依據應用流量來**的規則；比如下乙個時段是業務的高峰，可以提前做擴容；比如下乙個時段是業務低谷，可以提前對業務進行縮容。這裡面會有很多的決策規則。還有一些執行策略在裡面，比如前乙個決策是縮容操作，後面再進來乙個擴容操作，那前面這個任務還沒有完成的話要不要提前結束掉？ 或者前面乙個任務是縮容操作，後面再進來乙個擴容操作，那前面這個縮容操作要不要終止掉。這些都是屬於決策層的判斷。
3. 觸發層
觸發層更多的是接入實時監控獲取到準實時的監控資料，用於判斷當前這個應用要不要擴容或縮容操作。對於觸發層來講重要的是：高併發採集器 + 定時排程 + 聚合 + 規則判斷 + 原始資料落盤。觸發層是不需要決策什麼東西，只要規則生效了就會自動呼叫決策層發起擴容或縮容指令操作。
觸發層因為涉及到查詢外部的監控資料進行聚合。這裡面涉及到一些演算法（資料擬合的演算法）。如果是求平均的話那就是總量 / 總記錄數 = 求平均數. 這中間可能會有採集丟失的可能，因為計算求平均了，所以丟了點資料其實也所謂了。這塊不要想太多了。之前我的想法是乙個應用下面有10臺機器，採集的時候每台機器過來的時間點可能不在同乙個點上，相關幾個ms或1-2s。其實在求平均之後這個就不算什麼了。（晚上看下：關於資料擬合演算法的東西做個專題整理一下）
這裡面有些比較細節的問題：
1）決策要不要擴以及要擴多少臺？
有兩種策略：
a) 憑經驗來判斷。比如正常按一次擴10臺進行擴容。
b) 按業務的上坡與下坡或者講是按流量**來判斷。 通過準確的**可以獲得乙個比較精準的擴容數量。
2）縮容是按步進執行，擴容是一次性的
在執行縮容之前務必要先進行應用的靜默期等待。在這個靜默期期間可能會出現新的一次決策插入
3）關於如何定義高峰與上下坡的定義
什麼是流量高峰？什麼是上下坡，這個定義是怎麼樣的？
###拋幾個彈性遇到的問題####
1、如果安全閥值是由前5分鐘計算出來的乙個平均，那如何來解決脈衝的問題？
比如前五分鐘可能rt非常高了，這個時候還不會進行擴容操作，等到5分鐘之後再觸發一次資源擴容。可能這個時候應用都掛了。然後五分鐘之後應用的qps會下降下來，這個時候再擴容已經沒有意義了。而且會導致資源浪費。所以如何在出現這次脈衝波之前就提前把容量準備好。
運維平台系列 關於DevOps平台架構思考
現在很多公司都在推行devops平台。為了能夠提公升研發運維效率。這一章節主要寫點關於偏ops層面的東西，dev層面的東西主要涉及到研發域的內容包括 管理 編譯與發布管理 研發流程專案管理及bug管理等。乙個大的產品與技術架構圖 後續會將各個子產品域的設計大圖整理出來.1.關於決策層的思考 基於運維...
關於運維（2）
運維的職責覆蓋了產品從設計到發布 執行維護 變更公升級及至下線的生命週期，各個階段的職責包括 產品發布 這個階段運維工程師負責發布的具體工作，將具體的軟體和系統 硬體資源整合形成產品並對外提供服務。產品執行維護 這個階段的主要工作包括 產品效能 成本優化 產品對外提供服務最重要的一點是使用者體驗，使...
如何構建智慧型運維平台？
隨著技術的發展，運維支撐必須逐漸擺脫對人力的單純依賴，走向平台化。如何才能構建具有一定智慧型的運維平台？軟體即服務 software as a service 需要以軟體服務為基礎，實現運維的it能力和業務能力的對接。生活中，幾乎我們每一天都在接觸saas雲服務，比如 我們平時使用的蘋果手機雲服務，...