CMDB配置管理构建数据库过程拆解2
软件工程中的版本控制与配置管理

软件工程中的版本控制与配置管理版本控制和配置管理是软件开发过程中至关重要的一环。
它们的有效应用可以确保团队在开发过程中高效协同、追踪变更并保持一致的项目状态。
本文将从概念、工具和最佳实践等多个方面介绍软件工程中的版本控制与配置管理。
一、概述版本控制是指对工程中的代码、文档和其他相关资源进行管理和追踪的过程。
它能够记录不同版本之间的差异,并提供回滚和合并操作,以便团队成员之间能够协同开发,并保持项目的稳定性和一致性。
配置管理则是指在软件开发生命周期中,对软件配置项进行标识、控制和管理的过程。
它关注的是软件构建所需的各种软件和硬件配置,在不同的开发、测试和部署环境中保持配置的一致性,以确保软件的可靠性和可维护性。
二、版本控制工具1. 分布式版本控制系统(DVCS)分布式版本控制系统是一种将代码库完整地复制到每个开发者本地的版本控制系统。
其中最著名的就是Git,它的分支管理和合并功能极其强大,在开源社区得到了广泛的应用。
2. 集中式版本控制系统(CVCS)集中式版本控制系统是一种将代码库集中存储在服务器上,开发者通过客户端与服务器进行交互的版本控制系统。
其中最著名的就是Subversion(SVN),它的特点是易于上手和集中管理。
3. 其他版本控制工具除了Git和SVN,还存在其他一些版本控制工具,如Mercurial、Bitbucket等,每个工具有其特定的应用场景和优势。
三、配置管理工具1. 自动化构建工具自动化构建工具可以帮助团队管理代码编译、构建和部署的过程。
常用的自动化构建工具有Maven和Ant等,它们可以根据项目需要自动处理相关的编译、依赖和部署工作。
2. 配置管理数据库(CMDB)配置管理数据库是一种用于管理和追踪软件配置项的工具,可以记录各个配置项的属性和关系,并提供查询和分析功能。
通过CMDB,团队成员可以准确了解每个配置项的状态和变更历史。
3. 软件包管理工具软件包管理工具可以帮助团队管理软件的依赖和版本。
cmdb入库业务流程

cmdb入库业务流程下载温馨提示:该文档是我店铺精心编制而成,希望大家下载以后,能够帮助大家解决实际的问题。
文档下载后可定制随意修改,请根据实际需要进行相应的调整和使用,谢谢!并且,本店铺为大家提供各种各样类型的实用资料,如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等,如想了解不同资料格式和写法,敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!CMDB(Configuration Management Database,配置管理数据库)入库业务流程通常包括以下步骤:1. 数据收集:确定需要收集的配置项信息,例如服务器、网络设备、应用程序等。
cmdb基础操作

cmdb基础操作CMDB(配置管理数据库)是用于管理和跟踪IT资源及其关联信息的数据库。
基础操作通常包括创建、更新、删除和查询配置项的信息。
以下是CMDB的基础操作:1. 创建配置项:-在CMDB中,配置项(CIs)是IT资源的基本单位。
通过创建配置项,你可以记录和跟踪各种IT资源的信息,如服务器、网络设备、应用程序等。
-创建配置项时,通常需要填写关键属性,如名称、类型、所有者、状态等。
2. 更新配置项:-对配置项的信息进行更新是CMDB的关键操作之一。
这可以包括修改配置项的属性、关联其他配置项、更新状态等。
-更新操作可能由于硬件或软件的更改、服务请求或其他变更触发。
3. 删除配置项:-当某个IT资源不再存在或者不再需要跟踪时,可以通过删除配置项来清理CMDB中的数据。
-删除操作应该谨慎进行,通常需要考虑对应的依赖关系和可能的影响。
4. 查询和检索信息:-查询操作用于从CMDB中检索有关配置项的信息。
这可以通过执行各种查询、过滤和排序操作来实现。
-查询操作对于查找特定类型的配置项、了解配置项的状态、查看关联信息等非常有用。
5. 版本控制:- CMDB通常需要支持版本控制,以记录配置项的变更历史。
这有助于追溯配置项的演变,并在需要时回滚到先前的状态。
6. 关联和依赖管理:-CMDB能够帮助你了解IT资源之间的关系和依赖。
通过配置项之间的关联,你可以建立起资源之间的连接,形成更全面的视图。
7. 审计和报告:- CMDB通常提供审计和报告功能,用于跟踪配置项的变更、查看历史记录和生成有关配置项状态的报告。
8. 权限控制:-为了保护CMDB的数据安全性,权限控制是必不可少的。
配置项的访问权限应该根据用户角色和职责进行精细管理。
以上是CMDB的一些基础操作。
实际CMDB的功能和操作可能会根据实现的具体系统和需求而有所不同。
CMDB是IT服务管理(ITSM)和ITIL框架的核心组件之一,旨在帮助组织更有效地管理和控制其IT基础设施。
2012年信息系统项目经理继续教育中级C组试题及答案

