一、容量管理的設(shè)計(jì)理念

1、為什么要做容量管理？

1）容量風(fēng)險(xiǎn)未知

集群/資源池/Node容量水位缺乏可視化，穩(wěn)定性難以保證

隨著云原生和K8S普及，若沒(méi)有很好的容量管理，我們就無(wú)法感知整個(gè)集群、整個(gè)資源池以及Node容量的水位變化，也無(wú)法得知是否有必要采購(gòu)資源，無(wú)法察覺(jué)整體的資源風(fēng)險(xiǎn)。

• 容量變更根因難以追溯

有時(shí)我們?cè)谧鲆恍┌l(fā)版或迭代時(shí)，會(huì)發(fā)現(xiàn)原本充足的資源突然出現(xiàn)緊缺。此時(shí)，若要查探容量何時(shí)變化或追溯變化的根因，存在一定難度，也比較復(fù)雜。

• HPA覆蓋率低，業(yè)務(wù)穩(wěn)定性難以保障

B站有很多活動(dòng)和突發(fā)流量，但由于HPA的覆蓋率比較低，業(yè)務(wù)容量彈性往往難以保障。

2）降本增效大背景

• 資源使用率低，迫切需要提高整體使用率

• 資源碎片化較為嚴(yán)重，資源無(wú)法得到充分利用

• 平臺(tái)缺乏統(tǒng)一的資源協(xié)調(diào)能力

由于將物理資源分散到各個(gè)部門(mén)，如直播業(yè)務(wù)有獨(dú)立的直播物理資源池，電商有專(zhuān)屬物理資源，碎片化程度極高，所以平臺(tái)統(tǒng)一協(xié)調(diào)資源的能力難免存在欠缺。

• 資源占用大頭難以快速發(fā)現(xiàn)，治理困難

降本增效遵循二八原則，即20%的業(yè)務(wù)可能占了80%的資源。我們需要快速如何找出20%的業(yè)務(wù)，并推動(dòng)其進(jìn)行治理，這部分業(yè)務(wù)得到治理后往往收益較大。

2、不同部門(mén)的關(guān)注點(diǎn)

• 研發(fā)/部門(mén)：要有資源去做資源的擴(kuò)容發(fā)布、藍(lán)綠發(fā)布和回滾。希望部門(mén)的成本不能過(guò)高，避免資源浪費(fèi)。

• SRE：服務(wù)的穩(wěn)定性。在保證穩(wěn)定性的情況下，聚焦服務(wù)資源的使用率，以達(dá)到降本增效的目的。

• 平臺(tái)：需要統(tǒng)籌資源buffer，控制資源的超賣(mài)率，保證底層容量的穩(wěn)定，從而實(shí)現(xiàn)降本增效的目標(biāo)。

• 成本部門(mén)：資源使用率，賬單、預(yù)算和成本。

3、容量管理面臨的挑戰(zhàn)

• 內(nèi)部因素復(fù)雜，變動(dòng)頻繁

包括代碼變更、配置變更、壓測(cè)活動(dòng)、多活切量、定時(shí)任務(wù)和緩存過(guò)期等，都可能導(dǎo)致容量模型發(fā)生改變。

• 外部場(chǎng)景多樣，難以預(yù)知

B站活動(dòng)比較多，運(yùn)營(yíng)也會(huì)進(jìn)行不定時(shí)的推廣，一些熱門(mén)事件或話(huà)題都有可能導(dǎo)致容量的突增。

• 鏈路瓶頸點(diǎn)多，難以提前發(fā)現(xiàn)

無(wú)論是東西向流量還是南北向流量，整個(gè)鏈路比較長(zhǎng)，因此上游服務(wù)、下游服務(wù)和中間件都可能遇到瓶頸。

• 應(yīng)急依賴(lài)人工，恢復(fù)時(shí)間長(zhǎng)

以上問(wèn)題發(fā)生時(shí)，如果依靠人工應(yīng)急，上游擴(kuò)容可能會(huì)將下游直接打垮，容易引發(fā)二次故障。

4、容量管理的整體思路

整個(gè)容量體系的設(shè)計(jì)，從下到上分為幾大部分，包括基礎(chǔ)容量、彈性資源、合池和配額管理。

