论坛
潜水/灌水快乐,沉淀知识,认识更多同行。
ToB圈子
加入IT圈,遇到更多同好之人。
朋友圈
看朋友圈动态,了解ToB世界。
ToB门户
了解全球最新的ToB事件
博客
Blog
排行榜
Ranklist
文库
业界最专业的IT文库,上传资料也可以赚钱
下载
分享
Share
导读
Guide
相册
Album
记录
Doing
搜索
本版
文章
帖子
ToB圈子
用户
免费入驻
产品入驻
解决方案入驻
公司入驻
案例入驻
登录
·
注册
只需一步,快速开始
账号登录
立即注册
找回密码
用户名
Email
自动登录
找回密码
密码
登录
立即注册
首页
找靠谱产品
找解决方案
找靠谱公司
找案例
找对的人
专家智库
悬赏任务
圈子
SAAS
IT评测·应用市场-qidao123.com
»
论坛
›
运维.售后
›
运维.售后
›
长文 重构CMDB,避免运维之耻
长文 重构CMDB,避免运维之耻
宝塔山
金牌会员
|
2025-3-7 01:46:24
|
显示全部楼层
|
阅读模式
楼主
主题
975
|
帖子
975
|
积分
2925
CMDB,险些是每个运维人都绕不过去的字眼,但又是许多运维人的痛,因为CMDB很少有乐成的,因此我也把它称之为运维人的耻辱。那么到底错在哪儿了?该怎样去重构它?
我之前写过一篇关于CMDB平台建设的文章【平台篇】运维平台之CMDB体系建设,谁人太技术化了,我觉得照旧无法避免失败,文中也提到了部分失败原因。本日我想从我的角度来和大家探讨一下业务失败的原因,基于失败再去看重构的逻辑,也许会乐成。
从失败中探求乐成的逻辑,每每是最有效的,那我们就来逐一看看:
1、构造的计划问题
我必须把核心原因归结成这一条,许多公司把CMDB的建设责任放到底子办法建设部门,由他们主导承建。末了他们梳理出来的核心逻辑是面向底子办法资源的管理,你在他们的CMDB中都能看到如下菜单,AIX主机是哪些,中心件有哪些,大小机有哪些,Oracle有哪些等等,这些都是和公司的IT运维部门构造布局是逐一对应的。
构造的隔离是CMDB失败的核心原因!
这个里面能看到一些CMDB管理能力错位,拿两个例子来说一下:
A、中心件。一直搞不明确为什么中心件要作为一个单独的对象来管理,“皮之不存,毛将附焉”。
没有主机,没有业务这个皮,哪来的中心件
。把他单独拿出来管理,纯粹就是为了满足构造的一个管理视角。从来没人想过,这是主机上的一个资源对象,应该是一个附属资源,实在对他的信息管理和机器上的CPU、网卡一样。
B、进程对象,比如说数据库
这个是另外一种管理错位,是专业的管理平台应该去履行的管理职责,结果放到CMDB平台中了,然后CMDB管理了大量的动态属性,比如主备关系,服务状态等等,太复杂了。最简朴的看,从主机的角度来说,他就是服务器上运行的一个进程而已。
管它死活干嘛,那是监控体系做的事情,管它状态干嘛,那是**组件管理平台干的事情
。
2、Excel是最好的管理工具
当构造隔离,不可以或许形成有效的信息互动之后,Excel更是之上的一次痛击。可能从外围思考,为什么不去解决现实层面上的问题,而选择了Excel?Excel很简朴,特别是IT服务对象不多的情况下,几百个照旧可以或许应对的。我就拿个Excel记录一下,然后svn上小组内共享一下就好了,反正我的信息也就我使用,别的小组也不消(构造的隔离性)。对它的思考,照旧要回归的第一点,使用Excel是结果,但我比较反对Excel做法。
每次建设cmdb的第一个目的,就说要消灭掉Excel。
3、去简就繁
这个是从产品本身说的,我看了几个开源的产品,oneCMDB和iTOP(建议大家都体验一下),界面都是复杂的要命,还有商业的产品(具体哪家不说了)。
首先必须要解决产品易用性的问题,易用性不够,你怎么让能用户有使用的欲望呢,以下是来自于UC做的CMDB体系产品截图:
其次还有一种信息复杂带来的易用性下降的问题。我看许多产品都管理了一些无光的信息,信息的管理归类也是有考究的,没归类好,用户又被沉没了。
拿主机来说,维护其核心需要的信息就好了,比如说固资编号、地点机房的位置信息、厂家信息、上架信息、进程端口信息、维护信息等等。这些信息都是有运维场景的,比如说位置信息+固资信息在驻场需要操作的时候有用;上架信息对于过保维修有用;进程端口对于监控有用;维护信息在运维申请资源的时候有空,谁也不想用经常故障的机器吧;主机状态位是用来做资源池管理+监控使用的。
4、配置管理流程,而非业务管理流程
是业务变更触发配置变更,而非配置管理触发变更流程。下图是一个典型配置管理流程图,看懂的,请举个手!!!
许多配置的变更都是因为场景变更引起的,比如说机器搬迁导致机器的物理位置信息发生变革,那就搞一个机器搬迁流程吧;机器上的业务下线了,但进程信息没有清理,那是业务下线流程的问题....
5、和应用没有关联,更别提场景关联了,就更别提主动场景了
很有意思的现象:客户的监控体系中监控的应用主机信息都是该体系中自行维护的,从来没有思量从CMDB获取。也就是因为CMDB是另外一家产品,为啥呢?如果资源和应用关联起来了,并且由他来驱动监控,这个维护的动力是不是不一样呢?
哪怕是你的CMDB体系可以或许支持一下我上图中的工具盒子的能力,CMDB维护的动力不至于那么糟糕,它的数据也不至于那么糟糕。之前和人探讨过是先有操作体系安装把信息写到CMDB照旧先有CMDB的信息然后再有操作体系安装的动作?当然是后者了。事实上在服务器采购分配上机架的时候,实在所有的信息都分配完毕,此时入库,就可以启动远程主动安装了。
实在还有许多原因,比如说物理世界和逻辑世界是独立的,物理世界发生的过程没法直接映射到CMDB体系中(有些配置信息需要进入固件中);CMDB的对象Owner没有或者过多(Owner很累);过分强调CMDB的基线作用,引入对比(动态变革的情况基线的作用应该下降);夸大CMDB主动发现的作用等等。
说了许多的失败的原因,接下来就需要讨论一下解决方案了,既然讲重构,老王的重构逻辑是什么样的?
第一、重构你的CMDB头脑
建议大家不要把CMDB称之为CMDB了,那叫什么,就叫资源管理吧。为什么你要从改名字开始?老是叫CMDB,大家都回到过去的头脑上了,道不清说不明的,或者各执己见。
统统皆资源!!!
统统皆资源
!!!
统统皆资源!!
!
从底子办法的对象来说,盘算资源、存储资源、网络资源、IP资源、机房资源等等,在CMDB的管理上,把你的资源对象罗列出来,关系梳理清楚,就可以构建其能力管理了。
从上层的业务资源来说,
建立以应用为中心的资源管理逻辑
,把 统统都看成应用的资源来看待。比如说Host,应用包、权限、RDS服务、cache资源等等。
老王现在做的产品把CMDB一分为二,底层的底子资源层CMDB可以不要。在不要的情况下,我可以构建上层应用的信息管理平台(业务CMDB),它可以独自构造场景来驱动上层运维。以下是优维EasyOps产品截图:
随着应用相关的一些支持资源云化之后,面向应用的资源管理能力要不绝增强。我经常和大家举的一个例子,是IaaS公有云平台中的Mysql实力已经是一个资源对象:实例域名。怎样实现的对他们的管理,你只能把他当成一个附加资源来举行管理,不是么?
此时有意义的事情来了,你管理的业务资源信息越丰富,你的主动化驱动能力就越强。别再绕回去了,说让主动化来帮我维护这些信息。相辅相成、互相促进的事情,就不该设定前提,而是关注谁人上升式的过程。
第二、重构你的CMDB方法
尺度的CMDB方法是教你怎样迭代举行一个CMDB项目,这个没有错误,但我会指出有些方法是你必须要坚持的,否则你的体系会面临失败。
A、放弃你的excel
excel是一个CMDB失败的佐证,必须去除它的存在,许多时候大家说是体系不好用引起的,但我的观察是大家的习惯引起的。改变习惯很难,有些时候需要借助构造自上而下的力量。没有集中的平台依靠,平台是没有人去驱动优化的。
B、构建CMDB的微内核和弹性CMDB模子库
CMDB的微内核很小,实在你只需要应用、集群和主机三个概念就可以构建起一个CMDB,基于这三个概念,可以不绝去向周边扩散。应用可以往用户侧的概念不绝靠拢,形成业务的概念。主机可以在其关联或者拥有的资源上不绝去扩展,比如说主机地点的机柜、机柜地点的机房、机器关联的交换机等等。
这个微内核,我想是可以适用统统场景了,但还不够呢,怎样保证这个模子对所有企业做到落地可适配的?这个时候就是弹性模子的作用了。弹性模子由对象的弹性和对象CI及其关联的弹性定义实现的。简朴的明确,你就是实现了一个业务数据库的可视化定义,下图是对象的弹性定义:
下图是对象的CI及其关联关系的弹性定义:
C、构建“主动发现+尺度流程+人工维护”的CMDB数据库
主动发现是降低维护成本的一种有效方式,但我认为确保一个CMDB库信息的有效性,照旧需要其他几个手段,尺度化的流程和人工维护。
尺度化的流程是运维资源信息变更的场景化流程梳理,比如说机房搬迁,服务器搬迁,服务器下架等等,这个流程需要识别出来,并确定相应的CMDB配置项状态变更过程。
人工维护,在有些流程没有构建起来的情况下,则需要通过人工变更的能力把CMDB信息维护准确,比如说主机所属负责人变更,这个时候不建议流程了,可以通过人工直接变更完成。那怎样确保维护准确呢?通过外围体系来控制,比如说告警信息,如果负责人没有变更告警是直达原有负责人,导致告警不准确。
D、CMDB是连续迭代的过程
贪大求全求细、一步到位都是它的反义词,建议以微内核和核心需求为中心,快速实现,然后在此底子上快速迭代。随着底层云平台的出现,对CMDB都提出了新的要求,我们都知道,每一个IaaS都有一个自己的CMDB,怎样实现对IaaS云的CMDB管理?Docker和其他类似服务化平台出现之后,又怎样实现这类资源的管理?
E、边界、边界、边界
CMDB实现拓扑是为了故障定位,但不能实现故障定位;CMDB实现资源管理,可以去评估故障影响,但不能实现故障和变更影响评估;CMDB实现业务拓扑是为了快速的故障定位,但不能实现故障根因分析;统统都是因为在CMDB提供的数据底子之上,周边体系(变更、监控、发布)借助的CMDB提供的数据能力,实现自身的场景化体系能力。
第三、重构你的CMDB构造
围绕业务能力重构你的CMDB!!!
分离CMDB建设的层次和布局,独立建设不是没有可能,至少应该分离出两个CMDB体系--面向底子办法的资源管理体系和面向业务的资源管理体系。
面向底子办法的资源管理体系可以由数据中心的同事来建设,而面向业务的资源管理体系是由应用运维部门来构建。
这两者没有先后之分,当然如果有底层的底子办法的资源管理,在其上构建业务的资源管理体系之后,数据的关联性会更强一些。
如果在两个职能管理分离的构造中,这个独立建设的必要性就更强了。比如腾讯,CMDB就是分两层的,一层是有网络平台部建设的面向底子资源的CMDB管理平台,另一层是业务的CMDB(是否叫CMDB已经不紧张了),是各个业务部门建设的。
第四、重构你的CMDB产品形态
建立面向应用的资源管理CMDB!!!
核心是面向应用的CMDB产品思绪要发生重大变革,仅仅聚焦在资源管理是远远不够的,资源是静态的。必须要建立一个逆向头脑,不要从资源的角度维护资源,而是从应用的角度来维护资源。主机是什么?是应用的一个资源;Docker是什么?可以看成应用的附属资源;PaaS平台中分布式RDS服务是什么?是应用的附加资源等等。
这个形态要突出应用的核心位置,并以此为核心打造CMDB的管理入口,把资源管理、应用的场景维护等能力精密集成起来。
第五、重构你的CMDB服务场景
经常大家都在说CMDB场景化,那真正的场景化到底是什么?
基于流程的场景识别
这是最传统的场景识别方式,通过ITIL认识到IT服务管理的核心流程,这些流程实在就是运维的场景。这个场景还有两个方面需要改进,第一在企业落地的过程中要结合现实,细分成一些核心流程;第二,具体的场景流程需要基于角色举行分类细化,比如说网络运维、服务器运维、机房运维、业务运维等等。
基于服务化的场景识别
我自己觉得这个场景很好归类,把角色+维护的IT服务对象二维思量起来,把主动化+可视化当做目的,服务化(API化)的能力结果就是一定。同一个角色可能维护了许多IT服务对象,把这个IT服务对象的管理能力API化,供外部服务集成,IaaS云平台就提供了很好的示范。
基于应用交付流的场景识别
这个是应用运维场景的垂直识别。如果按照云盘算的三个层次来说,IaaS和PaaS依然是底层的运维支持能力,面向应用的运维能力才是真正直接作用于用户的。面向用户的代价流梳理对应的就是应用交付流的识别。里面有几个核心的场景:应用上线场景、应用维护升级场景、应用迁移场景、应用下线场景等等,贯穿了整个应用交付的生命周期管理。
末了,实在CMDB就是“资源+动作+状态”形成的同一入口。
CMDB到底是什么?什么可以让CMDB乐成?最近不绝在思考这个问题。有天我回到了之前在UC维护的一些代理游戏业务,看过Gameloft的游戏管理后台,才找到CMDB的答案。后来又对照我们公司CTO黎明之前在腾讯做的织云全主动化平台(【阅读原文】请相识“腾讯织云主动化平台”),对这个答案就更加具体而明确了。
在游戏运维管理体系中,几个信息是关键且必不可少的:
游戏关联的资源。游戏运行的主机有哪些?主机上启动哪些进程和端口?进程和端口分别属于哪些区服(一般用端口来分别)?
游戏关联的运维场景。开区开服、合区合服等等。
游戏当前的状态。检察区服的用户数量,连接数,资源的状态等等。
由此就已经构成了一个强入口,这个强入口不绝吸引游戏运维参与信息的维护,同时参与信息的变更过程。因此我也下断言,
CMDB应该成为运维人的入口,不仅仅是静态信息的入口,而且是一个动态变更和状态管理的入口,把面向场景的运维编排集成到CMDB之中才是未来,
否则在一个IT快速变革和构造弱束缚的情况中,CMDB的失败照旧不可避免。
谁让CMDB成为入口,谁就可以让CMDB乐成!不过当时CMDB是不是叫CMDB就真的无所谓了!
优维的EasyOps产品栈会在六月份Release这样的一个颠覆性CMDB版本,敬请等待。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有账号?
立即注册
x
回复
使用道具
举报
0 个回复
倒序浏览
返回列表
快速回复
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
or
立即注册
本版积分规则
发表回复
回帖并转播
回帖后跳转到最后一页
发新帖
回复
宝塔山
金牌会员
这个人很懒什么都没写!
楼主热帖
分布式事务 | 使用DTM 的Saga 模式 ...
Maxwell 一款简单易上手的实时抓取Mysq ...
Sqlserver2012卸载
哈工大信息安全概论期末复习 ...
WebLogic JNDI注入(CVE-2021-2109) ...
HTTPS基础原理和配置-3
轻量级CI/CD发布部署环境搭建及使用_03 ...
数字IC-1.9 吃透通信协议中状态机的代 ...
[DuckDB] 多核算子并行的源码解析 ...
.NET服务治理之限流中间件-FireflySoft ...
标签云
运维
CIO
存储
服务器
浏览过的版块
医疗.卫生
IT职场那些事
主机安全
云原生
快速回复
返回顶部
返回列表