容量规划，运维工程师的必修课

如今人们已经习惯从互联网上获取信息，因此，几乎任何一家公司都要有自己的网站。引入了一个新的事物后，必然会随之带来新的问题。网站是放在服务器上的，一般来说网站的访问量越大，服务器的压力就越大。为保证网站的正常运营，网站的运维人员有必要了解当前系统是否工作正常、系统的处理能力是否接近极限，以及需要新增多少台服务器来承载新增的压力。作为一名合格的运维工程师，对于以上这些必须要做到心中有数。

1　容量规划背景

一般的公司在网站扩容方面都是采用“凭经验+逐步尝试”的方法，这样通过逐渐逼近的方式得到系统的极限承载量。再专业一点的公司，会让运维人员搭建一套线下的测试环境，测试人员先在线下对各种关键URL做测试，通过分析测试报告找到系统的极限值。这种方法只能得出个大概值，因为真实的压力取决于用户的行为和当时的代码运行情况。

第三种方法是在线切换流量，也就是将一部分流量导入到某些服务器上，观察日志，直到出现报错为止，然后再将流量切挽回到其他机器结点上，这种方法能够得到最真实的系统压力，但毕竟牺牲了部分用户体验。

以上3种方法的共性都是单次有效，下次换了新的代码环境还要重新手工测试。除了以上的方法外，还可以利用一些系统命令做监控，每天做出容量报表，通过查看报表运维人员便监控到系统的实时压力及实时容量，当逼近根据经验判断的压力上限时，发出报警，提醒扩容。还有的公司是利用监控系统，找到半个月内的系统最大流量作为未来短期内的流量预估，基本上也是靠经验。

上述方法都不能正确地得到系统所能正常承载的极限压力，总的来说都是依靠经验或牺牲用户体验为代价。因此需要将系统的极限压力量化为具体的数据，进行更为准确的容量规划。

2　容量研究的意义

容量管理的基本目标有两个，一是使运维人员了解系统的承载力，二是以合理的硬件成本来满足业务需求。减少成本是企业生存的刚性需求，技术人员同样有责任在技术层面上帮助公司节约成本。在软件方面，开发人员通过改进程序算法来提升系统的工作效率；在硬件方面，运维人员除了规划服务架构，还要根据业务类型定制专用的服务器，有针对性地提升系统性能。无论在硬件还是软件方面，都是在原有服务的规模下通过提升性能来减少硬件成本。除了以上两个方面，还可以通过硬件容量规划的方式进行最直接的成本控制，容量管理一方面是节约硬件成本，另一方面节约了人力成本。

为方便陈述，我们这里所说的容量管理是指服务器容量管理。容量管理主要用于评估各集群模块在当前及未来流量下的利用率，让系统容量“可见”。

模块的性能表现和实际运行的指令息息相关，并不是一次测试便能适用所有类型的代码环境，因此，当有新项目上线或在原有基础上扩容时，较安全的做法是，需要重新评估机器性能用以考量服务的稳定性。容量管理可以量化服务的稳定性，测试人员可以专注于业务本身的测试工作，无须再做稳定性测试。

技术人员还要负责硬件成本预算的工作，在提交预算时要反复权衡服务成本与稳定性。对于预算中的刚性需求，技术人员必须提供充分的理由予以支持，需要一套有效的数据作为预算的依据。有了容量管理系统，任何时候都可以用数据说话，系统需要多少台机器不是技术人员决定的，而是由业务流量决定，这样就为技术人员分担了预算压力，使他们能够更加专心地投入工作。

3　容量研究的目标

目标是实现单入口流量预估，具体包括以下内容。

（1）判断现有系统规模还可以再承载多少流量。

大家应该有这样的经验，一到假期，大家花费在网络上的时间会很多，也许会发现网站的响应有可能会变慢。对于网站来说，假期的流量比一般时候的流量要大，因此，在节假日的流量会有所上涨。我们可以估计出新的流量来判断现有的系统是否可承受。

（2）对于新增的流量，采购设备时给予指导，花最少的钱办同样的事。

公司一般会在每个季度做一次预算，因此，要提供一套理论公式支持部门的预算申请。对于运维部门来说，就要用数据来说话了，提供容量公式是最好的证明。

（3）流量切换时可以量化。

为了保证服务稳定，通常会提供双机热备，有时保险起见，会提供多余的一套设备。或者为了提速，提供的服务会划分为多个冗余系统，当某个机房的服务出现问题时，为保证正常服务，需要将流量切换到另一个机房。切换多少流量过去呢？这时候容量系统就派上用场了，为了不至于“压垮”另一个机房的系统，需要事先知道另一个机房的系统容量还有多少空余。

（4）优化服务规模。

产品服务中的机器数未必是最优的，容量管理可以根据访问量和指定的容量利用率，自动计算出需要的机器规模。

以上几点是容量规划要实现的目标，更多内容请参考《大型网站服务器容量规划》

本文节选自《大型网站服务器容量规划》。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF92F3500001B9C41FE0C5401860