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

1、【平台篇】运维平台之能力管理系统建设能力管理的建设就是数据化IT服务的能力!能力管理(Capacity Managemenl)应该是ITIL里面一个非常重要的概念， 有些人叫容量管理， 但我还是觉得能力管理更好一些，能力直接的理解就是我们能做什么？还有多少能力冗余？让我们来看看ITIL的概念解释，指在成本和业务需求的双重约束下，通过配置合理的服务能力使组织的IT资源发挥最大效能的服务管理流程，ITIL给到的流程图如下:InputsSub-ProcessesOutputs TechnohEY SLAs, SLRs snd Service Culogue Plans and Strategv IS

2、Plans arid Strategy Business requirements and volume5 Operation a schedules Oeployment and Development phn and programmes Forward Schedule of Change Incidents & Problems Service reviews SLA breaches Financiial Plans BudgetsBusiness Capacity Management：prototype, s/ze and d8rjt btfs/mss reqi/iremenrs

3、Service Capacity Management: 栉apjJeP fuitg 2“臼 report Ofl Efihrv/cff srbl/sAarrd pmffiesof ose Qf 触forsrv/c$Resource Capctty Management: rnori/fiar,畑nreportCO阳“MftoFT Of右灯/npo阳丹 belln9 dMcf proflite* Qf UE Q# ccimjpwffrCapacity Plan Capacity Database Baseliines and profiler Thrhold& nd alarms Capaci

4、ty reports (regular; ad *iOc and exception) SLA End SLR recommeridation Costing dnd charging recommendations Proactive changes and service improvements Rtvistd operaiionftl schedule Effectiveness reviews Audit reports从上图的中间部分可以看到三大子流程，业务能力管理、服务能力管理和资源能力管理对于以上的图中从输入和输出侧还可以看到很多的概念，如果真的要是对照到我们的日常的运维中，理

5、解这些概念都需要很长时间。 那么在我的讨论中， 我不会让大家去先理解这些概 念性的东西，结合互联网运维的实际，构建相应的能力系统。一、前言在讲能力系统之前，有些概念还是要和大家达成一致，这样有利于后续的进一步探讨。第一、系统的分层化理解在之前的【运维的本质-可视化】和【运维自动化平台的深度解码】中都出现过对数据或者 平台的一种分层化理解。 个人觉得这种分层的理解特别重要，能够让你很快的找到你要做什么。那么同样对于能力系统建设来说，可以套用之前的模型,给出一个分层化的归类,其中越往上能力的建设难度越大，在具体的项目过程中，考虑到建设的成本和带来的收益,些能力建设可以舍弃。在用户储的朕务餐力曲呈S

6、L是建盛了他 绍阂慕或者海户诜内倉门対由渲染）等爲应用服务层幕T協口京J斷面向护嗎戒書功就的眼务轲 叢.比50说注刖用户、港花登fik支忖裁尊表示一个业务眼务提供的接胆务供力.比5S1说菠取用户昵称、获刖用户碁瑞和料等架构脖务层在H底网版昼E.有僵多的公口爼件.妙须址够箱 确鋼0他门倒姬务能/L詩别足刈于存暗*说。评玄IT早础瓷添的熾事普力.仅块 聚炼在网第和胆务爲俪毎洼力。第二、CMD啲核心作用此时CMDB勺核心作用就来了， CMD啄统一定要把资源和IT服务的关联关系建设起来，并且要以一种合理的方式。这个地方重要的几个关系有：1服务器和应用的关系。这个关系可以帮忙在后续做资源服务能力建设的时

7、候，自动化的构建面向业务（应用）的服务能力展现。经验告诉我们，此时要非常注意，对于一个大型的互联网业务来说，应用最好以树的结构存在，否则没法表达复杂的业务关系，其次一个服务器可能和多个应用有关联，需要支持一对多的关系表达。之前早期的YY资产系统就用的一级结构表达且只能一对一， 最后整个服务器和应用之间的关系根本没法维护，根本就不可用。服务器和业务的合理结构图如下：主机呂曲 9LSPis堆主目蛊人&11S庶用中诲戏中心1九:彬，一存lit平旨常匚，；K，薄曲中心，扎薪扼 一有师辛自官耳后台虫吐中，【“苣占*芒島4站甫茂中右腔茸活台虞品撤r用& k生修G a U序& S ；另外CMD陋需要提供一个

