2.6　资源利用率最优剖析

提升资源调度性能时主要关注系统本身接口的服务表现，提升资源实际利用率重在关注关联的影响因素，本节内容将指导如何通过实践逐步提升资源利用率。

2.6.1　解决什么问题

剖析资源利用率是为了寻找提升资源实际利用率的着手点。随着数据中心规模的扩大，机器资源达到了数十万台的规模，而且还在快速的增长中。资源的高效利用对降低成本至关重要。集群资源调度和管理的终极目标是，通过部署更多的Workload节约成本。对于专有物理集群，预算（机房、功耗、物理机、网络等一次性付费）一开始就固定了，充分利用各方面资源，就是将预算效益最大化；对于共享物理集群，目标是提升单位资源收益率；云端资源是按一定价格、采用弹性模式租用的，云端资源利用率不完全受资源供应商控制。当然，一个共享物理集群的资源利用率越高时，同等规模的物理资源相应承载的Workload一定越多，最终是有利于资源收益提升的。不论哪种物理集群，在SLA承诺的前提下，稳定性优先是底线，然后才是相应的资源利用率的提升。

实现资源利用率最优，在具体操作层面，就是要回答以下几方面的问题。

● 利用率监控：不同应用（或者项目）的资源利用率如何？

● 资源管理：BU（Business Unit）在当前资源中还有多少余量？

● 资源规划：按照有机增长，BU下个季度需要增加多少资源？

● 资源优化：如何进一步优化系统以提高资源利用率？

1.衡量方法

要想提高资源利用率，首先需要以数据来推动分析，而分析又有其针对性的场景。目前对数据中心的资源利用率衡量，普遍采用以CPU资源利用率为代理指标的方式。这种方式存在一定的局限性，如不包含RAM等其他资源。单纯以CPU资源利用率来衡量，在云服务供应商的资源调度分配场景下，局限性更加明显，因为很容易忽略其他资源成本。

因此，基于综合资源利用率指标来衡量IDC资源使用情况（包含计算资源的各个维度）是必要的。关于利用率指标的定义和使用，后面会进一步分析。

2.优化空间

有了目标、衡量方法，还需要评估当前集群有多大的优化空间。这个空间的大小影响投入产出比，也指导优化到什么程度就基本接近上限了。资源库存率（Deployed inventory与Inventory的比值）用于衡量资源优化空间的大小。对于不同的场景，资源库存、已使用资源的定义口径会不同，需要区别对待，后面会进一步分析。

2.6.2　如何解决问题

前面介绍了资源利用率最优剖析要做什么，以及为什么做。本节介绍如何做，才能实现资源利用率最优。这涉及利用率评估，需要明确哪些指标可以反映利用率最优的结果，以及指标的定义，便于统一计算口径和进行数据加工计算。

1.指标定义

上面场景中所提出的问题非常简单。然而，由于数据中心的Workload多样性，又经常发生变化，使用数据来回答这些问题变得异常困难。理论上，我们希望将利用率直接定义为：

利用率 = 业务完成量（Work done）/ 资源总量（Total resources）

抛开分母不谈（一般比较容易衡量），这样的利用率指标最大的问题是，业务完成量非常难以定义和测量。每个应用都有不同的指标来衡量实际的业务完成量，而一个集群甚至一台机器都会有多个不同的应用，总的应用数量成千上万。Workload的多样性、复杂性和多变性，使得定义和衡量统一的业务完成量变得非常困难。

（1）CPU利用率

目前一般使用比较多的是单一资源利用率指标，其中最常见的是CPU利用率，其定义为：

CPU利用率 = CPU使用量 / CPU容量［14］

CPU利用率指标有着非常明显的优点：简单、易于计算。然而，在实际使用中，该指标会有很大的局限性。例如，CPU利用率指标常常有误导性，因为存在额外开销（如内核的消耗等），CPU的消耗量并不与Workload的完成度直接成比例。此外，未被使用的资源也不总是资源余量，因此仅使用CPU利用率指标不能完全准确地衡量资源余量。据此进行的规划，同样也很难做到最优。另外，由于CPU利用率并未揭示利用率提升目标的上限，也不方便分解分析利用率提升的途径。还有，随着异构计算的发展、资源种类的增加，单一资源利用率并不能完整地反映利用率状况。

