结合公司现状浅谈CMDB

本篇文章结合参考资料中的几篇CMDB的文章再加上目前公司的现状谈一谈CMDB。

CMDB概述

CMDB:configuration management database,配置管理数据库。CMDB本质上是一个数据库,提供数据的存储、查询、校验等操作,是一个集中式的数据托管中心,托管的内容包含所有的软硬件资产(configuration items)。各个部门各个团队各个系统下属的各种重要的软硬件资产都属于CMDB统一管理的内容。

公司运维现状

资产现状

全国各地区内网不互通。这个就是现状了,因为公司产品是为国家服务,所以全国各地的环境都在各自的内网中,安全性极高,在这种情况下,每个地区都配置了几个运维手工维护当地的环境,内外网完全隔离。

运维情况现状

由于公司资产地域分散且网络不互通,因此公司的自动化运维程度基本为0。整体上来说没有运维开发的岗位,目前的运维仍然停留在人工运维结合shell脚本的时代,这些其实都算不上自动化运维,前段时间,开始搞ansible自动化部署和升级的事情,整个过程都是shell脚本完成。为了控制人力成本,甚至否认一些用新技术。拿Python这门语言来说,本身很适合自动化运维,用于自动化升级那是再适合不过了,虽然底层会依赖shell,但是Python写出来的逻辑必然会更清楚,但是上层考虑到后续维护人员需要掌握Python和shell两种技术,最终还是否定了Python,其实也就是否定了自动化运维。转而几种人员去研究日志中心和nagios监控,自动化运维的事情也自然不了了之。

CMDB现状

目前公司里面还没有产生建设CMDB的萌芽,资产管理部门和运维中心团队有自己的配置库,也就是自建库。但是并没有将产品团队的软件资产列入配置管理的范围。各个产品团队使用Confluence文档服务器或者Excel表格(这种情况较多)管理自己的软硬件资源,并称之为资源台账。就服务器而言,经常不知道一个ip对应的服务器是否正在使用,由谁使用,这些信息一无所知。如果各个团队使用自建库,而不是通过文档形式来管理,那这种CMDB最多也只能算是各自为政的CMDB,并不是集中式的数据托管。

CMDB设计

最简单的设计:一种配置一个表

比如,ip单独成表,host单独成表

优点:配置简单直观

缺点:一旦某种配置需要修改字段,就需要修改代码,代码维护成本太高

复杂点的设计:列式数据存储

表名,列名,列

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值