2023年7月11日发(作者：)

《运维之下》——第四章：服务器资源使⽤率服务器数量达到⼀定规模后，⽼板们开始担⼼了：“每季度这么⼤⾦额的服务器采购⽀出，我们的服务器资源使⽤率如何？”- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -指标计算了解资源使⽤率的前提是记录所拥有的服务器资源以及归属，在服务器采购到位后，就开始跟踪服务器的各项资源指标。但每次⽼板们问到这个问题时，作为运维⼈员还是很难直接回答。我们记录了每台机器历史的各项资源使⽤数据，但如何体现整体的资源使⽤情况，通过简单的指标表⽰出来还是⽐较⿇烦的。⾸先，我们不能把所有服务器罗列出来，逐台给⽼板汇报。其次，每台服务器每天的资源占⽤情况是随时间，随业务特性动态变化的，需要将CPU、内存、磁盘、IO等每个动态变化的资源指标分别换算成⼀个值。例如：⼀台CPU密集型的服务器，每个时间点访问量的不同，CPU使⽤率也是不同的，如图4-1所⽰。最后，每台服务器每天的平均值，由于⾼峰期或低峰期的差值很⼤，均值没有任何参考意义。取每台服务器每天的最⼤峰值，有时候可能由于某⼀次数据传输，或者跑⼀个临时MD5运算导致CPU使⽤率突增，也不能合理代表这台服务器的CPU使⽤率。图4-1 CPU使⽤率了解到的业界⼀般的计算⽅法是：◎

定义每天的业务⾼峰期为 10:00AM—10:00PM，求这段时间平均值表⽰该台服务器当天的使⽤率；◎

每天取峰值的3个点，求这3个峰值点的平均值表⽰该台服务器当天的使⽤率。对于定义业务⾼峰期，然后求平均值，我们认为不够精准，很多业务不⼀定⽩天时间达到它的峰值。如果每个业务都个性化定义⾼峰时间，⼯作量⽐较⼤，管理起来也很⿇烦。每天取峰值的3个点求平均值，很多时候⼈⼯操作或者临时性的计算很容易把这个峰值提得太⾼。经过多次讨论后，确定了下⾯的计算⽅法：（1）每台服务器的CPU、内存、磁盘、IO、⽹卡数据每2秒钟采集⼀次；（2）每天分别取这些数据的TOP n%求平均值。如图4-2所⽰为某台服务器某天的监控数据，我们计算出CPU、内存、磁盘和IO的数值如表4-1所⽰。图4-2 监控数据表4-1 资源数值 资 源 项 CPU 内存 磁盘 IO

数 值 98.12% 73.29% 58.69% 29.05%当然，怎么计算这个资源数值都没有问题，只要是统⼀的计算模型，能够表⽰所有机器的资源占⽤指标即可。我们这么计算是希望能够更接近服务器的平均峰值，消除⼀些临时性尖峰导致数值较⼤的问题。指标展现完成了资源使⽤率计算，但如何整体展现所有服务器的资源使⽤率也是⼀个问题。由于业务特性的不同，有消耗CPU的，有消耗内存的，也有类似离线存储消耗磁盘空间的，不可能把所有服务器的某项值加起来，然后求平均值，这样说明不了任何问题，⽽且值会低得可怜。在⼀个案例中，公司所有服务器每天的CPU值求平均值，CPU使⽤率只有23%左右。所有⼈看到这样的数据都会问⼀句话：“为什么我们的服务器资源使⽤率这么低？”对于如何体现公司整体的服务器资源使⽤率这个问题，我们也没有什么好的⽅法，不过可以从另外两个维度去体现。（1）将整个公司这个维度拆解到最⼩的相同功能集群的粒度，统计和展现这些⼩集群的资源使⽤率情况。这个时候就需要结合之前提到过的“服务树”，我们通过服务树将公司的产品划分到产品线->⼦系统->集群这样的粒度，每个⼩集群的功能是类似的，这群服务器的资源使⽤模型也是类似的。研发或运维在提交采购预算时，以最⼩集群为单位。领导在审批预算时，可以很⽅便地查看该集群的资源使⽤情况，决定是否购买。（2）每⽉统计出资源使⽤率不达标的服务器，发给相关的研发主管和运维⼈员，督促他们尽快利⽤或者归还资源。⽐如某个集群每⽉不达标的服务器数量超过该集群的5%，则认为这个产品线资源使⽤不达标。这样侧⾯解决了如何整体展现公司资源使⽤率的问题，给出最⼩集群资源使⽤率不达标的情况，展现的数据量⽐较少，⽽且能够很好地跟进和解决。还可以给出资源使⽤率不达标服务器和所有服务器的占⽐曲线，⽤来观察整个公司服务器资源使⽤率的变化情况。这样既满⾜了⼯程师需要了解具体信息，执⾏改进的需求，也满⾜了⽼板需要了解整体信息，把握全局的需求。怎么计算、怎么展现才算合理，每个公司都有⾃⼰的做法。当然，在你认为公司整体资源使⽤率都还不错的情况下，所有服务器的平均值也许可以作为⼀个基准，⽤来宏观监控整体资源使⽤率有没有变好或变坏也是挺不错的。不达标原因分析完成上述⼯作后，我们开展了⼀次资源使⽤率未达标服务器原因分析，按照未达标的原因进⾏了归类。如图4-3所⽰。图4-3 资源使⽤率未达标原因归类每类原因说明如下：◎