这些问题使得上面提及的大部分场景无法通过简单的CPU利用率来分析。因此，我们需要考虑定义新的资源利用率指标来满足这些场景的需要。

事实上，这些问题在工业界和学术界已经成为著名难题［14］（见第4章），其核心原因在于Workload的多样性、复杂性和多变性。本书无法提供单个指标来达到所有分析的目的，而是试图通过更新已有的指标、定义新指标并组合多个指标的方式来实现。

（2）综合利用率（Overall utilization）

综合利用率的定义是，针对单个资源，如CPU、RAM、磁盘、GPU、FPGA等，计算它们的利用率，并以不同资源单位成本的相对比例加权平均。

其中，∑wii=1。

需要注意的是，在计算整个IDC综合利用率时，分母应该包含所有产生成本的容量（Capacity）。例如，软件或硬件导致的故障机器、碎片、预留的资源（Reserved buffer）等都应该包含在内，才能反映出真实的综合利用率。

权重的计算由各个单位资源类型的相对成本决定，因此该指标也可以称为“成本效率”（Costed Utilization，CU）。

使用CU指标的好处是可以包含不同的计算资源类型，如果未来有异构计算的资源加入，则也可以简单扩展。

综合利用率用于衡量资源调度、资源管理、资源规划等整体优化效果，尤其适用于衡量成本优化效果的相关场景。

综合利用率指标并不能做到面面俱到，以适合所有场景。例如，能源消耗就不在综合利用率指标范围内。能源消耗效率一般指数据中心的能源消耗效率，它已经有了比较好的指标，就是PUE（Power Usage Effectiveness，能源利用率）［15］。此外，这里不涉及底层的能源消耗效率，而是侧重于上层的资源利用率。

2.指标分层

基于资源利用率的复杂性，我们建议采用多个指标组合的方式来解决问题。指标分层如图2-2所示。

在图3-2中，自上而下分别是业务效率、综合利用率、单一资源利用率和数据中心能源消耗，分别解释如下。

● 数据中心能源消耗指标（底层指标）：PUE用于衡量数据中心的能源消耗优化效果，不在本书的讨论范围内。

● 单一资源利用率指标：如前所述，单一资源利用率指标便于计算，易于理解，因此在很多场景中它仍然是首选的指标。

● 综合利用率指标：在这一层，我们引入综合利用率指标，以克服单一资源利用率指标的一些不足（其具体内容在后面详述）。

● 业务效率指标：最终我们还是希望能衡量业务的效率，但是由于每个业务的吞吐量（Throughput）不同，很难将各个业务的效率指标统一，只能把这一层的利用率留给各个业务自己去衡量。

下面介绍综合指标的定义，以及在不同的场景下如何使用这些指标。

（1）资源库存率

资源库存率是我们重点引入的一个新指标。该指标利用了SR（Stranded Resources）的思想，但是可以推广到不仅包含SR而且包含所有库存资源的场景。

SR是一个用于衡量资源浪费的指标［16］。SR的定义是，在一台机器上，由于部分资源被用完而其他资源未被使用，从而导致的资源浪费。比如一台机器，如果内存已经使用了100%，而CPU只使用了40%，那么剩余的50%的CPU资源（假设有10%的系统开销）就属于SR，因为已经不可能再调度任务来使用这些资源了。

与SR类似的一个指标是IiU（Imbalance in Utilization），可以通过

计算得到。有时候在集群中还会出现一种资源比较紧张，而另一种资源利用率低的情况，导致其中一种资源被大量浪费。目前在阿里巴巴生产集群（混合部署）中就存在这种情况，内存使用率要比CPU使用率高20%左右，Malte针对Alibaba clusterdata［17］的分析如图2-3所示。

