(深度好文)重构CMDB，避免运维之耻(3)

我自己觉得这个场景很好归类,把角色+维护的IT服务对象二维考虑起来,把自动化+可视化当做目标,服务化(API化)的能力结果就是必然.同一个角色可能维护了很多IT服务对象,把这个IT服务对象的管理能力API化,供外部服务集成,IaaS云平台就提供了很好的示范.

• 基于应用交付流的场景识别

这个是应用运维场景的垂直识别.如果按照云计算的三个层次来说,IaaS和PaaS依然是底层的运维支撑能力,面向应用的运维能力才是真正直接作用于用户的.面向用户的价值流梳理对应的就是应用交付流的识别.里面有几个核心的场景：应用上线场景、应用维护升级场景、应用迁移场景、应用下线场景等等,贯穿了整个应用交付的生命周期管理.

最后,其实CMDB就是“资源+动作+状态”形成的统一入口

CMDB到底是什么?什么可以让CMDB成功?最近不断在思考这个问题.有天我回到了之前在UC维护的一些代理游戏业务,看过Gameloft的游戏管理后台,才找到CMDB的答案.后来又对照我们公司CTO黎明之前在腾讯做的织云全自动化平台,对这个答案就更加具体而明确了.

在游戏运维管理系统中,几个信息是关键且必不可少的：

• 游戏关联的资源.游戏运行的主机有哪些?主机上启动哪些进程和端口?进程和端口分别属于哪些区服(一般用端口来划分)?
• 游戏关联的运维场景.开区开服、合区合服等等.
• 游戏当前的状态.查看区服的用户数量,连接数,资源的状态等等.

由此就已经构成了一个强入口,这个强入口不断吸引游戏运维参与信息的维护,同时参与信息的变更过程.因此我也下断言,CMDB应该成为运维人的入口,不仅仅是静态信息的入口,而且是一个动态变更和状态管理的入口,把面向场景的运维编排集成到CMDB之中才是未来,否则在一个IT快速变化和组织弱约束的环境中,CMDB的失败还是不可避免.

谁让CMDB成为入口,谁就可以让CMDB成功!不过那时CMDB是不是叫CMDB就真的无所谓了!

文章来自互联网运维杂谈

（编辑：ASP站长网）