第十三章 稳定运维，快速交付，以人为本（1）

第四篇 运维管理之道

当运维对象达到一定规模，复杂度会陡增，你会发现哪怕是记录简单的管理对象密码、堡垒机等信息都要几个excel，何况各种复杂的配置资源。运维管理的两个重要职能快速与稳定，既要做得快，又要不出问题，ITIL给了我们一个参考库，在这一章你将看到具体如何实现，包括配置管理库的如何设计，监控如何管理，变更实施的安全性如何保证，最后我们将回到人员本身，谈一谈运维这道手艺，以及ESNS在运维领域的重要性。

 

第十三章 配置管理

日常运维工作中常会寻找我有哪些运维的组件？它属于什么区域？它的IP是什么？它的变更关联影响是什么？能回答以上问题的数据，我们称之为的配置管理信息，存储这些数据的源称之为配置管理数据库，简称CMDB(Configuration Management Database)。英国商务部出版的《ITIL服务支持》一书这样定义CMDB：“它是一种包含每一个配置项（Configuration Item，CI）全部关联细节，以及配置项之间重要关联细节的数据库”。
    CMDB可以说是运维管理的资源地图，它告诉我们有什么、在哪里、什么状态、如何关联。首先定义好CI，包括物理硬件，如交换机、路由器、防火墙、服务器，也包括逻辑软件weblogic、apache httpd、nginx。为了准确标识CI，需为其定义属性，如唯一性、版本、大小、状态，随后进行CI的组合与关联，最终形成业务视角的逻辑实体。在这些信息外围还有大量附属信息，如登陆的堡垒机、用户名密码等，建立一套完备而精准的配置管理库是一个长期的过程。
    配置管理是运维管理的基石，它与监控管理、容量管理、事件管理、变更管理直接关联，向后者输出有效信息，支撑数据中心运转。IDC灾难恢复的首个系统往往不是交易系统，而是你的配置管理系统。在后续章节中我们还会详细说明与其他模块与配置管理的关系。
    在新项目、任务建设初期，为了加快整体进度，常常忽略了配置信息的录入，通常在一张本地的excel表格中保留相关信息，随着项目接近尾声，项目转运维进入标准化轨道后，配置信息的缺失常会引发大大小小的问题。必须建立一个有效的变更管理流程，在其中嵌入配置管理步骤，重视配置，保证配置先行，提前申请、登记好配置项。
    实际运维工作中还会出现不加区分的将各类配置项录入到CMDB中的情况。运维人员不得不做很多繁冗、重复的无效工作，手动录入低价值的数据，渐渐劣币趋良币，有价值的数据淹没在垃圾浩海之中。CMDB应该只包含那些计划将要积极去管理的配置项，并且通过各种方式让运维人员摆脱重复性工作，比如CI自动发现、提升录入界面用户体验等等。
    配置管理系统应保持一个持续迭代更新的过程，有专门的开发团队支持，而不是一个固定不变的产品。小型企业可以通过wiki、文件夹共享等方式临时性解决问题，中大型企业则必须拥有自己可控的配置管理系统。不应采用封闭、难客户化的系统，而要求开放自由、易扩展。配置管理系统不仅是用来保存数据，由于它的频繁使用，更应注重用户体验，让运维人员舒服的使用，从而提升日常工作效率。

 

   

13.1 配置管理系统分析

13.1.1 服务模型进行分层

CMDB的构建过程是一个庞大工程，涉及IDC管理团队与部门非常之多，如果要将整个IDC所有的CI分析、设计并进行关联生成最终的完整的服务视图需要花费2~3年时间。一般很难完整的从下往上构建，比如从IDC的机房、机柜信息开始分析CI，往上到硬件服务器、网络设备，最终一步一步延伸到顶层的服务，如图1；我们可以看到CI处在服务模型中，我们可以对其进行分层，典型划分方式包括：物理空间层、物理设备层、逻辑主机层、逻辑组件层、应用系统层、业务服务层。物理空间层包括机房、机柜、机架；物理设备层包括服务器、网络设备、防火墙、存储、加密机硬件等；逻辑主机层主要是附属在物理设备上的操作系统，比如redhat、windows、ESXServer，除此之外还有与存储相关的nas、lun卷信息；逻辑组件层主要是OS上的一切中间件、数据库；业务系统层则是由下层组件组合而成的业务系统。业务服务层是具体的业务公司对外提供的系列服务。

图一 IDC管理团队在分层模型中找到自己的位置