灾备：该类型服务器属于对重要服务的备份服务器，平时没有或有很少的流量。◎

特殊服务：该类型服务器属于特殊⽤途需要独占或者多副本存在，如ZooKeeper，或类似博客对外服务⼜需要安全隔离的业务等。◎

服务部署中：服务扩容、搬迁时，暂时未引⼊业务流量。◎

流量未达预期：业务已经在线上运⾏，但由于流量预估不准确，服务上线后流量和计算量未达到预期。◎

开发测试中：新服务⼩流量运⾏，处于开发联调阶段。◎

测试环境：研发或测试的线下集群，⽤于压⼒测试、功能测试等。◎

计划下线：服务优化、架构调整、业务功能裁剪等，空闲服务器处于待下线归还状态。◎

故障中：服务器故障停⽌业务，处于维修状态中。◎

⾼峰预留：为了应对⽐如业务促销活动、特殊节假⽇等流量⾼峰，提前储备的服务器资源。下⾯分析导致前⼏类原因出现的问题。1．业务线预算不准确◎

预估的业务流量较⼤，实际业务流量未达到预期，导致已经上线的服务器资源浪费。◎

项⽬计划不准确，原计划3⽉份进⾏新服务上线或者扩容，结果项⽬延迟到6⽉份，导致3个⽉时间的服务器资源闲置。2．服务器采购效率低，缺少快速伸缩的能⼒◎

随着公司对于服务器需求的数量越来越⼤，很早以前那种随⽤随买的模式已经不适合了，转⽽采⽤服务器集采的模式，从预算申请，到领导审批、采购招标、供货商送货、服务器上架、系统装机交付等多个环节，在正常情况下会耗时2个⽉。那么业务部门往往会提前并较多地购买服务器，造成⼀定时间段的服务器资源浪费。◎

为了应对某次突增⼏倍的业务促销活动流量，需要提前准备服务器资源。当活动结束后，服务器资源的归往往不及时，归还后其他业务部门消化这部分资源的时间也⽐较长。◎

服务器采购时资产是划分到各个部门的。服务器资源归还后，还存在部门间资产更新计算的问题。3．缺少资源监控平台缺少资源监控和审查机制，业务部门浪费的机器也不会及时归还。资源优化看到这⼏类原因后，第⼀时间能够想到的解决⽅案就是公有云。类似AWS的服务，能够快速地交付或归还虚拟机资源，按时间、按流量收费。虽然⼤部分业务是可以部署在公有云上的，但还有很多类似HBase、离线计算等对磁盘IO、内⽹带宽有较⾼需求的业务，不太适合在虚拟机上部署，成熟公司这部分业务的服务器数量⼀般占到30%～60%。先不讨论公有云是否真正省成本，仅就对⽬前国内云服务商的安全评估，我们还不敢把⾼敏感、⾼安全要求的⽤户数据、现⾦⽀付类业务放置在云端。另外，多机房服务冗余、机房间专线互通等各种因素也需要考虑进去。我们的⽬标是通过缩短服务器采购周期，资源能够具备快速伸缩的能⼒，结合预算审批、资源监控等⼿段，将不达标服务器控制在合理范围内。综合考虑后，可选的解决思路如下：（1）⽀持物理机租赁模式，提⾼服务器交付效率；（2）⽀持私有云和公有云的使⽤，降低物理机的需求；（3）统⼀预算平台，限制不达标业务的申请；（4）资源监控，不达标服务器资源能够及时归还。作为⼀些互联⽹公司，不希望投⼊过多的资源在固定资产上。运维⼈员也不愿意投⼊过多的精⼒在服务器的采购、上架、维保以及后续的报废处理上。当前已经有很多公有云⽀持虚拟机和物理机的租赁业务，传统的IDC⼚商也陆续提供物理机租赁业务，由他们负责服务器的采购、上架等⼀系列⼯作，按照我们要求的时间、地点（IDC、机柜位置等）进⾏交付。公有云或服务器外包公司提供⾜够的备机池资源，能够应对我们对于服务器快速伸缩的需求，按照实际租赁时间收费。成本⽅⾯，按照服务器3年淘汰，每次物理机采购实际是预付了3年的使⽤费⽤。采⽤租赁的⽅式按实际使⽤时间付费，不需要提前⽀付未来的费⽤。对于项⽬计划不合理、预算不准确、⾼峰期预留等问题，我们可以通过快速的服务器交付、归还的⽅式缓解这些问题，将成本⽀出降到最低。当前，⾜够的备机池、快速的交付时间是有成本⽀出的。预算平台和资源监控的结合，限制和发现那些资源使⽤率不达标的服务器，督促业务线及时归还资源，减少成本⽀付。提升服务器资源使⽤率还有很多⽅法，⽐如服务模块混布、资源闲时利⽤，这些属于运维可控的范围。另外，研发对于代码和功能的优化，效果往往会更加明显。