2012年信息系统项目经理继续教育中级C组试题及答案中级C 组-管理理论与实践篇-练习题一、单选题(共60 题)1.以下对服务质量同供方、需方与第三者之间的关系描述不正确的是哪项?CA 信息技术服务需方对服务质量提出需求B 服务供方则交付满足需求的服务C 服务需方、服务供方,以及第三方对服务质量的评价要求是一样的D 评价应当基于服务协议(不同的信息技术服务供方可以根据自身的服务水平和能力来同顾客建立服务协议)的要求2. 信息技术服务质量评价覆盖了信息技术服务生命周期的什么阶段?DA 服务战略 B 服务设计C 服务运营 D 服务的整个生命周期3. 下列哪项可作为衡量信息技术服务稳定性的指标?AA服务人员稳定性 B 服务连续运营的比率C 服务按恢复时间完成的比例 D 服务语言规范4. 下列哪项不属于互动性的评价指标?DA 服务报告提交率 B 互动沟通机制C 投诉处理率 D 需求响应灵活性5. 可视性是用于评价下列哪项内容?AA 评价服务供方服务过程与服务结果的可见机制与实施效果B 服务交付物的呈现完美程度C 检查服务行为的规范程度D 检查服务语言的规范程度6. 信息技术服务的完整性是指CA 确保供方信息不被非授权篡改、破坏和转移B 确保需方信息不被非授权篡改、破坏和转移C 确保供方在服务提供过程中管理的需方信息不被非授权篡改、破坏和转移D 确保供方在服务提供过程中管理的需方信息不被泄露7. 以下哪项不能用于评价信息系统集成服务的连续性?DA 重大事故发生情况B 服务按恢复时间完成的比例C 关键业务应急就绪度D 服务项(SLA)实现的完整度8. 信息技术服务可靠性的含义不包含以下哪项内容?DA 信息技术服务供方在规定条件下和规定时间内履行服务协议的能力B 信息技术服务供方所提供的服务是否具备了服务协议中承诺的所有功能C 信息技术服务供方所提供的服务是否持续稳定地达到服务协议约定的水准D 信息技术服务供方按照服务协议要求对服务请求响应的速度9. 在评价稳定性指标时,主要从哪方面考虑?BA 技术的稳定性 B 人员团队的稳定性C 工具的稳定性D 服务的稳定性10. 对于权重的设定下列说法不正确的是哪项?AA 同一服务类别的权重设置是一样的B 本标准中给定的权重值是推荐值,并非强调C 权重的设置应考虑不同行业对各个服务特性的关注程度D 权重代表着指标的重要程度11. 假设要考察信息系统集成服务项目供方某项目的连续性,以下哪项不是其评价指标?CA 服务按恢复时间完成的比例 B 重大事故发生情况C 解决率D 关键业务应急就绪度12. 下列对信息技术服务响应性理解不正确的是哪项?BA 响应性是强调了供方及时受理需方服务请求的能力B 有效性、及时性及互动性都是响应性的子特征C 供方对服务请求的响应及时说明响应性好D 供方与需方建立互动沟通机制能保障其处理服务请求的能力13. 评价的步骤有以下几步,请按照正确的顺序进行排序:a 数据采b c d集及计算;确定指标体系;确定评价目的和途径;确定权重值;E 确定服务类别;CA bcdea B ebdca C cebda D cbeda14.下列对信息技术评价模型理解正确的是哪项?DA 服务要素质量、生产质量、消费质量三者相互响应B 信息技术服务质量特性仅依赖于消费质量C 信息技术服务质量特性仅依赖于服务要素质量D 服务要素质量影响着生产质量,生产质量影响消费质量15. 优化改善的无形成果包括:AA 运行维护服务对象运行性能的提升B 优化改善方案C 优化改善方案的实施记录D 优化改善方案实施后评审记录16. SERVQUAL 模型中质量评价的结果是如何得出的?AA PQ (期望服务值)—EQ(感知服务值)B 感知服务评价结果C 期望服务评价结果D EQ(感知服务值)—PQ(期望服务值)17. 下列哪项不属于远程交付前的活动?BA 了解需要远程交付的内容、支持时间要求等B 准备必要的资料和工具C 对复杂情况或风险作出预案D 确保远程交互的工作条件满足安全、稳定和可用性要求18. 交付成果的管理包括下列哪项工作?AA 制定成果的管理流程B 明确成果的类别C 明确成果的规格或格式 D 明确成果的效用19. 现场交付适用于下列哪种场景?DA 供方驻场运维团队的现场交付活动B 供方的分包方提供现场交付服务C 供方根据事件或服务请求提供的临时性现场服务D 需方对现场交付的支持活动20. 在优化改善过程中需方应:BA 确保供方的人员、操作、数据以及工具等符合安全要求B 协助优化改善工作,如确认方案等C 对遗留问题制定改进措施D 不参与优化改善活动21. 响应支持是指供方对:DA 备品备件的响应支付 B 应急事件的保障服务C 日常预定服务的交付 D 故障申报的即时服务22. 下列哪项不属于交付策划的内容?DA 确认服务级别协议 B 编制交付实施计划C 准备必要的资源 D 建立与需方的沟通渠道23. 总结改进阶段的工作包括:BA 应急事件的责任认定 B 应急工作总结C 应急事件后的评审会议D 编制应急事件总结报告24. 交付规范适用于下列哪一种情形?DA 信息系统审计 B 需方评价和选择供方C 评价供方的服务能力 D 指导供方管理服务支付25. 应急事件关闭不包括下列哪项活动?DA 申请 B 核实 C 调查和取证 D 满意度调查26. 排查与诊断包括下列哪些工作?CA 事件级别评估 B 人员、设备调派C 问题沟通与确认 D 事件升级27. 事件升级是指?CA 管理升级B 只能升级C 资源调配升级 D 紧急程度升级28. 应急演练的目的不包括下列哪项内容?AA 证实应急响应组织的效能B 检验预案的有效性C 使相关人员了解预案的目标和内容D 熟悉应急响应性的操作规程29. 预案启动应:BA 具有自动启动模式B 遵从预案启动的策略和程序C 经营方管理层决策 D 经相关方协调30. 风险评估与改进是哪个阶段的活动?BA 应急响应B 应急准备C 应急处置D 应急总结改进31. 应急响应规程适用于以下哪一种情况?BA 自然灾害引起的对信息系统损毁的恢复响应B 重要信息系统的应急支援C 业务需要对信息系统的升级改造D 信息安全事件的处置32. 对于数据中心运维服务人员的要求,以下哪项不属于管理人员的必备要求:DA 掌握运维服务项目管理的知识、具备项目管理的经验B 并有IT 服务管理相关的培训/认证C 了解和掌握所在领域的主流技术D 具备产品研发三年以上经验33. 以下哪项不属于对存储的预防性检查?DA 检查存储关键硬件部件是否满足运行冗余度要求B 存储配置备份机制是否完善C 存储管理软件是否需要升级或打补丁D 将配置文件备份34. 数据(data)指用于记录信息的、按一定规则排列组合的符号。
配置管理的方法和工具

