mod

极客时间专栏/性能工程高手课/容量规划与服务效率/30 | 服务器的管理和部署：工业界近几年有哪些发展趋势？.md

@@ -0,0 +1,106 @@
+<audio id="audio" title="30 | 服务器的管理和部署：工业界近几年有哪些发展趋势？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/59/cf/59c09e723d371e2f5f9e3bb5f064ddcf.mp3"></audio>
+
+你好，我是庄振运。
+
+说起服务器，你一定不陌生。那你知道Facebook的服务器是什么样的吗？要知道，Facebook同时使用着很多不同的服务器。
+
+在应对需要高速缓存的Facebook新闻、广告投放和搜索时，Facebook使用的是有比较大内存和较强CPU的服务器。现在使用的每台服务器都有256GB的主内存和两个处理器的CPU。
+
+而在需要存储大量照片和视频的时候，Facebook就选择了适用于数据和对象存储的服务器，这种服务器只有很少的内存，但是却有几百TB的硬盘存储空间。
+
+今天，我们就从“服务器”入手，进入一个新的专题：容量管理工程。我们一起来看，要如何针对服务器设计、规划和部署的特点，开发出性能优越，能充分利用硬件资源的应用程序和服务。
+
+## 如何设计一种新的服务器？
+
+就像我前面用来举例的Facebook一样，大规模互联网公司的服务器，和我们家里以及办公室用的电脑可不一样，一般不是直接从市场上买的，而是自己设计的。
+
+那么这些服务器是怎么设计出来的呢？其实服务器的设计和其他的硬件设计一样，也需要经过好几个阶段，你可以看一下它们的设计路线图（如下图所示）。
+
+<img src="https://static001.geekbang.org/resource/image/d4/5d/d46d0710af39a5fb02b16cda0ddff85d.png" alt="">
+
+在最终进入大规模批量生产MP阶段之前，服务器的设计需要经历四个阶段，也就是：
+
+- Pre-EVT（Pre-Engineering Validation Test）：预先工程验证测试
+- EVT（Engineering Validation Test）：工程验证测试
+- DVT（Design Validation Test）：设计验证测试
+- PVT（Production Validation Test）：生产验证测试
+
+这之后才是批量生产MP阶段。
+
+每个阶段的目的和任务都有所区别，具体来讲，**Pre-EVT阶段**进行的是比较初级的模块测试，且往往是和硬件供应商一起进行的。这一阶段通过基准测试，**得出基本的模块性能**，为下一步的、更具体的设计提供性能数据。所以，此阶段一般只需要少数几台服务器原型就可以。
+
+第二个阶段是**EVT**，这个阶段是服务器开发的初期设计验证，重点在**考虑服务器设计的完整度是否有遗漏**。这些测试，包括功能和安全规格测试。这时候的服务器是样品，问题可能较多，测试可能会做N次。但是这一阶段需要有一个完整的服务器，会运行更加具体的基准测试，并根据测试结果，来调整服务器设计。一般需要几十台服务器来进行测试。
+
+**DVT阶段**的测试，需要生产厂商把服务器运送到数据中心。到此时，几乎所有的设计已全部完成，重点是找出可能的设计问题，确保所有的设计都符合规格。此时产品基本定型，可以进行负载测试，是为了发现在生产环境中可能出现的问题。这个阶段的测试可能需要用上百台服务器。
+
+**PVT阶段**更加注重生产流程。服务器需要用类似真实的生产线来生产，并且运送到数据中心。这时需要进一步，用更加真实的应用程序来测试。这个阶段一般就要有百台以上甚至千台的服务器了。
+
+**MP阶段**，就是批量生产了。到这个阶段，服务器硬件准备就绪，而且需要使用真实生产流程，来进行大规模生产和应用测试。所有设计及生产问题，应该没有任何遗漏及错误，成为正式面市的产品。
+
+## 服务器设计的机遇在哪？
+
+仅仅知道如何设计一种新服务器还不够，你还需要知道整个业界如今的趋势，才能给出最有性价比的服务器设计。虽然业界会有比如全球DRAM短缺这样的短期波动，但是长期来看，也是有迹可循的，比如摩尔定律的放缓，越来越大的HDD硬盘，新的SSD技术等。
+
+这些变化给我们的服务器设计带来了挑战，但同时也带来了机遇。CPU、内存、硬盘、网络、单处理器等几个方面的变化，不仅仅影响各公司数据中心未来服务器的发展方向，也对公司的软件和服务设计有重大而深远的影响。
+
+### CPU的趋势
+
+从CPU的趋势来看，简单来讲，摩尔定律正在失效，业界对CPU的性能增强，一般是通过添加更多内核来增大吞吐量。对于英特尔和其他CPU厂商（比如ARM）来说，这意味着，每一代处理器将拥有更多的内核，但运行频率一般要低于当前一代的处理器。之所以有这些趋势，归根结底，是因为用于生产芯片的材料所面临的挑战，以及物理方面的基本限制，例如，光子和电子的特性等。
+
+对软件来说，传统上，我们比较看重针对单线程的性能进行优化。鉴于这一硬件趋势的影响，这样的优化策略需要进行调整。无论处理器的体系结构（x86、ARM等）如何，**CPU单位价格的性能和每瓦性能的提升都在逐代地显著放缓**。
+
+所以，我们的性能优化策略，应该着重服务的**水平扩展性**，就是通过多线程和多服务器来扩展服务的总体容量。
+
+### DRAM内存的趋势
+
+DRAM内存的趋势如何呢？在全球市场上，DRAM内存仍然相对稀缺，价格很高。自2017年以来，每GB的价格已翻了一番以上。与影响CPU一样，相同的基本问题和挑战，也影响着DRAM性能和容量的提高。所以，各公司的服务器设计，都开始转向使用尽量少的DRAM内存。
+
+一个好消息是，新型技术比如NVM（非易失性内存）等也在成熟；这就为许多应用，提供了更便宜的DRAM替代品。现在已经有越来越多的服务器设计，开始**考虑使用NVM**。
+
+如果你的互联网服务和程序使用内存较多，并且SSD这样的快速存储还是不能满足服务的要求，除了尽量减少内存使用外，建议你考虑采用NVM。
+
+### 硬盘的趋势
+
+硬盘方面，硬盘的存储容量继续增加，但增速开始降低。这种趋势，是因为硬盘行业面临的材料挑战，以及物理方面的基本限制（例如控制磁场）。
+
+虽然存储容量变大，但是硬盘提供的IO性能，比如每秒随机访问IOPS的性能并没有增加。为了利用这些更大容量的驱动器，我们最好**把硬件和软件设计一体化**。比如，你可以把热数据缓存在闪存或内存中，并将相对较冷的数据存储在旋转硬盘上。
+
+### 网络的趋势
+
+与服务器功耗相比，数据中心的网络流量增长得更快。具体来说，与计算和存储有关的网络功耗不断增长，所以需要使用更快、更多的交换机间的网络链接。
+
+另一方面，新的技术比如硅光子技术，进一步降低了成本，也引发了新一轮的创新和数据中心的网络升级。比如有的数据中心，已经开始使用400G、800G甚至1.6T的高速网络。
+
+但是你要记住，不管网络技术如何发展，还是需要尽量地减少跨数据中心和跨机架的网络流量，也就是**尽量让网络在本地消化掉**。这里的“本地”可以是服务器本身、本机架、本数据大厅、本数据中心等等。为什么呢？还记得我以前说过的“带宽超订”吗（参考[第18讲](https://time.geekbang.org/column/article/185737)），因为越往外走，网络的带宽总是越小。
+
+如何才能尽量让网络流量本地消化呢？这就需要你考察公司内部各种服务之间的数据交互，尽量让有大量数据交换的服务在一起部署（比如部署在同一个机架内）。
+
+### 单处理器的趋势
+
+回到服务器的趋势上，有一个有趣的趋势就是：未来是单处理器的天下。
+
+以前服务器采用多个处理器，是因为每个处理器上的内核数目有限。所以，如果我们希望一台服务器有更多的计算能力，只能采用更多的处理器。
+
+但是现在这种情况也正在改变，我们正进入高度集成的多核CPU时代，也就是一个处理器上面，有几十个内核越来越平常，一个处理器就已经有足够强大的计算能力。比如，随着每一代x86处理器的发布，都会增加更多的内核和功能，性能大大提高。
+
+同时，服务器的内存密度也在增加。现在的单处理器服务器，能够置入的内存大小已经超过了以前服务器支持的内存密度。在很多生产环境中，内存容量和内存带宽，才是主要的性能瓶颈，而不是CPU。因此，在双处理器环境中，CPU使用率往往很低。
+
+综合以上因素，采用单个处理器的服务器，可以降低服务器硬件成本和软件许可证的成本，让各种硬件资源得到更加充分的使用。具体来说，我们在开发大型服务和程序的时候，可以尽量采用模块化的设计，比如分解成几个可以在单个处理器上运行的微服务。
+
+## 总结
+
+我们这一讲，介绍了服务器设计的不同阶段，讨论了工业界这几年的发展趋势，包括CPU、内存、网络、磁盘等不同的服务器资源类型。
+
+<img src="https://static001.geekbang.org/resource/image/8a/a8/8aad912aac2c4f56db93e30046c7b3a8.png" alt="">
+
+这些趋势，对于我们去把握下一代服务器硬件会有帮助。我们开发的互联网服务，总归是要运行在这些服务器上面，了解了这些趋势，我们才能开发出性能优越，能充分利用硬件资源的应用程序和服务。
+
+清朝的赵翼有一首诗说：“李杜诗篇万口传，至今已觉不新鲜。江山代有才人出，各领风骚数百年。”其实服务器的发展，又何尝不是如此呢？服务器的更新换代速度，虽然可能没有软件那么快，但是也是几乎每年都有很大变化的，每种服务器，也是“各领风骚一两年”。
+
+## 思考题
+
+你们公司的服务器有几种？是不是也是按照资源的大小，比如内存和存储的大小来划分的呢？
+
+你如果在公司已经工作几年了，有没有感受到硬件更新换代的特点？如果你在开发程序和互联网服务，想一想怎么设计你的程序和服务才能充分利用这些特点呢？
+
+欢迎你在留言区分享自己的思考，与我和其他同学一起讨论，也欢迎你把文章分享给自己的朋友。

极客时间专栏/性能工程高手课/容量规划与服务效率/31 | 规划部署数据中心要考虑哪些重要因素？.md

@@ -0,0 +1,119 @@
+<audio id="audio" title="31 | 规划部署数据中心要考虑哪些重要因素？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/44/2e/44e31abca21006204f5bd827c35a6d2e.mp3"></audio>
+
+你好，我是庄振运。
+
+上一讲我们讲了服务器的设计和部署，今天我们就来聊聊一个轻松的话题，一起来看看数据中心的秘密。
+
+你们公司肯定有很多服务器。根据公司和服务的规模，可能有几十台甚至几万台服务器，大些的公司甚至会达到几百万台服务器。那么这么多的服务器都放在哪里呢？它们的家，就是数据中心。
+
+你平时可能和服务器打交道比较多，离“数据中心”就比较遥远。但是我可以肯定地说，数据中心的知识，与我们每个IT从业人员（尤其是对于运维和性能工程的人员）是非常相关的。
+
+## 数据中心长什么样？
+
+要讲数据中心，你可能会问数据中心到底长得什么样子？
+
+<img src="https://static001.geekbang.org/resource/image/bb/45/bb828338451afc96bd56694422e25e45.png" alt="">
+
+其实许多科幻片里都会有类似数据中心的场景出现。一个数据中心往往有好几个大楼，每个大楼建筑物内部，都有着很好的空调和通风设施。大楼内一般分成几个数据大厅（Data Hall），每个大厅都有一排排的机架，中间留出足够的通道，方便数据中心的技术人员进行维护。
+
+<img src="https://static001.geekbang.org/resource/image/2b/0e/2b2ebaa87efdadd4f08ea5c2dfd05f0e.png" alt="">
+
+这是机架的背面。你可以看到，机架的布线必须非常整齐，太乱的话，日常中是很难进行维护的。
+
+<img src="https://static001.geekbang.org/resource/image/d5/ae/d580da6eb89261d102f994d8411542ae.png" alt="">
+
+## 数据中心的规划和部署
+
+对一个有全球用户的大互联网公司而言，它的容量通常也需要部署在全球范围内。运行公司各种服务的服务器，就放置在全球的数据中心里面。数据中心的建造成本很高，周期也较长，也有足够的复杂度，所以中小公司，往往会租赁别人的数据中心的空间，来放置自己的服务器，甚至是直接租赁服务器。
+
+但对于大公司，比如Google、Facebook、Amazon、Microsoft、阿里巴巴、腾讯等，它们规模很大，大到不能靠租赁来运营。而且因为规模大，自己建造数据中心，从经济上看更加划算。比如亚马逊，就自己建造了很多数据中心。这些数据中心分布在全球各地，如下图所示。
+
+<img src="https://static001.geekbang.org/resource/image/a8/e7/a8c407cb167bf1bfe8e61f49109dfce7.png" alt="">
+
+之所以要在全球范围内建造数据中心，主要是为了性能，而不是为了节省成本。因为一个服务如果有全球的用户，这些用户就都需要和公司提供的服务快速交互，比如上传照片，播放视频等等。对于在全球范围内运行服务的公司而言，“数据中心离用户距离近”就是唯一的选择。
+
+那么公司需要建多少数据中心呢？这个数量问题是容易解决的，就是**根据公司的规模和实际的需求，并且适当的做一些预测和远景规划**，而这就是我们下一讲会专门讨论的容量规划和预测。
+
+数据中心要建在哪里呢？表面上看，这个问题也容易回答。前面说过，全球建造数据中心的初衷，就是让它们靠近客户，那当然是根据客户的地点来建造数据中心了，哪里有客户就把数据中心建在哪里。
+
+这样的回答，道理上没错，只是考虑得不够全面。数据中心的选址还需要考虑很多因素，比如电力供应的稳定性、自然灾害发生情况、社会稳定性、所在国法律、人力资源、容量供应、建造成本等等。
+
+这些因素都很容易理解，不过有意思的是，“所在国法律”是其中非常重要的一个因素。
+
+一个公司总会存储各种用户数据，而公司是需要保护用户隐私的。但是很多国家的法律要求，建造在本国的数据中心，必须允许本国政府访问这些用户数据。这就与公司应尽的职责构成了冲突。
+
+我们有时候开玩笑说，放眼全球，还真找不到几个国家，能够在该国不用担心警察会突然破门而入，用枪指着头，强迫数据中心员工交出客户的数据。如果考虑诸多这些因素，地球虽大，却也难找到合适的地方建造数据中心。
+
+数据中心建造还有一个特点，就是建造周期很长，从选址、规划，一直到建造完成，最少也需要好几年。所以，为了让一个数据中心能够长时间有效使用，建造一般也会刻意地分期完成。比如假设一个数据中心，最终会建造6个大楼，公司通常会分成3个阶段，一次建造两个大楼。
+
+## 数据中心内服务器的生命周期
+
+我们上一讲讨论了服务器的设计。一种服务器设计完成后，公司就可以部署了，你也需要对这个部署过程有个了解。对于一台服务器，它的生命周期经过4个阶段，包括购买和运送、按服务分配、运行管理、最终退休。
+
+**购买和运送**
+
+公司给了预算并且确定数据中心有了放置的空间和计划，就可以订购服务器了。服务器一般都是按照机架的单位批量购买。之所以要提前做好购买计划，是因为从购买到运送，一般需要几个月的时间。
+
+**服务分配**
+
+服务器放置在预定义的机架位置后，需要给它们通电。通电后，机架会自动在资产跟踪系统中注册。然后预配操作将安装操作系统以及许多其他软件。新服务器安装完成后，一般是放到备用池等待分配。服务所有者会提出申请服务器的要求，然后负责分配的团队，按照要求将容量分配给他们。
+
+**运行管理**
+
+在服务器的整个生命周期中，服务器和机架可能都需要进行维护。维护可能需要置换有故障的磁盘、更换坏的主板、重新启动服务器、重新安装/升级/修补操作系统、运行修复软件、诊断软件等。
+
+我们通常的服务器设计，实际上已经考虑到了很多可能的维护工作。例如，既然换出磁盘是常见的修复任务，那么服务器设计可以让更换磁盘非常容易，无需任何工具比如螺丝刀等。
+
+**光荣退休**
+
+机架和服务器在数据中心的使用寿命是多久呢？通常约为3-4年。之后，我们需要让它光荣退休，将其从数据中心中移除，擦除所有数据，切碎磁盘，并遵循所有硬件的报废流程。
+
+为什么需要让服务器及时退休？因为当超过使用寿命时，它们的组件就容易发生故障。在处理维修单和更换这些组件方面，会给数据中心的技术人员带来负担。同样，各个组件的保修期也可能快过期，甚至可能因为技术的发展，置换部件已经很难买到了。更重要的是，新的服务器替换旧的，也可以提高性能和效率，比如每一代的CPU都会比上一代更加强大。
+
+## Facebook数据中心的网络部署
+
+讲完了数据中心的架构和服务器的生命周期，我们再看看数据中心的网络部署。
+
+数据中心内部的服务器之间，以及用户和服务器之间有大量的数据交换，这些对数据中心的网络部署也提出了很高的要求。为了能够更好地扩展，现代数据中心的网络设置也在不断地演化。下面我就用Facebook来举例，看看现代数据中心的情况。
+
+Facebook的生产网络本身，就是一个大型分布式系统，包括边缘网络、骨干网和数据中心内部网络。Facebook的网络基础架构也在不断扩展。从Facebook到Internet的流量，我们称其为“**机器到用户**”的流量，非常庞大，并且还在不断增加。但是，这种流量，相对于数据中心内部发生的“**机器到机器**”流量，就只是冰山一角了，后者是前者的百倍以上。而且这种流量的增长速度，几乎每年都增长一倍。由此，我们也可以看出数据中心内部网络的重要性。
+
+我们公司以前的数据中心网络，是使用集群Cluster构建的。集群是一个大型部署单元，涉及数百个服务器机柜，这些机柜的顶部（TOR）交换机，聚集在一组大型的交换机上。但是这种以集群为中心的体系结构有很大的局限性。
+
+所以我们的新一代数据中心网络设计，就不是基于集群的，也就是说，不是按层次分配的集群系统。我们将网络分解为多个小的相同单元，也就是服务器Pod，而不是大型集群，并在数据中心的所有Pod之间，创建了统一的高性能网络连接。
+
+这里的Pod，只是我们新架构中的标准“**网络单元**”。每个Pod，由一组称为设备交换器的四个设备提供服务，从而可以根据需要进行扩展。当前的多数机架顶部交换机具有4个40G上行链路，为被连接的服务器提供160G的总带宽容量。下图就展示了一个Pod和48个机架的网络连接。
+
+<img src="https://static001.geekbang.org/resource/image/47/06/471217886c8df796e77ead47ee6ef306.png" alt="">
+
+每个Pod的大小都一样，都是48个机柜，所以只需要基本的中型交换机就可以支持。对于机柜交换机的每个下行链路端口，我们在Pod的交换矩阵交换机上，保留相同数量的上行链路容量，这使我们能够**将网络性能扩展到在统计上无阻塞的水平**。
+
+为了实现大楼范围的连通性，我们数据中心内部，创建了四个独立的骨干交换机“平面”，每个平面，可以最多扩展48个独立设备。
+
+每个Pod的各个交换矩阵，都连接到其本地平面内的主干交换机，共同构成一个模块化的网络拓扑，能够容纳成千上万个连接10G的服务器。如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/ad/6b/add2ab671fbbbae972439e8510eb076b.png" alt="">
+
+对于外部连接，我们用光纤网络配备了数量灵活的**边缘Pod**。每个边缘Pod，能够为骨干网和数据中心站点上的后端提供很多Tbps的带宽，并且可扩展到100G和更高的端口速度。
+
+这种高度模块化的设计，使我们能够在一个简单统一的框架内，快速扩展任何维度的容量。
+
+当我们需要更多计算能力时，就简单地添加服务器Pod。当我们需要更多的内部网络容量时，就可以在所有平面上添加骨干交换机。当我们需要更多的连接时，我们可以在现有边缘交换机上添加边缘Pod，或扩展上行链路。
+
+## 总结
+
+我们今天讨论了数据中心这个重要的容量载体，它的内部结构、网络设置、服务器的生命周期，以及规划数据中心的一些考虑因素。
+
+<img src="https://static001.geekbang.org/resource/image/1c/58/1c392088ad67ec3085616c50f4e59958.png" alt="">
+
+数据中心可以说是服务器的“家”，也是我们的程序最终部署的地方。唐代诗人王建说：“今夜月明人尽望，不知秋思落谁家。”我们开发程序和部署服务，最好要了解数据中心的知识和架构，因为各种互联网服务，总归是需要数据中心的服务器和网络来支撑的。了解数据中心的配置，对我们服务的开发和部署是很有用的。
+
+对一些大规模的服务，数据中心的网络或者服务器资源，可能会成为性能和业务发展的瓶颈，所以我们也需要不断优化，并提前规划数据中心。尤其是现在的互联网服务，往往有很大的数据量，所以数据中心网络的扩展性尤其重要。
+
+## 思考题
+
+你们公司的服务器一定也在数据中心里，这些数据中心的地理位置在哪里？地理因素对你的互联网服务的性能比如端到端延迟有什么影响？
+
+你们公司用的数据中心是自己建造的还是租赁的？公司对数据中心的运营成本有什么要求和策略？
+
+欢迎你在留言区分享自己的思考，与我和其他同学一起讨论，也欢迎你把文章分享给自己的朋友。

极客时间专栏/性能工程高手课/容量规划与服务效率/32 | 服务的容量规划：怎样才能做到有备无患？.md

@@ -0,0 +1,131 @@
+<audio id="audio" title="32 | 服务的容量规划：怎样才能做到有备无患？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b0/a7/b0f7b0e0cc86e9ce89d547abcce9e8a7.mp3"></audio>
+
+你好，我是庄振运。
+
+今天我们来讨论一下在公司运营方面很重要的**容量规划**。容量规划，就是根据互联网服务的需求和公司发展目标，而决定容量的供应能力的过程。
+
+光说概念你可能不太明白，不过你可以这么理解，容量规划是为了回答一系列和公司业务运营有关的重要问题而产生的：
+
+- 单台服务器的最大处理能力是多少？
+- 未来半年公司还会有多少可用容量？
+- 春节前如果要进行一次大促，当前的容量能不能支撑？
+- ……
+
+今天我先讲容量规划的目标和基本过程，然后再一个一个地讲容量规划的六大挑战。
+
+我们前面也大概提到过，容量规划的目的有两方面。一方面是为了保证公司的正常运营和业务增长，及时地提供足够的容量，来满足未来所需。另一方面，也是希望空闲的容量越少越好，因为每一台空闲的服务器，都消耗公司的运营成本。
+
+现代的互联网服务规模的扩展，主要是用“水平扩展”而不是“垂直扩展”（通过增加服务器的数量和网络的带宽来提供更多的容量，而不是通过升级服务器）。相对于垂直扩展，水平扩展的优点显而易见，就是成本相对较低、调整容易、扩展性好。
+
+## 怎么做容量规划？
+
+整个容量规划的过程分为几部分：首先是容量测试来决定单位容量的负载能力；同时确定公司的业务增长需求，并且获取公司的运营预算。然后集成其他的考虑因素（包括时间、地域、灾难恢复等），做出合理的规划和决策。最后根据决策结果，进行容量订购。
+
+为了方便把握，我把这几个因素模块整合在一起，如下图所示，我们一个模块一个模块地讲。
+
+<img src="https://static001.geekbang.org/resource/image/ce/60/ce9ee8a71387400727ec1b1b0abeff60.png" alt="">
+
+### 容量测试决定单位容量的能力
+
+容量测试可以决定单位容量的能力。容量规划的基础，就是确定单位容量，比如一台服务器系统的处理能力。而进行容量测试，一般是让服务器处于最大负载状态，或某项性能指标达到所能接受的最大阈值下，对请求的最大处理能力。
+
+容量测试是性能测试里的一种测试方法，它的目的就是**测量系统的最大容量**，为系统扩容、性能优化提供参考，从而达到节省成本投入，提高资源利用率的目的。
+
+容量测试大致分为两种：线上测试和线下测试。我们在[第25讲](https://time.geekbang.org/column/article/191598)专门讲了线上测试，这里快速地复习一下。线上测试相对比较准确，因为是用真实的生产流量负载。线下测试，则比较容易进行。但是你要特别注意测试过程和结果的代表性，就是它能否真实客观地反映生产环境中的数据。尤其是测试环境的配置和驱动数据，一定要和线上的生产环境尽量保持一致。
+
+### 预测未来需要的容量需求
+
+要做好容量规划，除了单位容量的处理能力，另外一个必须要知道的输入，是服务和业务的需求。通俗点说，就是期望达到的用户数和数据流量大小。比如一个前端服务，要决定明年的容量需求，就需要确定明年的预期用户数目。
+
+对于未来的容量需求的预测，主要是参考历史的相关数据，然后建立合适的模型。比如我们在[第26讲](https://time.geekbang.org/column/article/192316)提到的针对时间序列的ARIMA模型，就是一个不错的模型。如果针对的业务已经有足够长的历史，那么过去的数据就很值得参考。
+
+反之，如果一个业务还没有上线，或者上线时间很短，那么历史数据就不是很可靠。如果你面对的是这种情况，有两种解决方法：一是可以类比其他相似的服务，不管是公司内部的还是业界的，都可以拿来参考。二是需要借助一些主观的推测。当然这种主观推测也不能凭空乱猜，而是要有理有据。
+
+容量规划时，公司的业务运营预算也要考虑进去。一个正常运行的公司，运营成本总是有限的（每个业务都有预算定额）。如果对一个业务预期的容量需求，超过已经设定的预算定额，那么，你要么是把容量需求降低到预算定额，要么就得向公司申请增加预算。
+
+### 考虑各种限制因素和挑战
+
+另外还有一点要注意的是，未来容量的需求预测总会和实际情况有差距，也就是说，总是有不确定的因素。
+
+所以，我们一般会根据估计的信心指数，对预测结果做几种不同的预测。比如90%的信心和50%的信心。这里信心指数越大，容量数值也越大，就是说越有把握满足需求。举个例子，比如我们要估计明年一个服务的容量需求，可能得出结论：
+
+- 如果只需要保证50%的信心，1000台服务器就够了；
+- 要保证90%的信心，则需要1200台服务器。
+
+但是，无论我们多么努力地去预测，总有些因素没有考虑到，从而导致实际情况和预测不吻合。所以，我们一般都要对容量的需求预测加上一个冗余Buffer，我个人的经验是10%的Buffer。比如我们的模型预计需要1000台服务器，那就加上100台的Buffer，也就是需要1100台服务器。
+
+### 及时和实时地调整
+
+也正因为容量的规划和使用过程中，有很多的不确定因素，随着时间的推移，这些不确定因素慢慢就会变成确定的因素。比如，在一个服务还没有上线的时候，做容量规划非常困难，因为不能准确地预测用户数量。但是随着服务的上线，开始积累用户量，对未来用户数量的预测就会变得越来越容易。
+
+所以，容量的预测和规划，也是一个持续和不断迭代的过程。开始的时候靠模型，靠历史数据和一些直觉来做大体预测。然后，定期地和实际的数据做对比，从而调整和纠正以前的预测。
+
+## 容量规划的挑战在哪？
+
+容量规划和预测时，除了前面讲的步骤和因素外，还有其他几个限制因素和挑战值得考虑。我总结了六个这样的挑战，包括地域的限制、服务器种类的区分、时间和季节性等等。
+
+### 容量规划不仅仅是钱的问题
+
+第一个挑战就是，容量规划不仅仅是钱的问题。你可能听说过：“能用钱解决的问题，都不是问题。”
+
+但容量的供应问题，很多时候还真不是砸钱就能解决。
+
+为什么有时候钱不能解决容量问题呢？如果公司的运营规模很大的话，需要的容量供应也就很大。在很多情况下，市场上能够找到的数据中心很有限，所以即使公司愿意投入很多资金，也不一定就能在需要的地点和需要的时间租赁到足够的容量。
+
+有的公司自己建造数据中心，那就面临更多新的的问题和挑战，尤其是时间方面。建立数据中心的交货时间至少是两、三年。数据中心建造和扩建，需要寻找可用的建筑商和建筑工人，但是找到足够的合格建筑商和工人并非易事。因此，数据中心的建设并不像把钱扔在问题上那么简单，需要提前很久就规划和考虑，要未雨绸缪。
+
+### 数据中心的地域因素
+
+第二个挑战是地域因素。当公司的业务需要部署服务器在多个数据中心时，每个数据中心都需要做相应的容量规划。也就是说，仅仅只有预测和规划一个总体的容量是不够的，还需要具体到每个数据中心的内部。
+
+数据中心往往分布在不同的地域，它们内部的服务器，并不能在数据中心之间随意置换。为什么呢？因为我们的业务也要求服务器尽量地离客户近些，从而降低网络延迟，提高带宽和可靠性。像Facebook、Google、腾讯、阿里这样的公司尤其是如此，它们往往在全球有很多数据中心，而且用户的规模很大，如果容量规划做不到数据中心这个层次，是肯定不行的。
+
+### 服务器种类的因素
+
+下一个挑战是服务器种类的挑战。公司往往会有不同种类的服务器，以便针对特定类型的工作负载进行量身定制。例如，有专门针对内存密集型工作负载的大内存服务器。当有多种服务器可选的时候，容量规划就需要选择最合适、最经济的服务器类型，这样可以降低成本并改善服务质量。
+
+对于一种具体的服务器而言，它的性能也是随着时间的推进不断改善的。比如一种计算密集型的服务器，虽然基本的机架设计不会改变，但是服务器使用的CPU还是会一直更新换代的，一般每年都会有新的CPU型号。
+
+所以，在做容量规划时，也要把这个因素考虑在内。比如要支撑一个服务，如果用现在的CPU型号预测，明年需要一千台服务器。可是同时明年的CPU会升级，性能提高了10%。那么考虑到这点，可能只要900台服务器就够了。
+
+### 时间和季节的因素
+
+容量规划也要充分考虑时间和季节的因素。在[第26讲](https://time.geekbang.org/column/article/192316)里，我们一起看过正常生产环境的负载变化。对大多数互联网服务来讲，在一天内，每天的上午上班时间的负载较大；在一周内，工作日的业务负载比较大。同时，当经历节日时，比如春节、国庆等，也要注意流量的预期变化。
+
+对于面向普通用户的社交网站，比如Facebook，每当新年、圣诞节时候，有些业务的用户使用量会好几倍的增长。这些业务包括照片和视频上传，朋友分享等。所以我们的容量规划过程会充分考虑到这些时间的业务需求，提前部署足够的容量来迎接这些峰值的服务流量。
+
+### 不同的灾难恢复场景
+
+还有，为了保证业务的可靠性，灾难恢复（DR，Disaster Recover）场景是必须考虑的。
+
+灾难恢复准备，意味着公司的容量可以容忍某个容量单位的损失。互联网服务其实有很多种不同的DR场景，最常见的是数据中心的DR，也就是说，假如一个数据中心因为天灾人祸的原因完全不能访问，其余的容量如何支撑整个互联网服务的正常运作。
+
+灾难怎样影响服务性能呢？损失的容量单位，会导致其他容量单位的负载增加。负载的增加量，取决于丢失单位在整个容量系统中的比例。具体来说，假设丢失的容量单位，平时承担的负载百分比为x％，那么在丢失该容量单位之后，所有其他单位的流量将增加[1 /（1-x％）-1] * 100％。
+
+为了帮助你理解，我先举个简单例子。假设一个服务有两个数据中心支持，这两个数据中心大小是同样的，都分别承担50%的服务流量。那么，如果一个数据中心不能用了，另外的数据中心就需要承担2倍的服务流量，也就是1/（1-50%）=2。
+
+再举个稍微复杂的例子。考虑以下情形，其中A、B、C的三个容量单位分别占流量的40％、40％和20％。如果单位A丢失，那么单位B和C的流量将增加1 /（1-0.4）-1 = 67％。如果C单位丢失，则A和B单位的流量将增加1 /（1-0.2）-1 = 25％。
+
+### 不同服务之间的互相影响
+
+最后，互联网公司的业务，往往会分解成很多的服务。面对外部客户的是前端服务；还有很多后端和内部的服务来支撑前端服务。所以，如果前端服务的负载有变化，后端服务也会受到影响。要预测后端服务的容量需求，也必须充分考虑前端服务，以及其他上下游服务的影响。
+
+一般来讲，每层服务调用都会有一定的负载均衡机制，在规划每层服务的容量需求，以及每层服务的不同容量单元的容量需求时，就要了解这些负载均衡机制，从而确定相关因子。比如，如果前端服务负载增加100％，则下游服务预计会增加多少负载？如果某个下游服务的负载增加也是100％，则相关因子为1。
+
+每个服务的总体负载确定后，还要考虑具体到这个服务在不同数据中心的分配，也就是需要确定每个数据中心分别分配多少。
+
+## 总结
+
+我们今天讨论了容量规划的过程和需要注意的地方。容量规划这个工作非常重要，正如清朝人陈澹然讲的：“不谋万世者，不足谋一时；不谋全局者，不足谋一域”。如果规划做不好，公司业务一定会受到严重的影响。要不就是没有容量可用，要不就是容量太多造成浪费。
+
+<img src="https://static001.geekbang.org/resource/image/42/5f/424a7025a0cfcc5b8113939f1efd6e5f.png" alt="">
+
+容量规划的工作并不好做，你从我说的几大挑战就看得出。所以需要对公司的业务特点和服务架构非常熟悉，并不断及时地调整，才能尽可能地达到预定的目标。
+
+## 思考题
+
+你们公司或者你的部门的业务，需要什么样的容量来支持呢？比如何种服务器？
+
+对于容量规划，你们部门对未来半年甚至一年的容量要求是多少？是哪个部门帮你们做容量规划，他们是怎样确保容量规划的准确性呢？
+
+欢迎你在留言区分享自己的思考，与我和其他同学一起讨论，也欢迎你把文章分享给自己的朋友。

极客时间专栏/性能工程高手课/容量规划与服务效率/33 | 服务效率提升：如何降低公司运营成本？.md

@@ -0,0 +1,147 @@
+<audio id="audio" title="33 | 服务效率提升：如何降低公司运营成本？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a7/2c/a7ad766716b6f65f29b7ef13b6f0422c.mp3"></audio>
+
+你好，我是庄振运。
+
+我们都知道，支持大量用户的互联网公司，通常会部署相当规模的系统容量来运行各种服务。
+
+如果你想要有效地运行业务，就应使业务的**容量需求**和**容量供应**尽可能地相等。为什么这么说呢？如果容量供应不能满足需求，那么部分业务将​​因容量不足，不能部署或扩展。如果容量供应过多，那么公司基础设施的效率就降低了。
+
+服务效率与业务的容量和公司预算直接相关。因此，**提高服务效率**和**适当地预测容量需求**，对于公司的持续成功至关重要。
+
+那么如何才能降低公司的服务容量需求呢？这就需要**运行的服务尽量高效**，提高服务效率将会帮助降低容量的需求。
+
+今天我就为你介绍八种提升服务效率的途径和相关的生产经验，以及提升执行服务效率的原则，希望对你有所启发。
+
+## 服务效率提升的途径和类别
+
+当各个服务团队的领导和技术骨干下定决心，要花时间在服务效率的时候，经常提出的问题是：怎么样做才能提高服务效率呢？
+
+要回答这个问题，你就必须先搞清楚一个问题，就是——什么类型的工作才是提升服务效率的工作？
+
+我多年来帮助很多不同的服务提升了服务效率；在这个过程中我逐渐意识到，一个公司的服务千差万别，可以提升效率的方式也是多种多样。但核心的一点是：任何能够让这个服务降低容量需求的工作，都是服务效率提升的工作。
+
+我把各种各样的服务效率提升工作分为八类：软件效率（Software Efficiency）、服务架构效率（Service Architecture Efficiency）、服务部署效率（Service Deployment Efficiency）、跨平台效率（Cross-platform Efficiency）、硬件效率（Hardware Efficiency）、容量组织效率（Capacity Orgnization Efficiency）、容量资源回收（Capacity Resource Reclamation）、用户效率（User Efficiency）等。
+
+这八种效率大体上分为两组：**软件服务**和**非软件容量**。
+
+<img src="https://static001.geekbang.org/resource/image/5f/e4/5fc0143c23b5a34e8742e761ec547ee4.png" alt="">
+
+对每一种服务效率，我先讲基本概念，然后再用具体例子来诠释，希望可以给你些启发。
+
+### 1.软件效率
+
+服务的软件程序实现千差万别，但不管哪种实现，它总是可以优化的，比如通过采用更好的数据结构和语言库等等。这方面的效率提升，都可以归类为软件效率。
+
+软件方面的效率提升比较直白，就是把程序的性能提高。比如减少CPU和内存的使用等等；这方面我们这个专栏前面讲了很多，多数内容都可以归到这方面。
+
+### 2.服务架构效率
+
+对一种服务而言，如果能够改进服务的实现架构，比如重新整合了内部的微服务，从而变得更高效，那么就是服务架构的效率提升。
+
+服务架构的效率又可以分为两种：一种是单独的一个服务，通过进行服务设计的优化来提高效率；另外一种就是通过合理借助其他服务来优化。
+
+比如一个数据库服务，如果有很多的查询请求，那么采用另外一个缓存服务，就或许可以大幅度地降低数据库服务的资源消耗。如果两个服务（数据库和缓存）的资源使用总和，还是小于仅仅使用数据库（而没有缓存服务）的资源使用，那么这两种服务的结合就是一种更加高效的服务架构。
+
+### 3.服务部署效率
+
+一个服务的软件程序总是要部署到硬件容量上。生产实践中，如何部署软件也很重要，也会对服务效率产生影响。比如采用什么操作系统，进行什么样的系统和软件配置，要不要采用NUMA绑定等。这些方面的优化都可以算是服务部署方面的效率提升。
+
+还记得我们在[第22讲](https://time.geekbang.org/column/article/189200)讲过的“使用内存大页面，来装载程序的热文本区域”吗？这其实就是一项服务部署的优化，就是通过提高系统和程序iTLB命中率，从而达到更高的服务效率。
+
+### 4.跨平台效率
+
+如果一个公司（尤其是后端）同时提供几种服务平台，提供的功能有重合，而且服务效率不同，那么用户可以迁移到效率更高的服务上去。这种迁移就是跨平台效率提升。
+
+一个互联网公司，随着时间的推移和规模的增长，内部往往有很多种服务提供重叠的功能。一个明显的例子是数据存储，经常有很多服务都可以提供数据存储的功能。虽然每种存储服务提供的功能并不完全一样，但对于一个要使用存储服务的用户来说，经常同时会有好几个选择。
+
+这种情况下，这个需要存储的用户，就可以考虑每种存储服务的服务效率；在满足所需功能的前提下，选择一种高效的服务，会帮助公司降低成本。
+
+对于一个已经在使用某种服务的用户而言，可以重新考虑各种可用服务的效率；如果另外一种服务更加高效，就可以考虑迁移过去。这种操作就是**跨平台的迁移**，其结果也是能够提升公司的服务效率的。
+
+我最近几年做过很多这方面的优化。比如曾经把一个用户的数据从一个低效的存储服务，整体转移到另外一个高效的存储服务，从而大幅度地降低了公司的容量和运营成本，节省了大约几千万美元。重要的是，用户的端到端性能并没有收到影响。
+
+### 5.硬件效率
+
+一个服务会使用各种容量资源（比如CPU）。所以，根据资源使用最大瓶颈的不同，采用不同种的服务器硬件，也会导致不同的服务效率。比如，假设一个服务的存储是最大瓶颈时，那么采用相对较大存储的服务器，结果就会比较高效。
+
+我就提升过一个存储服务的硬件效率。该服务受到存储空间的限制，并且近年来增长迅速。我评估后得出的结论是，如果这个服务继续快速地增长，公司很快就没有足够的容量来提供给它。
+
+所以我们决定，通过提升服务效率来减少服务的容量需求。在检查了所有效率提升的方式后，我决定首先提升硬件效率。 具体来说，我们采用了一种新型服务器，这种服务器相对旧的服务器而言，有较大存储容量，并逐步部署。
+
+下图分别显示了服务的容量规模（也就是服务器的数目），和已部署的总存储容量。
+
+<img src="https://static001.geekbang.org/resource/image/38/05/3897e6d4f7862781ec80e4b26e281905.png" alt="">
+
+<img src="https://static001.geekbang.org/resource/image/7d/2e/7de61e4513c9eb1891493af8647d312e.png" alt="">
+
+在20天的时间内，我们将服务迁移到新的硬件类型，服务器的数目减少了5％，而存储容量增加了11％。值得一提的是，新旧服务器的单位服务器成本差别不大，所以整个服务的效率得到了很好的提升。
+
+### 6.容量组织效率
+
+一个互联网服务在使用数据中心提供的容量时候，一般都是用某种方式把容量（比如服务器）组织在一起，形成一个容量单位。比如把服务器分组、组成集群等。这种容量组织的方式，也可以根据服务的特点，进行调整优化，从而变得更高效，这就是容量组织效率。
+
+一个规模很大的服务可能会需要很多容量。我曾经合作的一个后台服务，就使用了几十万台服务器。这么多服务器经常会分成几个容量单元，这样做当然有利有弊，但都是经过各种考虑的决定。有时候服务容量的分割也有历史的原因，比如一开始使用一个容量单元，但是随着服务的规模不断扩大，就建立了一个又一个的容量单元。
+
+分成几个容量单元的一个好处，是降低了容量操作的复杂度。不过也有坏处，其中之一就是资源效率使用率不会特别高，因为不同容量之间的资源不能互补。比如两个容量单元，每个有一千台服务器。一个容量单元是CPU吃紧，另外一个容量单元是内存吃紧。如果二者合并成一个容量单元，或许只需要一千五百台服务器就够了。
+
+所以适度地优化容量组织，合并容量单元，就可以降低容量的需求，提高容量的效率。
+
+### 7.容量资源回收
+
+一个服务所使用的容量，随着时间的变化，有些容量（比如一些服务器）就会处于空闲状态。如果及时回收，从而进行容量的再利用，也可以提升服务效率。
+
+一个服务从诞生到成熟，会不断地演化；表现在对容量的需求方面，也是不断变化的。可能有一段时期，部署的容量恰好满足服务的需求，容量的效率很高。但是过一段时间，服务的需求和资源使用特征发送了变化，有些容量和相对应的资源使用不再使用。这种情况下就需要进行容量和资源回收。
+
+这方面一个最直白的表现，就是可能有些容量处在空闲状态。举几个例子，假如有些服务器已经不能运行此种服务了，那么就把这些服务器回收，给其他合适的服务用。又假如一个服务对存储资源的使用下降了，那么对应的存储资源就可以减少，分给别的服务用。
+
+### 8.用户效率
+
+使用服务的用户，如果采用合理的方式，也可以帮助提升所使用服务的效率。这方面的效率提升就是用户效率。
+
+用户在使用服务时，可以尽量做到高效使用。我们曾经帮助一个存储服务提升效率，通过和客户合作，大幅度降低了客户的存储数据量。具体来说，这个客户以前是将数据对象的本来数据和一大堆元数据，都放到了存储服务上，这导致了相当大的物理数据存储。
+
+我们是怎么提高用户效率的呢？我们首先分析了客户的业务逻辑和数据使用场景，意识到客户存储的目的，是判断数据对象是否已经更改。我们先将存储的数据分为两部分，然后分别存储对象的哈希（例如MD5），而不是对象本身。另外，我们把数据的TTL（生存时间）缩短，并在对象哈希中定期强制清除陈旧数据。
+
+这样的优化工作取得了很好的效果，节省了93％的存储空间。具体来说，把客户数据大小从2.7PB，降到了0.2PB，如下图所示。
+
+<img src="https://static001.geekbang.org/resource/image/55/40/555309613ae7557ddc09718e23a5bf40.png" alt="">
+
+## 执行服务效率提升的原则
+
+除了前面说过的八类服务效率提升方法，在提高服务效率的生产实践中，我也获得了许多执行方面的经验。这些经验对于如何在部门之间协调，有效地执行效率提升，完成预定的效率提升目标等方面，有比较好的指导作用，希望能对你有所帮助。
+
+1.明确的所有权和承诺。
+
+根据公司的规模，公司可能会有许多需要提高效率的服务。对于每个这样的服务，每个效率提升工作都需要有明确的拥有者团队，并且需要得到团队的工作承诺。如果不能明确所有者，或者所有者不能承诺完成的时间，那么最后经常会互相扯皮，互相指责，工作失败。
+
+2.以效率目标为导向的计划和执行。
+
+对于每个服务及其效率组件，要定期设定要实现的效率目标。例如，针对存储服务的效率目标可以是：“将明年的存储空间利用率从30％提高到40％”。但是注意，目标设定的频率和大小，必须适应服务的特征和团队的工作特点。
+
+3.为每个效率组件部署检测工具。
+
+你需要开发一定的工具，来监视整个服务和每个组件的效率水平，以便快速检测到异常。对于异常的效率降低，这些工具必须有自动触发或警报功能。有效的工具，能帮助你及时发现问题，并立即采取行动。
+
+4.紧密的跨团队协作。
+
+鉴于当今业务和服务的复杂性，许多服务效率的提高，都需要多个团队共同合作。例如，某个服务可能依赖其他服务，并且该服务的效率提高，也可能需要所依赖服务团队的协作。
+
+5.公司范围内的协调。
+
+尽管每个主要的独立服务，都可以通过采用我们提出的框架来独立工作，但也需要在公司范围内进行协调，因为公司需要保证总体业务的需求。
+
+## 总结
+
+互联网公司业务复杂，规模庞大，需要有大量的基础设施和容量去支撑。我们这一讲讨论了如何提升服务效率，降低容量需求，从而节省公司成本。
+
+<img src="https://static001.geekbang.org/resource/image/c3/35/c3e45332a08bcd75e5963ed5aec1e535.png" alt="">
+
+通常一个互联网服务的规模是不断增长的。开始的时候，或许你不在乎它的服务效率和系统容量，但是很快你就需要重视了。所以，你最好未雨绸缪，把相关工作定义好。正如唐朝诗人杜荀鹤的一首《小松》，有两句说：“时人不识凌云木，直待凌云始道高。”如果公司业务发展快，它的服务规模增长也很快，那么服务效率提升的工作就会越发重要。
+
+我通过多年的容量规划和服务效率提升工作，积累了大量的服务效率优化的知识，今天的分享，希望能帮你开拓思路，提供经验。
+
+## 思考题
+
+提升一个互联网服务的效率有很多种方式，其中一个是服务软件的效率。我们前面几讲提到了很多性能优化的工作。你能举出几个可以归类于软件效率提升的例子吗？ 提示一下，优化代码算不算是提升服务软件的效率？
+
+欢迎你在留言区分享自己的思考，与我和其他同学一起讨论，也欢迎你把文章分享给自己的朋友。

极客时间专栏/性能工程高手课/容量规划与服务效率/34 | 服务需求控制管理：每种需求都是必需的吗？.md

@@ -0,0 +1,143 @@
+<audio id="audio" title="34 | 服务需求控制管理：每种需求都是必需的吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/30/94/30e50e5429e2c5abdcf5fccd4a784d94.mp3"></audio>
+
+你好，我是庄振运。
+
+上一讲，我们探讨了如何通过提高互联网服务的效率，降低对公司服务容量的要求。今天我们讨论另一个有效手段——互联网服务的内部需求控制管理。
+
+互联网公司内部，往往有很多后端服务，比如Key-Value，也就是键值数据库服务。公司内部对这些后端服务，会有很多使用的需求。需求自然有合理的，也有不是很合理的。我们要做的，就是确保那些合理的需求，能够使用这些后端服务，并且将那些不合理的需求，尽量挡回去，或者，让提出需求的内部客户提高容量使用效率。
+
+你不要小看了互联网服务的需求管理，它对保证容量供给和服务质量很重要。因为公司给一个服务的容量总是有限的，如果不能控制需求，那么有限的容量很快就会被用光，从而影响公司的正常运行。
+
+今天我先讲讲服务需求控制管理的总体目标，然后分享一整套大规模需求控制管理的方法给你。这套方法是我在多年实践中总结出来的，实践证明它是行之有效的。
+
+## 为什么要做服务需求控制？
+
+想做好大规模需求控制的管理，你就需要先宏观地弄清楚服务需求控制的目标。
+
+一个公司要想成功、有效地运行互联网业务，它就应该尽量让各个内部服务的容量需求和供应尽可能接近。
+
+<img src="https://static001.geekbang.org/resource/image/cc/e0/cce79df848392a1b392e40a50ec85ce0.png" alt="">
+
+如上图所示，左边是公司业务增长，导致容量需求越来越大；右边是公司预算成本有限，容量供应有限。
+
+我们总是希望这两者能够匹配，越接近越好。如果容量供应不能满足服务需求，那么会导致部分业务的发展受到阻碍。如果容量供应过量，就会有闲置容量，造成浪费，从而降低公司基础架构的效率。
+
+要降低容量需求有两种方法，一种就是[第33讲](https://time.geekbang.org/column/article/196699)我们谈过的**提高服务效率**，另外一种就是这一讲要说的**控制需求**。这二者最好互相配合，共同努力。
+
+## 需求控制管理难在哪里？
+
+现在我们就来看看需求控制管理要怎么做。不过，要理解这套方法为什么是这样的，又为什么可以说它是“行之有效”的，你需要先了解做需求控制有哪些挑战。我总结一下，主要有下面几个方面的挑战：
+
+一是很多公司，尤其是大公司，**服务的规模会越来越大**。这个规模表现在很多方面，包括服务数量很多，使用服务的客户也很多。注意这里的客户不仅仅是外部客户，更是内部客户。这就要求我们的工作不能仅靠一个人或者一个团队，必须是分布式的。
+
+二是服务的内部**客户的容量使用情况很不一样**。有的客户对容量使用量很小，增长也不快；有的使用量就很大，或者飞速增长。这就要求我们，在宏观上需要对客户的使用设置一定的配额，否则一个服务的容量，一旦被某些客户用光，其他客户的性能就会非常差。
+
+三是内部**客户的资源使用可能不稳定**。客户使用的不稳定，会导致特别大的峰值出现，对服务的稳定性造成影响。所以，我们必须在微观上，实时监测客户的资源使用情况，一旦发现超出期望的效率衰退，就需要及时通知客户，让他们尽快解决。
+
+四是**停止服务的代价高**。一个内部客户一旦开始使用一个服务，就很难让人家离开。所以必须严把入口关，不要随意地让服务上马。
+
+五是资源使用效率的提升，必须**要经常与用户沟通**，和用户一起不断地提高使用效率，同时也需要开发一些工具来帮助用户。
+
+## 需求控制框架如何构成？
+
+我把整个需求控制的框架按照逻辑，分成了五大模块。如下图所示，我们一个一个地来展开阐述。
+
+<img src="https://static001.geekbang.org/resource/image/b8/db/b87fdd22bda5fc7de9045f35461c98db.png" alt="">
+
+### 服务入口控制：需求审核
+
+第一个模块是服务入口控制。一个服务的需求在开始使用服务之前，必须进行上马前的审核。这个审核，需要统筹考虑需求优先级、和什么产品相关、对公司业务的影响、需求量的大小和轻重缓急、是不是已经计划好的等很多因素。
+
+每个服务需求的请求，要求以任务的形式进行，审核人员要定期的处理这些任务。为了帮助审核人员做出适当的决定，请求者最好提供足够的信息。一般来说，按照刚刚提到的几个方面来准备就可以，越详细越好。
+
+出于平衡利益的考量，审核人员的组成十分多样，至少要包括服务开发团队、运维团队，以及提供容量的团队。为什么这样设置呢？给你举个例子，服务的开发团队，可能希望服务的内部客户越多越好，因为客户多的话，这个服务就变得越来越重要。服务的运维团队，可能更关心服务和系统的稳定性，不要出现各种性能和可靠性问题。而提供容量的团队为了保证容量供应，可能不希望用户有太多的需求。
+
+经过审核后，每个请求会产生几种不同的结果：或批准，或拒绝，或需要客户提供更多信息，或者要求客户降低请求的大小，又或者推迟这个请求。
+
+之所以把这个审核放在第一位，是因为我在实践中发现，很多的客户请求都是“拍脑袋”想出来的，其实根本不合理，而且请求的大小，往往是狮子大开口。当你审核一个“需要几千台服务器容量”的请求后，你必然要与提出者沟通。而在很多情况下，他们的请求在沟通后降到了只需要几台服务器。
+
+这个“沟通”也不难，你只要对每个请求多问几句，比如这三个“劝退”问题：
+
+- 你为什么有这么大的需求？
+- 你能讲讲你的理由吗？
+- 能不能推迟一下这个请求？
+
+差不多有一半客户在答完这三个问题后会降低请求的大小，甚至很多会直接取消请求，说：“仔细考虑后，我们其实不需要这个请求。”
+
+### 分布式的需求控制管理和效率提升
+
+第二个模块是分布式的需求控制管理和效率提升。
+
+为了适应大规模服务的场景，需求控制的方法必须是分布式的。我们一般是把整个公司的各种使用，分成差不多10到15个产品组，比如按照产品种类来分。这样我们就可以针对这些产品组，分别合作，让每个产品组设置特定人员和团队来和我们合作。
+
+为什么这么做呢？因为只有这样，我们的工作才能合理扩展。
+
+我曾经为一个互联网服务做过三年的需求控制，学到了很多经验和教训。这个服务有几千个内部客户，如果只有我一个人和所有的客户打交道，根本行不通，累死也做不过来。
+
+更重要的是，每个产品组的内部人员，其实才是最适合审核本组需求的人，因为他们对这些请求最清楚。这个请求到底需不需要？请求的大小到底合不合适？由他们来做审核，远远比我做得好。
+
+**产品组级别的审核**，本质上是一种有效的，可扩展的分布式模型。而且，除了需求控制和审核，还有其他一些类型的工作，也更适合在产品组级别执行。比如下面我们会提到的配额限制等。
+
+采用这个模式，所有的服务需求，都会先确定是哪个产品组，然后将需求任务分配给产品组，让他们进行产品组级别的审核。产品组的审核决定也不是随意决定的，同样要基于几个因素，包括请求的优先级（例如功能的重要性）、增长配额以及产品组内下层团队之间的协作等。
+
+### 宏观需求增长控制：设置增长配额
+
+第三个模块是在宏观上控制增长，也就是设置增长限额和配额。我通过四个问题来阐述。
+
+1.在哪个级别设置增长配额？
+
+我刚刚讲了，每个产品组会对自己内部的服务需求进行审核。如果没有产品组级别的配额限制，产品组有可能胡乱批准他们自己的请求，从而滥用这个服务。如果对他们的服务需求，加上配额限制，事情就好办了。所以，**增长配额必须设置在产品组的级别**。
+
+另外，在产品组下面的级别，也可以设置配额。因为有的产品组很大，内部也有几十甚至几百个团队，所以每个团队也需要设置相关的增长配额。这也有利于产品组内部的协调。这里的要求就是，产品组内部的配额总和，必须不能超过产品组级别的总配额。
+
+2.怎样设置增长配额的频率？
+
+这个设置可以是一年、半年，或者是一个季度。太频繁会增加工作负担，但是时间太长也有弊端。所以，我们一般都是半年或者一年设置一次。如果是一年，一般是年初设定一年的增长配额。
+
+3.如何设置增长配额的大小？
+
+每个产品组的实际配额大小也需要考虑几个因素，比如产品的特征、重要性、预期增长、产品发布计划、内部客户端效率等等。对每个产品组的情况都了解后，就可以根据实际情况和业务影响，来平衡各个产品组的配额。当然前提是，总体配额不超过总容量。
+
+4.如何及时地控制需求的增长，保证不超过配额？
+
+我们需要**搭建一些工具和配额使用情况面板**。这样就可以每天监控每个产品组的资源使用情况，并将使用情况与增长配额进行比较。如果产品组的资源使用量，连续7天比每日的配额快，我们就通知产品组，并创建对应的任务。
+
+任务的优先级别在一开始要设置成最低的。但是如果产品组的使用量，已经超过了年度总增长配额，那么你可以将任务更改为高优先级来解决。如果有连续3周以上的实际使用量，都超过了年度总增长配额，并且产品组没有采取任何措施，那么对应的任务就会提升优先级到最高级。
+
+### 微观增长控制：资源使用的实时监测
+
+第四个模块是在微观上进行增长控制，就是实时地进行资源使用检测。
+
+产品组对一个互联网服务的使用有很多实例。虽然每个实例的情况都不同，需要区别对待，但不会变的核心点是：每个使用服务的实例，都需要**进行实时的、微观层面的监测**，以确保它的效率不衰退。
+
+一旦你发现实例的效率衰退，就需要及时地通知这个实例的所有者。一般是以任务的形式发给客户，让客户诊断和根因，然后解决。
+
+这个部分，和刚刚讲过的宏观层面的配额限制是互相呼应的。只有在微观增长方面检测和控制得好，才能更容易保证配额不超标。
+
+### 资源使用效率：不断提升
+
+最后一个模块，就是不断提升资源使用效率。最好的措施，就是我们上一讲说过的提高服务效率。这里的服务效率，主要是客户端的效率，目的是满足内部客户基本要求的情况下，尽可能地降低资源量。
+
+但我们实际中碰到的一个难点是，内部客户通常只对自己的指标比较了解，比如QPS，或者数据的大小。既然我们的最终目的是节省成本，那么，就需要让客户直观地了解指标和成本的对应关系，比如1TB的数据相当于多少钱。
+
+有了指标和成本的对应关系，产品组就能方便地按照任务的重要性来安排工作、调配人员。一个能节省1千万元的任务，当然比只能节省1百万元的任务更重要。
+
+为此，我们针对每个互联网服务，都提出了一种易于计算和理解的对应指标。比如，对某个存储服务，我们就考虑了数据大小和QPS这两个输入指标，然后根据整个服务的成本来做映射。一般来讲，为了反映最新的服务状态，这个指标是需要定期更新的，例如，服务增长、硬件效率、服务效率等。
+
+## 总结
+
+这一讲我们讨论了容量控制的管理方法，这套方法可以有效地降低服务的容量需求，也就节省了公司的运营成本。实际执行这条管理方法的核心是：在不影响公司正常发展和内部客户合理需求的条件下，尽量降低内部客户对每个互联网服务的需求。
+
+<img src="https://static001.geekbang.org/resource/image/9f/71/9f58d7822457afec81a953d09218a271.png" alt="">
+
+总体来讲，这套方法的核心是分布式和系统性。对于新的内部客户需求，要进行审核以确保需求请求是合理的。而对于现有客户的需求，要在宏观级别，确保需求配额不要超过；在微观层面上，确保资源使用效率不退化，还要不断地寻找效率提升优化的机会。
+
+唐代诗人岑参有首很有名的边塞诗，有两句是描写塞外的寒冷：“将军角弓不得控，都护铁衣冷难着。”说的是边塞都护府的将军，手冻得拉不开弓，几乎不能控制弓箭了，铁甲也冰冷得让人难以穿着，非常辛苦和困难。我们做容量控制管理的工作也着实不容易，需要和各个内部客户产品组打交道，互相理解，为了共同的目标和公司的利益一起工作。
+
+## 思考题
+
+你的公司里最大的互联网服务是什么？这个服务的容量增长是怎么控制的？
+
+如果这个服务的客户要求实现一个新的功能，所以需要很多服务器，而你负责这个服务的容量管理，你会如何回答客户呢？
+
+欢迎你在留言区分享自己的思考，与我和其他同学一起讨论，也欢迎你把文章分享给自己的朋友。