2.4 容量管理的目标与收益
虽然我们在QA那里能够获取到各应用模块的性能数据，但在新项目上线或原有基础上扩容时，仍然需要每次重复评估服务稳定性，这说明我们在平时的工作中对服务系统的容量没有很直观的认识，对系统资源的可用率，我们需要量化。
为了让大家更直观地看到系统的已用率及剩余可用率，在此展开容量管理相关的工作。容量管理的主要目标用于评估各集群模块当前及未来某流量下的容量状态。
为方便陈述，我们这里所说的容量管理是指服务器容量管理。
容量管理的基本目标是以合理的硬件成本满足业务需求。其实我们平时所做的很多工作都是在完成这一目标，比如开发人员改进程序算法，提升处理能力。运维人员根据业务类型，定制专用的服务器。而我们的容量管理，从表面上看是在管理服务器，其实容量管理一方面是节约硬件成本，另一方面节约了人力成本。
每季度在做预算时，这是公司全体技术人员头痛的时候，虽说服务器运维和开发人员关系不大，但按照以前的做法，运维人员需要向开发人员索取申请机器的理由，开发人员就要自圆其说地给出一套理由，而运维人员根据申请的机器数又要酌情删减，这样才好向上面交待，大家都是走个“形式”。有了容量管理系统，我们可以用数据说话，要多少机器不是我们说了算，是业务“说”了算，这样就可以使技术人员更加专心地投入工作。
容量管理还可以节约人力，这体现在服务扩容方面。扩容就是在集群中增加结点，就意味着包括以下工作：
（1）服务环境部署；
（2）关联模块配置；
（3）同步定时任务；
（4）向数据中心注册；
（5）向操作中心注册；
（6）对内部系统的权限申请；
（7）代码同步；
（8）数据同步；
（9）开启服务；
（10）qa回归测试；
（11）应用上线。
以上仅是增加一台结点时所做的基本工作，而且其中每一个环节都不能出错。另外，向内部系统申请权限是要花时间成本的，通常需要一两天的时间，这就意味着，为了应急突发事件引起的扩容，需要提前准备一些已申请权限的机器在备机池中，听上去就感觉好累，这些都是运维人员的工作。
为减少盲目扩容时付出的人力成本，提前知道目前的系统还能支撑多久。比如在节假日时流量会增长，为保证服务稳定，只好按经验添加机器。
机房由于物理原因可能导致不可用时，用户将无法访问到服务。例如用户在访问某网站时，突然该网站所在的机房出现了问题，不管是运营商的问题还是机房建设的问题，总之，为保证用户的业务访问，必须将流量切换到其他机房或运营商上运行，这在之前，为了避免压垮对方机房的服务器，都是一点一点尝试做的，如先切换5%的流量，观察一会后，没有问题，再切换10%的流量，之后再胆大点，切换20%的流量，这种循序渐进的切换方式，必然也会造成用户的请求失败，如果涉及金钱交易，对公司的损失想必是非常大的。有了容量系统，我们知道对方机房的容量后，这样便可一次性地把流量切换过去。
另外，当系统服务过于冗余时，为了节省资源，我们通常要在集群中下架一些服务器，这通常不是下架一两台，少则十几台，多则几十台。下架机器并不是简单地把服务器关掉就行了，需要在上下游通过各种配置，把下架的机器屏蔽掉，保证没有流量才行。这通常牵扯到上游服务，也需要申请，所以，下架服务器既需要人工成本，也需要时间成本。万一机器被下架的太多，可能随时重新扩容。有了容量管理系统，该下架多少台机器是通过计算得出的，没有人工干涉，可以让运维人员更踏实。
最另人欣喜的是，容量规划还可以帮我们找出模块最大可正常处理的请求数。
模块一般都有配置文件，就拿PHP来说，其配置文件php-fpm.conf中配置了PHP进程可处理的最大并发数，每个请求的最大执行时间等。之所以可以这样配置，原因是PHP内部都有个“仲裁器”，由它来控制管理处理的请求，当请求超时时，它会将请求“杀掉”。显然，这部分被“杀掉”的请求已不属于被正常处理的，容量规划可以找到正常处理请求数的最大值。
总结，容量管理系统给我们带来的收益如下。
（1）科学地评估系统所用的资源是否合理。
（2）科学地预测未来资源的增长，并进行合理的预算采购。
（3）运维人员以科学的方法对资源进行有效管理，这包括优化集群中结点机器数量，预知服务可承载的最大压力，预知系统何时性能燃尽等。