第8章容量管理_红桃-红桃娱乐博客新闻站

摘要：随着企业对外服务的内容和用户不断增长，企业会不断增加对硬件和云基础设施的投入，用于满足业务发展的需要。但是很多业务和技术架构师很可能没有关心或思考过采购这些IT资源的必要性，或者应采购多少IT资源才算合理。当前很多

随着企业对外服务的内容和用户不断增长，企业会不断增加对硬件和云基础设施的投入，用于满足业务发展的需要。但是很多业务和技术架构师很可能没有关心或思考过采购这些IT资源的必要性，或者应采购多少IT资源才算合理。当前很多企业的资源管理常态是上了新的产品或业务，相应的硬件和云资源也随之增加，最后导致企业费用支出不断上升、投入产出比很低，甚至入不敷出。很少有人从顶层设计层面出发，思考这些业务和产品到底需要多少IT资源，以及需要这么多IT资源背后的逻辑和依据。

本章将从容量管理的目标、容量管理的方法和策略、容量分析系统建设、容量优化方式，以及容量预案这几个维度来阐述容量管理的要点。

很多互联网企业的研发部门在实际生产过程中都会面临各种各样的复杂业务场景及相应的困难和挑战，这些汇聚到IT支撑环节，就形成了对IT资源的需求和规划。此时容量管理就起到了极大的作用，它可以为企业业务和技术负责人进行统一的IT资源规划提供有力依据，帮助其进行决策，而不会在真正的IT资源成为瓶颈或问题时显得顾此失彼。

作者认为容量管理的目标有以下几点。

成本控制

当一个企业快速发展时，IT资源会得到几何式增加，相应的费用支出也会急剧增加，大型互联网企业的IT资源费用每月可达到千万元甚至亿元。此时，如何控制好这些硬件和云资源的成本会成为企业架构师和CTO（首席技术官）最为关心的问题之一。一些微小技术、架构优化或容量主动管理，都可能节省几十万元甚至几百万元的费用，规模效应非常明显。

业务支撑

业务支撑的典型案例是在电商活动或市场活动时，用户会在某个时刻大规模涌入，现有的应用服务能力和质量会在瞬间面临极大挑战，如果没有提前做好容量管理和规划，那么很可能面临服务质量急剧下降，甚至出现服务不可用的局面。而容量管理可以提前预知当前的IT资源水位和承受极限，技术负责人可据此做出判断并采取相应的扩容等措施。

企业内不同的人和角色对容量管理有着截然不同的认知，因此产生了多种对容量管理的看法，下面是几种常见的企业内部不同人员对容量管理的看法。

（1）管理层视角：研发服务器的数量、机器多了，业务能力就强了。这个想法在当前仍然是很多管理层的认知。

（2）业务部门视角：满足自身业务需求和目标所需要的IT资源费用，投入越多、付费越高、业务支撑能力就越强。

（3）架构师视角：新增的功能和模块需要的云主机或裸金属物理机数量，优秀的设计师可能会进一步评估依赖的数据库、缓存等资源数量。

如果要对企业的IT资源进行系统的容量管理，首先需要将企业内部各部门、各角色对容量管理的目标和效果认知达成一致，这样才能更加容易地推进容量管理的落地。

一般承担容量管理和评估角色的是业务架构师，从业务架构师的角度，大多数的人会用以下简单的逻辑和公式评估容量。

容量=当前业务规模所需要的硬件资源×预期的业务增加幅度×折算系数

例如，（1）当前的IT资源成本为100万元。

（2）营业资源折算系数为每份营业指标对应的IT资源投入。假定上一年营业指标为1000万元，则营业资源折算系数为100万元/1000万元=0.1。

（3）业务部门定的指标为上一年1000万元的1.5倍为1500万元。

为了支撑今年业务规模所需要的额外IT资源成本为500万元×0.1=50万元，即IT资源需要整体扩容50%。

这个公式虽然简单粗暴，但也不失为一个简单有效的办法，至少可以能在管理层面前解释通，但是IT的资源可以这么简单的估算吗？有没有什么办法可以在业务规模增加1倍时，最大限度地控制IT资源成本，甚至做到让IT资源不增加呢？