什么是库存资源？当前如果把剩余资源全部拿掉，服务不会受到任何影响，那么这些剩余资源就是库存资源。库存资源是检查资源利用率的一个有效指标，结合资源利用率，可以更好地支持资源规划，以及进行预算控制。

资源库存率与资源利用率的计算有所不同，比如在实际占用资源的计算上，资源库存率应该使用资源画像的结果，而不能直接使用系统报告中的CPU使用量，因为CPU使用量并不是软件运行所需的最少资源。因此，一般存在如下关系：

资源库存率〈1-总的资源申请量（Total resource requirements）/总的资源容量（Capacity）

对单一资源库存率进行计算时，根据每个任务的画像[18]，计算出任务运行必需的资源。对总的资源库存率进行计算时，是在单一资源库存率计算的基础上，对不同的资源类型进行归一化（加权平均）折算。资源库存率的上限是1，理论上，下限可以小于0[19]，在实践中一般不会达到这么低的库存水平。资源库存率的计算要求公式的分母（容量）必须包含所有的计算资源，而不管机器是否上线（包括未被分配的机器，以及因故障下线的机器）。

资源库存率和综合利用率的区别在于计算公式的分子不同：资源库存率计算公式的分子（总的资源申请量）是基于每个任务画像的（估算资源的实际需求量），而综合利用率计算公式的分子是实际使用的资源量，因此通过资源库存率扣减的资源会比通过综合利用率扣减的资源多。资源库存率反映的是可以从集群中拿掉而理论上不影响业务的资源比例。资源库存和库存率能更好地揭示资源优化的潜力，更好地指导资源规划以及预算控制。

在图2-2中，综合利用率之一的资源库存率（库存资源就是还可部署应用的资源）指标计算依赖多个维度库存的分解，其中的部分数据可以通过单独统计得到（如SR、故障机比例等）。按照分解的思路，想提升综合利用率，就需要对分解的维度（影响库存的因素）进行优化。在表2-3中列出了单维度的库存资源指标的降低途径。

资源库存率的适用场景为IDC的资源优化空间分析。相比于综合利用率，该指标更好地揭示了实际的库存，可以衡量优化空间和优化程度。

SR可以配合资源库存率一起使用来衡量资源库存。SR是库存的一种，反映了因调度分配不够优化导致的碎片。注意：在云服务器供应环境中，资源交付按SLA约定进行，并不能直接套用资源库存率。客户业务的Workload实际开销，与实例规格的承诺SLA性能不完全一致，并且之间的资源差距，云资源调度系统无权干涉。

（2）单一资源利用率

上面主要介绍的是综合利用率的库存资源衡量和使用。与综合指标对应的是单一维度的指标。CPU和RAM的利用率都已有定义好的标准。除针对特定场景提出新的CPU、内存计算方式之外，推荐用Linux自带的统计方式。

单一资源利用率适合在具体开展资源优化分析工作时进行参照。

（3）EMU（Effective Machine Utilization，有效机器利用率）

Google曾经使用过EMU（见参考资料［18］），其定义为：

EMU = LC吞吐量+ BE吞吐量

EMU是每个业务单独运行需要的归一化的机器数量的累计。由于装箱（Bin-packing）的效果，EMU的上限不是归一化的，即可以超过1。由于上限不固定，且与Workload的组成和画像有关，因此这个指标不宜作为比较基准。

EMU可以作为特定业务场景的定制指标。

（4）业务效率

业务效率（Work done per usage）指标用于衡量各个应用或者业务的资源利用率，其数值反映的是每单位资源提供的服务量。计算公式如下：

业务效率 = 业务完成量（Work done）/资源分配量（Resource allocation）

其中，“业务完成量”指任务完成的数量，“资源分配量”指任务运行前申请的资源总量。二者都可以采用加权平均后的数值，以便与其他指标结合，共同反映业务更多维度的综合成本效率。在特殊情况下，“业务完成量”也可被定义为资源实际使用量，此时的业务效率指标呈现为百分比，表示资源实际被利用的情况。