首先是基礎(chǔ)容量，它包含平臺(tái)關(guān)注的集群容量、資源池容量、Node容量，以及應(yīng)用畫(huà)像的相關(guān)數(shù)據(jù)。雖然我們將服務(wù)本身發(fā)版涉及到應(yīng)用資源的容量視作基礎(chǔ)容量，同時(shí)業(yè)務(wù)也會(huì)關(guān)注。

在這些基礎(chǔ)容量之上，我們構(gòu)建了一些彈性資源，包括VPA和HPA，還有我們的合池和配額管理。同時(shí)我們構(gòu)建了整個(gè)容量可視化的一些頁(yè)面，用于幫助我們的業(yè)務(wù)和平臺(tái)更好地將自己的資源數(shù)據(jù)可視化，做一些資源的管理。

二、容量管理之降本增效

1、降本增效通用手段

2、具體方案介紹

1）彈性伸縮-VPA(Vertical Pod Autoscaler)

針對(duì)每一個(gè)服務(wù)，我們都有服務(wù)的軟限和硬限，這是K8S的基本概念。應(yīng)用CPU Used即應(yīng)用的CPU的真實(shí)使用量。B站所有的硬限和軟限都是通過(guò)我們的發(fā)布平臺(tái)caster去指定，它們可能是業(yè)務(wù)基于經(jīng)驗(yàn)設(shè)置的，設(shè)置的值不一定合理。隨著業(yè)務(wù)和服務(wù)越來(lái)越多，這種不合理性就會(huì)越發(fā)明顯，導(dǎo)致分配率非常高，但整體的使用率卻不高。

如何解決這個(gè)問(wèn)題？

我們認(rèn)為，研發(fā)部門(mén)無(wú)需關(guān)注軟限多少，只需關(guān)注需要多少資源?；趹?yīng)用的真實(shí)CPU使用量和應(yīng)用畫(huà)像，評(píng)估它的服務(wù)等級(jí)、是否多活等指標(biāo)，以此判斷應(yīng)動(dòng)態(tài)分配多少軟限。這種方法能提高整個(gè)服務(wù)的部署密度，提高整體資源池的使用率。

進(jìn)行大型活動(dòng)時(shí)，如果分配率已經(jīng)很高，可以應(yīng)用VPA的策略，把非核心服務(wù)（如 L2/L3的后臺(tái)服務(wù)）用來(lái)降級(jí)，調(diào)低軟限，給核心服務(wù)騰讓資源。

我們通過(guò)VPA管理平臺(tái)下發(fā)VPA策略，使其經(jīng)過(guò)VPA-API組件。這個(gè)組件是一個(gè)中間代理，主要實(shí)現(xiàn)對(duì)K8S集群中VPA Generator對(duì)象的增刪改查操作，負(fù)責(zé)匯總收集VPA相關(guān)的可觀測(cè)數(shù)據(jù)。

VPA Generator主要負(fù)責(zé)拆解先前下發(fā)的具有相同畫(huà)像的規(guī)則，如果下發(fā)一個(gè)L0等級(jí)的多活規(guī)則，它會(huì)拆解并創(chuàng)建很多對(duì)應(yīng)VPA對(duì)象，最后通過(guò)VPA Recommender從監(jiān)控系統(tǒng)中采集一些對(duì)應(yīng)的應(yīng)用資源指標(biāo)，計(jì)算推薦值即合適的request值，并通過(guò)VPA Updater組件調(diào)整Pod的資源。

發(fā)布服務(wù)時(shí)也可能涉及到資源改變，VPA Webhook會(huì)監(jiān)聽(tīng)類(lèi)似事件，再動(dòng)態(tài)調(diào)整Pod值。

①策略管理

包括VPA指標(biāo)管理、模板管理和預(yù)估/對(duì)照組。

• VPA的指標(biāo)管理：基于不同的指標(biāo)例如CPU的使用量max、P99等做一些調(diào)整。
• VPA的模板管理：基于我們的一些應(yīng)用畫(huà)像，例如根據(jù)L0服務(wù)或L2服務(wù)等不同的服務(wù)畫(huà)像做一些不同的模板和管理。
• VPA的策略預(yù)估與對(duì)照：分清哪種指標(biāo)或哪部分對(duì)我們更優(yōu)，因此我們會(huì)對(duì)不同的策略進(jìn)行策略預(yù)估和對(duì)照，以便擇優(yōu)。

