共计 5353 个字符，预计需要花费 14 分钟才能阅读完成。
一分钟精髓速览
当成千上万的服务器都处于低利用率时，就意味着巨额的节约，良好的容量治理能够帮忙打消某些“最初时刻”的长期应急式的自觉或者超量洽购。除了老本正当管制方面，容量治理还要预估对客户可能产生影响的业务倒退和危险变动。
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 公布！