为了更好地优化IT资源成本，首先我们得理解当前企业IT资源成本的构成。

在多数研发人员的定义中，IT资源一般指裸金属物理机、云主机、数据库、缓存之类的资源，但在运维工程师的角度看，这些仅仅是IT资源的一小部分，远远不是整个IT资源。IT资源成本构成如图8-1所示。

公有云资源一般包括：云主机、缓存、数据库、流量、存储和弹性IP、SSL（安全套接层协议）证书。

当整理清楚IT资源成本的构成后，随后就可以提出以下几个问题。

（1）当前的IT资源有哪些，资源利用率有多少？

（2）当前的IT资源能否支撑当前业务？

（3）在业务不断增长的情况下，IT资源什么时候会达到瓶颈？如果要扩容，该扩容多少？

回答以上3个问题，关键要对当前IT资源的利用率进行评估，只有掌握并了解当前企业所有的IT资源和利用率，才能知晓当前的IT资源健康度，并对其进行管理。在大型互联网企业中，一般用容量水位来代指IT资源的利用率。

容量水位是当前实际消耗的IT资源（包括裸金属物理机、购买的云厂商资源和其他依赖的SaaS服务）占用当前总体可用资源的比例。

例如，当前企业的IT资源研发部门有两台物理机，但实际上只使用了一台物理机，另一台物理机闲置，没有安装任何应用服务，所以该业务的资源使用率只有50%，也就是说当前的容量水位是50%。

只有知道当前的容量水位，我们才可以依此进行各种判断和规划。后面进行容量分析时也是基于容量水位的元数据进行多维度整合分析，并进一步优化的。容量评估元数据1如表8-1所示，容量评估元数据2如表8-2所示，是常见的容量水位所需要收集的数据。

我们需要实时获取基础的容量水位元数据，并通过分析形成一个全面的容量水位数据和报表，供研发部门和业务部门实时查看并进行决策。8.3小节将详细介绍容量分析系统建设。

容量水位2/8原则

需要注意的是：要留意容量水位的短板效应，不能光看平均的容量，还要注意业务的流量峰值。

容量水位短板：现在的业务系统都有消耗各种IT资源，但是我们要识别出最先达到瓶颈的那类资源，然后去做优化。系统实例图如图8-2所示，一个业务系统由服务器和数据库提供服务。随着业务发展用户增多，系统访问越来越慢，此时我们要识别的是哪种资源达到了瓶颈，如果是数据库，那么我们就优先考虑扩充数据库资源和提升数据库的服务能力。

系统峰值和容量水位关系

很多系统由于用户使用习惯不同，会造成流量的不均衡，在做系统的峰值评估时一般会遵循80/20原则，即80%的流量会在20%的时间内到达。新闻系统访问曲线如图8-3所示，一天中大部分时间的用户访问量是稳定的，但是在晚上6点会集中有一波用户访问量，是平时访问量的4倍。此时我们要评估在这个时间点上业务系统的容量是否能支撑住，后续的容量规划也需要按这个峰值的基准来估算。

在其他ToB（面向企业级用户）或公司内部的业务系统或场景中，峰值往往没有那么明显，我们反而要考虑系统是否有大量的冗余资源可以释放。

为能有效进行容量分析和预警，我们需要从各个阶段主动进行容量分析和优化。容量管理策略可以分为以下3个阶段。

（1）事前容量规划——需要知道当前业务需要多少IT资源。

在进行年度IT资源预算规划或新业务、新产品上线前需要仔细评估所需的IT资源。

（2）事中容量监控——需要实时获取容量信息。

业务和产品在服务用户的过程中，需要投入人力建设相应的容量监控和预警系统，实时收集与容量相关的数据，当容量水位低于或高于预先设定的阈值时，就需要报警，报警后开发工程师和运维工程师方可进行容量扩缩容等优化。8.3小节将会全面阐述如何建设容量分析系统。

（3）事后容量调整——根据业务情况及时调整容量。

开发工程师和运维工程师需要做好相应的预案，以应对突发的流量或对处于生命周期末端的产品进行缩容。8.4小节将会从容量优化方式角度介绍如何进行容量调整。