②數(shù)據(jù)運(yùn)營(yíng)

包括VPA的覆蓋大盤(pán)、VPA執(zhí)行記錄和VPA策略分析。

• VPA覆蓋大盤(pán)：分析整個(gè)資源池的覆蓋率和執(zhí)行記錄，記錄服務(wù)軟限的調(diào)整幅度。
• VPA策略分析：調(diào)整后，通過(guò)可視化界面觀察是否還存在問(wèn)題。

③黑名單

整個(gè)服務(wù)的使用量一般會(huì)在活動(dòng)時(shí)劇增，或某個(gè)服務(wù)上線了新功能，進(jìn)行壓測(cè)，都會(huì)導(dǎo)致整個(gè)容量數(shù)據(jù)變化。所以我們制作了黑名單機(jī)制，進(jìn)行VPA策略避讓?zhuān)ＷC在非預(yù)期的情況下，不會(huì)對(duì)這些服務(wù)進(jìn)行相關(guān)調(diào)整。

④預(yù)警

即使執(zhí)行了VPA，通常也有可能出現(xiàn)不符合預(yù)期的情況，所以我們制作了失敗率、覆蓋率和冗余度的策略預(yù)警。如果本次調(diào)整有多處不符合預(yù)期，提前預(yù)警將遞送給SRE和平臺(tái)方，然后進(jìn)行治理和排障。

2）PaaS合池

我們的漫畫(huà)業(yè)務(wù)、直播業(yè)務(wù)和OGV業(yè)務(wù)都是獨(dú)立的物理資源池，如下圖所示，番劇的CPU分配率很高，而漫畫(huà)跟直播的分配率相比較低。如果番劇需要資源去完成一些事情，漫畫(huà)和直播往往不能滿(mǎn)足，所以需要采購(gòu)獨(dú)立的預(yù)算，或額外申請(qǐng)?jiān)粕腺Y源。

所以我們認(rèn)為業(yè)務(wù)不應(yīng)關(guān)注底層資源，從而完成了PaaS的合池。合池后，業(yè)務(wù)更關(guān)注邏輯的配額管理，即整個(gè)配額的使用率。如果使用率過(guò)高或出現(xiàn)問(wèn)題，業(yè)務(wù)可以解決，底層資源則由平臺(tái)統(tǒng)一管控，進(jìn)而平臺(tái)的統(tǒng)一管控能力提升。

合池具體如何落地？可分為以下幾步：

• 標(biāo)準(zhǔn)化治理

基于歷史原因，不同的資源池使用不同策略，甚至配置、內(nèi)核版本也各不相同，所以涉及到標(biāo)準(zhǔn)化的操作。首先，去除特殊約束，有些服務(wù)可能綁定了特殊的物理機(jī)發(fā)布。其次，不能配置nolimit相關(guān)的服務(wù)，因?yàn)楹铣赝戤吅笕绻硞€(gè)服務(wù)壓力比較大，且配得不合理，往往會(huì)增加物理機(jī)的壓力，影響其他業(yè)務(wù)。同時(shí)，我們還進(jìn)行了去cpuset化、統(tǒng)一操作系統(tǒng)內(nèi)核和日志規(guī)范化的操作。

• 平臺(tái)支撐

由于合池完畢后資源也不能無(wú)限使用，所以要基于合池后的不同組織進(jìn)行邏輯配額管理，再整個(gè)大資源池覆蓋VPA。

• 老板的支持

合池涉及到不同的部門(mén)，這一方面最重要的是需要老板的支持。自上而下進(jìn)行的合池較依賴(lài)協(xié)同合作。

3）配額管理

容量平臺(tái)提供了配額管理相關(guān)的策略下發(fā)能力，同時(shí)對(duì)接內(nèi)部的CMDB業(yè)務(wù)樹(shù)。基于組織業(yè)務(wù)的關(guān)系，可以設(shè)置不同的組織需要的資源數(shù)量。若使用超額，會(huì)聯(lián)動(dòng)發(fā)布平臺(tái)，進(jìn)而控制整體資源。如果資源不夠，可能就無(wú)法發(fā)布或擴(kuò)容。

降本增效的收益

