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

【平台篇】运维平台之能力管理系统建设 能力管理的建设就是数据化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敏感性的。比如说缓存类的、图片类、存储类，还有一种小数据包类的服务。对于以流量为主要考察维度的能力来说，可以直接把网卡的理想能力作为基准（千兆网卡），用直接的业务流量和他作除；把包量作为能力维度来说，可以设定一个包量的基准，比如说负载均衡转发类的设备。最终都获取到服务器网络的一个能力使用率。