如果业务范围发生变化，那么业务效率公式中分子、分母的内涵及其数值会随之变化。例如，交易应用的业务效率指标用来衡量整个交易体系每秒支持的交易数，而搜索应用的业务效率指标用来衡量整个搜索体系每秒支持的查询服务数。由于两者业务属性不同，因此不能简单地通过业务效率的数值大小来评估其优劣。业务效率指标除了不适合用于横向比较，在用于纵向比较时也须非常小心业务本身的变化。

虽然每个业务都是一个由多个模块构成的庞大而复杂的体系，但是可以用一种简单的方法来衡量整体业务效率——在业务效率公式中，将一天需要处理的请求总量作为分子，将一天实际申请的资源总量作为分母。例如，系统一天处理10000次交易，一天需要占用100台服务器，那么业务效率 = 10000 / 100，即每台服务器每天的业务效率是——处理100次交易。

3.数据聚合

在上面的指标中，一个重要的要求是可以按照应用和BU（Business Unit）维度（以及默认的位置、机房）聚合。对于专用机器来说，按照应用和BU维度聚合问题不大；而对于共享集群来说，则有一些需要明确的地方。

需要记录每个容器的使用以及预约情况，以便将一台机器的使用关联到应用上。

机器上的未分配资源被统一计入集群的分配率。例如，如果资源只分配出去20%，其中10%被用掉，那么应用的利用率就是10%/20% = 50%，而分配率只有20%。

对于提供服务的团队来说，在短期内无法进一步做针对业务层面的使用关联。例如，中间件和数据库团队为其他团队提供服务时，如其他团队有自己专用的机器，这些机器的利用率低则直接反映出中间件或者数据库的利用率低。我们短时间内无法把这部分的利用率关联到实际使用中间件或者数据库的团队上。

4.落地思考

如果没有SLA、稳定性保障，指标数据就会失去价值，所以要确保共享最优和资源的稳定性。下面拿马路和车辆来类比进行介绍。

● 确保共享最优：马路上有很多车辆在行驶，物理机好比马路，虚拟机好比车辆，有的车辆体积大，有的车辆负载大，对应于虚拟机的规格、资源消耗类型的多样性。车辆共享马路，对应于虚拟机在超线程、超卖CPU层次实现CPU、LI/L2/L3 Cache、内存、网络、磁盘等资源的分时共享。

● 确保资源的稳定性：马路上的交通事故或者周围的车辆行为，都可能影响车速，对应于在某些场景下，同一宿主机上的其他虚拟机（如容器）也会影响应用性能的发挥。但是稳定性优先级还是比较明确的，对于虚拟机（如容器）的稳定性，首先要确保自身的稳定性，其次要确保同一宿主机上的邻居应用的稳定性、同一交换机网络的稳定性等。

确保共享最优和资源的稳定性就是要做到先于业务方发现问题，要求对于资源层面的任何问题（如部署关系问题、资源隔离竞争问题、资源容量不足等），资源调度系统都应该第一时间感知，并通知业务方自动调用业务迁移、腾挪接口，以及时解决问题，实现业务能完全透明地依赖资源，将业务方对接资源的注意力完全集中在单机性能表现上。

除了上面提到的问题，还有大家不常接触的物理机/虚拟机故障、实例自动迁移、应用定点扩容、设备搬迁/维修/腾挪、单机实例数、高等级应用的打散、有无状态应用的打散、位置感知（Rack、Pod、Switch）、负载均衡、面向物理机超卖、面向应用超卖等问题。

资源利用率达到最优是一个演进的过程，而不是一蹴而就的。一般资源利用率提升会经过“预算”决定一切的阶段，然后发展到突出垂直的“业务自己控制容量水位”，再发展到在业务稳定下，基于水平的整体资源分配、全局稳定性视角的资源弹性这样一个演进过程。在演进过程中应该避免典型问题的发生，例如业务控制实例数无法扩容，CPU利用率达到70%以上，已经严重影响同一宿主机上其他应用的稳定性，也对上下游的RT（Response Time）产生影响，同时间接影响上下游系统的容量评估。

2.6.3　案例分享