IDC管理团队必须对CMDB模型分层达成共识，清楚自己所在的位置，一个管理组所运维的CI可能在多个层上都有体现，我们只需要找到大概位置，比如网络小组的管理的CI，网络硬件设备属于物理设备层，网络区域属于逻辑主机层。

13.1.2 各IDC团队发现CI

各IDC管理团队在清楚自己位置，明白上下游关系后，开始寻找自己所管理的CI，通常有以下几种方式：
1.在IDC管理团队负责的资产清单中整理出CI。资产并不一定由运维团队负责，有些组织中有专门的资产管理中心，从运维团队、资产管理团队日常交互的信息中可以挖掘出大量的CI，而这些CI一般分布在物理层面，例如服务器、网络设备、存储设备等。
2.在IDC管理团队日常工作面对的组件中整理CI。以系统组、中间件组为例，他们每天工作面对得最多就就是操作系统以及运行在OS上的各类中间件进程了，运维团队整理出这些对象，并抽象出能够表示、承载这些对象的CI。在这里强调下抽象与实现之间的折中，在面向对象的设计中强调面向接口编程，抽象出所有对象的共性，对CMDB而言则无需完全遵循这一点，暂时忽略掉抽象的通用性、扩展性，而将CI聚焦在组织中最常用的对象上，如果你组织所使用的90%的中间件都是weblogic，你就有必要为weblogic建立一个单独的CI，将它的基本属性与关联关系独立出来，同时在未来CMDB的界面设计上也要精耕细作，注重用户体验。
3.由运营应用管理人员从业务角度定义CI。运营人员所属的业务服务条线就很好的定义出了业务服务CI，而他们直接管理的子系统则是应用系统CI，应用系统CI又有大大小小的逻辑组件组成，他们之间有集群、组合关系，这些细节暂时无需关注，重点是找到当前层面的CI，并与下游层级做好对接。

图二 各管理团队寻找自己的CI项

配置管理项要与资产管理项严格的区分，两种信息的用途完全不一样，配置管理用于日常的运维，而资产关乎于IT成本核算。根据三种方式筛选出各层级、团队的CI后，开始对CI进行抽象提炼，CI的抽象以功能、组织占用比来提炼。“硬件设备”可以看成是物理设备层最高级别的抽象，我们可以将网络设备、服务器等各类具体实现映射到”硬件设备“这个CI之中，但这种抽象粒度的太过于宽泛会为后续的CMDB表示层设计用户体验提升造成很大的阻碍，我们必须以硬件功能将CI项进一步的具体化，"PC服务器"是运行在x86架构上的服务器，”交换机"是负责二层网络转发，“路由器”负责三层网络数据包选路，“防火墙”负责网络安全控制，这些功能特定并在组织内占有一定比例的CI单独建立。回到抽象层面上，我们有必要保持一个抽象的”硬件设备“CI来存放特殊、组织未标准化的设备，比如加密机、第三方软硬一体设备、应用安全控制硬件，这类非标设备常常因为没有一个合适的CI定义而造成信息遗漏。在CMDB中建立CI项只存在关联关系，而没有继承关系，这与面向对象的设计截然相反，尽管我们定义了”服务器“、”交换机“、”硬件设备“几个CI，但它们之间是没有父子继承关系的。在CI模型分层中进入逻辑层后，标准粒度的CI应是动态的、运行中的对象，如独立的操作系统或在单一操作系统上提供同一服务的单进程、进程组，而不是一个软件。不用担心对象的粒度无法组成一个完整的服务，在逻辑层面上我们可以通过定义“集群”、“组合“等各种关系将这些CI对象拼装层合适的CI。