配置管理的方法和工具配置管理是软件开发过程中不可或缺的一个环节,通过有效的配置管理方法和工具,可以提高开发效率、保障软件质量,以及方便追踪和控制软件配置的变更。
本文将介绍几种常用的配置管理方法和工具,并探讨它们的应用场景和优缺点。
一、版本控制系统版本控制系统是配置管理中最基础也是最重要的工具之一。
它可以记录和管理不同版本的软件代码和其他相关文件,以及协助团队协同开发。
常见的版本控制系统包括Git、SVN等。
通过版本控制系统,开发团队可以方便地管理代码的变更历史,回退到之前的版本,避免代码冲突,提高开发效率和代码质量。
二、自动化构建工具自动化构建工具是配置管理中的另一个重要工具。
它能够自动化地将源代码编译、打包、部署到指定环境,从而简化繁琐的手动操作,减少人为错误的发生。
常见的自动化构建工具有Maven、Gradle等。
使用自动化构建工具,开发团队可以快速构建和部署软件,提高交付效率,降低错误率。
三、配置管理数据库配置管理数据库(Configuration Management Database,简称CMDB)是一种用于管理配置项的数据库。
它可以记录软件和硬件配置项的变更历史、关联关系等信息。
CMDB可以帮助开发团队追踪和控制软件配置的变更,并提供综合的配置管理视图。
通过CMDB,团队成员可以了解软件的不同版本、配置关系,以及其它相关信息,有助于解决问题和做出决策。
四、持续集成工具持续集成是一种开发模式,旨在通过频繁地将代码集成到主干分支,并通过自动化的构建、测试和部署流程,及时发现和解决问题,保证软件质量。
常见的持续集成工具有Jenkins、Travis CI等。
使用持续集成工具,开发团队可以快速集成代码,减少集成冲突,及时发现和修复问题,提高软件质量。
五、故障管理工具故障管理工具用于追踪和管理软件开发和运维过程中的故障和问题。
它可以记录问题的描述、严重程度、状态以及处理过程,以便团队成员协同解决。
CMDB构建与应用PPT课件