• 成本：通過(guò)這些手段，我們實(shí)現(xiàn)了22年H1在線業(yè)務(wù)PaaS物理機(jī)的0新增，同時(shí)整個(gè)S12的活動(dòng)保障實(shí)現(xiàn)了0采購(gòu)。

• 平臺(tái)：統(tǒng)一管控能力極大提升同時(shí)，快速支撐大型活動(dòng)方面，活動(dòng)數(shù)量攀升了不止10倍。以往進(jìn)行大型活動(dòng)支撐時(shí)，直播資源不足往往需要采購(gòu)預(yù)算，周期漫長(zhǎng)。目前我們可以通過(guò)協(xié)調(diào)資源和統(tǒng)籌調(diào)度盡快交付資源，時(shí)間也從原來(lái)的一個(gè)半月縮短到現(xiàn)在的一個(gè)小時(shí)或兩個(gè)小時(shí)。PaaS的整體使用率獲得較大提升。

• 業(yè)務(wù)：首先，對(duì)于小業(yè)務(wù)而言，由于本身資源池的資源較少，物理機(jī)不多，所以宕機(jī)對(duì)它的影響較大。合池后資源池的規(guī)模較大，服務(wù)相對(duì)分散，所以無(wú)論掛一臺(tái)機(jī)器還是兩臺(tái)機(jī)器，對(duì)小業(yè)務(wù)的影響會(huì)大大降低。第二，業(yè)務(wù)整體的容量需求得到快速滿(mǎn)足。資源緊張時(shí)，它也可以進(jìn)行臨時(shí)的藍(lán)綠發(fā)布或者HPA超賣(mài)。

三、容量管理之穩(wěn)定性

1、在線業(yè)務(wù)的典型特征

2、彈性伸縮-HPA(Horizontal Pod Autoscaler)

HPA的設(shè)計(jì)理念與VPA相似，包括策略管理、彈性預(yù)檢、可觀測(cè)和預(yù)警。

• 策略管理

因?yàn)镠PA基于CPU使用率、內(nèi)存使用率或QPS之類(lèi)等指標(biāo)進(jìn)行管理，有些基于不同的應(yīng)用畫(huà)像進(jìn)行管理。例如，針對(duì)L0和L1的服務(wù)，它們的CPU使用率若達(dá)到30%就應(yīng)該擴(kuò)容，至于非多活的服務(wù)，達(dá)到擴(kuò)容標(biāo)準(zhǔn)的最小值則可能稍高。

• 彈性預(yù)檢

配備HPA后也并非萬(wàn)無(wú)一失，因?yàn)镠PA做彈性會(huì)涉及到下游及一些基礎(chǔ)的技術(shù)組件，比如數(shù)據(jù)庫(kù)會(huì)涉及到一些連接池，需要考慮它是否會(huì)滿(mǎn)，是否會(huì)導(dǎo)致其他風(fēng)險(xiǎn)等。所以我們進(jìn)行一些彈性預(yù)檢的相關(guān)措施，包括臨近值預(yù)檢和容量風(fēng)控等能力。

• 可觀測(cè)

我們會(huì)觀測(cè)異常記錄和覆蓋率，比如對(duì)L0服務(wù)的覆蓋率如何，是否所有L0的服務(wù)都覆蓋了HPA，HPA被觸發(fā)時(shí)HPA的彈性質(zhì)量如何等問(wèn)題進(jìn)行觀測(cè)。

• 預(yù)警

我們?cè)O(shè)計(jì)了擴(kuò)縮容的失敗預(yù)警和HPA失效的預(yù)警，如果觸發(fā)一些HPA擴(kuò)容或縮容的事件，研發(fā)部門(mén)會(huì)收到相關(guān)時(shí)間通知，告知因服務(wù)壓力或流量導(dǎo)致HPA發(fā)生變化。

1）HPA可視化

①HPA管控

包括HPA 的批量開(kāi)啟和禁用。保障大型活動(dòng)時(shí)，往往會(huì)希望容量是穩(wěn)態(tài)的，再基于穩(wěn)態(tài)的容量進(jìn)行壓測(cè)，此時(shí)需要先關(guān)閉HPA，在低峰谷區(qū)進(jìn)行壓測(cè)。在資源不變的情況下，壓測(cè)穩(wěn)態(tài)能夠支撐的量的數(shù)值。后續(xù)可能分為幾輪壓測(cè)，最后一輪壓測(cè)會(huì)開(kāi)啟全部HPA，觀察我們最終能支持的量，基于這些量預(yù)估容估。除此之外，還可能涉及HPA的增刪改查能力。