为了很好地监控和实时掌握当前的业务容量水位，大中型互联网企业一般会建设自己的容量分析系统或监控大盘，用于成本控制和提供容量信息供业务部门决策。本小节将会从以下常见的3个维度来讲述如何建设容量分析系统。

针对容量管理策略阶段一，首先我们需要知道支持业务的所有IT资源总量，可以在每台主机上安装相应的监控或脚本，定期收集相应的服务器信息。容量数据表如表8-3所示，表中实时数据可供业务部门决策。

容量水位越低，则说明资料利用率不高、可优化空间大，可以采取一些缩容、降低配置等措施；容量水位越高，则说明业务即将或已经达到了资源瓶颈，需要进行扩容或增加相关IT资源投入，否则容易给业务造成风险。

容量大盘所需要的关键信息可以有以下几个维度。

（1）当前的资源总体负荷情况。

（2）每个类名资源的情况。

（3）当前的资源瓶颈。

（4）资源的峰值。

在实践过程中可以结合一个企业的研发能力来综合考虑容量大盘的建设，比较简单的方式是可以定期每周或每月通过手动和自动的方式收集相关的容量数据信息，形成一个综合数据报表，供业务负责人决策。

95分位值是统计学上的概念，如收集100个数据，从小到大排列，95分位值就是取出第95个用户的数据做统计，50分位值就是取出第50个用户的数据做统计。

在运维领域，95分位值的意义也很重要，在性能统计中，95分位值的波动最明显，能够放大暴露线上的性能问题。相对来说，如果不是特别关注50分位值的图形，那么波动并不明显。如果能够保证95分位值的稳定性，那么就能很好地体现系统的稳定性。

针对容量管理策略阶段二，我们需要实时获取容量信息，并对其进行有效监控，当系统的容量趋势不断上升或下降时，便要采取相应的动作。我们可以通过建设巡检系统，根据运维工程师关注的一些资源瓶颈点进行定期的监控，如应用服务的CPU Load（负载）、JVM（Java虚拟机）内存、GC（垃圾回收）、网络连接等容量信息。应用集群CPU容量趋势图如图8-4所示，如果达到了预期设定的报警阈值，可以提前发报警给相关人员告知当前的容量情况，相关负责人员可以根据当前容量并结合实际的业务做出扩容或缩容的决策。

常见的巡检项目和纬度可以参考如表8-4所示的MySQL巡检项和如表8-5所示的Redis巡检项。

大中型互联网企业为了能更好地监控应用系统的各项指标和状态，会投入巨大的资源建设相应的监控系统和CMDB系统（Configuration Management Database，配置管理系统）。监控系统不仅能监控业务各项系统状态，还能推动容量管理的优化。CMDB系统则存储大量的软件和硬件资产信息，可以快速地让业务了解当前拥有的资源总数。1. 监控系统

监控系统可以通过对各应用元数据的收集、汇总和展示，看到各个业务产品的系统负载，以及应用所依赖的物理资源的使用情况。并且能够通过设置各类元素和指标项的预警阈值，达到有异常就可以报警通知相关接收人员的目标。2. CMDB系统

CMDB系统可以管理一个企业的全部服务器，包括物理机和各类云厂商提供的云主机资产，以及相关对应的资源状态、使用人员、产品应用的环境和项目信息，可以为其他系统，如监控系统、自动化发布等DevOps类系统提供有效的支撑。

CMDB系统可以进一步提供类似业务线—产品线维度的资源和负载情况，进一步供相关负责人进行分析和决策。

针对容量管理策略阶段三，当我们有了容量评估的各个维度数据后，业务或技术负责人就可以根据当前的容量水位进行扩容或缩容决策，或者根据业务进一步规划后续的容量。容量优化是容量管理的核心，是容量管理价值的集中体现。我们可以从业务、资源、架构三个纬度来进行容量优化。

业务容量优化需要和业务部门一起评估，如果某个业务处于急速上升期，为了应对业务的飞速发展和突发流量，对容量水位的要求会低一些，反之如果某个业务处于下降或产品生命的末端，对容量水位的阈值要求就会高些。

例如，当前公司有两款产品：A产品和B产品，设定的容量阈值基准线为0.6。

