DevOps与传统的融合落地实践及案例分析（上）(3)

把这两层的维度强关联起来,然后在应用上层构建应用的各种的管理场景,比如说应用的发布、应用的部署、应用的监控等等.应用的数据分析,由它来进行进一步的驱动CMDB的流转,因为在应用的维度上,才符合以前讲的高频的特征.

今天到任何一个组织,其变更的场景来说,应用是最频繁的,比顶层基础设施更频繁.如果符合高频的特征可以理解场景化的能力最强的,场景化的能力强那驱动力就是最强的,今天把CMDB转化成IT资源管理,以应用的视角看资源.这个平台里它的核心作用是毋庸置疑的,应用是CMDB平台的元数据.

这里面怎么样的上层联动?CMDB这么多的数据,其实就是一类的实例的数据.比如说这里面到底有多少服务器、服务器有多少的虚拟机?这是实例的数据,然后就是拓扑的数据.我的服务摆在机柜上,介入的上面数据是什么.同样是根据顶层的资源拆出来的,一个基础资源一个是应用的资源,分成实例管理和拓扑管理.

今天很多人讲自动化,其实资源有生命周期的状态,一定不能通过自动化来替代的.比如说这个IP地址从资源池里面分配出来给业务池使用,一定要通过一个流程申请出来,无论是自动化的还是以前离线流程的,这是一个生命周期的状态,IT地址退还不能保留业务使用,这个一定要有流程控制的,这里面自动化不能代替人工的流程,流程是聚焦在事前的管理.

再往上是场景应用,要找各种的场景应用,构建出来这一层做的形象的比喻就相当于今天的地图一样的,比如说百度地图,这个地图可以在不同的场景用,大众点评可以用,滴滴也可以用,今天的CMDB也起到这样的作用.这么多场景建设的时候,事件平台是一个很好的入口.

因为今天看到传统的行业太多的监控系统,这个监控系统都要进行收敛,怎么收敛?把所有的监控实践发到统一事件系统,由统一事件系统根据底层的IT对象关系自己来进行收敛,现在老的监控系统基于CMDB收敛是很难的,基本上找不到监控厂商来修改,提一个需求要带来大量的成本.

为什么一直在讲CMDB核心的管理模型是应用的管理模型,IT形态发生变化了,这个模型不用改变的,不用调整的,比如说是公有云.CMDB模型的扩展力是把所有的资源管理起来,这个资源分成本地资源和第三方的资源,本地资源是应用部署在同一主机上的资源,比如说程序包、操作系统的版本,使用的内存,或者是这里面的配置的版本等等,甚至在本机占用了端口甚至是接口服务都是我们的资源.第三方资源如阿里云,这些资源都可以通过应用管理维度集中起来.

第五则：痛苦的事情优先解决

基于角色和产品如何梳理管理能力?运维的复杂度为什么复杂?在这儿,因为运维角色太多了,管理的对象太多了,产品太多了,最终出来的能力管理流程也可以太多.开发测试没有如此复杂,开发就开发,测试就测试.这里面一定要通过角色＋场景,最后导出我应该构建什么样的能力管理的平台出来,一定要有这样的思路.

今天讲的运维自动化,最后我变成配置管理或者是工具的自动化或者是调度的自动化,这个远远不够,其实运维自动化弥漫在每一个角色、每一个场景里,今天说的基于容量的自动扩容不算自动化吗?CMDB的自动发现不算自动化?基于监控事件故障自愈不算自动化吗?都算.基于这个图把自动化的场景收敛一样,作业和调度的能力是底层平台化的能力,在各个子系统使用.

第六则：工具也是一种文化

这里面讲的作业管理和调度的管理应该是平台级的能力,不需要进行场景化的理解.在自动化的构成要素里有一个原子化的事务,同时有调度编排原子化的事务,有两个要素有够了.再往上是面向角色的场景化收敛和归类,工具可以把我们的能力拼装起来,在各个场景下使用.工具是真正推动变革的有效手段,好的经验一定是通过自动化的手段沉淀管理过程.

文章来自微信公众号：优维科技EasyOps

（编辑：ASP站长网）