获取实际数值 配置信息内容: 1、设备型号、CPU型号、内存型号等信息; 2、操作系统IP地址等信息;
固定资产类CI
Page ▪ 17
实际应用
案例
基于CMDB
服务器维护影响核实
以前需要在多个表格文 件中查找,还需要和管 理员确认,目前可以一 键查询,节省时间,提 高效率。
系统配置管理
集中采集和管理各业务或应用 系统的配置参数,为系统恢复 或重建提供数据支持。实现配 置数据的自动分发。
04 建设经验
Page ▪ 23
CMDB的建设是个系统工程,通常需要跨系统,甚至跨部门的合作, 建设周期较长,风险控制时刻关注! CMDB的建设应该以业务和服务需求为导向,不能贪大求全,而应循 序渐进。管理规模的控制会影响建设的周期,甚至成败。
02 CMDB的构建
Page ▪ 7
阶段实施,全阶段培训
以业务服务为中心,建立配置档案,实现IT资产管理、配置基线管理及配置履历管理,与各管理系
统进行数据联邦,实现配置信息的自动采集,展现业务视图、业务影响分析等服务应用。
业务服务 目标确定
系统与数据 分析
CMDB模型 设计
CI数据关联 性定义及建 模
通过邮件确认、人工修正等 方式对已有数据准确性进行 校验和改进
CMDB构建过程
CMDB
建立CMDB数据的维护流程,尤其是
变更和配置流程,确保CMDB数据的 正确性、一致性
实现自动化数据采集手段,完善 和补充CMDB中的配置信息,减 低人工工作量,提高数据采集效 率
面向运维服务,实现集中的配置数据中心
CMDB维护 设计
CMDB应用 设计
CMDB展示 设计
运维平台之CMDB系统建设