8、基础的 CMDBk务分类的管理能力。这个业务分类不能太深，不 建议超过四级；其次业务分类树最好统一级别，这样更容易管理规范化，人太随意，随意之 后会影响其他系统数据的准确性。当前我们的业务分类示例如下：游我中心-游就包管理系境管理腮勢D打包服务包同歩脈筲口包菅瑾搦口 包同步客户端D局盟渠道包相对槌揺腮务0打包服劳（BO）匸游戏色管理系统m声qlL :游我包管理亲统 儁隼群同Imysqll I- 游试大厅比赛斗地主D象棋斗牛D斗地主I）宝石大作战 日拱茬 ：億州扑克 -站到底U屏将天厅朋务.酬瑚乐2、服务器和组件的关系这份数据主要是来源于持续部署系统的数据沉淀，持续部署系统把某个包部署到哪些服务

9、器上，需要通过CMD骸口把关系沉淀到 CMDE中,因为很多技术指标是包关联的。它对于后续自动化管理接口服务能力和应用服务能力起着至关重要的作用，能够打通数据之间的关系。第三、能力基准-高负载、低负载对于不同的业务（应用）来说，甚至是应用内不同的功能模块，能力高低标准是不同的，主要是和业务的需要相关性能大。比如说对于核心业务来说，可能能力标准设定在一个很低的水 平，考虑突发业务的需要；而对于一个平稳期的服务来说，可能能力标准就会设置得高一些，比如说80%因为业务本身没有太大的变化。对于负载偏高的资源、接口或者服务，我们称 之为高负载或高负荷；反之称之为低负载或低负荷。此负载不是系统的Load A

10、verage。二、分层的能力系统建设第一、资源服务能力网络的服务能力很好计算，就是考虑上下行的带宽能力。那么和应用关联最大的就是服务器的资源服务能力，并且也是变化最频繁的一块能力。对于一个服务器来说，它能提供的资源只有四类：CPU十算资源、内存资源、磁盘的 10资源和网络10资源，除了这四类资源，别 无其他。所以大家在做能力系统建设的时候，有时候会把load average 考虑进来，非常的不合适，有点本末倒置的感觉。1服务器的能力计算方法f（x）=max（cpu 能力、内存能力、网络能力、10能力）。CPU能力的计算公式： 直接使用cpu的使用率作为能力使用情况，最好把单CPU的使用率也纳入

11、基准，而不仅仅是汇总的 CPU这个地方可以发现那些资源使用不均衡的情况，特别是 一些单进程的daemon程序。内存能力的计算公式：其实把内存纳入计算是不合适的，对于很多服务来说，内存要么不够， 要么多余。对于不够的情况，应该纳入到监控范畴去发现问题， 通过服务迁移或者优化来解 决问题。所以这个地方可以忽略。网络能力的计算公式：对于大部分应用来说网络IO都是足够的，但不排除几类业务场景，是典型的网络IO敏感性的。比如说缓存类的、图片类、存储类，还有一种小数据包类的服 务。对于以流量为主要考察维度的能力来说，可以直接把网卡的理想能力作为基准（千兆网卡），用直接的业务流量和他作除；把包量作为能力维度

12、来说，可以设定一个包量的基准， 比如说负载均衡转发类的设备。最终都获取到服务器网络的一个能力使用率。磁盘能力的计算公式：磁盘能力也直接取磁盘的 util的指标，不要IO的读写次数那类指标，看IO是否繁忙就可以直接用 Util或者lOWait这个指标来计算。有了以上四块的资源能力（百分比），我们可以直接取以上四类指标中的最大值作为这个服务器当前的能力情况。对于一个服务器来说，能力最终会转换成一个百分比指标（负载），然后和我们设定的能力基准（高、低）进行对比。如果低于某个水平，则认为服务资源使用不充分；如果高于某个基准值，此时则认为服务器资源的能力无法支撑业务的进一步发展。举个实际的例子：EI?u

