Tags
ARS asset Atrium Blog BMC cacti ci cloud Cloud Computing cluster cmdb cms Enterprise faq Ganglia GLPI Google grid GroundWork Hyperic HQ inventory ITIL ITSM linux Movie Nagios NSM OCSNG OpenNMS opensource opensuse oss OTRS remedy service desk snmp Tomcat training translation twitter v3 wordpress Yum zabbix ZenossCategories
Recent Comments
Views
- zenoss opennms comparison/比较 - 470 views
- 手把手教您构建CMDB/CMS - 353 views
- OTRS::ITSM期待中的开源ITIL工具 - 299 views
- Deploy asset management solution - 285 views
- Archive - 219 views
- About - 170 views
- CMDB选型解密 - 170 views
- Open Source Ticket Request System – OTRS 2.2.6 - 157 views
- Build Zenoss 2.1.2 on Redhat Enterprise Linux 5 - 134 views
- 掀起CMDB的盖头来 - 125 views
Blogroll
Category Archives: CMS/CMDB
规划CMDB数据填充-003
From 《Step by step to build a CMDB》步骤17-规划CMDB数据填充 本文描述填充过程的任务3到任务4: 任务3 映射CI和数据源 现在拿出您的CI清单,并把每一类CI与具有相关信息的数据源映射起来。一个简单的电子数据表格,像图17.2一样的就足够了。有更复杂数据需求的大一点的企业可能需要多个数据页或者通过CI分类来连接到不同的数据页。 这项工作的最终目标不仅是识别用以填充CMDB数据源,而且还识别了流程和平台的接触点,有些平台对数据填充是有影响的。这项工作也是至关重要,用来定义数据调和规则,定义数据优先度,这些会在下面的步骤,任务7“建立调和规则”中用的。 工具映射如下图17.2所示,包括了每一个CI类,相关的属性,相关的关系数据,和数据源。 图17.2 Ci和数据源之间的对照关系图样例 您可能会发现一些s数据源之间的重叠,特别是CI库存清单的属性数据。这些数据通常包括唯一物理特性和CI的地点的说明 ,例如:型号、序列号、地点和所有者。此信息可能被存储在其他多个地方,它们也可用于CI数据填充的来源和日常维护的来源。 多种的资产和库存清单数据来源可能包括如下: 审计(资产清单或者配置发现数据库;无代理和有代理方式) 资产管理系统 采购系统和许可证管理 财会系统(采购或者收货) 合同管理系统 变更管理系统 其他财务应用和系统 任务4 访问数据源环境 为了确保数据质量,你应该访问所有的数据源环境,而不仅仅只是CMDB,还包括连接工具和相关技术,要逐一访问查看每一个数据源。在这里,“进来的是垃圾,出去的就是垃圾”这个俗语是适用的。CMDB项目的成功可能依赖于对系统或者基础架构的更新,以适应网络流量和数据量,还依赖于确保每一个数据源的数据质量。 当你规划CMDB数据填充的时候,要自问这样几个问题,是有关外部映射数据源质量的: 现在那些信息在那里、怎样被存储的? –数据库、电子表格、Word文档? 当前环境中有没有审计(发现)工具、软件分发、配置管理或者采购系统,用来自动的跟踪和存储这些信息? 或者数据时被手工地收集和更新的? 这些系统是基于开放标准还是私有技术的? 这些系统的厂商有没有标准化的工具?或者CMDB厂商? 需要被继承的数据源的物理位置在那里? 在CMDB和数据源之间,通讯的方式是双向的还是单向的? 还要考虑有关映射数据源性能相关的问题: 就当前的数据源来说,现实的性能、容量和可靠性是怎样的? … Continue reading
规划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部分功能的有限的访问给他们,用来消除他们顾虑,并参与进来。 * 地区 – … Continue reading
Posted in CMS/CMDB
Tagged Atrium, BMC, cmdb, cms, configuration management, ITIL, ITSM, v3
Leave a comment
规划CMDB数据填充-001
From 《Step by step to build a CMDB》步骤17-规划CMDB数据填充 目标 在这一CMDB关键的步骤中,会为CMDB的初始化CI数据填充,做精细的计划。需要考虑到所有CI数据,把不同CI类型对应到不同的数据集中,安排正确的顺序将这些数据集CMDB。其中定义对应的规则来调和重复数据是很重要的,不仅在CMDB初始化数据填充阶段重要,在以后的日常维护过程中也是非常重要的。做出了本阶段的详细规划后,这样在第18步即“选择自动化CMDB填充工具”时,就能考虑需要什么样的配置发现和自动化工具了。 实际上,把数据填充到CMDB中是非常基础的工作,必须事前做好充分的数据范围和类型的分析。对于一个典型的CMDB数据填过程来说,将需要做如下工作: 建立里项目程碑和高阶项目计划,以及配套的支撑数据库和操作流程。 安排项目启动会议,单周或者双周的项目进度沟通会。 识别子项目(每个数据集分为一个子项目),建立每个子项目的目标和需求清单。识别和制定项目工作活动内容,确定项目的工作流程,并且按照项目计划排程所有活动。包括: —并行开展项目(用户界面定制,DSL数据填充); —串行开展项目(发现工具,数据调和,等等) 为每个子项目分配项目负责人,让他们来负责汇报项目的进展、问题升级和下一步的工作。 为所有项目参与人员建立一个开放的沟通平台,包括所有内部、外部人员(邮件组方式,数据库、通报) 为可能出现的紧急事件预留至少10%的时间和预算的缓冲。
Posted in CMS/CMDB
Tagged BMC, ci, class, cmdb, dataset, step by step to build a cmdb
Leave a comment
联邦的CMDB–神话/现实/需求/还是策略?
来自:Jonathan Markworth(CompuCom Systems有限公司管理顾问,探讨联邦数据库的优点) 使用一个具有单一的、全知的、万能的和自维护功能的工具,来管理IT基础架的方方面面信息,是否是最好的方案呢?使用一个能做所有工作的全集成平台,来替换您积累下来的所有管理工具是否是最佳方式?现实情况是,大多数组织都已经实施了几十种应用程序、工具、实用程序、数据存储、硬件平台和管理框架,它们一起运行着一个或更多的IT服务管理功能。它们中的每一个应用都有自己的数据库,对当前环境中的一些关键管理功能提供信息支持。在CMDB应用场景中,这些工具相关的数据库中,其实也包含了大量关键的CI属性,这些属性可以用于识别CI之间的关系。重要的问题是,如何利用现有的投资和资源来建立一个底层共享的数据库,比如一个CMDB。
CMDB配置采集工具部署之4大挑战
挑战1:沟通成本大 项目的参与沟通方可能很多,最多的情况下,可能包括:网络部门、系统部门、安全部门和各个业务部门。沟通的内容主要是配置采集的实施技术方式。其中采集的安全性,风险分析是最重要的部分;在部门多的情况下,面对多种选择的时候,逐一给项目各方说清所有方案,特别是讲清楚利弊是非常耗时的。在充分沟通了所有技术可能性之后,才能做出倾向性选择。逐一这是第一轮沟通,搞清楚了倾向性而已。 挑战2:决策成本大 特别是银行等金融企业,安全性要求特别高。安全风险方面的建议往往是最重要的,他们的建议对配置采集工具的实施具有决定性意义。在各方都充分理解了配置采集工具的架构和安全性之后,就是拍板定夺了。这种逐级的审批和决策是需要较长的周期。 挑战3:前导时间成本太大 在前导时间里,可能还没有部署正式的ADDM采集服务器。在这个阶段里,要配置网络,让以后的采集服务器能够处于能够扫描到所有目标服务器设备。还可能需要在每台服务器上配置相关的准备工作,主要是坚持主机的操作系统的账户、采集协议和安全配置等是否满足配置采集工具的要求。这写工作是一个群众性运动,需要让所有的系统管理员配合。此项工作的设计人员设备多,最好能尽早的开始。