集群调度和管理的终极目标是节约成本，这在阿里巴巴也不例外。我们选取阿里巴巴在线服务集群作为案例进行分享。其成本开销主要集中在日常需求场景和大促突发需求场景下的采购成本上。

日常需求场景下的采购成本指的是，为了满足阿里巴巴各种业务的日常需求（扩容、新增）进行定期采购扩容[20]。在该场景下，我们可以直接以集群利用率来对齐成本[21]，所以可以通过提升利用率手段来减少采购成本。

大促突发需求场景下的采购成本指的是，在每年“双11”、春节红包等活动中，为应对比日常业务量多几倍的场景，需提前规划采购一批物理机或阿里云ECS进行弹性扩容支撑。在该场景下，除提升利用率外（在日常场景下就做好了优化），由于大促场景具有分时特性（分时搞活动），还需做到分时复用来达到容量的复用，从而减少采购成本。

在这两大场景中，我们面临的技术问题如下：

● 单一资源时序调度，可以做到瞬时分配率最优，却很难做到全局分配率最优。

● 混部CPU分配率最优。例如，混部容器规格较大（32C-64G-60G），支持混部物理机存在三种以上异构比例，即“CPU：内存”为A（1：3）、B（1：4）、A/B（1：5）。若随机放置32C-64G-60G混部容器，则很容易形成碎片。

● 细小规格（4C-8G-60G或8C-16G-60G）混部容器产生的碎片，导致大规格混部容器无法分配。

● 在线内存分配率低。例如，物理节点CPU和内存配比为1：5，实际配比为1：4，这就导致CPU瓶颈和内存冗余。

● 在混部机器上，在线和混部存在相互干扰的内存碎片。

针对在线内存分配率低的问题，需进行碎片治理。一种解决方案是数据分析驱动碎片优化，基于宏观层面的应用分析、集群分析，以及微观层面的节点分析，如图2-4所示。

应用分析主要包括：

● 应用数据统计，目标是生成应用单维度的负载特征画像数据。例如应用的CPU利用率、内存利用率分析报告。应用的负载特征会随着业务的调整而发生变化，因而单维度统计的频率不宜太高或者太低，通常一周的窗口期，就可以完成刻画应用的常态负载特征。

● 应用分类，分为在线应用和混部应用，主要用于识别任务等级。

● 按应用干扰分类，注意识别延迟敏感的任务和极端消耗资源的业务。

集群分析主要包括公共池、非混部池、混部池（实时混部池）、独立池（硬分割、软分割资源池）分析。

节点分析包括应用节点和典型物理节点分析，可形成利用率分析报告，频率为每周（只需要统计，不需要找原因），最终输出核心数据，如CPU利用率（周级别）、CPU分配率、CPU个数等。

下面基于碎片优化思路简要介绍内存超卖的调度技术，以及碎片优化方案。

我们统计出某集群物理机的内存分配率在90%以上、CPU利用率在20%以上，发现大部分机器的情况都如图2-5所示。

尽管内存分配率接近100%，但是内存的实际使用率只有50%～60%，并且非常稳定（呈水平状）。

为什么会这样？因为大部分在线应用是Java应用，JVM静态分配内存的特性决定了内存运行稳定。在启动容器时，JVM便已经指定了最小堆内存，后续无法动态改变。此外，除了JVM申请的最小堆内存，由于会预留内存给运维应用和其他Agent使用，所以往往容器都会申请比JVM堆内存大一定规格的内存（比如JVM堆内存为5.8GB，容器会申请8GB内存）。

我们可以得出结论：在启动应用容器后，大量的节点一次性申请了充足的内存（按照峰值内存申请），在某种程度上应用启动时已经决定了内存浪费的程度[22]。

于是，我们想到能否在现有的集群中，对已经分配出去但未能有效使用的内存进行二次调度，这样就不仅解决了“内存分配遵照内存硬件的大小进行规整分配”，而且还会带来额外的更多可用内存。因此，我们引入了内存超卖的调度技术。