（1）A产品处于用户急剧增长、产品快速迭代时期。

因为A产品的发展后劲十足，所以我们在做容量预警时可以适当降低容量水位的阈值，如到0.4时就可以提前准备对硬件和云资源进行扩容，以应对后续的用户增长和突发访问流量。

（2）B产品处于生命周期晚期、用户逐渐减少、产品迭代趋向停滞。

当产品或业务处在生命周期晚期时要特别注意，此时的IT资源投入和费用支出很可能无法获得高回报的收益，这时要考虑适当提高容量水位的阈值，如可以逐步缩容到容量基线0.8，从而减少IT资源费用的支出。

业务架构师不仅需要站在技术角度评估，还需要具备业务架构和分析能力，如此才能更好地将自己的专业技术赋能业务，给业务带来增值价值。

在真实的互联网或传统企业IT资源生产场景中，我们经常遇到的是容量水位偏低造成资源有较大浪费的情况。尤其是在一些大型互联网企业，每月的IT资源成本有几千万元甚至几亿元，一个小小的优化点会带来巨大的费用节省，此时容量优化的意义和价值就会凸显出来。一般来说资源容量优化可以从下列几种纬度出发。

云主机降配

云主机降配是最直接的，也是大多数开发工程师和运维工程师能第一时间想到的方案。利用云主机的Resize（动态调整）特性，对云主机的一系列参数进行调整，这种优化方式基于单机的监控数据就可以处理。云主机降配比较常见的指标有CPU规格、内存规格、磁盘挂载、使用时长、超售比等。

混合部署

站在架构师的角度，业务一般分为在线业务和离线业务。

（1）在线业务。负责和用户交互，以及提供实时数据给用户，对系统的响应时间和可用率都提出了较高要求。

（2）离线业务。负责批量计算，不需要实时响应用户，一般为计算量大、CPU密集型业务，但是对系统的及时性要求低，一般用于批量数据分析计算。

混部策略

（1）可以将在线业务和离线业务混合部署，在晚上业务低峰期开启离线业务计算任务，有效地利用CPU，实现峰谷轮动。

（2）一些负载较低或对SLA（系统可用率）要求不高的在线业务也可以进行混合部署，充分地利用IT硬件或云主机资源。

例如，产品A和产品B都是后台业务类型，平时使用人员为业务内部人员，使用频率低，可以将产品A和产品B的应用交叉混合部署，甚至共享缓存和DB实例，用来降低IT资源的投入。

这种混部策略在很多企业都有实际的应用落地，在资源管理技术完善的情况下，能获得较好的服务器利用率收益。在不影响业务SLI指标的前提下，比较常见的数据是CPU利用率额外提升10%。

网络带宽

在大型互联网企业中，网络带宽的成本是占比较大的一个方面，容易被忽视，成本优化空间很大。

一般来说，网络带宽的成本由以下几项构成。

（1）外网带宽。

大型互联网企业的产品后端架构一般是服务化形式，系统架构师需要系统性地梳理产品及产品线的系统架构，查看服务间的调用是否都是走内网的，如果走外网可以调整为走内网，可以减少外网的带宽成本。

例如，Service-B依赖Service-A的接口，Service-A的接口通过http://ServiceA.company.com域名对外暴露服务。如果Service-B直接访问http://ServiceA.company.com，会直接走外网带宽，造成计费，如果Service-B走内网域名、IP或服务器上配置Host（主机名）、IP均可以引导网络走内网，从而大大减少外网带宽费用，网络链路转化如图8-5所示。

业务层也可以通过主动限速等设计，尽量将带宽控制在一个合理范围内。

（2）CDN（内容分发网络）带宽。

业务使用CDN时，主要的带宽成本为CDN出口带宽和CDN回源带宽。一般技术层的优化策略可以参考以下几点。

①增加富媒体文件的压缩比，或者使用新格式。如腾讯云支持的WebP、TGP格式等压缩效率比较高的格式图片，不仅可以节省带宽、减少存储成本，还可以提示页面加载效率。

②配制合理的CDN缓存规则。让当地或就近CDN节点上的缓存内容，直接提供给用户访问。多个用户访问相同资源也无须回源站获取内容，以此减少CDN回源带宽。