13.1.3 IDC管理团队定义CI属性

  很快我们手上有了一批合适的CI清单，我们还有大量数据来说明CI是什么，这些数据可以用来作为CI的属性，我们有什么方法从这些数据中发现属性信息？我们将CI的属性分为六类：核心、附属、控制、服务、关联、扩展，下面我们对这些属性类别进行逐一说明。

  核心（core）：运维工作中在操作该CI时经常要使用的信息，具有唯一ID、命名、生命周期、易变化等特征。核心属性维持了CI在整个运维管理工作中的有效运转，其中的每一个属性都是必要的。
  唯一ID：表示当前CI在CI对象集合中的唯一性，数据库表字段unique id递增序列保留增长容量空间可以适用大部分CI属性要求，唯一id与CI本身所代表实体的没有关系。
  命名：命名与唯一编码的不同之处在于命名是在前台可见的，它是印在到CI实体内容之中的，命名本身就包含了唯一标识作用，同时还附带其他说明。我们所说的印在主要指逻辑层面上，比如一个操作系统命名为CNSZ031415，一个weblogic java进程加入SERVER环境变量chs-coreStg7891，这个名称是“活生生”的，可以通过程序在运行态的实体中动态寻找，这为以后的的自动发现、自动化运维等工作埋下伏笔。命名内容是组装而成，我们应当精简命名，命名体现我们最关注的，其他关注点在单独的属性中体现，不同层级关注点不同。”CNSZ031415“，"CN"表示中国，”SZ"表示深圳，“03”表示测试环境，1415是主机层面上的序号分配，以上命名信息解码可能是一个系统管理员所关注的。而在中间件层面与应用系统联系的比较紧密，因此命名中要体现出所属的应用系统，“chs-coreStg7891”中，“chs-core”是子系统名称，Stg是环境名称，7891则是序号。
  生命周期：一个CI项也有着“从摇篮到坟墓”，从自然中来到自然中去的过程，在不同时期的的管理级别有着不同的要求，生命周期不仅仅作为一个状态存在，还可以作为一个期限而存在，资源管理中为了保证所有资源合理而有效的利用，常常定义一个资源“释放”期限帮助我们对CI资源进行管理。
  

  控制（control）：控制属性与CI本身也没有关系，它关注与权限、审计、版本等控制方面，这些属性在整个CMDB中是通用的。值得我们关注的是权限、审计、版本这三个控制属性在映射到数据存储对象后的位置截然不同。
  CI的操作权限是受到用户所属角色、组织、单位限制的，我们在CI元数据中定义此属性，但此属性不是说明我属于谁、属于那个组织，而是说明我是谁，属性表示的是“我是银行的服务器”，通过后面的关联，我们可以导航到“我是一个跑着weblogic java进程的服务器”、“我是一个为银行信贷应用服务的weblogic java进程服务器”，在这些属性说明中没有做我们那些不该做的事，我属于谁、属于哪个组织，我仅仅说明我自己。权限的切入点不能放在CI之中，比如在CI中定义“银行”、“信用卡服务组”、“李四”这样的组织、人员信息以标识它的权限，这样的设计会让后续CMDB的维护难度大大加大。权限的切入点要放在"行为”、“属性”两个层面，对于服务器的读写权限中的读写是一种“行为“，我们应该做一个行为的拦截器对权限进行控制，这是放在CI之外的，而”属性“层面则是通过属性内容由”规则“去自行判断的，规则控制这权限，”规则“有时剥离在CI之外的，”我是一个为银行信贷应用服务的weblogic java进程服务器“，在这个CI配置项的表述过程中它表达的是自己的属性，而”只有为银行应用服务组服务的基础架构人员才能修改银行机器，且只能修改weblogic java进程的PC server“，这是一条规则，规则是权限控制的逻辑，而权限控制的输入是当前操作人员的所属属性、CI控制属性，输出是”你是否可以操作“。CI的控制属性不完成权限控制工作，它是权限控制实现的输入元素之一。
  审计告诉我们谁在什么时候新增、修改、删除、甚至查询了CI对象，CI的审计信息量视情况可大也可小，审计功能可以做成定制化开关，控制数据库容量。为了做好版本控制，如果每次对CI的变动都保存完整的CI信息以及其所有关联的CI当前版本信息，这会大大增加开发复杂度以及增加DB数据存储量，从经验上看没有必要在所有的CI上定义版本号，而是通过”变更快照“、”审计对比“功能中附带的完成版本控制工作，变更快照帮助我们对操作CI的上下游配置信息进行快照，并保存在当前变更流程中，由于CI变化只与变更有关系，在变更流程中启动快照，在数据库结构化信息之外保存CI信息，即可完成未来异常问题的查询。另一种做法是在开启了审计功能的CI上记录每一步修改的内容，根据这些修改信息我们一样可以完成故障信息的收集以及版本回滚。

  服务（service）：运维管理工作最终提供给用户的是服务，而不是一个主机，一个进程，服务属性与CI属性也没有直接关系，而是与服务流程相结合，分析关联影响。你可能要问一个属性怎么来识别分析影响？首先，服务属性一般在分层模型中的应用系统层，例如我们对”承保系统“定义：一级核心、运维时间：23:00~24:00、是否冻结等，这些属性都是围绕着服务、应用而言的。下一步我们会分析CI之间的关系，这些服务属性是向下继承的，当我们安排变更操作一台服务器时，进入变更流程后就会自动的发起关联影响分析，你会收到询问信息，”你确定要维护这台机器吗？他是承保系统，已经冻结变更，并且维护时间只有一二小时哦？“真正的变更影响分析是通过服务属性、CI关联、属性继承来进行的。当然，你可以完全忽略这些CI关联影响评估信息，但金融类IT运维以风险控制为中，变更安全粒度要求非常严格，什么时间点可以做什么事要求通过CMDB中的数据进行分析，输出一份准确报告。

  附属（attached）：这些属性一般是可选的、固定的，与实际运维工作无直接联系，仅仅是帮助我们更进一步了解CI。例如CNSZ031415服务器，它的CPU主频是3300MHz，这个主频就是附属属性，附属属性由于其稳定性，常常批量导入、默认设置。

 关联（associated）：CI属性中一个非常重要的种类是关联，它表示CI之间以一种什么样的关系组合在一起，形成一个面向服务、应用的整体。我们认为CI之间的关联也是一种属性，这类属性具有双向导航特性，可以由一个CI找到上下游、平行层级的关联CI，关联属性的定义我们在下一步详细讨论。
 扩展（extend）：扩展属性是为一线运维人员服务的，他们以文档、图形、模板、服务目录、应用档案等非结构化数据方式组织起来，关联到外部的知识库、运维规约、应用档案，告诉一线运维人员操作方法、生产风险、一般规则。