方案介绍：我们建立了一个内存超卖的优化体系，通过监控→告警→修改内存超卖→持续监控的闭环机制来实现动态、可回滚的内存超卖机制（1-2-3闭环），通过监控采集→分析→重调度腾挪→持续采集分析的闭环机制来确保稳定、可靠的内存超卖保护（1/4-5-6闭环），如图2-6所示。

对于自动化管理节点的超卖，以及在提高整个集群资源利用率的同时保障集群的稳定性，最核心的功能是管理节点的超卖比，它会根据用户配置规则和集群当前状况自动为每个节点配置合适的超卖比。

内存超卖系统整体架构如图2-7所示。

各个组件的功能如下：

● 最上层的Rules、Alerts和Metrics是输入数据源，用来控制节点的内存超卖比应该配置为多少。

■ Rules是用户可以管理的超卖规则，比如指定某个节点的超卖比为110%（定义为“规则1”），“规则1”的优先级高，属于动态调整规则范畴。另外一些节点只配置了“规则0”，不超卖。

■ Alerts和Metrics从外部获得数据，其核心逻辑是：当节点的内存发出告警时（节点的内存使用率高于90%），则会降低内存超卖比；当节点的内存使用率比较低时，则会自动提高内存超卖比。

● Decision对上面的三个数据源进行整合处理，包括重复数据清理、过期Metrics处理、优先级整合等，然后根据当前集群的节点数据[23]，生成各个节点的目标超卖比配置。

● Queue中存放了需要处理的节点超卖请求。

● Filter对从Queue中取出的超卖请求做进一步的过滤，比如判断是否有同一个节点的新请求（如果有，则使用最新请求的配置）、根据预先配置的规则过滤掉某些节点的配置[24]。Filter是可扩展的，用户可以编写自定义的Filter。

● Ratio queue和Worker是最终配置节点超卖比的Worker，按照超卖比的不同来区分。

1.智能内存超卖策略

在具体实施中，内存超卖的更新规则如下：

● 所有的内存超卖比都不能超过预先配置的上限（默认是150%），通过Filter实现。

● 如果没有监控和告警，则平台会按照用户配置的规则为节点配置超卖比。

● 如果接收到告警（内存使用率超过90%），则平台会自动调低节点的超卖比，发送消息给应用腾挪搬迁系统，由该系统[25]腾挪节点上的容器。

● 如果从Metrics监控数据中发现节点的内存使用率很低（低于40%），则平台会提

高节点的超卖比来支持调度更多的容器。

2.内存超卖稳定性保障

要提高节点的内存超卖比，可以增加节点上调度的容器数量，从而提高节点的内存使用率。但是，由于每个节点上调度的容器数量和特性不同，因此不是每个节点都需要相同的超卖比。

我们为所有节点都配置了10%的内存超卖比，虽然大部分节点都能正常运行，但是也会出现个别节点的内存使用率超过90%的情况。在这种情况下会有很大的稳定性隐患，所以更好的方式是根据每个节点的实际运行情况来分别配置内存超卖比。

比较稳妥的策略是当收到节点的内存告警时，平台会判断当前的内存超卖比是否高于1，如果是，则计算合理的超卖比让内存的使用率低于80%（默认值，可以配置），然后交给Worker执行。

当超卖比降低之后，理论上，节点的内存分配率会高于100%。此时内存超卖系统会发现该问题，并对节点上的容器进行自动腾挪，从而降低节点的内存使用率。

除了上面介绍的内存超卖策略，优化碎片还有如下策略，它们分别对应一种特定场景问题。实际上，这些策略需要同时作用、相互配合来优化整体的碎片率，从而提升内存分配率。下面列举的都是具体的案例场景，它们之间没有必然的联系。

（1）重启再调度优化

当实例重启后，针对无状态节点进行再调度，使编排关系符合最新要求。

（2）调度系统性能优化

性能优化一般分为两步：分析性能瓶颈和优化性能瓶颈。

● 分析性能瓶颈：一般依赖性能Profile，目前有两种分析方式，即微基准测试（micro branch mark）和pprof。根据调度器自身的Metrics分析瓶颈；使用Prometheus采集模拟器的调度器Metrics。

