【平台篇】运维平台之能力管理系统建设

能力管理的建设就是数据化IT服务的能力！

能力管理(Capacity Management)应该是ITIL里面一个非常重要的概念，有些人叫容量管理，但我还是觉得能力管理更好一些，能力直接的理解就是我们能做什么？还有多少能力冗余？让我们来看看ITIL的概念解释，指在成本和业务需求的双重约束下，通过配置合理的服务能力使组织的IT资源发挥最大效能的服务管理流程，ITIL给到的流程图如下：

从上图的中间部分可以看到三大子流程，业务能力管理、服务能力管理和资源能力管理。对于以上的图中从输入和输出侧还可以看到很多的概念，如果真的要是对照到我们的日常的运维中，理解这些概念都需要很长时间。那么在我的讨论中，我不会让大家去先理解这些概念性的东西，结合互联网运维的实际，构建相应的能力系统。

一、前言

在讲能力系统之前，有些概念还是要和大家达成一致，这样有利于后续的进一步探讨。

第一、系统的分层化理解

在之前的【运维的本质--可视化】和【运维自动化平台的深度解码】中都出现过对数据或者平台的一种分层化理解。个人觉得这种分层的理解特别重要，能够让你很快的找到你要做什么。那么同样对于能力系统建设来说，可以套用之前的模型，给出一个分层化的归类，其中越往上能力的建设难度越大，在具体的项目过程中，考虑到建设的成本和带来的收益，有一些能力建设可以舍弃。

第二、CMDB的核心作用

此时CMDB的核心作用就来了，CMDB系统一定要把资源和IT服务的关联关系建设起来，并且要以一种合理的方式。这个地方重要的几个关系有：

1、服务器和应用的关系。这个关系可以帮忙在后续做资源服务能力建设的时候，自动化的构建面向业务（应用）的服务能力展现。经验告诉我们，此时要非常注意，对于一个大型的互联网业务来说，应用最好以树的结构存在，否则没法表达复杂的业务关系，其次一个服务器可能和多个应用有关联，需要支持一对多的关系表达。之前早期的YY资产系统就用的一级结构表达且只能一对一，最后整个服务器和应用之间的关系根本没法维护，根本就不可用。服务器和业务的合理结构图如下：

另外CMDB还需要提供一个基础的CMDB业务分类的管理能力。这个业务分类不能太深，不建议超过四级；其次业务分类树最好统一级别，这样更容易管理规范化，人太随意，随意之后会影响其他系统数据的准确性。当前我们的业务分类示例如下：

2、服务器和组件的关系

这份数据主要是来源于持续部署系统的数据沉淀，持续部署系统把某个包部署到哪些服务器上，需要通过CMDB接口把关系沉淀到CMDB中，因为很多技术指标是包关联的。它对于后续自动化管理接口服务能力和应用服务能力起着至关重要的作用，能够打通数据之间的关系。

第三、能力基准---高负载、低负载

对于不同的业务(应用)来说，甚至是应用内不同的功能模块，能力高低标准是不同的，主要是和业务的需要相关性能大。比如说对于核心业务来说，可能能力标准设定在一个很低的水平，考虑突发业务的需要；而对于一个平稳期的服务来说，可能能力标准就会设置得高一些，比如说80%，因为业务本身没有太大的变化。对于负载偏高的资源、接口或者服务，我们称之为高负载或高负荷；反之称之为低负载或低负荷。此负载不是系统的Load Average。

二、分层的能力系统建设

第一、资源服务能力

网络的服务能力很好计算，就是考虑上下行的带宽能力。那么和应用关联最大的就是服务器的资源服务能力，并且也是变化最频繁的一块能力。对于一个服务器来说，它能提供的资源只有四类：CPU计算资源、内存资源、磁盘的IO资源和网络IO资源，除了这四类资源，别无其他。所以大家在做能力系统建设的时候，有时候会把load average考虑进来，非常的不合适，有点本末倒置的感觉。

1、服务器的能力计算方法

