您的位置:时时app平台注册网站 > 彩世界网址 > CMDB初步了解

CMDB初步了解

2019-11-01 11:52

一、配置管理规划

1.CMDB简介
CMDB存储与管理企业IT架构中设备的各种配置信息,它与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。CMDB也被认为是构建其他ITIL流程的基础而优先考虑。
2.CMDB的功能
CMDB工具中至少包含这几种关键的功能:整合、调和、同步、映射和可视化。
3.CMDB建模思路
CMDB模型具有层次,包含核心模型和扩展模型,而扩展模型就是基于核心模型扩展出来的。围绕核心模型逐步驱动周边的资源配套,逐步实现资源完善。主要配置管理面向消费,发挥数据的价值,以数据和模型为核心、以整合的思路进行推进,实现元模型和拓展模型的相结合。
4.CMDB的优势与缺陷
1.整合、关系映射、防止配置偏差
2.CMDB节省成本和可扩展性
3.CMDB集成ITIL
4.为管理变更提供可预测方法
5.增强版本管理流程
6.CMDB初创时与各管理业务的数据模型不兼容
7.CMDB的易用性较差
5.CMDB难题-数据的准确度
数据的准确性对CMDB来讲是致命的,而CI无法及时更新、数据维护流程繁琐、数据完整性低等都会造成数据准确性降低。我们在构建CMDB时应该对这些方面的问题有所警觉。
6.CMDB的价值
1.避免配置数据被重复维护,降低数据管理的总成本;
2.共享同一套配置数据,使各运维业务对IT资产的基本配置情 况达成共识,并驱动各流程的自动化协同;
3.能够以CI为核心,拉通各个管理工具中孤立的数据,并通过面 向管理场景的数据分析和可视化,使IT管理者能更加全面的掌握 CI的运行状态和管理现状,提升管理的透明度

浅谈Restful API

理解RESTful架构 : 

RESTful API 设计指南 :  

先介绍一下我们的业务情况,我们公司的运维项目较多,有网络、系统的、桌面的、软件的,而且这些项目用到的设备都存在共用的情况,比如一个段线路,会属于多个项目使用,一台客户的电脑,也可能装有多个管理软件,同时它又是属于桌面运维的,这些我们的IT组件一是数量多(光是需要桌面运维的电脑台数在5000台以上),二是相互的关系复杂。

Restful 规范

客户组织:指我们的客户的组织及用户信息

浅谈ITIL

上面介绍的都是规划阶段的事情,这时具体的配置工作还没有真正展开,上面的整体模型相当于战略,也是一个重要的基石,它决定了后续许多的事物构造,比如后续要介绍的内容,同时这种模型如此规划时,它如何在其它的流程中作用(比如事件管理、变更等)中发挥作用,也是做了考虑的。说到这个就有一个建议了:

自定义用户认证:

 

在构建ITSM系统时,我的建议是首先从配置管理开始,而不是通常人们建议的从事件管理开始,配置管理决定地你们的运维管理的精细度与作业方向,它如何规划设计,会直接影响流程,你的绝大多数的数据质量也是由配置管理所决定的,在这个基石没有想清楚与确定前,展开事件及其它流程,最后整个作业可能是松散的,甚至可能是错误的,你的配置管理越精细,它对你的事件流程及变更流程,都是会产生影响的,配置管理颗粒度越细,它对我们的服务人员的作业行为要求就越高,引发的变更控制措施也就越多。在我的想象中,配置管理是一个服务平台的最底层建筑,它也是一个约束整个服务机制的重要所在。所以在项目的最初期,我一直是想先开发CMDB的,先把CDMB搞出来,然后灌数据,直接维护,不用事件管理,也不要变更管理,而是光光的 CMDB,到时我想看看所有的CI信息进去后,整个运维地图是如何的,故障的推演是否能实现,如果这些都是稳固的,再在这个基础上构建其它的应用模块。

CMDB资产管理部分实现

需求:

  • 存储所有IT资产信息
  • 数据可手动添加
  • 硬件信息可自动收集
  • 硬件信息可自动变更
  • 可对其他系统灵活开发API
  • API接口安全认证

配置项分析

图片 1

每个配置项的序存储的属性信息分析

图片 2

立业之本:定义表结构

  •  各种硬件都能存
  • 资产变更有记录
  • 资产ID永不变
  • 资产要有状态机

 重中之重:接口设计好

  •  可对内外灵活开发接口
  • 接口定义要标准化
  • 一定要提供排错依据
  • 数据返回要标准
  • 要能增删改查
  • 所有异常要抓住
  • 接口安全要注意

 表结构设计

图片 3

CMDB资产数据自动汇报及更新流程图

 

图片 4

3)CI命名规划

 

5)配置数据收集

浅谈ITIL

