CMDB反思3

CMDB模型设计1

http://blog.vsharing.com/xqscool/A1274634.html

分类的问题上比较有感悟。在之前编写新版的CMDB模型的时候,曾将刀片机、x86服务器、小型机等统一归为服务器,通过架构和机箱(刀片、机架、立式,好像是这三种)区分。由于使用的是SD,而且到我那一期时字段剩余的不多,为了方便统计和展示,才出此下策——不过当时感觉很好哈,终于一统天下了,不过也是无奈的选择。

如果分类在存储和展示上都能够自定义而且有足够的空间的话,确实如破子所说,分类是不应该吝啬的。

很好奇破子公司所用的CMDB里面的数据结构是怎么设计的,我近期在这个方面上一直存在问题,总是担心过于灵活的话会影响到性能,毕竟最终使用起来上万条记录的相互关联和查找还是会很费数据库性能的。

分类是最简单的,无限分类,最多加个图片和说明,其他的就没什么了。

属性集的设计和破子所想的是一样的,因为如果开发像HP SD的那种过度灵活的功能反而导致系统配置异常负责,而且很容易由于某些微不足道的问题使系统功能受到影响。

属性集中的各个属性可能拥有自己的功能,比如维保信息的属性集,可能有开始日期、结束日期、续保历史、续保文件等,而且可以设置在结束日期多少天之前进行提醒。

每类属性还需要有对应的说明文本(不一定只是文本),来指导用户进行填写。

CI与CI之间的关系也是我最头大的问题,N多类CI的关系都被大家称作为“安装”,而且由于用户前期参与不够,所以大家都期待能够在系统研发完成后定义和限制,比如当服务器关联某个软件的时候,只会有自动选择一种关系,那就是安装,当服务器关联某个网络设备时,只会自动选择一种关系,那就是连接等等,当然,上述的例子举得比较简单。上述的关系时给予分类的,并且要有关系说明。关系是需要提前整理出类-类关系矩阵的,这样后期直接根据当前类和目标类就可以确定可选的关系了(不过话说确定的类与类之间应当只有一种关系)。连接说明这个很好理解,至少也可以将物理连接的编号填写进来啊~

让我比较头疼的是“可用性传递”这种关系,比如说在可用性计算的时候,影响可能是单向或双向的,而且不同方向还具有百分比。“可用性传递”、“连接”、“调用”等不同的关系貌似应该通过不同的模块来实现。

物理连接关系如果称为“硬”关系,那么软件之间调用关系就是“软”关系了,“硬”关系铁定会对“软”关系产生影响。

想到这里,又想起一个问题,连接、调用在监控的角度来看又是会产生影响的,晕。

关系的穷尽在公司里面比较难搞,头疼中。

在看破子的CMDB模型时,感觉动作这一块很有意思。因为按照我的想法设计的架构图中,作业这一块是由单独的系统控制,并与CMDB相关联。

这两天思考了一下,如果在CMDB中就能够定义动作,那么确实有助于服务的标准化,但是动作记录在哪里呢?按照文中的意思,应当是一系列的操作?我的理解是,在CMDB中定义动作只是为了与其他系统保留一个接口,适时的将动作与其他系统的作业进行关联,从而实现标准化或者自动化?或许自动化是后期的事情,那么前期的这些动作如何与流程、工单相关联?如何准确记录时间,这些都是问题。标准化动作如果要配备相应的资料,那么就需要考虑不同品牌、不同型号的问题,当然,通过资料库进行相应的匹配技术上来说没什么难度。

看到破子的服务和CMDB结合的想法,确实给了我不少启示。某些一直以来没想明白的问题感觉有些明了了。

服务对象的部分,之前公司内一直将其作为一个CI管理,然后每个系统又要分子系统和组件,每个系统又会和其他系统组成系统群……当然,前一个是因为方便计算可用性,后一个纯粹是蛋疼且讨好客户用的。

你能想象一个系统群掌握在一个人手里是什么感觉么?所以业界说惹怒了SA小心使出必杀技。

服务对象应当划分到服务管理中,CMDB中就别搞什么服务了,看着就头疼。

如果这样,那么像PC服务,服务对象中应当直接包含客户所有的PC——我估计说到这里管理层就会头疼了,因为他们认为这个不归我们管理,客户就该乐了,因为他们认为这个该我们管。这个问题还有待考虑。

一直以来,如何精确定位事件的影响面,是最让领导们纠结的问题之一。服务主体的概念需要按照每一个服务来确定,而我司一般签框架协议,业务系统的运维服务一般都是一股脑的叫过来。加入服务主体的概念后,签协议就需要用户配合确定服务主体是谁,明确这些信息之后,影响面基本上也就确定了。

哦,我们这里单独管理机构,所以服务主体可以直接使用机构信息——不过这机构成天变来变去的,我看悬啊……

服务体制这一块我先思考一下。服务在我们这里或许会有服务主管。但是体制中指定的角色映射其实不是固定的,这就导致实际上需要给一个员工分配很多角色,甚至是只用一次的角色。如果能够自动映射……我想多了。

服务级别的定义需要和客户所签订的内容一致,这样在接近或低于的情况下就可以自动产生告警。而且各类工单的时限要求也可以取自服务级别中,倒计时的方式给人更强的紧迫感,对于系统中所涉及到的人员也会从全局了解自己所背负的责任。

最后有些纠结,破子的想法确实不错,但是最终开发出这么复杂的系统,我还真担心部门内部是否有人会用会配置?需要了解的内容太多了。