13.3.4 确定CI间的关联

  确定CI之间的关联关系过程也相当具有挑战，关系的设定决定了以后在使用过程中对配置项的快速定位与影响度分析的有效性。不同的CI之间会有不同的关系类型，相同的两个CI对象之间还可能有不同的关系，而且关系的确定也需要有适当的粒度，关系的保留采用“有用性”原则，也就是对业务来说是有用的。忽略那些对业务不影响的关系类型。CI之间的关联关系类别限定在四种范围内：组合、集群、使用与依赖，除此四种再无其他关联关系。
  CI之间通过关联关系最后组成一个一件完整的“产品”，我们不会按照大多数ITIL软件一样对这个产品分解成层次结构型体，这种提前定义一个CI所属层级会让CMDB失去灵活性，很多情况下一个CI在不同的产品中属于不同的层级，这里的层级与服务分层模型层级是不一样的，这里的层级是相对于最终拼装组成的完整产品而言。产品结构层级对于工程领域产品配置项来说非常有效，一个产品的组成部分是固定的，而产品组成的元素关系相对于虚拟软件而言更靠近现实世界，大部分可以采用依赖关系。而IT“产品”很难用工业产品标准化的方式将服务、应用、进程、OS、硬件资源组合起来，不同的应用有着不同的组成元素，并且随着IT的演变，组成组件的类别与关系也在不断变化，另外，即便是同样的组成形式，IT“产品”组成元素之间的多重性也在变化，在应用访问量预计大增时，应用服务器集群的量会陡增，我们没有必要用产品层级的方式将CI之间固定起来，而是应以一种灵活而零散的方式自由组合我们CI。
  依赖：表示一个CI的存在强依附于另外一个CI，依赖追求CI间完整性，禁止CI独立存在后产生的垃圾数据。进程与OS之间就有这样一种依赖关系，在添加一个weblogic进程实例时我们要求必须录入它所依赖的OS，进程脱离了所运行的OS则没有任何意义。依赖关系也会产生一些问题，由于强依附关系的存在，CI链可能因为某一个CI确实导致整体信息的录入延时，回到我们的例子，weblogic和OS对象在不同管理团队运维，中间件组录入weblogic信息时强依附到系统组的OS，而系统组不一定录入了OS信息，从而中间件组也无法录入。必须在变更管理中建议有效流程保证相互依赖的CI信息有序录入。
  组合：表示一个CI由哪些其他CI组成，是一种“整体与部分”的关系。组合关系相对于依赖的强制性要稍微弱一些，可以独立创建一个CI，之后再陆续补充它的组成CI。一旦组合关系建立后，下层被组合CI的生命周期就与上层CI联系上，在这里产生了一种强制关系。车险承保系统由weblogic中间件组成，我们可以单独创建车险承保系统，后续再添加weblogic进程，一旦这种关系建立好后，它们的生命周期就统一起来了，如果要下线车险承保系统，就必须先下线下层的weblogic进程，这种生命周期的传播是从上至下的。组合关系适用与下层CI唯一服务于上层CI的情况。  
  使用：标示一个CI将另一个CI作为资源CI使用，这种关系是松耦合的，oracle数据库使用了一个存储lun卷，即便lun卷不存在，oralce数据库还是能够运行，它可以将数据存储到其他卷上去。现实世界里不会出现CI间完全松耦合情况，提出这种关系，是为了保持CMDB的灵活性，我们无法界定组合、依赖关系时，我们会将CI间定义为使用关系。
  集群：集群是IT领域常出现的概念，它表示一组对象共同完成一个任务，对象间有主备、并行、优先级等进一步关系，集群后形成一个逻辑CI，比如10个weblogic进程集群对外提供服务，他们是并行的，两台ESX vmvare设备互为主备等。在运维领域的集群会引入负载均衡、容错、高可用的术语的讨论。集群是4种关系中比较特殊的一种，伴随着关系的建立，集群（cluster）中的每一个成员（member）间还有亚层次的关系，如果是优先级，成员都有一个级别属性，如果是主备关系，成员会标明为主或备。这在设计CMDB数据模型是要提前考虑。

  

  

