一分钟精髓速览

当成千上万的服务器都处于低利用率时，就意味着巨额的节约，良好的容量治理能够帮忙打消某些“最初时刻”的长期应急式的自觉或者超量洽购。除了老本正当管制方面，容量治理还要预估对客户可能产生影响的业务倒退和危险变动。

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 公布！