标签：自身 个数 结束 调用 软件 bsp 解决问题 配置 单元
最近这几年，国内外CMDB失败的案例比比皆是，成功的寥寥可数，有人质疑CMDB is dead？但各种业务场景表明，当下数据中心运维，CMDB依然是不可或缺的一部分，它承载着运维的基础，掌握运维的命脉。
分析以往失败的案例，静静的想一想，失败无非两点：
一、CMDB自身建设能力不够，无法适应当下数据中心和云环境的新形势。当下数据中心的特点是敏捷、动态、持续发展。甚至当风暴来临时，数据中心的环境是瞬息万变。传统型CMDB跟不上节奏，只能望洋兴叹，频繁应付处理各式各样的问题。
二、非场景驱动，无法支撑业务需求。CMDB建设目的就是为了满足业务的需要，能够保证业务持续高效的运作，但是很多情况下大家只是把CMDB作为一个静态的配置管理库，未能和业务紧密关联。
若想使业务系统走上敏捷运维之路，势必对传统型CMDB进行一次革新，实现观念和思路的转变。将从一个简单的静态配置信息库转变到为业务系统提供持续运行的能力，为资产提供精算运营的能力，为技术架构提供敏捷自动化的能力上来。打造一个云计算下的由业务场景驱动的服务型CMDB。
下面，我们通过一个常见的业务场景，从业务部门提出业务系统需求，到内部IT资源协调、上线部署、监控运行，再到日常运维，来分析如何建设CMDB，才能保证业务系统的敏捷运维。
（一）系统首先内嵌一个业务系统上线的审批流程，步骤如下：
1、业务部门向系统架构组提出业务系统建设的SLA（服务等级协议）要求；
2、系统架构组根据SLA的要求，分析得出最基本的架构单元；
3、运维部门根据基本架构单元进行部署实施。
（二）从系统实现上分两种形态：部署形态和运行形态
部署形态
1、流程结束后，将业务系统、SLA要求、部署详情写入CMDB；
2、根据既定的部署流程，启动流程（系统预先内置部署流程）；
3、匹配自动化脚本（或者调用API）；
4、自动创建运行环境，部署系统；
5、更新CMDB。
运行形态
1、监控工具从CMDB获取策略；
2、监控工具收到指令，立刻实施监控；
3、监控工具实时反馈业务系统SLA指标给CMDB；
4、CMDB将实时反馈与原有的设定进行对比及趋势分析，判断运行的状况；
5~8、一旦当前运行状况不满足要求，CMDB触发自动化流程，对运行环境实时弹性扩容。
以上可以看出，CMDB已经转变为自动化，由服务驱动整个过程，让业务系统的运维更加敏捷。因此，构建持续、高效、敏捷型的运维，服务型CMDB的建设更显重要。
服务型CMDB建设需要从2个方面入手：
1、服务意识
传统型CMDB，服务的对象是运维人员，大多被动接受一些指令。然而，云计算下CMDB的服务对象更多是业务策略、流程、自动化工具。由被动的模式变为主动模式，需要主动去发现问题、解决问题。
2、服务框架
提供完整的API体系，构建围绕上层业务的服务，充分整合外部应用，为应用的扩展提供便捷。
若想建设健壮运行的CMDB，以上两个切入点只是开始，扎实的基础功能必不可少：
1、建模能力
建立灵活的底层数据模型，可以随时扩展资源，满足不同应用场景的消费需要。
2、自动发现能力
采用轮询机制、APM抓包、API调用等方式，发现数据中心和云环境的基础设施、虚拟应用以及它们之间错综复杂的关系。
3、清晰的表现能力
通过多维度、多视角，清晰明了地展示整个数据中心的架构。
4、管理粒度
在基础设施同应用模型之间建立授权管理机制，根据业务需要来确定管理的深度和粒度。
5、容量分析能力
评估数据中心，综合度量分析，掌控运维家底和态势，并持续推动运维能力的改进与提升。
6、影响分析
通过影响分析功能，快速分析故障影响的范围和程度，及时找出故障根源，保障业务高效运行。
在这个理想化的场景下，CMDB为业务系统提供SLA服务要求，为系统架构的建设和扩展提供驱动能力。没有一个CMDB能够做到开箱即用，每一个企业都有不一样的管理角度和管理粒度。我们只有先做好CMDB自身的服务，夯实基础，灵活扩展，上层才能依据业务按需实施。CMDB的建设不是一蹴而就，而是由业务场景驱动、慢慢磨合，CMDB建设之路任重而道远！
作者简介：周振中，现任优云软件产品汪，运维工程狮一枚，小半条腿跨入运维的浩瀚世界，目标是成为一只有点逼格的产品汪，就酱。
标签：自身 个数 结束 调用 软件 bsp 解决问题 配置 单元
原文地址：http://www.cnblogs.com/uyunsoft/p/6866797.html
