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和数据源之间，通讯的方式是双向的还是单向的？ 还要考虑有关映射数据源性能相关的问题： 就当前的数据源来说，现实的性能、容量和可靠性是怎样的？ 系统上当前的活动状况怎样？ 活动用户数 其他并发继承此数据源的工具 备份、病毒扫描、报表或者数据挖掘的日程 审计工具（配置发现或者库存清单）扫描或者排队日程 其他任何将影响性能的事情 硬件和当前环境是不是能完全满足今后数据迁移所需要的附加工作量和空间需求？以及满足对于以后的日常数据同步？有没有对今后几年里增长率有做过计算？ 是不是需要考虑要满足什么约束或者特殊权限？ 厂商是否在与他们数据库集成方面有建议的最佳实践？（使用热备的生产机来降低作业压力） CMDB周边的数据集和连接技术是什么？ 网络环境中物理的限制（带宽、距离等）是否会有影响？ 当前的版本是多少？在以后的六个月或者一年里是否有升级的计划？有哪些好处？ 为当前的解决方案是否得到了足够的资料来负责架构、排错以及连接系统的维护？ 通过尽早的回答这些问题，就可以避免后续可能出现的性能问题，那些问题会影响项目的成功。如果数据源不太可靠，而且数据质量和性能方面是有问题的，这个时候，可以回到这些数据的关键利益相关者那里，与他们讨论，并确定这是否会影响到使用方面的关键需求。如果没有，需要把这部分数据需求从CMDB项目计划的第一阶段中展示放弃。这里最重要的是第一阶段的合理部署，实施结果能够获得用户全面的适应。然而，如果这些数据依然是比较关键的需求，那么需要与数据所有者，和收益者各方进行沟通，并引起各方的高度重视，共同确定一个解决方案。
规划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配置采集工具部署之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 team Capacity to present results and status of project to sponsors and stakeholders Self-motivation Ability
CMDB需求分析之最佳实践
今天终于移师厦门开发中心，这意味着我所经历的史上最长CMDB需求分析基本告一阶段，也意味着CMDB的构建、集成、定制和 测试工作也徐徐拉开了大幕。 回忆前三个月所做的的需求分析工作，虽然各项调研和讨论工作进行的缓慢，不过细致的工作最终还是换回了令人满意的成果，起码我是这么认为。 需求分析的过程是对需求的重新整理、重新定义和梳理。项目的立项并不意味着项目目标树立的精准，项目范围控制的合理。实际需求可以在实施的初期阶段来重定义，从新分析，着觉得不是浪费时间。而且这一点对于中国用户至关重要。国内很多项目都是资金或者预算驱动的，先有需求，通过需求推到出项目的价值，在通过项目的投资回报率申报项目预算的过程在国内是很少见得。国内的项目往往是有多少钱需要花，那么大家在来看，如何把需求花到极致，达到最大的产出。这也是很多需求分析做的贪多、贪大、求全的根源，这样做的好处是在一个项目周期内就把需求实现的尽善尽美（愿望是这样），坏处是：可能导致厂商和服务商的服务成本超支，从而造成的项目质量降低，从用户角度来说一次性接受一大堆的系统功能，负担重，接受度低，同时客户满意度低，项目满意度差。 我认为较好的最佳实践还要抓项目的主要目标，抓需要实现的主要价值点，抓重点放弃那些可做可不做的功能。懂得放弃的人才懂得获得。把所有的功能需求做成能够分批、分期上线的成果；确保让系统用户能buy in每一个阶段性成果，不要奢望给用户带来革命性的提高，由于那样也意味着，你对他们当前工作方式的影响是巨大的，没有用户愿意接受巨变。 需求分析时，从技术上讲，对会议组织人要求很高。需要此人能非常熟悉CMDB项目实施的方法论，需要此人能够非常熟悉产品的各个功能点，需要引导有效的需求分析会议。在白板上尽可能多的画图，用Visio或者ppt等工具尽量多的讲解各种架构图、功能图、流程图具有事半功倍的效果。不管会议上您可能收到怎样的抱怨、抵制、反对；stakeholder的反馈将是你最宝贵的收获。没有互动和反馈的需求分析会是相当无聊和浪费时间的。切忌在大型的企业中，要慎重地计划每一次需求分析会，理由也很简单，企业组织越大，沟通的成本也越高。需求分析沟通的效率和成功完全取决于CMDB项目执行的方法论，取决于分析引导人的各种项目背景经验，还取决于对客户状况了解和上手的速度。