● 优化性能瓶颈：主要聚焦于并发能否改为异步、减少锁冲突、关键耗时算法能否优化等方面。

（3）资源的申请量和使用量不一致

场景1：某活动申请了几百台虚拟机，实际上有50%的虚拟机就足够了。由于业务没有做好预期，或者防止超预期，多预留了资源，最终导致资源的申请量和使用量不一致。

场景2：某活动申请了几百台虚拟机，白天其整体利用率偏高，晚上其整体利用率偏低。

解决方法：每一次资源的申请量和使用量要保持一致，系统统一追踪、统一透明化度量。7×24小时，满负载运作，对在线系统部署、调度提出更高的要求。

（4）资源使用不均衡

场景：某活动申请了几百台虚拟机，实际上只有60%的虚拟机有请求，压力符合预期，40%的虚拟机几乎闲置。由于业务特性、应用架构、应用部署等多种原因，导致负载不均衡。

解决方法：单个应用可能看不出来，但是往上一层看，例如“活动”的上下游、业务链路，甚至机房层面，负载不均衡就非常明显了。对大盘进行基本监控非常有必要。

（5）故障修复

场景：机器的磁盘、内存条、网卡随时都可能坏掉，例如，每天坏掉三五台，一个星期也就二十多台，然后进入维修流程，比如经过一个星期的慢慢修复，甚至更长的修复周期。修复好后，回归可用资源池又需要一段时间，如进行环境清理、基础软件配置等。这种浪费很隐形、很零碎。一年下来，500台服务器、1000个工作小时是最少的了。

解决方法：实现自动化、检测—维修—上线加速处理，不需要人工介入，在故障处理链路上坚决不依赖人工。

（6）排队等待

场景1：“双11”大促上线前，需要提前购买N台服务器。比如传统自建机房数据中心，需要提前规划，如提前3个月甚至4个月，在这期间，资源闲置。“双11”大促下线了，比如下线3天、4天还是一个星期，在这期间，资源依然闲置。

场景2：业务规划涉及资源容量、DevOps系统和调度系统。比如有N个应用，每个应用申请M个资源，由于队列长度总是有限的，因此存在等待时间——资源交付完毕后到服务交付之前的时间。服务交付得越快，越能节省资源。

解决方法：满足突发资源需求的最佳方式是使用公有云服务，无须支付从保有资源的采购到过保修期全生命周期的成本，从而降低了资源保有时间，节约了大量成本。使用云服务，可以使业务专注于快速上云、快速下云，优化流程和效率。

（7）年度评估

场景：整年的预算，细化到12个月进行比较，然后依赖几次大促活动，提升资源利用率。依据利用率均值进行年度核算方便、直接，但不够精细。促销活动时间有限，绝大部分时候是非促销活动时期。如果预算按全年峰值申请、核算，则将导致冗余过多。整个年度资源预估，无形中没有充分把握资源生命周期特征。

解决方法：针对资源生命周期各个阶段的诉求进行评估，结合自建数据中心长期保有资源——支持常态需求，租用云端弹性资源——支持突发需求，使全年预算更精细。

（8）具体问题具体办法（Case by case）

场景1：申请机器，请走流程，等待SRE（Site Reliability Engineer，网站可靠性工程师）审批；客户反馈、投诉，请走流程，等待客满人员介入跟进。

场景2：登录控制台，网络不通。

场景3：操作系统、JDK需要升级，请走流程，等待SRE、研发人员审核。

解决方法：有些情况机器完全可以自动发现、自动处理。如果流程总是期待人工介入，那么Case by case就是在浪费人力。

（9）一致性

场景1：基础软件运维工具预安装了某个版本的操作系统，并依赖特定版本的容器，当实例等待分配时，才发现不兼容。

场景2：A系统依赖B系统数据，假如B系统数据更新了，而A系统还是老数据，时间久了，就会发现A、B系统有很多数据不一致。因为A系统保留了部分数据，B系统也保留了部分数据。