②可視化

主要是HPA覆蓋率，要確定整個(gè)HPA在不同區(qū)域和不同等級(jí)覆蓋的應(yīng)用數(shù)及覆蓋率，對(duì)比指標(biāo)數(shù)據(jù)和彈性實(shí)例。

彈性實(shí)例對(duì)比表明當(dāng)前服務(wù)的實(shí)例數(shù)量，并展示一個(gè)關(guān)鍵數(shù)據(jù)。這個(gè)數(shù)據(jù)幫助我們基于HPA配置策略，確定彈性實(shí)例的最終數(shù)量。彈性實(shí)例受限于HPA的最大值控制。如果純粹通過(guò)配置策略計(jì)算擴(kuò)容的實(shí)例數(shù)，那么能夠通過(guò)HPA擴(kuò)至15個(gè)。但如果無(wú)最大限制，可能會(huì)直接擴(kuò)至20個(gè)。因此，借助可視化能直接看出HPA的設(shè)置是否合理，了解整個(gè)HPA變化的實(shí)際趨勢(shì)。

2）HPA并非可以無(wú)限擴(kuò)容

HPA受限于連接池或下游服務(wù)有限的承載能力，因此我們排查了整個(gè)過(guò)程需要使用消息隊(duì)列、Tidb、泰山KV、緩存以及中間件等相關(guān)組件。整體排查后，發(fā)現(xiàn)MySQL風(fēng)險(xiǎn)較大 ，因?yàn)榇蠖鄶?shù)組件基本是集中式的代理，例如Tidb和泰山KV都是集中式的proxy部署，無(wú)連接池相關(guān)風(fēng)險(xiǎn)。緩存使用的redis和mc往往具有較大支持連接數(shù)，所以風(fēng)險(xiǎn)相對(duì)可控。MySQL 則不同，因此我們?cè)趶椥灶A(yù)檢這方面增加對(duì)MySQL和連接池的預(yù)檢。如果整個(gè)擴(kuò)容導(dǎo)致MySql水位變高，就會(huì)進(jìn)行相關(guān)提示。服務(wù)進(jìn)行HPA擴(kuò)容時(shí)，可能會(huì)導(dǎo)致下游的服務(wù)壓力、下游雪崩，導(dǎo)致一些底層的中間件出現(xiàn)一定的問(wèn)題或壓力。

解決這個(gè)問(wèn)題的整體思路：

一是HPA預(yù)檢，二是基于全鏈路的彈性，三是對(duì)超出預(yù)期的流量做一些組件的限流。

3）容量巡檢

容量巡檢的作用在于，如果某些服務(wù)有風(fēng)險(xiǎn)，能夠?qū)崿F(xiàn)相關(guān)數(shù)據(jù)可視化。

針對(duì)不同的場(chǎng)景和不同的角色，關(guān)注點(diǎn)也不同。

業(yè)務(wù)更關(guān)注整個(gè)業(yè)務(wù)維度，例如使用率如何、有無(wú)風(fēng)險(xiǎn)應(yīng)用等應(yīng)用維度，能盡快找到這些列表，進(jìn)而快速完成治理。配額管理方面，則包括整個(gè)配額的使用率和配額可調(diào)度的實(shí)例數(shù)量，幫助快速判斷配額風(fēng)險(xiǎn)。

平臺(tái)方則更關(guān)注資源池的分配率，如可調(diào)度的實(shí)例數(shù)峰值、資源使用率、資源池是否為單節(jié)點(diǎn)，還會(huì)關(guān)注整個(gè)VPA的調(diào)整失敗率和冗余度?；谄脚_(tái)方的關(guān)注事項(xiàng)，我們制作了風(fēng)險(xiǎn)的巡檢大盤(pán)，用以確定哪些資源有風(fēng)險(xiǎn)、哪些資源比較空閑、哪些資源急需治理等情況。

4）超載保護(hù)

