在现代软件环境中，就像那些内置的软件环境可扩展的微服务架构，击中容量限制是生产水平的常见原因事件。可以说，也可以通过主动规划来防止一系列事件团队。
一种t New Relic, for example, our platform is made up of services written and maintained by more than 50 engineering teams, and capacity planning is a mandate for every one of them—we can’t afford for our real-time, data platform to hit capacity limits. The first time through, each team spends several days focused on the analysis and development work needed to model their capacity needs. Once they have their capacity models in place, the ongoing practice of planning occupies, at most, a few hours a quarter—a time investment that’s more than worth it if it prevents just one incident per year.
为了帮助使过程尽可能顺利，重复新的遗物网站可靠性工程团队出版“容量规划指南”，带领团队完成容量规划的过程。这篇文章是根据那篇指南改编的。
什么是容量规划？
简单地说，容量规划就是团队在规划迭代之间确保他们的服务有足够的空闲容量来处理任何可能增加的工作负载，并有足够的缓冲容量来吸收正常的工作负载峰值。
在能力规划过程中，小组要回答以下四个问题:
- 我们每个服务中目前存在多少免费容量？
- 有多少容量缓冲区我们的每项服务都需要什么?
- 考虑到自然的客户驱动增长和新产品特性，从现在到下一个容量规划迭代，我们期望工作量增长多少?
- 我们需要向每个服务添加多少容量，以便在预期的工作负载增长之后仍然有目标的空闲容量缓冲区?
对这四个问题的回答——以及服务的架构和使用——有助于确定我们的团队用于计算其能力需求的方法。
计算能力
我们使用三种常用方法来计算给定服务的空闲容量:
- Service-starvation
- 负载的
- 静态资源分析
值得注意的是，服务层（例如，应用程序主机，负载均衡器或数据库实例）的每个组件都需要单独的容量分析。
Service-starvation分析
服务饥饿包括减少服务层可用的服务实例的数量，直到服务在给定的工作负载下开始出现问题。在不导致服务失败的情况下可能出现的资源“匮乏”量表示服务层中的空闲容量。
例如，一个团队有10个部署的实例服务x，在生产环境中处理10K RPM硬盘驱动器。研究小组发现它能够减少服务x到8，仍然支持相同的工作量。
这告诉团队两件事:
- 一个服务实例最多可以处理1.25K RPM驱动器(换句话说，10K驱动器除以8个实例)。
- 业务层通常有20%的空闲容量:两个“空闲”实例等于业务层的20%。
当然，这个场景假设服务层支持10K rpm的稳定状态;如果工作负载非常高，那么跨10个服务实例的可用容量实际上可能小于(或大于)20%。
负载的分析
负载生成有效地是服务饥饿的倒数。您而不是将服务层缩小到故障，而不是在您的服务上生成合成负载，直到它们达到故障点。
那么，您的正常工作负载的百分比将基于您能够成功处理的合成工作负载的数量。这表示服务层中的空闲容量。
静态资源分析
这种方法涉及到识别最受限制的给定服务层（通常，CPU，内存，磁盘空间或网络I / O）的计算资源以及确定该资源的百分比可用作当前部署的该资源。
虽然这可以是估计服务中自由容量的快速方法，但有一些重要的塔拉斯：
- 某些服务在其生命周期中的不同点在不同点中大大不同的资源消耗配置文件（例如，在启动模式与正常操作中）。
- 可能有必要查看应用程序的内部以确定可用内存。例如，应用程序可能在启动时分配其配置的最大内存，即使它没有使用该内存。
- 网络接口控制器(NIC)或交换机中的资源通常以低于制造商发布的最大吞吐率达到饱和。正因为如此，基准测试非常重要实际的最大可能的吞吐量而不是依赖制造商的规格。
无论选择哪种方法，都要在高峰和非高峰工作负载期间进行试验，以准确了解服务可以处理什么。
现在，让我们来看看如何在能力计划练习中应用这些方法。
容量规划：一个完整的例子
我们的产能规划包括五个主要步骤。团队完成这些步骤，并在模板中计算他们的能力需求，示例如下。
- 列出您的服务，并计算每个服务的免费容量使用一个可用的方法论以上讨论。自由容量通常最佳表示为整体能力的百分比;例如，“此服务层有20％的免费容量。
- 确定每项服务需要最安全的最低可用容量。空闲容量是针对代码中意外的工作负载峰值、服务器停机或性能退化的缓冲区。
- 通常，我们为每项服务推荐至少30％的免费容量。
- 在所有情况下，团队都应该将他们的服务扩展到最少N+ 2-它们应该能够减掉两个实例并仍然支持服务层的工作量。
- 确定你下次什么时候审查你的能力需求，并保持那个日期。您应该按季度审查成熟的、典型增长的服务，并按月审查新服务或快速增长的服务。
- 预测您的服务可能经历的工作负载增长百分比在你下一次能力评估会议之前。基于历史趋势数据和任何已知的变化(如新产品特性或体系结构变化)来进行预测，这些变化可能会影响增长。
- 计算您需要添加多少容量在下一次容量评估之前，向您的服务发送，以便您可以保持您的目标空闲容量和支持你预期的成长。
容量规划模板
将您的计算结果记录在一个模板中，并使大型工程组织中的所有利益相关者(例如，现场可靠性工程师、工程经理和产品所有者)能够访问这些信息。这个示例模板涵盖了基于java的服务的容量规划:
| 项 | 标签 | 例子 |
|---|---|---|
| 一种 | 服务名称/组件 | 集电极/ Java SVC实例 |
| B. | 今天的日期 | 2019年4月1日 |
| C | 下一个能力规划锻炼的预定日期 | 7/1/2019 |
| D. | 方法使用方法 | 静态资源分析 |
| E. | 当前服务层大小 (主机或容器实例的数量) |
60. |
| F | 每个服务实例的当前内核 | 10. |
| G | 每个服务实例的当前存储 | 100GB. |
| H | 坚定的自由产能 （占百分比） |
20％ |
| 一世 | 目前的利用率 公式:E - （E * H） |
60 - (60 * 2) = 48 |
| j | 目标的自由能力 (比例;应该表示至少两个自由实例，或n+2) |
30％ |
| K. | 在C日期之前的预期工作量增长 | 15％ |
| L. | 为最低计划工作负载提供服务所需的容量 公式:我+（i * k） |
48 +（48 * .15）= 55.2 |
| m | 维持目标空闲容量所需的容量 公式:L +（L * J） |
55.2 + (55.2 * 3) = 71.76 |
| N | 需要增加的额外容量 公式:摘要(M - E) |
综合（71.76 - 60）= 12 |
| O. | 额外的核心需要 公式:n * f. |
12 * 10 = 120 |
| P. | 需要额外的存储空间 公式:n * g. |
12 * 100GB = 1.2TB |
迭代能力计划
在团队建立了常规的能力规划时，有必要迭代他们收集的数据。关于能力的未来决定应通过预测的能力与实际需要的能力之间的差异来了解情况。
团队应该问这样的问题:是什么导致了这些差异?服务业是否如预期般增长?还是经济增长放缓了?是否需要考虑架构上的变化或新特性?
这些问题可以揭示团队是否恰当地预测了与有机增长相关的增长。
在极少数情况下，团队可能会努力正确计算他们的能力需求。在这里，我们建议团队规划时间以减少他们的能力需求，或工作以使他们的服务更有效。
我们也鼓励团队建立主动提醒（例如，在实际增长超出其预测及其服务之前，在下次审查之前击中容量限制的情况下，以进行内存杀戮或CPU限制）。
当然，即使是最佳的容量规划努力也不一定地防止现代软件环境中的所有相关生产事件。但谨慎，一致，迭代，主动规划可以很长，以尽量减少与能力有关的事件。这使得它完全值得努力。
