一分鐘精華速覽
當成千上萬的服務器都處于低利用率時，就意味著巨額的浪費，良好的容量管理可以幫助消除某些“最后時刻”的臨時應急式的盲目或者超量采購，除了成本合理控制方面，容量管理還要預估對客戶可能產生影響的業務發展和風險變化，
B站在降本增效大背景下，從業務視角對整體容量做了可視化管理，本文詳細描述了其容量管理的背景、思路及成效，
作者介紹
嗶哩嗶哩資深SRE專家 張鶴
TakinTalks社區專家團成員，2020年加入B站，先后負責主站/直播/OGV/推廣搜相關的SRE作業，深度參與多活、活動保障、混沌工程、容量治理相關的建設，并主導容量管理平臺、混沌平臺的架構設計和落地，曾負責B站S賽、跨年晚會、拜年祭等相關活動的基礎架構保障作業，目前主要負責推廣搜業務的穩定性建設、PaaS治理，
溫馨提醒：本文約4500字，預計花費9分鐘閱讀，
后臺回復 “交流” 進入讀者交流群；回復“2252”獲取課件資料；
背景
對于B站來講，我們最大的三個活動是S賽、拜年紀、B站跨年晚會，在用戶增長的背后，SRE團隊做了非常多的事情來保障業務連續性，比如多活、混沌工程等等，
今天換個角度聊聊——“容量管理”，B站為什么要做容量管理的平臺？我們的容量管理體系是怎么設計的？平臺側和業務側我們是如何去運營、讓作業變得“可視化”的？我也將結合容量管理平臺在S12賽事中的實際應用，來分享“賦能業務”的一些經驗，
一、為什么B站要做容量管理？
在做容量管理之前，B站面臨了幾個很明顯的痛點，如下圖所示，
除了需要解決未知的容量風險，在提倡“降本增效”的大背景下，提高資源利用率，制定合理的、有資料支撐的預算決策也非常重要，
而此前，B站在大型活動中的容量決策，比如S9、S10等，并沒有沉淀下來可供S12參考的相關資料，系統本身容量是否足夠、是否需要擴容、應該擴容多少等等，少有容量資料支撐，另外，全年的預算制定也迫切需要參考容量資料，
二、B站容量體系是如何設計的？
2.1 不同角色的訴求
基于上述的痛點，我們計劃做整個容量體系的設計，其中不同的角色關注的流量指標其實不太一樣，比如：
研發部門：關注是否有足夠資源，能擴容、能發布即可，級別比較高的研發Leader可能更關注整個部門的資源使用率、部門的成本是否合理等；
平臺：更關注平臺的售賣率、資源Buffer、資源使用率，以及其他降本增效的作業；
SRE：核心關注穩定性，還需要提升總體資源的使用率，實作降本增效的大目標；
成本部門：更關注賬單、成本、預算、資源使用量等，即節省整體費用，
2.2 容量體系整體設計
從下往上看，最下層主要是基礎資料（基礎容量），比如機器、資源池等偏向云底層的層面，SRE和平臺更多要感知到集群的容量、資源池的容量等到底怎么樣，無論資源池如何超賣或者調控，前提是整體底層的資源使用一定要在安全水位，
在基礎容量之上，我們構建了一套基VPA的伸縮策略，以及基于HPA 的彈性擴縮實體的策略，還和業務的資源池做了合池，合池后可能就會面臨一個問題，即都在一個大池子里，如何控制每個業務方使用的資源？此時，就需要基于業務做配額管理，即管控每個業務能使用多少資源，
在更上層，我們還提供了一套容量可視化以及可運營的資料，提供給業務做支撐，提高業務團隊的效率，包括基于業務部門的組織容量、容量事件等，比如容量運營周報，將不同的部門的使用率公開排名，根據資料提供優化建議等，這部分我將在后面詳細地介紹，
三、容量運營與可視化如何幫助業務解決問題？
3.1 基礎容量
基礎容量是整個容量體系的基礎，上文提到基礎容量我們更關注集群、資源池、 node 以及一些應用維度的容量報表，如下圖所示，
集群：關注集群容量水位和超賣率；
資源池：關注資源池容量水位、超賣率、資源冗余度，資源使用率決定了我們是否需要及時采買機器、判斷是否能承載更多業務；
Node：關注Node資源水位、Node超賣率，因為超賣會有熱點帶來的壓力，所以對Node做了使用率相關的報表；
應用：關注使用量、使用率、實體數、單實體容器數等，業務比較關注應用層面的資料的，比如，服務是否是單點的，因為單點代表如果一臺物理機掛了，恰巧服務在這臺物理機上，此時服務會短暫不可用，對于核心業務來說是不能被接受的，
基于這些指標，我們做了一些可視化的界面，與對外監控系統 Grafana 資料默認存盤 2 周不同的是，我們整個容量平臺的資料是持久存盤的，目前已存盤接近兩年的資料，
3.2 業務組織容量
在降本增效的背景下，如何幫助業務去解決問題？業務側一般更關注如何找出哪些服務占用了較多容量、哪塊業務的資源使用率比較低可以縮容、成本突增或者使用突然增多到底是哪個業務導致的、業務治理或者架構整合后到底治理效果如何等等，需要比較直觀的界面，能幫他們了解全域，
所以基于以上幾點，我們做了基于業務組織的容量報表，如下圖所示，
以B站直播業務為例，直播作為一個大部門，假設整體容量使用率是 40%，想要提高使用率，通過直觀的可視化報表可以看到直播大部門下，分支業務例如營收，會有送禮、抽獎之類的服務，發現其資源較多且使用率低時，業務團隊就能依據可視化報表的資訊，提前做治理從而獲得更多的收益，
同時，能夠基于趨勢圖，看到直播業務下哪些業務突然占用了較大容量，比如新業務場景、研發或者業務突然擴容等，并且支持資料下鉆，可以下鉆到營收業務下，了解到底是抽獎還是送禮業務引起的變化，
3.3 容量事件
從事件源上看，能引起容量變化的事件有很多，其中包括發布平臺/HPA變更平臺/Node管理，在發布平臺里，研發可以擴容或新增服務，以及修改容量配置等，所以發布平臺會導致容量的變化，另外，HPA擴縮容、Node物理機新增或洗掉等，也會導致容量的變化，
所以我們內部對接了各種容量變更的平臺，做了容量事件相關的能力，當一個業務發現整體資源使用變化很多，此時能通過容量事件快速定位事件源，及時感知容量風險，并追溯容量變化的根因，
3.4 容量周報
容量每周都在發生變化，所以我們平臺做了周報的分析，從成本、效率、風險這三個核心出發，業務部門和平臺方的周報關注點差異較大，
3.4.1 部門容量周報(業務側)
業務側周報核心關注以下4點——
整體資源容量，資源使用率，環比上周變化，即和上周比較，資源使用率增加或減少了多少，
應用容量Top，即哪些應用占用了較多資源，方便業務快速感知大頭資源，提高降本優化效率，
風險應用Top(優先展示L0/L1應用)，本部門是否有風險較大的應用，如有使用率較高的核心服務，可以提前擴容，
一周容量變化應用Top，即新增了哪些服務、哪些服務做了擴縮容、下線了哪些服務等，做到一目了然，
（外部周報展示--部門main整體資源利用率）
3.4.2 內部周報（平臺側）
平臺側周報核心關注以下2點——
部門資源使用率及排名，部門容量Top；
部門資源空閑率Top(大于5000核部門)，
通過公開排名，了解哪些業務的容量治理較弱，并優先治理，同時，由于其資源使用量較大，優先對其做治理，平臺也將得到更大的治理收益，
（內部周報展示--整體資源利用率）
3.5 容量巡檢
不管是在活動大促，還是在日常業務穩定性保障中，我們都需要密切關注整體容量是否存在風險，所以有了容量巡檢體系，
3.5.1 業務類巡檢
根據業務側關注的2個方面——應用容量巡檢、配額巡檢，我們做了可視化展示，
應用峰值使用率較高的，會有穩定性風險，需要考慮緊急擴容；而應用使用率較低的，則要考慮是否可以縮容以節省資源，
前面講到我們做了合池，那么需要關注合池后配額使用率過高的情況，避免導致后續擴容或新增業務無法滿足，提前發現風險并做治理，
3.5.2 平臺類巡檢
平臺更關注底層的使用率情況，可調度實體數是否滿足后續的業務需求，以及資源池是否是單節點等等，同時，因為平臺覆寫了 VPA，那么VPA 調整完后的失敗率也是平臺比較關注的，
基于此，我們做了平臺巡檢大盤、資源池巡檢管理、VPA巡檢管理等等，在巡檢大盤中，對風險資源池/空閑資源池Top、風險應用Top、風險配額Top等做了相應展示，
3.6 容量管理的業務價值
容量管理落地后，我們可以直觀看到整體作業對業務帶來的幫助，比如容量資源導致的發布問題減少80%、容量問題導致的線上故障降低90%等等，從這個角度來看，業務部門并非是在配合平臺做容量管理，而是大家共同在為最終的業務目標努力，能確保容量管理落實好后，業務的訴求得到更快回應，穩定性也能得到較大提升，
四、容量管理是如何支撐S12賽事的？
前面我們講的是平臺側的能力、業務側的需求，接下來，我將以剛過去的B站大型賽事S12為例，具體闡述容量管理平臺在具體業務場景中的應用，
4.1 S12活動節奏
4.2 S12賽前容量預估
S12賽前的容量預估主要分為三大步，
第一步，參考歷史基礎容量資料，計算容量delta
無論S賽事還是跨年晚會，B站多年來的大型活動，沉淀了一些歷史資料可作參考，基于歷史資料可以計算出增量，
舉個例子，S11 在11月舉行總結賽，活動保障啟動在8月，拿8月的使用量a和S11峰值使用量b做比較，并根據delta = 1 + (b-a) / a，來算出S11當年的增量系數，比如1.3、1.5等，
第二步，S12新增場景，預估增量
考慮到S12在原有基礎上，會有一些新增場景，此時需要在業務目標明確后，將其轉化成技術目標，技術目標再去轉化為容量需求，得到一個預估的增量d，
第三步，S12容量預估，得到資源缺口
在資源準備中，額外buffer通常是10%～20%，總容量的預估，可以根據S12當前8月的使用量e和buffer來推算，公式參考如下：
容量預估=(e * delta + d ) * (1 + buffer )
這部分預估的容量，減去當前的總資源存量，即可得到整體的資源缺口，并以此為依據進行容量調整，
4.3 S12的PaaS合池
4.3.1 合池前后對比
在合池之前，各塊物理資源池相對獨立，如下圖所示，漫畫業務的整體資源使用率最低，而直播可能已接近飽和，此時由于直播是完全獨立的物理資源池，漫畫和電商業務的空閑資源無法被利用，在往年，例如S11時期，就需要采購資源或臨時從云上新增資源來支撐整個活動，
S12賽前，我們把諸如漫畫、電商、直播等的在線類微服務合池完后，業務不再需要關心總體的物理資源池，即只需關心自身業務邏輯配額的使用率，而非底層的分配率或使用率，在物理層面有在線統一物理資源池，底層的分配率、使用率完全由 SRE 和平臺來保證，
4.3.2 合池可能風險
合池后可能會面臨一些不穩定因素，比如，不同的資源池或不同的業務，其內核版本可能有差異，所以我們做了整體物理層的標準化，統一內核以及去CPUSET化，通過底層的 VPA 策略動態調整整體資源使用，
4.4 S12的配額管理
由于合池后的每個業務都共用一個資源池，所以各業務的資源配額需要做到細分管理，避免資源被無限度使用，這里我們通過容量管理平臺進行管理，容量配額下發邏輯如下圖所示，
配額是基于組織數來下發的，比如某個組織能使用多少配額，策略下發后會作用在規則引擎上，業務變更時，比如要做發版前，會先在規則平臺上了解對應業務的配額是否足夠做發版，若資源不夠，則會提醒配額不足，此時需聯系 SRE 調整配額或者進行配額治理，以此我們就能做到配額管控，保證整個資源池不會被亂用，
4.5 S12的容量支撐
整個 S12 賽事期間，容量支撐可以大致分為四個方面——HPA、VPA、彈性上云、容量巡檢，如下圖所示，
4.6 S12的容量監控大盤
對于S12賽事活動保障，整體關注的核心指標有業務指標、SLO、資源飽和度，容量監控大盤能根據核心指標，幫助更快地定位潛在風險點，并快速做決策，
首先是業務指標，S12我們比較關注直播間在線人數，如超過1000萬、2000萬等等，當賽事期間的整體流量增加，點播業務也會被影響，所以點播在線人數也是我們關注的業務指標之一，
其次是SLO，SRE團隊會更關注核心介面的QPS，以及吞吐、延遲、錯誤率等，
最后是資源飽和度，包括核心服務飽和度、核心中間件飽和度等，
五、未來規劃
5.1 容量風控
我們發現有一些服務的容量變更操作缺乏依據，比如想當然地做縮容，沒有指標去提示或驗證，很有可能導致服務故障，所以我們會做容量風控相關的攔截策略，基于容量畫像、應用群包，去做到容量變更風險控制，
5.2 彈性伸縮
第一塊是分時調度，B站有些小活動比如漫畫業務，基本是在夜間有1個小時左右的峰值流量，其他時間點都是正常的流量，加入分時調度后，比如夜間0-1點的活動，我們就可以在23點前提前做好擴容，活動結束后完成縮容，
第二塊是彈性預測，一方面是能夠預測有規律的流量壓力并提前擴容，另一方面如果監控系統掛了，彈性的預測資料也可以作為監控資料的兜底，
5.3 熱點打散
我們是基于軟限調度，同時軟限也基于 VPA 做了調整，但仍難避免有些服務在物理機上會有熱點，所以我們將基于物理機去做二次調度等作業，（全文完）
添加助理小姐姐（shulie888)，憑截圖免費領取以上所有資料
并免費加入「TakinTalks讀者交流群」
宣告：本文由公眾號「TakinTalks穩定性社區」聯合社區專家共同原創撰寫，如需轉載，請后臺回復“轉載”獲得授權，
本文由博客一文多發平臺 OpenWrite 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/548342.html
標籤：其他