Tag Archives: cms
资产CI的一生
在ITIL v3以后，配置管理进化为“服务资产和配置管理SACM”，换句话说，资产和配置管理不分家。两个流程应该是融合的。从微观上看资产管理设计到CI的所有生命周期状态，而这个服务资产在CMDB中出现的状态为整个生命周期中的一部分。 最好能通过资产管理为统一入口，来完成对CMDB中资产的生命周期管理。例如：一台服务器在到货以后，完成资产入库后，就应该在CMDB中自动创建CI，在上架部署了软件后，有配置资产自动采集工具，采集回详细配置信息后，资产状态就自动变为“部署”，当在运行维护中服务器宕机或者维护时，在资产管理中也能看到更新的信息。下面是建议的服务资产的生命周期状态: 编号 状态名称 状态描述 1 到货 表示为CI的物品在采购以后，被相关部门签收。 2 组装 设备的组件在被组装的过程中 3 维护 该设备处于宕机后的维护状态 4 宕机 该设备处于宕机状态，还未对其进行维护 5 终止 不在处于被部署的状态 6 转移 该设备正在被转移到其它的地点或者机房途中 7 删除 配置项被标记为删除状态 8 库存 设备处于库存中，还没有被部署 9 借出 已被其他单位或者部门借走 10 处理 该设备已经被拆卸，其本身已经不可用 11 保留 该设备已经被某单位或者部门预订，已经不再库存中了 12 返厂 由于设备已经被损坏或者过保，必须被退回厂商 13 部署 CI的默认状态，表示设备处于正常的生产运行状态 14 订购 该设备已经被订购，还未到货，仍然不可用 配置项管理和资产管理的联系和区别。 Service Asset and Configuration Management (SACM)
CMDB选型解密
自打承接了《Step by Step Guide to Building a CMDB (Updated for ITIL V3)》的翻译工作之后，由于平时工作太忙，翻译工程只能在业余时间完成；现在渐渐感到了此项工作的压力，每每想到读者对英文翻译版本读物的高期望和要求时，就愈加感到此项工作责任之重。不过本书对我来说还是一剂很好的补品，对我最近的ITSM项目都有直接的借鉴和指导作用。 说来此书有很多实用且精彩之处，相信读了英文原版的人更能有所体会。我忍不住想把其中的部分内容提前与你们探讨，这里想与你们分享如下两个内容。 上图还给所有CMDB用户一个清晰地CMDB功能点考察点，CMDB作为业务服务管理的核心，各个厂商其实并没有达成解决方案功能的标准和共识。通常情况下厂商提供的CMDB产品的发展和起源有以下几种情况：1）按照ITIL中对CMDB的需求和标准从无到有开发的标准CMDB产品；2）伴随变更流程或者业务影响管理而开发的CMDB功能模块；3）伴随配置自动化发现工具而开发的相应CMDB功能模块；4）应资产管理或者监控工具扩展而生的CMDB功能产品。用户在挑选CMDB产品的时候一定要明确CMDB的核心功能，除了以上功能外，其他的附加功能可能是nice to have的功能，而非必须。本图位于原版书的134页，如果您对我的翻译有建议请留言，多谢！ 上表为评估一个CMDB产品厂商的综合打分评价表样例。在选择并且评测一个CMDB厂商时，需要仔细考察的产品功能共有8点。用户需要注意的是一定要搞清楚其中的每一个功能是否是由厂商的CMDB产品的相关模块所提供的，如果不是的话需要搞清楚，每个功能是否是CMDB的外围或者其他产品模块，或者二次开发实现的。如果是这样的话，这种解决方案可能不是一套集成统一的解决方案，可能出现其他附加非CMDB产品的采购，可能在实施阶段付出不必要的集成和开发费用。虽然这些潜在因素在采购和实施阶段可能是隐形出现的。征集上表中相关术语的中文翻译：Weighted ，Weighted Rating Score，Total Weighted Score。有好的建议请留言。本图位于原版书籍的141页。
选书名
好消息《Step by Step Guide to Building a CMDB (Updated for ITIL V3)》即将翻译成中文出版。市场里ITIL的书越来越多，但是讲CMDB的书却一直很少，能讲解清楚CMDB建设过程的的书就更少。可是国内ITIL用户CMDB建设之瓶颈却越来越明显，我们希望有一本好的书作为这项重要工作的参考指南。 给此书起一个好的名字是头等大事，目前能想到的书名如下： Step by Step Guide to Building a CMDB 中文书名？(polls) 寻求前100名投票者，请对以上书名投票，并评论；如果您有更好的书名，欢迎推荐；请在下面留言，请正确填写邮箱，您推荐书名一旦被选用必有感谢送上。
手把手教您构建CMDB/CMS
If you have no idea about how to build a CMDB, you should check out this document. It come from http://www.bmc.com/products/product-listing/53556216-141391-2117.html Download it: Step by Step Guide to Building a CMDB (Updated for ITIL V3) (pdf) 该《手把手CMDB/CMS构建指导手册》包括了配置管理数据库/系统建设的所有相关流程、技术和指导性建议。如果你有CMDB的建设意向，该手册非常值得仔细阅读。 欢迎留下一个反馈，投票或者留言都行。 [poll id="8"]
CMDB中存什么？
当然是配置项和它们之间的关系，即：CI 和 Relationship。 那么如何规划那些类型的CI和Relationship需要保存到CMDB中呢？可以参考的数据模型是DMTF的通用信息模型，它是以面相对象的方式来描述各类CI和关系。它是一个工具用来帮你对环境中的各种物理和逻辑的CI和关系进行分类，参考这个模型选择一些有用的类（广度），然后在参考它对每个类属性的描述（粒度）。这些类的选择只是一个初步的研究，每个CMDB厂商和工具对其实施和参考的力度都不同，也需要看您具体实施的是什么工具。例如：你需要描述银行基金业务系统，你可能选择的CI类包括：客户群、业务流程、业务活动、业务服务、IT服务、应用系统、应用、软件服务器、服务器、网络、存储等；关系包括：组件、依赖和影响。CI类和关系的选择也基本上遵循够用就好的原则；而且每个类对应的CI实例都需要有人负责管理维护，需遵循，谁负责、谁维护的原则保障其属性的精确性。对于整个CMDB来说如果存在没有Onwer的CI或者关系，如果它是由自动化配置发现工具来更新的；那么它可以存在，如果不是的话，它可能根本就不该存在。所以CMDB中保存的数据不是越多，越细越好；而是够用就好，能保证更新就好。由于数据根本就不是免费的，即使国内的人力成本低，也不应该雇用一帮专职更新CMDB的人。 综上所述：我们说明了CMDB中数据选取和存放的最基本原则和方法，在CMDB产品选型过程中需要着重考察产品的数据模型本身和其管理的能力，还包括其CI和关系的扩展和定制能力；包括数据类型的支持和界面定制的程度。那么CMDB中的CI和关系有该如何展现呢？这是CMDB系统的另外一个功能：可视化。下面是一个CI和关系展示的实例供参考： [http://media-001.yo2cdn.com/wp-content/uploads/266/26670/2009/10/s1-4-blog.swf#swf&width=320&height=320] 全屏查看或者下载Flash文件 第一代的配置展示方式是，纯数据表格方式。第二代具有一种固定格式的图形展示方式，除了那几张视图外，别的需要单独开发。下一代的具有各种视图定制功能，并且支持关系和ci的过滤等等。