读者可能会好奇，为什么关系只有这四种，下表列出了CMDB中一些常用的关系，现实世界中的关系可以被描述成很多种。CI与面向对象设计不一样，CMDB并不强调父子继承关系，即便有这样的一层关系，也会通过定义两种不同的CI实现。而对于其它各种关系的描述我们可以映射到“依赖”、”组合“、”使用“与”集群“上。

编号关系说明示例备注1安装在..上Install on数据库安装在主机上依赖2连接关系Connect with主机与网络相连使用3依赖关系depend on应用依赖于中间件依赖4父CIparent进程与它的一个具体实现，父是进程（process)不使用这类关系5子CIchild进程与它的一个具体实现weblogic，子是weblogic不使用这类关系6物理关联associate with主机与存储关联使用7文档关联with doc某软件有某文档使用8使用关系use谁使用某PC使用9监控管理admin & monitor谁监控某机器使用10组成关系consist of销售系统由主机、DB和中间件组成组合11运行于…上perform on应用运行于OS上依赖12备机standby主机A是B的备机集群

在建立好合适的关系后下一步是确定关联对象间的多重性，它用来指出可被允许生成的关联CI数量，即最多可以生成多少数目（上限），最少不得低于多少数目（下限）。关联的两端以"下限..上限"的格式标示出多重性。星号（*）代表不指定上限，下限最低为0。CI的关联关系、多重性确定后，也就完成了CI间导航功能，我们可以根据一个服务CI生成一颗该CI所引用的资源树。
  除了以上四种关系外，还可能有一种独立的系统层面的关系，比如A系统调用B系统，这种关系有助于我们生成应用间服务架构图，这种关系不是在配置管理层面，如果要做成一套大而全的系统，这种情况的关系则需另外考虑。
  

13.2 配置管理系统设计

  CMDB已拥有一个非常成熟的市场，可以采用商用、开源、自主研发三种方式来实现我们的CMDB系统。从下面的结构图来讨论配置管理系统设计的三个方面：用户界面、数据模型、附属功能。

  图~~~

  13.2.1 用户界面设计

  用户界面直接面向配置管理员以及其他IT运维管理人员，他们有职责定义CI、管理与使用CI属性以及确定它们之间的关系，并将他们关联上运维操作与管理流程。配置管理系统不是用来存储冷冰冰的数据的，在运维管理中，配置管理、监控管理系统的使用频度要远远高于其他系统，在界面上关注用户体验是无形中提升运维效率方法，好的IT运维经理应该时刻关注一线人员的情况。

  CI管理：配置管理员、IT运维管理人员对CI的操作，可以简单的认为只是日常简单的增删改查。用户体验的提升就潜藏在这基本功能之中。
  对于复杂的一屏下来几十个字段的CI，我们应该分屏、向导式的一步步引导运维人员录入数据；具体说来，在进行CMDB界面设计时，要通过各种视觉手法来告诉用户，这个向导过程总共有哪些步骤、用户已经完成了多少步，以及还有多少步未完成等信息。这些要求其实是任何信息导航设计所要达到的一些基本目标。如果一个界面设计达到了这些目标，它就能使得用户具有一种对整体的把握感。当用户看到自己所完成的每一步所带来的进展以及他在整体上正在一步步地向成功接近时，他就会更加有信心并愉快地完成整个任务。在向导结束前，将用户的输入以某种方式显示给用户以便确认，并且越及时越好。这一准则应用了反馈原理。该原理指出，任何同人进行交互的系统，都需要将其内部状态以某种方式表现出来，尤其是要对用户的输入动作进行反馈，只有这样，用户才能知道系统是否检测到并接受了自己的输入，以及自己的输入是否正确，这样用户才能进行相应的后续操作，比如调整自己的输入或改正错误。缺乏反馈的系统会让用户感觉茫然和焦虑。向导式界面是一种着眼于帮助人们处理复杂任务或不常见任务的交互策略。为了更有效地达到上述目标，我们需要对其中的很多交互细节加以认真处理。对于常用的输入，应尽可能采用自动补全的方式，运维管理人员输入部分有效的信息后就能自动查找、关联到所需CI。CI属性的选择是有规则限制的，比如一个WII区安全区域的weblogic就无法运转在APP区域的host上，这些规则要提前定义好，并提早过滤掉干扰选项。网页上减少全屏刷新，通过ajax局部范围的更新内容，递进式层级显示数据。各CI管理菜单应按分析出的服务分层模型归类。无论底层的数据库schmea如何灵活的设计，也没有办法将CMDB前端完全产品化，用户体验的提升是在配置管理系统反复迭代的开发过程中实现的，IT运维团队应当有一个专职的开发工具团队在后端支撑运维工作。

  

  报表与查询：报表功能可以实现依据不同的属性组合进程查询、检索CI集合，定制IT运维管理所需要的报表清单。在CI查询上，由于CI的类别特别之多，要提供一个类似于搜索网站统一查询页面，按大类划分，无论是何种CI关键字，都可以在一个查询界面中搜索到结果。

  图形化：配置管理库的一个基本功能是将CI之间的关联关系图形化展示出来，可视化应当对CI对象进行树形结构展示；另外CI集合还要能最终组合成IT系业务视图。CI可视化的另一个重要功能是对网络拓扑支持，依据IDC情况对网络拓扑分层展示，下面是一个三层网络拓扑展示功能。