③去问号回源。只缓存URL中的问号“？”前路径中的地址资源，而不再缓存整条URL地址资源。

④开启CDN父层。CDN父层是指相对于边缘节点的上层再加了一个共享存储池，用来将多个CDN边缘节点的请求汇聚父层，由父层在回源站获取资源。

⑤开启CDN分段（分片）回源（缓存）。CDN分段回源是指将一份文件拆分成若干个小文件回源，这个做法的优点是通过识别不同类型的文件大小来调整分片的大小。将用户第一次请求由分片服务自动拆分成若干个分片，最终将分片缓存在边缘或父层中。

⑥多个加速域名共享CDN缓存。即多个加速域名使用同一个源站，多个加速域名默认都会回源获取资源。配制共享CDN缓存策略，多个加速域名只会回源一次，减少回源带宽。

⑦限制回源带宽。对源站带宽有一定的限额，如果达到带宽上限会引起无法响应和无法请求到源站任何资源。

⑧CDN预取（预热）。将资源提前一次性推送到CDN的边缘或父层缓存节点，这样只占用一次上传带宽，而推送到CDN边缘或父层的内容可直接被用户访问。

（3）专线带宽。

为满足业务的容量和可用性，大中型互联网企业一般都会自建1个或1个以上的机房，业务会混合部署在这些机房中，大部分的场景下，部署在多个机房的业务会相互调用。此时可以采取以下两种策略。

①判断并推动业务在稳定的专线带宽和不稳定的外网之间做一个取舍。如果业务对系统的可用率（SLA）要求不高，或者业务可以忍受经常的网络抖动，就可以直接走外网访问，费用比专线费用节省60%以上。

②梳理业务和应用服务场景，尽可能将相互间调用量限制在同一个IDC （互联网数据中心）中。

上述两个小节主要是从业务和资源角度做的容量优化，系统架构师会更加关注系统架构优化，从而达到容量优化的目的。

容灾级别分析和优化

很多产品和服务在上线时，工程师或系统架构师会很自然地采用双服务，甚至多服务集群部署的形态，但是大部分情况下业务对可用性的要求并不高，如后台管理、离线业务，过度的容灾反而会带来资源浪费。

此时需要和业务一起联合梳理并定义整个业务系统的重要级别，保障优先级和可用率，对不同的保障级别和可用率要给出对应的负载和备份策略，以此达到分级区分的目的，这对提升资源的使用率很有效。

案例一：

某大型产品企业的登录服务容量优化，根据实际的业务状态，先联合业务对各个系统服务的级别、可用率和容量策略做定义。容灾级别定义和策略如表8-6所示。

如表8-6所示，原先的登录服务、风控服务、消息通知服务和后台管理服务都是多机房多集群部署的。在对系统分级和可用率重新定义后，只保留了登录服务，其他风控服务、消息通知服务和后台管理服务都优化为单机房，并且撤掉了后台管理服务的多集群，只保留单点，整个优化行动节省了50%以上的硬件资源成本。

熔断降级设计

案例一经过调整优化，登录服务保留了双机房部署，风控服务和消息通知服务降为单机房。此时虽然IT资源成本降低，但是系统的可用率和保障力度没有降低，这是如何做到的呢？服务强依赖如图8-6所示。

原来登录服务强依赖的风控服务和消息通知服务在发生故障时势必会影响登录服务，造成登录服务不可用。但风控服务不是核心链路服务，只是登录提示风险的依据，而非登录必要流程，所以需要改造原来的登录业务逻辑，将对风控服务的依赖由强依赖改为弱依赖，服务弱依赖如图8-7所示。

如此一来，登录服务不再强依赖风控服务，在发现风控服务有故障时会自动熔断和断开服务，登录服务还能继续执行后续的流程为用户提供服务，保障用户登录服务的可用。如此设计，不仅保障了系统的可用率，还减少了服务资源和部署成本。

过期数据的归档和删除

很多业务数据如日志访问记录、操作记录、历史购买和账单数据等，数据量巨大，如果一直存放会消耗大量的磁盘资源，并对系统的数据查找产生压力，过期数据的处理策略有以下几种。