TIL即IT基础架构库(Information Technology Infrastructure Library,ITIL,信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订,现由英国商务部OGC(Office of Goverment Commerce)负责管理,主要适用于IT服务管理(ITSM)。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。

1、事件管理(Incident Management)

事故管理负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到服务级别协议所定义的服务级别。

2、问题管理(Problem Management)

问题管理是指通过调查和分析IT基础架构的薄弱环节、查明事故产生的潜在原因,并制定解决事故的方案和防止事故再次发生的措施,将由于问题和事故对业务产生的负面影响减少到最低的服务管理流程。与事故管理强调事故恢复的速度不同,问题管理强调的是找出事故产生的根源,从而指定恰当的解决方案或防止其再次发生的预防措施。

3、配置管理(Configuration Management)

配置管理是识别和确认系统的配置项,记录和报告配置项状态和变更请求,检验配置项的正确性和完整性等活动构成的过程,其目的是提供IT基础架构的逻辑模型,支持其它服务管理流程特别是变更管理和发布管理的运作。

4、变更管理

变更管理是指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务管理流程。变更管理的目标是确保在变更实施过程中使用标准的方法和步骤,尽快地实施变更,以将由变更所导致的业务中断对业务的影响减少到最低。

5、发布管理

发布管理是指对经过测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程。发布管理以前又称为软件控制与分发

 

事件管理的目标是在不影响业务的情况下,尽可能快速的恢复服务,从而保证最佳的效率和服务的可持续性。事件管理流程的建立包括事件分类,确定事件的优先级和建立事件的升级机制。

问题管理是调查基础设施和所有可用信息,包括事件数据库,来确定引起事件发生的真正潜在原因,一起提供的服务中可能存在的故障。

配置管理的目标是:定义和控制服务与基础设施的部件,并保持准确的配置信息。

变更管理的目标是:以受控的方式,确保所有变更得到评估、批准、实施和评审。

发布管理的目标是:在实际运行环境的发布中,交付、分发并跟踪一个或多个变更。

 

服务台:服务台是IT部门和IT服务用户之间的单一联系点。它通过提供一个集中和专职的服务联系点促进了组织业务流程与服务管理基础机构集成。服务台的主要目标是协调客户(用户)和IT部门之间的联系,为IT服务运作提供支持,从而提高客户的满意度。

 

2)CI属性设计

CMDB介绍

CMDB -- Configuration Management Database 配置管理数据库,CMDB存储与管理企业IT架构中设备的各种配置信息,它与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。

在实际的项目中,CMDB常常被认为是构建其他ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功与建立CMDB有非常大的关系。

70%~80%的IT相关问题与环境的变更有着直接的关系。实施变更管理的难点和重点并不是工具,而是流程。即通过一个自动化的、可重复的流程管理变更,使得变更发生的时候,有一个标准化的流程去执行,能够预测到这个变更对整个系统管理产生的影响,并对这些影响进行评估和控制。而变更管理流程自动化的实现关键是CMDB。

CMDB工具中至少包含这几种关键的功能:整合、调和、同步、映射和可视化。

  • 整合是指能够充分利用来自其他数据源的信息,对CMDB中包含的记录源属性进行存取,将多个数据源合并至一个视图中,生成连同来自CMDB和其他数据源信息在内的报告;
  • 调和能力是指通过来自每个数据源的匹配字段进行对比,保证CMDB中的记录在多个数据源中没有重复现象,维持CMDB中每个配置项目数据源的完整性;自动调整流程使得初始实施、数据库管理员的手动运作和现场维护支持功能将至最低;
  • 同步指确保CMDB中的信息能够反映联合数据源的更新情况,在联合数据源更新频率的基础上确定CMDB更新日程,按照经过批准的变更来更新CMDB,找出未被批准的变更;
  • 应用映射与可视化,说明应用间的关系并反应应用和其他组件之间的依存关系,了解变更造成的影响并帮助诊断问题。

...

Django自定义用户认证

整体模型

CMDB介绍

1)CI分类规划

如果实现安全的WEB API接口认证?

MadKing开源CMDB源码

 

cmdb文章推荐: 

 

参考:金角大王

细节的作业进程就不一一介绍了,在做这个计划与真正执行时,发现一些很有意思的现象,也算是经验了,这些点我会在下面逐一介绍到,下面将我们的整体的配置模型做一个介绍,

本节内容

示意1

资产管理功能开发

上面介绍的是思考过程,在完成这个思考过程后,在项目启动会上,汇报了此构想,得到领导认可,同时为了验证可行性,我找了一个公司典型的项目做了一次试验,看一下这样的模型是否存在问题。这里要说明一下,我们把结构与关系分离,一是考虑结构与关系是互不对等的,二是可以让其独立作用在不现的地方,这样分离之后,结构与关系本身更加严谨,我们将结构用于事件定位,关系用于故障推演,一个着眼于现在,一个着眼于未来。下面将展开细节说明。

决定后,剩下来就是攻破结构与关系了。在那段时间的思考中,CI的结构是首先想通的,可能是因为以前是做ERP实施的关系,也可能是因为客户是汽车制造商的关系,最终我发现将CI组装时,它的呈现很象ERP中的BOM结构,这是个父子结构,它可展开任意的节点,这种结构具有很大的扩展空间,也解决了配置管理颗粒度大小变化的问题,经过几天的思考后,我已非常确定这个思路可以解决我们的CI结构问题。