三层展示核心网络骨架

第一层：数据中心(IDC)、职场、租用机房

第二层：安全区域、CORE、其他

第三层：防火墙、核心交换机、F5、其他设备

 

层级关系：上层实体可以分解成下一层图。例如第一层中的IDC实体有第二层中的安全区域、CORE组成。

安全区域的定义：在同一防火墙后被保护的区域，行使单一的功能区域。（通过路由层ACL保护的区域也属于安全区域，定义在一个子集）。

关联关系的定义：定义出所有图层实体之间的关联。比如直连、专线、cn2等。由于要生成图形，管理关系是否有方向的定义

最后一层的拓扑图：进入第三层后是详细的拓扑图

 

 

图形与配置管理数据相结合

图形中的所有实体、关联都存在于配置管理系统中查看。
我们所有核心实体都从CMDB中来，例如防火墙、汇聚层交换机、F5等

配置管理中要体现出实体间的关联、关联的方向

配置管理中要体现出实体间的包含

图形是通过配置管理数据中的属性自动生成的

 

图形的检索和定位

由于和配置管理的关联，图形是可以检索和定位的。

主要检索的字段有网络设备名、保护网段等。

通过检索网段能够查到安全区域，并进入查看拓扑图。这样便于确认终端间的逻辑路径，经过的防火墙。

 

 

13.2.2 权限控制与规则定义

权限控制：CMDB是否拥有完善的权限控制功能。权限是服务于整个运维管理系统的，要考虑CMDB中的数据模型是否适用于当前整体的运维管理系统。
    权限系统分为授权对象、保护对象。授权对象一般指被授予权限的用户，仅仅只有用户的设计看似简单，如果所有的用户对保护对象都关联一条权限，则会产生大量冗余数据，这对于系统管理来说本身也是一件痛苦的事情。为了解决这个问题，我们在在用户的基础上创建角色，将一组权限集合归为一个角色并赋予用户。
   保护对象有功能、数据两类，功能对象包括菜单、按钮、操作，这类对象可以是对一般的CI对象操作的保护，也可以集成到运维流程管理控制之中。数据包括CI类型、条目，要记住，我们保护的不仅仅是动作，还包括数据的本身。要识别出数据的保护级别，可以通过在CI类型与单个属性中进行设置。

图~~~

规则定义：CMDB中也需要规则，这个规则用在对CI对象输入的限定上。“如果是WII区域的weblogic，那么它所依赖的OS也必须在WII区域”，“当OS的状态为已上线时，必须输入该OS的应用管理员”，“主机名是按’cnsz’加上数字的规则定义的，输入的主机名称不符合规范”，这些都是基于属性的规则，我们在输入一个CI对象的所有数据时，先通过规则来验证该CI输入是否正确。如果CMDB具备一个有效、动态、灵活的规则引擎，CMDB数据录入的准确性可提升一个级别。
    OPENAPI：开放的API有两层意义，一是有利于与内外部系统的CI数据的集成汇总，通常企业会采购一批完整的IT组件设备，例如vmvare的虚拟机管理，我们可以通过OPENAPI将数据有vmvare导入到cmdb。除了完整组件同步外，对于自动发现的CI导入一样提供了标准接口。二与直接通过数据库层面导入数据相比，OPENAPI在规则、权限之前，对数据的精准性进行了更严密控制。

    

     13.2.3 数据模型的设计

