这是一个创建于 366 天前的主题，其中的信息可能已经有所发展或是发生改变。
做的很不错，自定义 model ，灵活性强，功能完善，开源免费
介绍： https://blog.ops-coffee.cn/s/veops-open-source-cmdb-devops
Github： https://github.com/veops/cmdb
官方还提供了在线 Demo ，感兴趣的可以看看
 |
1
TZ 2023-11-23 08:31:25 +08:00
我还以为骂人
|
 |
3
sun522198558 2023-11-23 08:55:49 +08:00  1
star 了
|
 |
4
yestodayHadRain 2023-11-23 09:10:15 +08:00
房车老哥
|
 |
5
37Y37 OP @yestodayHadRain 房车是我的，这项目不是
|
 |
6
brom111 2023-11-23 10:47:20 +08:00 1
看了眼 这个项目好像改过名字。好久之前就 star 了
|
|
7
37Y37 OP @brom111 开源时间好多年，之前只有后端 api ，也没怎么更新过，对普通用户不友好，今年增加了前端，也开始频繁更新了，我看现在基本每周发版
|
 |
8
heong 2023-11-23 11:35:25 +08:00 1
房车老哥 威武
|
 |
10
Tumblr 2023-11-23 12:53:43 +08:00
其实 CMDB 的难点不在于用哪个产品，而是后期的管理、使用和信息更新，很多做 CMDB 的，用着用着里面的数据就 outdated 了。一个企业在尝试 CMDB 的时候，必须约定好后期的信息更新流程，否则用着用着就废了。。。
当然啦，先利其器，找到一个好的产品，必然对后期的使用起码辅助效果，甚至可以事半功倍了。 |
|
11
37Y37 OP @Tumblr 手动更新不靠谱，自动更新很有效，我们目前是这个模式，更细的我有单独写过我们的落地方案，开源的这个产品我看也有自动发现，使用的时候就得具体再看了。不过你说的对，工具本身并不能解决任何问题，还是得配合规范和管理，只是在这个过程中不同的工具带来的管理成本差别很大
|
|
12
Tumblr 2023-11-23 15:43:13 +08:00
@37Y37 #11 是的，主要是规范和管理。规模上来之后，一些流程规范不到位，即使有自动化的方案，也很难细致化落地。以我们这里为例吧，虽然绝大多数会按规范，但还是有少部分人不太按规范。
举个场景： 一台 AD 域里的 Windows 服务器要下线，正常来说，应该是提个变更，变更工单中选择合适的参数之后，会自动创建一些自动化任务，把这台服务器退域，移除监控项目，更新 CMDB 的数据状态，直到这台服务器关机下架（物理服务器）或者在平台删除（虚拟机），看上去很理想是吧？但是有的人就会直接关机，手动下架，并且不知会 stakeholders 。 |
|
13
37Y37 OP @Tumblr 嗯，确实，应该类似的场景有很多，对于你提到的这个场景我们是这么做的，会有探针检测主机存活状态/数据变化，如果主机不在了，那则会提示管理员做后续处理，例如移除监控/更新 cmdb 等等原本自动化的流程
CMDB 系统的好处是，可以尽可能的收集全信息，然后针对不同场景做自动化处理，cmdb 与上层系统必须做到强依赖，做到数据唯一，从这个方面来进一步倒逼数据准确，不然上层业务就会有问题 |
 |
14
jones2000 2023-11-23 16:52:42 +08:00
可以追踪一条记录的完整过程吗？比如我写入一条记录，什么时候写入主的，什么同步到副本机器或其他节点。整个过程通过图的方式展示出来。可以回溯看历史上的某一条记录的整个过程。
|
 |
16
chilaoqi 2023-11-24 19:57:56 +08:00
cmdb 的建设成本太太太太高了。
|
 |
18
spug 358 天前
很不错的 cmdb ，我们也在用。
|
Select Language