Tag Archives: Atrium


规划CMDB数据填充-002

From 《Step by step to build a CMDB》步骤17-规划CMDB数据填充 本文描述填充过程的任务1到任务2: 任务1  再次回顾CMDB范围 现在进行现实检验。你能否确实交付在第2阶段即“定义需求和创建IT服务模型蓝图”中定义的CI范围涉及的相关数据?你在CI数据一旦交付以后,能否有足够的资源来维护整个系统和所有数据?这些都是重要的问题,因为您所选择的CMDB解决方案,可能很容易地就超越了您需要的范围,超出了你可以能容易维护的程度。 在规划CMDB数据填充时,您的思想应该是“少即是多“。先学会走再跑。让CMDB的首次推广得到充分验证后在考虑扩大范围。您需要帮助保持 CMDB的团队和CMDB数据用户的积极性。同时避免项目范围的蔓延,否则可能破坏的实施的效果,以及用户对新的解决方案的接受度。 请谨记这样几个考虑因素,从而来帮助您始终专注于那些核心需求上,并能对关键的限制作出反应: * 成本 – 每个人都必须面对业务现实,包括预算和费用的现实。因此,在您的CMDB项目预算范围里,对主要需求排列优先级。如果出现新的想法,那么也只是在新的预算来下了以后才考虑。 * 时间 — 您可能需要在给定的时间内实施CMDB,来使您企业在此方面的业务需求得到满足,如 Sarbanes-Oxley 法规,或支持一个非常关键的新流程。当您计划了CI数据填充的顺序后(后面介绍的这一步),不仅要对CI数据排优先级,而且还要明确时间的限制。 * 实用性 – 如果没有足够的资源用来实施和维持CMDB,以满足CMDB要求,那么您可能需要缩小实施范围,以便您可以在您实际有限的资源里运作项目。你还可以考虑分两个阶段进行实施,把非关键的要求放到第二个阶段中。 * 外部强加的优先事项 – 有些业务的运作,例如企业治理、数据保护和信息自由,可能会影响您既定的优先次序。您可以通过分阶段实施CMDB数据填充来减少外部因素的影响。如果你没有从一开始就计划足够的时间来达成最后期限,那么你可以尝试投入更多的资源来克服时间上的限制。然而,还要意识到,以后你要申请更多的资源,没有资源的保证,你可能无法充分管理好项目。 * 所有权 – 有时IT资产的负责人并不属于IT组织。如果资产所有者决定不参与的CMDB,这会严重限制了CI数据内容的提供。您可以提供CMDB部分功能的有限的访问给他们,用来消除他们顾虑,并参与进来。 * 地区 – 地理区域上的边界,可能会限制建立企业范围的CMDB。由于地理或行政上可能的边界,我们可能听过“最好再也不要从总部传来这样神经质数据库方案”。最好预防这种情况的办法是,尽可能早的让所有地区的相关人员参与到CMDB项目里来。 * 组织架构 – 很多企业把IT划分成为清晰地、各自为政的独立部门,通过这种方式来对CMDB里的不同范围负责。例如:通信部门的人可能是一个单独的组织结构,他们可能拒绝参与到项目中来,因为他们觉得这超出了他们的控制范围。这时候就要让其他的IT组织参与其中,让每个人都知道谁是项目负责人。 当你计划你的CMDB数据填充的时候,越能专注于关键受益人的需求,就越能够达成项目的业务目标,就越能让您的项目顺利。您需要就已经确定的 CMDB范围,与所有的利益方沟通它可能的影响和效果。收集他们的反馈,并对有必要方面做进一步讨论。 任务2 识别CI 使用在第15步即“设计IT服务模型蓝图”中设计的IT服务模型蓝图为基础,来生成用于CMDB数据填充的CI以及相关属性和关系数据的清单。这个清单的细节应该到数据字段级别,以便,你能够识别并且映射一个或者多个数据源到特定的CI数据。 例如,如果你把一个实际的服务器CI的属性和关系数据都列出清单,你就可以找出一些现有的能提供属性数据的数据源,可能包括库存管理的数据库和发现或者网络管理工具。但是另外一些数据字段可能没有现成的数据源。你将在第18步“选择自动化CMDB数据填充工具”中用到以上差距分析。或者您可能决定使用手工的方式来填充和更新这个字段,这里还需要仔细的考虑到数据的负责人,和在21步“建立CI生命周期管理流程”中需要支持的流程。 至此,你需要专注于用来满足项目目标的要求。在步骤11到14,你定义了与其他流程的结合点,明确的CI需求。专注于那些能直接对流程收益人产生直接影响的CI数据。

联邦的CMDB–神话/现实/需求/还是策略?

来自:Jonathan Markworth(CompuCom Systems有限公司管理顾问,探讨联邦数据库的优点) 使用一个具有单一的、全知的、万能的和自维护功能的工具,来管理IT基础架的方方面面信息,是否是最好的方案呢?使用一个能做所有工作的全集成平台,来替换您积累下来的所有管理工具是否是最佳方式?现实情况是,大多数组织都已经实施了几十种应用程序、工具、实用程序、数据存储、硬件平台和管理框架,它们一起运行着一个或更多的IT服务管理功能。它们中的每一个应用都有自己的数据库,对当前环境中的一些关键管理功能提供信息支持。在CMDB应用场景中,这些工具相关的数据库中,其实也包含了大量关键的CI属性,这些属性可以用于识别CI之间的关系。重要的问题是,如何利用现有的投资和资源来建立一个底层共享的数据库,比如一个CMDB。

掀起CMDB的盖头来

今天是项目计划提交后的第二天,客户方项目经理对项目的推迟表示感到非常吃惊,期望能让我们给出一个合理的解释。其实这也同样的超出了我的预料,难道软件项目管理和运作都是所谓的人月神话么? 在我看来CMDB项目的实施和运作有是有可能分阶段、逐步地交付项目成果的。简单的来说首先交付的当然是CMDB和配套发现工具系统本身,丑媳妇不要怕见公婆,把这个不加粉饰的原型系统拿出来,让项目各方包括最终用户来试用和评估。接着按照CMDB配置数据的来源的不同,把数据顺序的导入CMDB,并且开展数据的调和工作,完成基础数据的初始化。在基础数据的基础上,需要对CMDB服务模型加以验证,选取重点的系统来验证,让系统经理和CMDB相关用户也参与进来,用事实和数据讲话,对模型和工具做最终的确认。这个其实是一个小范围内的推广,它的经验可以直接应用于下一个阶段。接下来是对其他所有被采集对象的普遍扫描和CI数据同步,在这个阶段里还需要实现CMDB和所有ITIL流程的集成,ITIL流程是CMDB的主要消费者 ,这个集成往往是两家不同的产品,这种情况下,如果集成的效果欠佳,CMDB的实施成果也会打折扣。最后结尾的交付物可以是CMDB的审核和报表等产品。 正如ITIL的实施一样,没有两个国内公司的ITSM实施是相似的,就像国内不存在两片相同的树叶一样。那么国外的树叶又如何呢?从ITSM实施方面来看,相同的树叶在国外还是非常多的。相同的原因在于,往往用户选择了相同的产品如Remedy ITSM套件,往往由于定制化的人力成本很多用户也在尽量避免对产品的定制,如果通过配置可以实现的需求,绝不定制或者开发。我们也应该多走工业化标准生产的道路,少以中国特色为借口来实施个性化二次开发。

手把手教您构建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"]

Page 2 of 212