即使有了這些保障，也無(wú)法保證萬(wàn)無(wú)一失。因?yàn)榱髁客话l(fā)很常見(jiàn)，如佩洛西事件等熱點(diǎn)事件導(dǎo)致B站的直播流量激增、超出預(yù)期，所以這方面需要依靠彈性資源。另一比較重要的手段則是依靠技術(shù)組件限流熔斷和降解。

• 限流

目前限流主要包括分布式的全局限流和基于http、grpc、qps的限流，同時(shí)因?yàn)槊總€(gè)業(yè)務(wù)方基本上都會(huì)健全賬號(hào)，所以我們會(huì)對(duì)一些比較核心的業(yè)務(wù)做基于caller即調(diào)用方的限流，從而避免因某一個(gè)業(yè)務(wù)的流量突發(fā)而導(dǎo)致整個(gè)賬號(hào)體系出現(xiàn)問(wèn)題。

另一方面，我們基于BBR進(jìn)行動(dòng)態(tài)限流，基于cpu使用率、成功qps和響應(yīng)rt等限流，同時(shí)聯(lián)動(dòng)移動(dòng)端并進(jìn)行流控。如果服務(wù)端超出承受極限，我們會(huì)給移動(dòng)端下發(fā)策略，驅(qū)使移動(dòng)端做流控的控制，避免用戶(hù)重試導(dǎo)致雪崩。

• 熔斷

包括通過(guò)滑動(dòng)窗口計(jì)算成功失敗率以及熔斷后需要進(jìn)行的操作。

• 降級(jí)

基于多活進(jìn)行跨可能區(qū)的降級(jí)，業(yè)務(wù)對(duì)這個(gè)操作無(wú)感，這也是我們做多活的一個(gè)好處。而對(duì)于Node SSR相關(guān)的降級(jí)，支持降級(jí)至靜態(tài)頁(yè)，業(yè)務(wù)也無(wú)感，但耗時(shí)相對(duì)長(zhǎng)些。至于數(shù)據(jù)類(lèi)的降級(jí)，假若AI方面的算法服務(wù)出了問(wèn)題，我們可以進(jìn)行兜底數(shù)據(jù)展示，但用戶(hù)方的內(nèi)容質(zhì)量就有所下降。弱依賴(lài)降級(jí)時(shí)，部分服務(wù)會(huì)直接降級(jí)，不展示非核心數(shù)據(jù)。

四、容量管理之可視化運(yùn)營(yíng)

1、基礎(chǔ)容量

我們更關(guān)注集群、資源池、Node和應(yīng)用維度的數(shù)據(jù)，所以制作一些可視化圖表，以便更快查看整個(gè)集群資源池和應(yīng)用在這段時(shí)間內(nèi)的變化趨勢(shì)。

以資源池和Node為例，由于要控制超賣(mài)，所以要控制資源池和Node的容量水位和超賣(mài)率（Node也有部分熱點(diǎn)）。

有些會(huì)觸發(fā)二次調(diào)度，把上面的部分服務(wù)調(diào)用到非熱點(diǎn)的服務(wù)中。應(yīng)用則包括應(yīng)用的資源使用量、使用率、實(shí)例數(shù)和單實(shí)例容器數(shù)，它的容器包括多少容器數(shù)，例如有一個(gè)Pod，它可能包含一個(gè)主容器和相關(guān)伴生容器，伴生有可能導(dǎo)致容量變化。我們基于這些數(shù)據(jù)制作趨勢(shì)圖，并在監(jiān)控上保存應(yīng)用的相關(guān)容量數(shù)據(jù)。與監(jiān)控相比，因?yàn)閿?shù)據(jù)點(diǎn)更加分散，所以保存期限更長(zhǎng)，目前已保存了超過(guò)兩年的容量數(shù)據(jù)。

2、業(yè)務(wù)組織容量

業(yè)務(wù)痛點(diǎn)

• 在進(jìn)行降本增效時(shí)，如何快速找到資源占用的大頭并優(yōu)先治理；
• 哪些業(yè)務(wù)的實(shí)用率較低使用不合理；
• 是哪個(gè)業(yè)務(wù)擴(kuò)容導(dǎo)致成本突增
• 容量治理的效果如何，
• 哪些業(yè)務(wù)的治理不符合預(yù)期

解決方案