前面是我们将企业、组织内对CI分析全过程，并且对用户UI、权限、规则以及对外开放都都提出了设计要求，那么最核心的CMDB CI schema应当如何设计？
我们将问题分解为关键的CI数据模型、权限模型，首先我们讨论CI数据模型的设计进行讨论。
  CI数据模型设计有两个极端。
  将所有的CI放入到一个CI表中，我们称之为巨婴表，这个表要解决的第一个问题是对于不同类型的CI有不同的属性，随着CI类型越来越多，这个表的字段要无限扩张，不同的数据库对表字段数量是有限制的。第二个问题则是将所有的CI全部放在一个表中，其性能会出现瓶颈，特别是要求保证事务一致性时。第一个问题的限制是硬性的，而第二个问题我们可以通过通过多种手段缓解甚至解决，例如使用缓存提前预热数据，建立灵活的外部索引表，对于报表数据提前一天夜间运行等。第一个问题的解决方式是预留在巨婴表上预留字段数，或者在每次新属性时加入新字段，问题逐渐演变成到底我们是该使用面向行的关系型数据库，还是可以开始在低层用户分布式的面向列的数据模型。在这里笔者尝试过使用hbase存储CI，并采用面向列的解决方案，最终得出的结论我们的cmdb不适应这种存储方式，我们的面向列是伪列，是我们把所有CI拼装起来的列，而我们的本质仍旧是面向行的。
  好了，让我们从一个极端走向另一个，为每一个CI建立一个表，在不断变化的CI关系中创建关联表，服务器是一张表，OS是一张表，交换机又是另外一张表。这可能走向另一个极端，我称之为芝麻表，整个schema设计下来动辄几百张表，让日后的开发人员根本无从维护。或者说本身设计这批schema的维护人员也会陷入到自己设计的痛苦之中，这里最怕的是寻找我们的边缘数据，那些在边角日常不会经常使用的对象我们会问“它在哪里，它是什么？”
  分析强调的是对问题的需求和调查研究，而不是解决方案。前面我们做了大量的分析工作，分层模型、CI查找、属性定义、关联CI，我们需要依据分析工作中整理的信息完成设计。设计强调的则是满足需求的概念上的解决方案。在两个极端设计方案之间我们选择平衡。
  在巨婴表的基础上，我们拆分CI与属性，CI类型与属性类型，把他们分解为4张表。对于芝麻表，我们用CI类型控制芝麻表的产生，不允许CI的某一具体定义一个独立表，最终我们的ER实体图如下：
 我们用8张表保存CI、CI属性、CI关系以及版本信息，相对于芝麻表，我们核心对象、边缘对象都统一放入到这8张表中。对于特殊CI资源，你会问我是否也要套用这个基础表模型？我的答案是如果特殊CI资源不属于边缘数据，而是在整个IT组织中都需要使用的，时刻被关注的，例如IP资源，那么为什么我们不在这简单的数据模型上做进一步扩张呢？
 CI_Type、Attribute、Attribute_Type、CI_Type_Attribute 4张表的作用放在面向对象编程中可以认为是类的存储地，例如一个人，它定义了人这个CI，以及人的属性，有名字、性别、身高。Configuration_Item、CI_Attribute则是具体的对象，还是以前面的人这个类举例子，在这两张表中存放的则是“小明”这个人，它的姓名是小明、性别男。CI_Relationship存放的是CI间的关联关系，CI_Attribute_History存放属性的版本信息。

    在讨论完CI数据模型的折中设计后，再回头来看看权限模型。在权限控制那一节我们已经谈过权限设计模块基本元素。权限的授权对象是固定的，一般有用户和角色。用户、角色之间是多对多关系。而保护对象是不固定的，一个按钮、菜单、数据项等都是保护对象，而保护行为一般可固定在是否可以读写上。谁对什么可以有怎样的动作，这就是一个权限的判断规则，who、what、how三个元素组成的一条规则。who固定在用户、角色之上，what不固定，how除了读写外也由其他的动作类型。
   最终的权限控制放在了一张表中，表的字段如下：
   图~~~~
 privilege_id是主键，privilege_auth_type，privilege_auth_value关联到用户或角色表，例如这条权限规则是用户的，则privilege_auth_type指向user，而privilege_auth_value是user_id。这两个字段代表了规则的who。privilege_protect_type、privilege_protect_value则代表了保护的对象，如果我们保护的是数据CI，那么privilege_protect_type标识为CI，privilege_protect_value标识为CI的ID，注意，我们在数据保护上可以对一条CI进行保护，也可以对一个CI type进行保护，最后我们看到的是具体保护的行为是什么，在这里用privilege_operate表示。

  