13、9H2014/fi：9201W102016/112014j&12201W132014J&15中均员勒CPUM2D23261930202022630Idvd ：(% i40383G册533829415Smemoy(%別6020436?546250.867netwark ii)0占O.t0.MU.340780.69O.Gb仁LI0.8360.80 4er.oo%采集1星期的苦类资画便用情尿*这餐身入的最高三个点t去掉毛利,精取平均值，JI盾再取囚类资原利用率中的最亢 宿*汁豆會我.闿刊tt畠 MLBQMj最丈员67*4聊毎行特标的區高二亍点.作平半b證厉再选靱昜大的值.作为腥奔器代栽.比加说如畑豆

14、刑尿衣寅戢牯皆闪站工藩应的 尺戟手“為.在具体的容量系统中，可以提供一个界面来设置这个容量计算策略和基准。如下:|7CPUfl*用宅獻认r憾盘空间便周率p外网入也豊戯认）蔽阿网入赳量猷认Jrw那网出包屋飲询17內网出包量歓认】F畀FU適壘戯AJW内阿入桃量猷认JP外阿出逋塞獸认j17冈列tt源量戡认】厂瞪蛊心濮rOft 10rCPUIftfer亚均等特町间irl特性名祢计mjULMlIWi1D10 |OI 10 lionI WD |i I5000050000500005000030Q0D0 |300000 I3ODDD0 2、面向应用的能力计算（以游戏中心为例）有两种业务分类策略会对容量管理有

15、一定的影响。如下:A、一级业务分类策略游戏中心I I服务器1 服务器2 服务器3 .服务器N前提*1. 树的深度是22、子节点是数掲节点计算方法1每个节点胃个值，I6ST均模型 最后得出目标值是（jc1+x2+TJ轩*师） /NB多级业务分类策略前尿I*设定理的浑直筑2. 暫据节卢都在叶子节卢.上3. 非吋子节卢的型锦苗拦由叶于节 卢算出耒乩叶子节卢的敎号刊之前的叶子节 点款环栢等计算过稚11. 时三绒这辰的能力悄，哥平均算2、对一一沁迪匡的能力伯.星在吝目的三层书朮上能力平均卄鼻：第一种策略，缺少一个层级关系，很难对容量管理进行归类分析；其次更扁平化的统计，会 导致数据更加的被平均化掉，导致

16、数据失真。对于一级、二级的业务负载情况， 大家也可以结合自己的项目情况，算法不一定要选择平均算法。比如说上图中管理服务底下有 2台服务器，打包服务底下只有1台设备，此时如果计 算游戏包的业务负载，我觉得可以用权重方法。让管理服务的权重为2,打包服务的权重是1,乘以各自的业务负载，最终可以得出游戏包的业务负载。同样，更上一层，也可以采用 这个方法。简单的取权重的方法，就是把其底下的服务器数量作为权重值。最终系统能够以上的设置进行计算，也根据应用的层级关系，实现如下的各级别的数据图表, 达到辅助运维的目的。如下：开Em 0DwIT3U*1UK1越上3亠 一i三 y I0i皿.一第二、架构服务能力对

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

18、：Client总据护藍:字节执存时阖1平均建握虽g失験莘厲）1024Client100 垢)3002.卿灿0.04IM6. 40L6W0,0000512Client1CHJ 后3004.2W仇如00200 (iS)10. S17B0.0000Client1(H) (W)300畫嶺皿O,KW200 (谏)12-OftSW0,00128Clien:100环3004l20012 36YW0.0000Client曲擔抚爭：宇节數IE運井釵故于均处1034Client120 (W)MO2” 6674W0.0000丽卡氐00时0. 90002046pliejit300L 70&1#认 000020( i3

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

20、功能或者服务，比如说游戏中的支付、登陆、领取礼包等等，对他们的能力的评估非常关键，是后续的系统规划、性能优化、扩容变更的参考数据，甚至是自动化调度。幸运的是，因为要提供给 web端或者app端调用，目前这块基本上都是 HTTP 的实现，这就给给我们获取应用服务能力提供了一些标准化的实现。对于HTTP类应用服务的能力只用关注两个指标即可，千万不要杂糅太多其他的指标：1、 吞吐量(throughout )。其实就是每秒能处理的请求数TPS,延时越小，吞吐量可以越 高。2、 延时(Iantency )。是我们接受的业务性能延时是多少？对于web网站来说，PC端，一般都是1s,移动端2-3s左右。不过