这四个纬度构成我们需要关注的所有配置信息,每一个纬度都是一个结构独立的树状目录,它可以多层级多节点的细分下去(这一点非常重要),在CMDB中我只会放入运维对象的所有信息(结构与关系),而运维对象与其它三个面的关系,也是会存放在CMDB中的,当客户组织、服务目录、运维组织都与运维对象发生关联时,这时,运维组织与客户组织(一个服务人员服务的客户是哪一些,或一个客户对应的服务人员是谁),客户组织与服务目录(一个客户享用哪一些服务,或一个服务哪一些客户),运维组织与服务目录(一个服务人员可以提供哪一些服务,某个服务哪一些服务人员可以提供),这些都可以通过虚拟连接起来,这种模型的建立,会带来日后无比便利的统计分析与查询汇总,同时也会解决我们现在许多管理上的症结。

由于以前实施REMEDY时,我们积累了一定的经验与知识,也具备一些配置管理的概念,所以规划方面,相对单纯一些,我们以管理科为主导,各业务领域的主管为成员,目标是所有项目的CI项纳入管理,在此作业开展前,我制作了一个作业计划,主要分几个阶段。

说明:

我现在所讲的,是经过很多思考与折腾后,所整理出来的,我对配置管理的出发点,是从软件实现方面考虑的,这可能与其它的公司有一些不一样,一开始,在思考整个配置的模型,也是CMDB的业务层面逻辑,很长一段时间,在CI的结构与关系方面,我一直无法理清楚,因为当 CI的结构是怎样,关系是怎样不确定前,整个模型根本无从建立。最开始首先确定的是,我决定把CI的结构与关系分离,即结构是结构,关系是关系,两者不互为影响,作用也各自不同,这个想法应该是比较大胆的,而且这是在我对ITIL不熟悉的情况做出的决定,如果这个做法错误,后续的很多工作都会受到影响。

剩下的关系是花的时间比较久的,查了不少资料,我一直想确定到底CI之间有哪几种关系,这本身我一直觉得这个ITIL的推广组织本身需要制定或想通的,而不应该由我来思考,我也看了常态下象IBM他们的做法,但他们关系与结构是互为一体的,而且他们对关系的定义简单了些,所以最后没有采用。在思考CI的关系时,我甚至上升到哲学的层面,去思考人与人之间的关系有哪一些,事物与事物之间的关系有哪一些,看是否能对得出CI之间的关系有一些启发作用,也在网上查了很多关于事物关系的说明,可惜没有找到有用的说明资料。

运维对象:常态上说的配置管理,即CI的集合

最终找到一个解决方法,是一个周五下午快下班的时候,当时正在画一个示意图,想向领导表达,日后如果我们完成配置的结构与关系构建后,呈现给我们的是一个怎样的东西,当时只把CI抽象成几个集合,CI是用一个圆圈图示代替,在画了几个图示后,突然有一点灵光闪过,我发现当把几十万个CI用这样方式串联起来时,象一个个灯泡一样,有的亮有的不亮,通过关系将这数量庞大的灯泡连接起来时,这种情况好象电路图,每一个CI 位于一个复杂的线路中,形成我们公司自已的配置地图,而且这是一个三维的图形,多个项目形成一个面,每个项目的根据结构展开的所有CI形成一个面,而每个 CI之间的关系又形成一个面,脑子里当时形成了这图象(这个三维的图形后来尝试了好几次用VISIO或PPT画出来,一直没有成功),想到这一点当时很兴奋,终于看到了一道门。于在是周末休息时,去书店把数字电路的书找来看了一些篇章,最终确定引入门电路的概念来解决关系的问题。

运维组织:指我们内部的服务机构及员工信息

为了后续交流的方便,我还需要对项目这个名词做一个定义,我是把它当成一个CI的集合,它是运维对象的一个节点,你也可以理解一个项目就是一个CI,这个CI是一个虚拟CI,它可以展开许多子节点,每一个节点都是CI,项目由于是我们公司很重要的一个“单位”,它与结算、人员、组织、服务目录这些都会存在关联,所以后续会经常提到它。

CMDB先开发出来还有一个好处,解决了配置数据收集维护问题,我们的配置数据届时会非常庞大,如果先收集,那在系统还未上线前,只能用电子表格维护,考虑到关系、结构的复杂,这基本上是不现实,每天有事件发生,无法做到同步的更新,不先收集,要等到系统上线的准确时间点,完成数据收集,这个难度又太大。(做过ERP的朋友,应该知道在系统上线时,仓库盘点数据导入的难度,只要业务不停,数据总是一个动态的,而我们的配置数据远比这种数据复杂),有了CMDB后,我们有足够的时间去收集试验,同时还可以同步更新。

4)CI模版制作

服务目录:不作名词解释了

我在这家公司工作了三年,很少象这样需要开动所有脑力去思考一件工作,配置是一个很重要的基础,同时也是让我耗费脑力最多的一块,所以先把它写下来。

本文由时时app平台注册网站发布于彩世界网址,转载请注明出处:CMDB初步了解

关键词: