Recent Comments
- 真正实施CMDB，使用开源的 OneCMDB，正好可以学习一下规范
- 我安裝的OTRS後，玩了一會，之前在配置管理裡可以打開並進行設置，現在打開的卻是“網站無法顯示該網頁...
- 期待能有一篇文章详细比较下rt和otrs 目前正在打算使用rt orts自己搭建试用过 可以多交流下
- 即使企业不用说作为个人也是应该尝试一下的士逐渐的影响其他人 其实我感觉在流程中控制用户行为没什么 有...
- 呃,ITSM这东西不能和remedy比吧?虽然并不是很多企业都上remedy的.因此我感觉,无论是什...
Tag Archives: cms
规划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配置采集工具部署之4大挑战
挑战1：沟通成本大 项目的参与沟通方可能很多，最多的情况下，可能包括：网络部门、系统部门、安全部门和各个业务部门。沟通的内容主要是配置采集的实施技术方式。其中采集的安全性，风险分析是最重要的部分；在部门多的情况下，面对多种选择的时候，逐一给项目各方说清所有方案，特别是讲清楚利弊是非常耗时的。在充分沟通了所有技术可能性之后，才能做出倾向性选择。逐一这是第一轮沟通，搞清楚了倾向性而已。 挑战2：决策成本大 特别是银行等金融企业，安全性要求特别高。安全风险方面的建议往往是最重要的，他们的建议对配置采集工具的实施具有决定性意义。在各方都充分理解了配置采集工具的架构和安全性之后，就是拍板定夺了。这种逐级的审批和决策是需要较长的周期。 挑战3：前导时间成本太大 在前导时间里，可能还没有部署正式的ADDM采集服务器。在这个阶段里，要配置网络，让以后的采集服务器能够处于能够扫描到所有目标服务器设备。还可能需要在每台服务器上配置相关的准备工作，主要是坚持主机的操作系统的账户、采集协议和安全配置等是否满足配置采集工具的要求。这写工作是一个群众性运动，需要让所有的系统管理员配合。此项工作的设计人员设备多，最好能尽早的开始。
21世纪最缺的是什么？
21世纪最缺的是人才，在ITIL项目中更是重要。特别是CMDB项目，项目团队人员构成是呈金字塔型。 最顶端的人是Project Executive Board“项目执行委员会”，简称PEB，它就像是一个公司董事会；它对CMDB项目的目标、预算、工期、项目变更等负责。PEB人员数量应愈少愈好，不过下面的个角色也是缺一不可。首先，要请至少一个C level的人加入，比如数据中心的CIO。其次，关键利益干系人，它们是CMDB的价值的主要承载者，叫好和批评项目成果的都会是它们。然后是CMS/CMDB系统的负责人，它们对CMDB的规划、维护和之后的发展最重要。最后是项目实施资源的主要提供方领导，说白了他就是出人出力的部门，今后项目的执行和实施都靠他们。所以PEB的人数在4人左右。他们是相关部门的领导。我在最近的项目实施中，也遇到了几个问题，需要去找客户的老板来拍，也就是找到PEB的人决策。其实之前也听到其他同事在项目过程中，曾经感慨道“客户的领导还真辛苦，大事小情都需要替下面做决策，他们的脑袋真禁拍！”。国内的管理者的确挺辛苦的，毕竟所带领的团队都还比较的年轻，这也是国内IT管理的成熟度低的一个体现。 金字塔下面的人就是都是我们的天天加班、做牛做马的辛劳工作的实施人员了。没有规矩不能成方圆，实施团队的技术素质和构成、团队沟通等都是至关重要的。对项目的质量，项目工期都有非常重要的影响。金字塔下面的兄弟姐妹都是一条船上的人，大家要互相配合才能完成项目的各项工作；在这个过程中没有一个船老大也是不行的，船老大就是项目经理。对CMDB的项目经理的要求可不低，重要有以下几点： Planning skills IT service management background Previous involvement in building a database ITIL Manager’s certification Ability to make decisions Capabilities to motivate staff Ability to blend a team Strength of character to lead a … Continue reading
CMDB需求分析之最佳实践
今天终于移师厦门开发中心，这意味着我所经历的史上最长CMDB需求分析基本告一阶段，也意味着CMDB的构建、集成、定制和 测试工作也徐徐拉开了大幕。 回忆前三个月所做的的需求分析工作，虽然各项调研和讨论工作进行的缓慢，不过细致的工作最终还是换回了令人满意的成果，起码我是这么认为。 需求分析的过程是对需求的重新整理、重新定义和梳理。项目的立项并不意味着项目目标树立的精准，项目范围控制的合理。实际需求可以在实施的初期阶段来重定义，从新分析，着觉得不是浪费时间。而且这一点对于中国用户至关重要。国内很多项目都是资金或者预算驱动的，先有需求，通过需求推到出项目的价值，在通过项目的投资回报率申报项目预算的过程在国内是很少见得。国内的项目往往是有多少钱需要花，那么大家在来看，如何把需求花到极致，达到最大的产出。这也是很多需求分析做的贪多、贪大、求全的根源，这样做的好处是在一个项目周期内就把需求实现的尽善尽美（愿望是这样），坏处是：可能导致厂商和服务商的服务成本超支，从而造成的项目质量降低，从用户角度来说一次性接受一大堆的系统功能，负担重，接受度低，同时客户满意度低，项目满意度差。 我认为较好的最佳实践还要抓项目的主要目标，抓需要实现的主要价值点，抓重点放弃那些可做可不做的功能。懂得放弃的人才懂得获得。把所有的功能需求做成能够分批、分期上线的成果；确保让系统用户能buy in每一个阶段性成果，不要奢望给用户带来革命性的提高，由于那样也意味着，你对他们当前工作方式的影响是巨大的，没有用户愿意接受巨变。 需求分析时，从技术上讲，对会议组织人要求很高。需要此人能非常熟悉CMDB项目实施的方法论，需要此人能够非常熟悉产品的各个功能点，需要引导有效的需求分析会议。在白板上尽可能多的画图，用Visio或者ppt等工具尽量多的讲解各种架构图、功能图、流程图具有事半功倍的效果。不管会议上您可能收到怎样的抱怨、抵制、反对；stakeholder的反馈将是你最宝贵的收获。没有互动和反馈的需求分析会是相当无聊和浪费时间的。切忌在大型的企业中，要慎重地计划每一次需求分析会，理由也很简单，企业组织越大，沟通的成本也越高。需求分析沟通的效率和成功完全取决于CMDB项目执行的方法论，取决于分析引导人的各种项目背景经验，还取决于对客户状况了解和上手的速度。