（1）删除。如定期删除6个月的访问日志记录，推动业务明确每个产品业务存储记录的时间边界，不需要的数据及时、定时删除，节省空间。

（2）归档。如有一些业务数据无法删除或要求存储的时间特别长，可以从业务侧优化，定期归档。

案例二：

一个计费类型产品，用户在点击账单页面后需要显示本月和本年的费用支出金额。原先的后台设计逻辑是查询DB某个时间段内的所有单个账单记录，并汇聚到应用内存里进行统一合并统计。用户账单量的增长会导致后台查询时间长、计算效率低下，逐步抬高DB和应用服务器的负荷。

（3）归档策略。每月定期批量计算每个用户的账单，将每个月的上百条甚至上千条账单合并计算成一条账单，每年一个用户最多有12条账单，归并后可以删除单条历史账单，这种方法可以节省99%以上的空间，SSD磁盘费用成本节省60%以上。

业务系统的性能优化

如之前的容量定义，容量是指一个应用在可接受的服务质量指标前提下所能容纳的最大业务数量。因此若能在相同的资源容量和服务质量指标前提下支持更多的业务数量，也是对业务资源的节省，此时需要关注系统的性能优化。常见的系统性能优化策略有以下几种。

（1）应用层。

理论上说如果应用层优化得好，很多的服务器是可以不采购的，但在实际情况下业务根本没有时间和精力去做性能优化。

①减少数据库交互。一些上下文所需的数据，如能从缓存里获取就不应该再次请求DB，查询DB比较耗时，频繁地查询数据库不仅会增加数据库的Load，还会耗尽应用的连接，影响整个服务的吞吐量。

②提升热点缓存命中率。如果热点缓存命中率过低，则每次去存储层获取数据效率和响应时间都会较低，可以结合业务看缓存的对象和相关上下文的设计是否合理。

③异步调用。应用服务会对一些请求做一些附属的事情，但用户并不需要立刻拿到这些处理结果，这些场景比较适合异步优化。异步优化提升了应用的响应时间，提高了并发支持的用户量，还有一个好处就是可以将强依赖转变为弱依赖，提升系统的可用率。

④线程池优化。批量操作一些异步时需要注意控制线程池的数量，避免突发大批量任务涌进后快速消耗大量服务资源，导致出现线上服务不可用的情况。

⑤快速失败策略。系统在调用依赖服务时，如等待时间过长，在突然遭受依赖服务故障，或者依赖服务过载还未熔断时，整个系统的响应时间会被拖长，很容易耗尽系统的线程资源从而导致服务质量急剧下降。做系统优化时，可以系统性地排查应用的依赖点，以及相应的超时时间设置。其他方法有JVM（Java虚拟机）调优和减少依赖链路等。

（2）数据库层。

相应的优化策略可以参考以下几种维度。

①优化SQL。通过优化SQL，可以降低数据库服务器的资源要求。

②合适的索引。合适的索引可以优化数据库，但不是每个数据都需要被索引，选择需要的数据建立索引，可以规避空间的浪费。

③读写分离。数据库读写方面的优化有很多，大部分情况下可以做异构设计或队列缓冲设计，降低数据库服务器的规格要求。

④事务优化。事务优化是非常消耗资源的行为，若使用不当会有逻辑问题。

⑤分库分表。分库分表大部分情况下是业务规模等需求导致的额外作用，主要是为了解决数据库的性能问题。

数据库系统优化还需要结合具体的业务综合分析，并做大量的性能压测和业务调优，才能达到满意的效果。

其他优化

（1）测试服务资源机器的优化。

产品在上线前一般会经历联调、冒烟、压测、演练等环节，很多复杂的产品或平台甚至可能会有多套测试环境。如果能全方位认真统计和梳理这些测试环境，那么我们就会发现测试所消耗的IT资源比例会相当大，常见的一个开发部门，测试环境和生产环境的资源比例可达到1∶3，甚至更高。所以我们不能忽视对测试服务资源的管理和控制。