f(x)=max(cpu能力、内存能力、网络能力、IO能力）。

CPU能力的计算公式：直接使用cpu的使用率作为能力使用情况，最好把单CPU的使用率也纳入基准，而不仅仅是汇总的CPU，这个地方可以发现那些资源使用不均衡的情况，特别是一些单进程的daemon程序。

内存能力的计算公式：其实把内存纳入计算是不合适的，对于很多服务来说，内存要么不够，要么多余。对于不够的情况，应该纳入到监控范畴去发现问题，通过服务迁移或者优化来解决问题。所以这个地方可以忽略。

网络能力的计算公式：对于大部分应用来说网络IO都是足够的，但不排除几类业务场景，是典型的网络IO敏感性的。比如说缓存类的、图片类、存储类，还有一种小数据包类的服务。对于以流量为主要考察维度的能力来说，可以直接把网卡的理想能力作为基准（千兆网卡），用直接的业务流量和他作除；把包量作为能力维度来说，可以设定一个包量的基准，比如说负载均衡转发类的设备。最终都获取到服务器网络的一个能力使用率。

磁盘能力的计算公式：磁盘能力也直接取磁盘的util的指标，不要IO的读写次数那类指标，看IO是否繁忙就可以直接用Util或者IOWait这个指标来计算。

有了以上四块的资源能力（百分比），我们可以直接取以上四类指标中的最大值作为这个服务器当前的能力情况。

对于一个服务器来说，能力最终会转换成一个百分比指标（负载），然后和我们设定的能力基准（高、低）进行对比。如果低于某个水平，则认为服务资源使用不充分；如果高于某个基准值，此时则认为服务器资源的能力无法支撑业务的进一步发展。举个实际的例子：

在具体的容量系统中，可以提供一个界面来设置这个容量计算策略和基准。如下：

2、面向应用的能力计算（以游戏中心为例）

有两种业务分类策略会对容量管理有一定的影响。如下：

A、一级业务分类策略

B、多级业务分类策略

第一种策略，缺少一个层级关系，很难对容量管理进行归类分析；其次更扁平化的统计，会导致数据更加的被平均化掉，导致数据失真。

对于一级、二级的业务负载情况，大家也可以结合自己的项目情况，算法不一定要选择平均算法。比如说上图中管理服务底下有2台服务器，打包服务底下只有1台设备，此时如果计算游戏包的业务负载，我觉得可以用权重方法。让管理服务的权重为2，打包服务的权重是1，乘以各自的业务负载，最终可以得出游戏包的业务负载。同样，更上一层，也可以采用这个方法。简单的取权重的方法，就是把其底下的服务器数量作为权重值。

最终系统能够以上的设置进行计算，也根据应用的层级关系，实现如下的各级别的数据图表，达到辅助运维的目的。如下：

第二、架构服务能力

对于一个标准化的服务架构来说，里面提供很多种标准化的组件，这些组件肯定有着基准的能力，比如说前端web组件、分布式存储mysql、分布式redis cache的能力等等，这部分的能力基准可以做到和业务无关，来自于组件的性能测试基准。这个性能测试基准再结合业务使用模型，大致评估出架构服务在当前业务下的处理能力。这个很有意义，特别是在业务上线之前，一定要明确业务的需求和业务特点，把他们作为组件需求的标准输入，运维就可以准确的评估资源需求。通常我们可以见到前端web组件的ab测试情况，分布式cache在不同数据大小下的Get/Set情况，Mysql的OLTP性能测试TPCC情况等等。示例如下：

第三、接口服务能力

接口有点类似于现在的一个通行概念：微服务，从架构层来说，这块属于逻辑层的范畴。它在大部分的场景下，不能构成一个完整的用例，提供的是一种数据的读写能力、鉴权能力等等。一个接口提供的服务能力，是影响上层应用服务能力的重要因素。在目前大部分的技术架构中，这块能力的获取都存在着实现难点，1、源于各自实现协议不一。如果在一个基于标准化接口协议的实现中，接口的能力评估就非常简单，可以依赖统一的压力测试框架实现；2、源于接口太多，实现起来成本也非常的高。因此在当前的情况下，不建议去把这块的接口服务能力建设作为重点。

第四、应用服务能力

应用服务是用户侧能直接感受到功能或者服务，比如说游戏中的支付、登陆、领取礼包等等，对他们的能力的评估非常关键，是后续的系统规划、性能优化、扩容变更的参考数据，甚至是自动化调度。幸运的是，因为要提供给web端或者app端调用，目前这块基本上都是HTTP的实现，这就给给我们获取应用服务能力提供了一些标准化的实现。

对于HTTP类应用服务的能力只用关注两个指标即可，千万不要杂糅太多其他的指标：

1、吞吐量（throughout）。其实就是每秒能处理的请求数TPS，延时越小，吞吐量可以越高。

2、延时（lantency）。是我们接受的业务性能延时是多少？对于web网站来说，PC端，一般都是1s，移动端2-3s左右。不过在移动端下，google的挑战的目标也是1s。有了这个基准，这个时候就可以把不达标的比率计算出来。

其他的指标都是基于两个核心指标下的系统表现，比如说负载、jvm GC情况、IOPS等等。而这些指标是为了让我们看到系统性能上不去的问题原因可能在哪儿，比如说读写磁盘频繁、SWAP交换频繁、内存不足等等。

传统的性能测试方法获取到的性能基准是不准确的，因为没有模拟真正现网的用户访问请求分布情况（一个Webserver提供了十几个服务），单纯的压测某个应用服务功能获取到的结果，并不能作为未来容量预估的真实参照。

在这个地方提供几种简单的方法：

1、负载均衡器权重调整法

这种方法适用于海量的环境，比如说之前我们维护农牧场的时候，前端设备接近千台的时候，我们就会用LVS调整权重的方式，在一个LVS RS池中，把某个RS的权重不断调整增大，最后不断去观测吞吐量和延时的表现，但达到设定的基准的时候，此时把当时的请求情况记录下来，作为未来容量的基准。

2、Tcpcopy模拟法

Tcpcopy 是由网易技术部于 2011 年 9 月开源的一个项目。它应该是获取能力数据成本最低的一个方法，因此强烈的推荐。Tcpcopy可以将线上的流量直接导入到测试环境，达到实时的模拟线上的目的，还可以放大生产导入过来的流量，具体的资料大家可以网上找找。目前我们这边的测试组搭建了核心业务的Tcpcopy环境，这种环境能带来很多好处，比如说构建自动化测试用例、现网服务的自动化测试回归等等。

三、、能力管理的场景化应用

第一、成本优化

这是最核心和最直接的驱动力，特别对于运维的成本控制职能来说。通过能力系统，可以发现当前资源的负荷情况、接口及应用服务的性能指标，如果这些指标偏低，都应该去驱动运维、研发去进行优化。在资源的低负载层面，运维承担着首要的资源，需要进行资源合并或者虚拟化进行优化；而对于接口及应用服务的性能偏低，研发应该牵头去进行优化，运维提供更多的数据（比如说APM）进行协助，持续改进。因此我也建议在一个规模不大的运维IT环境中，由于成本优化动力不强，不要去着手能力系统的建设。

第二、能力预测

运维经常有月度、季度或者年度的资源采购计划，此时借助能力系统的预测能力来做未来的资源评估，一则基于数据预测可以更科学，其次可以大大缩短评估的时间和人力成本。这块的评估模型也不是太复杂，根据过往的历史数据，做线性预测或者指数平滑预测都可以。

第三、变更优化

在很多业务场景下，高负荷是会影响到业务的正常使用，因此我们需要对高负荷的业务做资源的优化，哪怕是扩容或者服务调整等等。

第四、自动调度

这个数据可以反向作用各类系统，比如说业务调度平台，架构服务平台等等。当发现资源或者应用服务处于一个高负荷的情况，可以定制自动化的调度策略做服务变更，实现了数据和自动化的完美对接。

四、能力系统的建设关注点

第一、资源服务能力带来收益最大，其次是应用服务能力

对于和应用关联的服务器资源高负荷能力优化，能够避免业务的异常；对于其低负荷的能力优化，能够带来成本节省，都有直接的可见收益，并且是运维能够完全控制。对于应用服务能力的优化，由于需要研发、测试的配合，从能力的建设来说成本偏高了一点，而往往研发又会用产品的需求作为挡箭牌，回避这块的优化。因此我建议，这块的优化，如果要做，需要把应用性能数据拿出来，直接告诉研发哪儿可以优化，那么他们就会无法回避。

第二、成本导向的驱动力最大

对于海量规模的互联网业务来说，上万台设备，只要从能力维度优化几个点，都能带来大量的成本节省。对于很多团队来说，成本的收益都是能直接感知到的。

第三、跨团队的合作

能力系统的建设不是运维组一个人能完成，还需要测试的参与，更需要研发后续的优化支持，只有团队之间的合作顺畅，才能让成本优化、性能优化变成大家日常关注点。

在以上的讨论中，我始终没有把人的能力纳入以及其他的一些ITIL概念纳入。主要考虑人的能力不好衡量，特别是在自动化能力不断提升的水平之下；去ITIL概念化，会让能力系统建设更简单，减少过多的干扰。个人认为：坚持成本优化和用户体验优化的能力系统建设，才能真正应用起来。

另外说到能力，我会联想到《教父》的一个开场，一个意大利人恳求老教父为自己主持公道，因为他女儿惨遭暴徒糟蹋和殴打，法律和警察却不能帮到他。教父如是说到：“你为什么要去找警察呢？为什么不先来找我？如果你找到我，我让那些人渣吃尽苦头....”,影片用一种对话式的方式展现了教父的能力。那么真正的运维能力系统，是否可以充当这样的角色？