根據(jù)以上痛點(diǎn)，我們?cè)O(shè)計(jì)了組織業(yè)務(wù)容量，基于內(nèi)部的CMDB即組織業(yè)務(wù)數(shù)，通過(guò)聚合應(yīng)用指標(biāo)，從下往上逐漸遞歸，算出整個(gè)組織和業(yè)務(wù)的容量，呈現(xiàn)歷史容量的變化趨勢(shì)。例如，總?cè)萘渴?萬(wàn)盒，1萬(wàn)盒屬于整個(gè)直播業(yè)務(wù)，而直播的分支包含直播的房間、直播營(yíng)收相關(guān)業(yè)務(wù)。

列出每一項(xiàng)所占的資源，就能清晰地感知哪些業(yè)務(wù)是資源占比的大頭和占比總量。通過(guò)圖片上的紅線和紅點(diǎn)，就能分析它的使用量與使用合理性。下圖右方則呈現(xiàn)了整個(gè)容量的變化趨勢(shì)，這樣就能快速定位不合理的板塊。同時(shí)，我們支持?jǐn)?shù)據(jù)的一鍵下鉆，作用同上。

3、容量事件

資源治理時(shí)，往往會(huì)遇到資源變少變空或不能發(fā)版的問(wèn)題。以往查詢(xún)這些問(wèn)題根源，我們可能要翻遍各個(gè)平臺(tái)。例如，查看是否有人在發(fā)布平臺(tái)進(jìn)行擴(kuò)容或縮容操作，部分服務(wù)是否因壓力過(guò)大觸發(fā)HPA，或是否有人在管理平臺(tái)中臨時(shí)添加了機(jī)器導(dǎo)致容量變大。

由于平臺(tái)數(shù)量多，業(yè)務(wù)SRE排查相當(dāng)困難，所以我們做了容量事件相關(guān)的平臺(tái)，以消費(fèi)包括發(fā)布平臺(tái)、HPA以及Node管理等整個(gè)變更平臺(tái)的變更事件。通過(guò)變更事件，把數(shù)據(jù)消費(fèi)到容量事件平臺(tái)上，統(tǒng)籌觀察這段時(shí)間業(yè)務(wù)的容量變更，因此容量事件是我們快速定位容量變化根因的重要途徑。這樣做的收益很顯著，以往容量發(fā)生變化，業(yè)務(wù)必須聯(lián)系SRE和平臺(tái)。而現(xiàn)在無(wú)需這樣操作，就能快速感知容量變化的根因，處理效率提升。

4、容量周報(bào)

容量周報(bào)分為部門(mén)周報(bào)和內(nèi)部周報(bào)，業(yè)務(wù)部門(mén)更關(guān)注整體資源的用量以及資源使用率的變化。觀察這些數(shù)據(jù)能更好地感知容量效果。除了降本增效以外，業(yè)務(wù)還關(guān)注穩(wěn)定性，希望得知具體的風(fēng)險(xiǎn)應(yīng)用有哪些，以及一周內(nèi)哪些應(yīng)用有怎樣的容量變化。

對(duì)于內(nèi)部來(lái)說(shuō)，SRE和平臺(tái)比較關(guān)注哪些部門(mén)的自營(yíng)資源占量較大而使用率較低，這些部門(mén)對(duì)我們來(lái)說(shuō)往往是能用于降本的組織，我們需要提前與他們溝通，所以就需要內(nèi)部周報(bào)幫助完成。同時(shí)我們也列出了部門(mén)資源使用率的排名，排名越靠前說(shuō)明治理得越好，反之亦然。

張鶴

嗶哩嗶哩 

基礎(chǔ)架構(gòu)部 資深SRE

2020年加入B站，先后負(fù)責(zé)社區(qū)/直播/OGV/推廣搜相關(guān)的SRE工作，深度參與多活，活動(dòng)保障，混沌工程，容量治理相關(guān)的建設(shè)，主導(dǎo)容量管理平臺(tái)，混沌平臺(tái)的架構(gòu)設(shè)計(jì)和落地，負(fù)責(zé)B站S賽、跨年晚會(huì)、拜年祭等相關(guān)活動(dòng)的基礎(chǔ)架構(gòu)保障工作，目前主要負(fù)責(zé)推廣搜業(yè)務(wù)的穩(wěn)定性建設(shè)。