一般来说，测试环境使用率偏低。在产品不同功能迭代的间隔周期内，大部分的测试资源是闲置的，无法充分利用，此时可以从资源的即时分配和回收角度入手。当前比较好的策略是引入容器来进行测试资源的生命周期管理，如处于测试空档期可以缩容或关闭部分容器，一般来说至少可以减少50%的测试环境费用支出。

（2）服务器保修替换。

服务器的质保期限是3年，3年后服务器是否应该下线是非常值得探讨的问题。当然粗略估计，因为服务器直接报废的成本是不划算的，所以会有一个容量替换策略。在实际操作时不只是简单的容量或成本问题，还涉及预算问题。

服务器过质保期限后的故障率会增高，可以根据业务对系统可用率的要求，如非核心的P1、P2级别或离线的业务，继续使用过保后的服务器，进一步利用服务器的最后剩余价值。

（3）硬件资源的精细化管理。

大中型互联网企业由于服务器数量众多，因此相应的内存、磁盘、网卡等配件量也非常可观，此时若能管理好这些备机和配件，使之合理分配，也能极大地降低成本和费用。

①建立固定的备机和备件池，过保的服务器、暂时未使用的服务器、内存、网卡等配件可以统一放置备件池，并统一分配管理，供业务方随时查询使用。

②定时监控服务器的负载，如配置256GB内存的服务器，一些业务在服务器的内存使用率长期在比较低的水平，可以从该服务器上拔出相应内存归还进备件池，供其他服务器使用。

③业务申请新的资源时可以先检查备件池，如有满足业务需要的服务器，可以直接上架使用，无须重新采购，可以节省很大一部分费用。

业务平台或产品如果正处在快速扩展期或有运营大促等活动时，我们的关注点会更多在容量预案上。基于容量分析基础，一旦达到容量预警的阈值，我们就需要启动相应扩容预案，保障服务的稳定和可用。容量预警阈值没有一个标准值，每个产品或业务都可以根据实际的业务和系统情况进行自定义，并没有统一标准。容量预警条件和措施如表8-7所示。

业务需求的快速变化、流量的突增都会对应用服务造成挑战。当出现容量预警并需要扩容时，业务方的期望是越快越好，在一些大促活动等紧急条件下，很可能需要马上执行预案并立即生效。但在实际情况下，无论是应用服务、数据库、缓存还是网络对其进行扩容都需要一定的时间或流程来准备资源，甚至资源到位后还需要进行扩容测试，避免因为扩容造成不该有的服务故障。因此对容量预案提出了更高的要求。要做一个好的容量预案，必须关注以下几个要点。

（1）明确的信息。

明确启动容量预案的时间和条件，当真实的容量预警发生时可以缩短和减少执行容量预案的讨论时间和决策成本。

（2）操作简洁。

容量预案的操作步骤需要非常细致和明确，如果容量预警来得很突然，并且在主要负责人员无法立刻支持的情况下，那么任何一位开发工程师或运维工程师都能根据制定好的操作步骤进行“傻瓜式”操作和操作后的验证，保证容量预案达到预期效果。

（3）操作安全可靠。

有条件的情况下，所有容量预案都需要提前进行准备测试并演练，保证所列出的容量预案操作步骤是安全可靠的，那么实际执行容量预案时就不会有意想不到的问题。很多的容量预案会忽视这个步骤，所以在执行预案操作的时候就会碰到一大堆意想不到的问题，如对服务器进行扩容时，却有给应用服务器申请对应数据库的IP白名单等。

（4）容量预案的监控和后续评估。

容量预案执行期间和执行完毕后要进行实时监测和评估，用于后续的复盘和决策。发现原有容量预案的问题后并进一步优化容量预案流程，可以提高后续的执行效率。

（5）提前储备资源，进行应急支撑。

如果当前产品生产环境是基于云厂商平台的，资源是基于云厂商大的资源池的，则扩容相对简单。如果产品依赖企业自建的机房和基础设施，那么此时要根据容量规划的评估提前准备冗余硬件等资源，用于应对产品的快速扩张和突发的流量。

容量管理是一个复杂的系统工程，方式和方法多样。为达到容量管理的效果，不仅需要在策略、方法、方式上进行定义、明确和落地，还需要在组织、管理、流程上统一进行配合、协同，这样才能达到良好的效果。

（1）设定容量管理目标。