最最后说一句:我靠,破子你研究得太深入了。

CMDB反思3,布布扣,bubuko.com

时间: 2024-10-19 15:12:56

CMDB反思3的相关文章

CMDB反思5

ITSM工具规划设计 http://blog.vsharing.com/xqscool/A946789.html 相比PPT中被管的数个对象(像培训什么的也都在其中),我们的需求其实就要小得多,但是问题在于流程依然不清,责任依然不明. 由于近期需要解决的CMDB中的相关问题,所以着重看了下PPT中对应的部分,其他的部分慢慢研究. 看了破子的这个PPT,之前有一些迷惑的地方才清晰起来,比如属性集. 具体的内容就不多说了,破子在其他的文章中说得已经很明白了. PS:印象笔记的索引功能超乎想象的好用,

CMDB反思4

CMDB模型设计2 http://blog.vsharing.com/xqscool/A1275233.html 估计大家看到破子的这两篇都有点晕哈,我也有点晕. 两篇对比来看. 第1处,属性部分新增了动态的内容.这也是我一直考虑的问题——毕竟咱是搞监控多年,监控的数据是否存放在CMDB中也考虑了很久.因为CMDB使用的更多应当是当前状态,如果要记录性能数据的话就需要记录历史情况,这样感觉将CMDB与监控打包在一起了.我这里还是只是提供接口,CMDB可以调用.再者,CMDB有这些属性,也必须有数

CMDB反思1

由于,基本已经完成一期的功能开发,所以要继续CMDB的开发工作了. 最近看了不少CMDB相关的文章,也思考了不少,后面将所思所想(比较浅)记录一下. 发现很多内容都记录在Wiz上,抽空整理到博客中. 七问CMDB http://blog.vsharing.com/xqscool/A1267069.html 话说CMDB只是一个系统,而配置管理是一个流程,CMDB固然重要,但是维持它的流程更为重要.反观我司,只在CMDB建设初期的时候按照配置管理流程行事,建设快结束的时候就开始抽调配置管理流程的人

记一次服务器上架的总结和反思

由于博主所在公司最近业务量上升,各个项目进度加快,使得原有饱和的服务器资源变得紧张起来.博主很是着急啊,于是就做了一系列的资源使用统计和分析,然后向上递交了采购计划. 如题<记一次服务器上架的总结和反思>,服务器采购计划最终是批了.博主心情愉悦地等待着这批服务器的到达,并设计了相关的上架流程和自动化方案,最终进行了具体的实施操作.虽然在实施过程中遇到了一些问题,不过都是些不影响主流程的小问题,其中不乏在流程中忽略的点和未设计到的点,这些都是很值得事后思考和反思了.毕竟,这只是一次扩容,以后这种

CMDB开发

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

关于2016.12.12——T1的反思:凸包的意义与应用

2016.12.12 T1 给n个圆,保证圆圆相离,求将圆围起来的最小周长.n<=100 就像上图.考场上,我就想用切线的角度来做凸包.以圆心x,y排序,像点凸包一样,不过用两圆之间的下切线角度来判断. 这就是下切线(我自己瞎编的名字): 好像是对的啊: 然后我就保证必AC的希望,用这种写法交了,然后就只得了N=2的暴力分... 自以为是正解,却落得如此下场... 为什么?这样不对吗?借用学长的力量,果然被Hack掉了: 这种情况,圆心排序后,检测的顺序并不是圆上的切点的顺序,自然就会挂. 蓝瘦

CMDB专家实践谈:自动化运维的基石CMDB

CMDB是什么? 运维百花齐放繁荣景象的同时,也让碎片化问题产生:每个人都想整合运维平台,但是往往事与愿违. CMDB就像一个人的大脑核心,是一个信息协调库,其存储的资料是协调身体完成各种复杂运动的信息来源. 我心中的CMDB .碎片整合 面向运维工具的碎片化场景,是盘活整个运维管理的数据核心 .元数据库 提供运维活动的基础元数据,是唯一可信的运维配置数据服务 .场景驱动 为运维联动提供数据驱动,可协调工具来完成各类自动化场景 自动扩容+自动监控 CMDB如何建设? 痛点现象与对策I模型建不好

暑假反思

成功的,又一门功课成功地成为了全班倒数,还是最能体现一个人编程水平的c++实训.又得好好反思一下自己的学习状态了. 刚来到华工时的那种不甘,让我近乎维持着高中的学习状态,课内成绩荣登榜首,ACM一直保持着努力状态,这时的我的代码能力可以说是超过了除了几个原本有底子的大多数人.自大一上打下良好的基础之后,一直维持“学霸”状态的我开始反思:我想成为什么样的人?我所热爱的到底是什么?并且开始打算大一下甚至花一年的时间来明确这个方向. 直到现在我都觉得那个时候的决策是正确的. 但是,从现在来看,我的寻找

cmdb项目1

CMDB项目 需求: 1.ip地址 2.mac地址 3. 1.查看Linux硬件基础信息 1.查看cpu       cat/proc/cpuinfo (1)processor:包括这一逻辑处理器的唯一标识符. (2)physical id :包括每个物理封装的唯一标识符. (3)core id :保存每个内核的唯一标识符. (4)siblings :列出了位于相同物理封装中的逻辑处理器的数量. (5)cpu cores :包含位于相同物理封装中的内核数量. (6)如果处理器为英特尔处理器,则v