【平台篇】运维平台之CMDB系统建设CMDB是运维的基础核心系统,所有的元数据和共享数据管理源,类似于业务中的账号平台的作用。
本篇文章,我将从概念篇、模型篇、到实现与实施篇具体的进行阐述。
CMDB也称配置管理,配置管理一直被认为是 ITIL 服务管理的核心,因为其他所有流程均需要使用配置管理数据库 (CMDB)。
在上篇的平台体系中,CMDB位于最底层的支持系统位置上,可见其作用。
配置管理为什么起到核心的作用,这个地方不做逐一介绍,简单举个例子,比如说变更系统发起了一个部署请求,要部署某个版本到现网,部署完成之后,上层的变更系统会把变更的结果写到CMDB中,对配置进行归档;在某个机器down机,此时可以快速的知道该机器的具体用途,确定影响的业务;当机器需要重新恢复的时候,可以快速的根据CMDB中的信息进行恢复。
一、概念篇1、配置管理和配置文件管理。
ITIL所讲的配置管理是从软件工程管理角度出发的,把一切对象都当做配置,比如说源代码、文档、人员、服务器甚至硬盘和内存等等。
所以说他和业务程序的配置管理有着本质的不同,为了有效区分,我们又习惯说业务程序的配置管理叫配置文件管理。
但又有着一定的联系,在ITIL中,业务程序的配置可能会以一个配置项存在,附属在应用程序上,具体什么是配置项后面再解释。
2、配置管理和资产管理既然把一切资源对象都当做配置来看待,特别是服务器、机房、机柜等等,那他和我们的资产管理又有着什么样的不同呢?其实这两个系统的区别在很多时候大家都不是很清楚,会混为一谈。
具体的区别我之前做过一个总结,如下:在上图中,你把握核心的区别点就是导向,配置管理是面向业务管理,而非成本,这个会决定配置管理的粒度。
当前如果业务非常简单,不需要对服务器端口进行管理,此时则不需要考虑纳入端口的管理,否则增加管理的代价。
3、配置项配置项是指要在配置管理控制下的资产、人力、服务组件或者其他逻辑资源。
从整个服务或系统来说,包括硬件、软件、文档、支持人员到单独软件模块或硬件组件(CPU、内存、SSD、硬盘等等)。
ITILV2基本理论及流程解析