场景3：业务系统C同时依赖A和B监控系统，当出现A和B监控系统同时发布，且业务系统C产生新数据、新的监控需求时，需要A、B监控系统各自相对闭合，正确处理A、B监控系统支持业务系统C的相同指标和不同指标。

场景4：DevOps系统数据库中记录了VM（虚拟机）信息，以及对应的物理IP地址，而调度资源库中没有相关信息，下游业务系统数据库中也没有这些信息。

原因：在调度系统中直接挪动了机器，而在流程里没有“直接的记录”和“相关通知”，上下游的“依赖”也脱离了；或者是登录物理机做了人工特殊处理。

解决方法：业务层面、链路层面、子系统的数据统一、接口统一、服务规范统一，既关系到效率，也关系到服务，需要产品来解决。

（10）可达效率

场景1：有一个问题需要咨询，请找A；转交，请找B；搞不定，再转交，请找C。

场景2：有一个业务需要找A、B合作，而A、B各有自己的需求，最后经过讨论找到C，并由A、B各出一些资源。时间久了，A和B既同又不同。

解决方法：交流沟通的规范、形式的一致性，特别有助于效率的提升。

---

[1]原地发布指单个容器部署所属的物理节点不变，非原地发布指单个容器发布后所属的物理节点已经发生改变。非原地发布的执行，一般通过扩容、缩容的组合来实现。首先在新的物理节点扩容新版本节点，然后将老版本节点释放。

[2]这意味着上层业务架构不会捆绑资源，资源池的资源是共享的。这在一定程度上要求业务实现高可用设计，如不依赖网络IP地址、不依赖特定资源节点。如此，服务器硬件故障、基础软件升级或者资源回收再分配，方可随时发生。

[3]不能等到硬件发生故障后，再进行被动的搬迁。结合硬件故障发生的前置“线索”，完全应该提前搬迁。

[4]其实，对资源具体位置的感知，开始可能合理，但是随着业务的发展，可能又变得不合理。

[5]独占会限制资源的充分分时共享及资源池的隔离，随着相应的Buffer预留等，最终导致资源利用率偏低。

[6]确定性稳定性是指对稳定性的潜在风险，需要明确识别出来，提供相应的应急预案。

[7]本身就是一个系统化工程，如何判定为故障，尤其是在夯住的、半死不活的场景中。

[8]包括故障机本地，以及业务流程中维护的记录、状态信息的清理。

[9]专有云看集群资源利用率，公有云看单位资源收益。

[10]针对在线资源而言，在离线或者在线和离线混部场景下，目标则不完全一样。

[11]一般为百万级别的规模，这里可能指容器、虚拟机节点或者物理机的数量。

[12]只校验相关参数的有效性，而不实际生产资源。

[13]16个物理计算单元，通过超线程计算，对外输出32个vCPU。

[14]以数据中心的物理机或者云供应商提供的虚拟机为载体的资源。

[15]一个单元通常对应一个地域或者一个机房，可提供完整的业务服务。

[16]当多个任务需要资源时要进行排队，任务等级高的资源优先被调度，任务等级低的资源后被调度。

[17]在单机上发生资源竞争时，优先杀掉资源等级低的任务。

[18]对于高优先级资源是request（申请量），对于尽力交付的优先级资源（等级比高优先级任务低些）是usage（使用量）。优先级取决于任务特性，一般request值大于usage值。

[19]资源库存率的下限小于0，表示整体资源量低于实际需求量，这是危险情形。

[20]为了节约成本，应尽可能提高日常集群的利用率。

[21]也就是说，如果利用率低，则可以认为采购和容量也存在一定的不合理性。

[22]提前锁定了内存开销，而且浪费的单台物理机平均数量在40%左右，且是稳定的浪费，在运行过程中没有及时调整。

[23]即集群状态（Cluster state），有哪些节点、它们处于什么状态、是否可以修改超卖比、当前超卖比是多少等。

[24]比如节点状态，如果不可调度，则无须进一步处理。

[25]对其简单的理解，就是一种主动运维系统。