13.3 配置管理数据准确性的保证

13.3.1 识别CI的OWNER

    要想保证CI的准确性，首先就得找到谁使用CI、谁维护CI、谁对CI负责、CI的准确性与谁的KPI挂钩，而不是在大家需要使用CMDB数据时才抱怨。CI的使用者与CI的维护者对数据的准确性要求不一致时就会出现前面的抱怨。这两个角色可能出现在一个团队，也可能在不同的团队，系统服务组的资产负责人是CI的使用者，而系统服务组的运维负责人是CI的维护者，他们在同一个团队，他们也会因为数据的不一致而产生矛盾。跨团队间关于数据不一致的问题频率可能更高，CMDB的某一条数据的准确性可能是无关生死的问题，但如果整个CMDB的大部分数据都荒废而陈旧，后面的CMDB管理工作将如大厦将倾，岌岌可危，没有人再对CMDB负责，最终是为了数据准确性而定期的做一次“资产盘点”，重要时刻数据用不上，每隔一段时间还要增加工作负担，事实上推动另一个团队人员及时的录入一条“无关紧要”信息非常之难。

    我们第一个要识别的是CI的OWNER，CI的OWNER对数据的准确性负责。他们不一定是数据的维护者，他们更多的是承担起对数据准确性的审计、受理数据异常问题、推动数据维护者及时更新、修正数据。对于数据维护者而言，他们的KPI与他们维护的数据准确性是直接挂钩的，数据维护者的维护动作一般是嵌入在某个变更流程中的。被升级出来的数据异常应以变更质量问题处理。

13.3.2 识别CI的生命周期、关联运维流程

将CI的维护关联到运维流程之中是保证CI的数据准确性另一手段。要将CI的维护关联到运维流程之中就必须先识别CI的生命周期。

    不是所有的CI都需建立生命周期，生命周期的出发点是保证数据准确性以及资源的有效利用，只有那些资源宝贵、功能独一、具有明显生存期的CI才需要建立。比如硬件服务器资源、SAN存储卷资源是很宝贵的。一条生产专线的建设本来就分为提交、勘察、建设、测试、上线等生命周期步骤。对于这些特殊的CI我们应当识别出来，定义其生命周期属性。

下面流程是一个典型的硬件系统生命周期：

申请：每一个生命周期都是有一个起点的，他可能是有一个运维申请流程引发，这个时候我们定义了一条空数据的CI对象。

受理：申请必须被授权以确保它符合预算和其他要求。大多数组织都有正式的程序对于新技术要求授权。

安装：当申请的设备是符合规格的，那么运维服务支持团队开始对它进行安装部署工作，这部分的内容是嵌套在运维流程之中的。

测试：对新安装部署的设备进行测试，确认它满足生产运行的要求。

上线：一旦设备经过前期几步骤，则正式上线运行。

下线：当设备不再需要或无法满足我们要求时，安排其下线。

我们在不断的询问，下一步做什么？在某些情况下我们可以设置一个定时器，或者依据一些依赖条件进行自动检测，不管是定时器还是检测，他们所要完成的任务都是“提醒”我们需要进入生命周期的下一个阶段了。定时器适用于租期到期的情况，而依赖条件则适用与检测上层依赖资源是否存在，比如一台已上线的服务器上没有应用了，CMDB的报表功能会“提醒”我们是否下线该服务器。
CI的生命周期可以嵌入到运维管理流程的，在一个具体的变更步骤中可以定义是否修改一个CI的哪些属性。

13.3.3 数据有效性的审计

在确认CI的OWNER，并将CI生命周期嵌入到运维流程之中后，可能还是无法保证数据的正确性，因此还需要建立起配置管理审计机制来保证数据准确性。

审计工作发生在日常的运维中，CMDB数据的使用者发现数据异常后需要有途径立即受理，记录下问题后更新CMDB，而不是置之不理。配置管理审计类似于资产的盘点，企业应根据需要设置周期，一般一年至少展开一次。另外，CMDB还可以就一定的范围进行专项审计，从而小范围、细致地核查某类CI或某项关键服务所涉及的CI"账实相符"的状况。当CMDB审计发现数据不符时应尽快查明原因，并通过变更工单提请变更，最终修改CMDB数据。CMDB审计流程应该独立展开，审计员应由专门成立的监管部门担任。