21、在移动端下，google的挑战的目标也是1s。有了这个基准，这个时候就可以把不达标的比率计算出来。其他的指标都是基于两个核心指标下的系统表现，比如说负载、jvm GC情况、IOPS等等。而这些指标是为了让我们看到系统性能上不去的问题原因可能在哪儿，比如说读写磁盘频繁、SWAP交换频繁、内存不足等等。传统的性能测试方法获取到的性能基准是不准确的，因为没有模拟真正现网的用户访问请求分布情况(一个Webserver提供了十几个服务)，单纯的压测某个应用服务功能获取到的结 果，并不能作为未来容量预估的真实参照。在这个地方提供几种简单的方法：1、负载均衡器权重调整法这种方法适用于海量的环境， 比如说之前

22、我们维护农牧场的时候， 前端设备接近千台的时候， 我们就会用LVS调整权重的方式，在一个 LVS RS池中，把某个 RS的权重不断调整增大，最 后不断去观测吞吐量和延时的表现，但达到设定的基准的时候，此时把当时的请求情况记录 下来，作为未来容量的基准。2、Tcpcopy模拟法Tcpcopy是由网易技术部于 2011年9月开源的一个项目。它应该是获取能力数据成本最 低的一个方法，因此强烈的推荐。Tcpcopy可以将线上的流量直接导入到测试环境，达到实时的模拟线上的目的，还可以放大生产导入过来的流量，具体的资料大家可以网上找找。目前我们这边的测试组搭建了核心业务的Tcpcopy环境，这种环境能带来

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

24、度或者年度的资源采购计划，此时借助能力系统的预测能力来做未来的资源评估，一则基于数据预测可以更科学，其次可以大大缩短评估的时间和人力成本。这块的评估模型也不是太复杂，根据过往的历史数据，做线性预测或者指数平滑预测都可以。第三、变更优化在很多业务场景下，高负荷是会影响到业务的正常使用，因此我们需要对高负荷的业务做资源的优化，哪怕是扩容或者服务调整等等。第四、自动调度这个数据可以反向作用各类系统， 比如说业务调度平台，架构服务平台等等。当发现资源或 者应用服务处于一个高负荷的情况， 可以定制自动化的调度策略做服务变更， 实现了数据和 自动化的完美对接。四、能力系统的建设关注点第一、资源服务能力带来

25、收益最大，其次是应用服务能力对于和应用关联的服务器资源高负荷能力优化，能够避免业务的异常； 对于其低负荷的能力优化，能够带来成本节省，都有直接的可见收益，并且是运维能够完全控制。对于应用服务能力的优化，由于需要研发、测试的配合，从能力的建设来说成本偏高了一点，而往往研发 又会用产品的需求作为挡箭牌，回避这块的优化。因此我建议，这块的优化，如果要做，需 要把应用性能数据拿出来，直接告诉研发哪儿可以优化，那么他们就会无法回避。第二、成本导向的驱动力最大对于海量规模的互联网业务来说，上万台设备，只要从能力维度优化几个点，都能带来大量的成本节省。对于很多团队来说，成本的收益都是能直接感知到的。第三、跨

26、团队的合作能力系统的建设不是运维组一个人能完成，还需要测试的参与，更需要研发后续的优化支持，只有团队之间的合作顺畅，才能让成本优化、性能优化变成大家日常关注点。在以上的讨论中，我始终没有把人的能力纳入以及其他的一些ITIL概念纳入。主要考虑人的能力不好衡量，特别是在自动化能力不断提升的水平之下；去ITIL概念化，会让能力系统建设更简单，减少过多的干扰。个人认为：坚持成本优化和用户体验优化的能力系统建设，才能真正应用起来。另外说到能力，我会联想到教父的一个开场，一个意大利人恳求老教父为自己主持公道，因为他女儿惨遭暴徒糟蹋和殴打，法律和警察却不能帮到他。教父如是说到：你为什么要去找警察呢？为什么不先来找我？如果你找到我，我让那些人渣吃尽苦头.”,影片用一种对话式的方式展现了教父的能力。 那么真正的运维能力系统，是否可以充当这样的角色？欢迎您的下载，资料仅供参考!致力为企业和个人提供合同协议， 策划案计划书，学习资料等等打造全网一站式需求