ITILV2基本理论及流程解析ITIL(Information Technology Infrastructure Library)是一套管理IT服务的最佳实践框架,提供了一系列的流程和方法来改进和优化IT服务管理。
ITIL V2是ITIL框架的第二个版本,于2001年发布,下面将解析ITIL V2的基本理论和流程。
首先是服务管理,它是ITILV2中最核心的概念之一,也被称为服务生命周期管理。
服务管理包括需求管理、服务交付、服务支持和服务改进四个阶段。
需求管理阶段的目标是理解用户或业务部门的需求,并在此基础上开展服务交付阶段。
服务交付阶段主要包括服务策略、服务设计和服务过渡。
服务策略阶段确定了服务的目标和战略,服务设计阶段将策略转化为具体的服务设计方案,服务过渡阶段实现了新服务的部署和升级。
在服务支持阶段,需要提供用户支持和技术支持,确保服务的正常运行。
服务改进阶段则通过对服务性能和质量进行监控和评估,不断改进和提升服务水平。
第三个基本理论是配置管理,它涉及对IT基础设施中各种配置项的管理和跟踪。
配置项是指IT基础设施中的各种组件和资源,如硬件设备、软件应用、网络设备等。
配置管理的目标是建立一个准确、可靠的配置管理数据库(CMDB),记录和跟踪各种配置项的属性和关系。
通过配置管理,可以有效地控制和管理配置项,提高系统的可用性和稳定性。
最后一个基本理论是变更管理,它是控制和管理IT基础设施中各种变更的过程。
变更是指对IT基础设施中的配置项进行任何形式的修改、升级或替换。
变更管理的目标是确保变更的顺利进行,并最小化对服务的影响。
变更管理包括变更评估、变更控制和变更实施三个阶段。
在变更评估阶段,需要对变更进行全面分析和评估,确定变更的风险和影响。
变更控制阶段对变更进行批准、排期和优先级管理。
变更实施阶段负责实施和验证变更的结果,并进行后续评估和反馈。
总结起来,ITILV2基于服务管理的理念,通过服务管理、服务台和问题管理、配置管理和变更管理等基本理论和流程,帮助组织优化和改进IT服务的交付和支持,提高用户满意度和IT系统的可用性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
CMDB:ITSM的必需—配置管理数据库构建过程拆解
2007-10-29 13:33:51【作者】于翔陈宏峰
联邦性:CMDB成熟的印记
Gartner 2006年发布的CMDB研究报告指出,并不是所有的配置数据库都是CMDB,它必须具备联邦性、协调性、同步性、映射和可视化四大特性。
这份报告给出了CMDB成熟度评估的具体依据。
目前,很多软件厂商都宣称向用户提供CMDB工具,在其ITSM解决方案中也会包含CMDB组件。
但如果站在专业ITSM 实施的角度,它们中的一些更像是帮助台资产库尚未蜕变完全的产物。
我们看到,很多所谓的CMDB得不到完整变更流程的支撑,数据的实时性无法保证;而一些产品介于IT 资产库和配置数据库的中间,模型设计和配置策略不符合ITIL流程规范。
联邦性、协调性、同步性、映射和可视化是区分不成熟和成熟CMDB的刚性标准。
而现在,CMDB市场的发展仍然处在向这一标准逐渐靠近的过程之中。
联邦性是软件供应商难于攻克的部分,同时也是近期技术进展最大的CMDB特性。
从2006年开始,许多厂商将CMDB的联邦能力作为产品研发的重点,并相继推出了具有联邦特性的CMDB产品。
这些产品包括IBM的 CCMDB(变更和配置管理数据库)、Managed Objects的CMDB 360°,以及HP、BMC、CA、Symantec
等公司的类似产品。
联邦式CMDB符合技术和应用的发展方向,这一点已经能够通过现阶段的客户实践加以验证。
在高度异构化的IT环境中,企业将所有IT资产的配置信息保存在一个通用数据库的想法并不现实。
如果能够将多个数据库连接在一起,通过一个逻辑配置数据库构筑一个联邦式的CMDB,对于企业而言是一种切实可行的方案。
这样一来,客户不必把所有配置数据都存储在一个大数据库中。
联邦式 CMDB 通过记录不同数据库中配置信息的关联关系,在接到客户的访问请求时,可以快速追溯配置数据的保存位置。
以前,很多厂商把CMDB的开发局限在自己的专有架构中,这种传统的技术方式限制了CMDB对多数据源配置信息的发现与集成能力。
同时,不合理的数据复制方式还会造成集成后CI的高度冗余。
联邦式 CMDB 通过逻辑上对配置数据的灵活调用和统一管理,弥补了传统CMDB的缺憾。
推进方式:由点及面
CMDB的实施自然是“条条大路通罗马”,但在现阶段,从小处入手精心设计,逐步扩大CMDB的覆盖范围还是技术专家和企业客户所青睐的项目推进方式。
传统的CMDB构建方法是自下而上地推进,也就是先做一个大的配置数据库,再逐步精炼CI。
但这种方式的缺点是投入巨大且浪费时间,很多企业耗时数年才能完成CMDB的部署;已经拥有简单配置数据库的用户往往会选择自中而上的推
进方式,以现有数据库为基础,添加必要的CI和CI之间的关系后,用户可以用比较短的时间就组建一个功能相对丰富的CMDB。
而对于占据大多数的白手起家的用户而言,“自上而下,渐进式扩充”是一种可行性更高的方法。
专家建议,用户可以先从订单系统、邮件系统这样的垂直应用开始,尝试在单一环境中发现、收集、追踪和管理配置信息的技巧,逐渐积累配置管理经验。
在构建了相对成熟的配置管理流程后再构建更大范围的CMDB。
一些用户还会先期规划一个小型的试验项目,它会包含CMDB所必须的审计、控制、自动化等环节。
启动这种试验项目可以帮助企业收获一些关键的CMDB部署体验。
例如,对IT资产配置的描述方法,如何通过准确的配置信息来支持IT 服务管理,事件、故障、变更和发布管理流程的串联和磨合,以及如果更高效地对配置记录做出变更。
而有专家建议,在启动这样的试验时,最好选择一个能够得到广泛支持的IT 服务,而不是对业务营收至关重要的IT服务。
同时,这样的服务不应该需要进行频繁地更新,并且在IT系统框架中处在相对独立的环境之中。
因为频繁的变更操作将增加管理的难度,也更容易导致管理错误的发生。