上周做了一个自动化运维管理体系的培训。在提到两个案例时，突然发现他们在做自动化运维时不约而同地将配置管理放在首位去考虑。整理培训课件的时候，我还没太在意这个顺序，讲得时候串在一起就很明显发现这个优先级了。
今天为什么要讲这个话题呢？当然是为了推介我们的CMDB解决方案。各位有兴趣的可以继续往下看，没兴趣的话也算是捧个人场了，感谢，感谢！
做CMDB这件事，搁在十年前那是大兴土木的活，因为要“大而全”。但时间走到今天，这“大而全”的事儿就不那么灵光了。现在找过来聊CMDB的，我们都会开门见山地说：要做CMDB，就是“小而美”的方式。不是说我们有多拽，而是，不这么做，难成！我们都经历过“大而全”的痛苦，见到过实施后的空洞期。我们不想在十年后重构CMDB的时候再来走一遍回头路。真没这个必要！
纵观这十多年CMDB建设的变化，最大的一个是CMDB不再是一个配置管理库，它将是运维的数据服务中心。专心专注于提供数据的消费。连接场景-服务-数据。
看一个产品，不是关注它的功能，而是它能解决什么问题，用什么方式来解决。
我们的CMDB团队有技术能力、有咨询能力、有产品能力，这样的组合会更能从行业的角度，用户的痛点以及落地的要点来解决遇到的任何问题。也许会有人说，你在这里瞎白活，一点都没有干货！但，什么才是干货呢？难道只有告诉你如何梳理分类，如何设计模型，如何构建场景才是干货？思想没有改变，所有的干货都只是挂在店里的“南北货”！从实施角度来看，达成共识的合作才能事半功倍。那么，我们寻找的就是在CMDB建设上能认可“小而美”的构建方式。因为我们关注的是“痛则不通”的痛点，所以关注功能更多会让我们把眼睛放在了工具上，而不是主体的感受上。客户重构CMDB的本意不是买工具，买模型。他们要的是解决数据不准，供给不畅，消费不好的问题。这个，我们擅长！
我们坚持做场景，以场景引导出服务，由服务告诉我们数据是什么，在哪里 。
也许你们会觉得讲这些很虚。没办法，如果理解不到这个层面就看不到背后的价值。认可我们的客户，基本都经历过十年的折磨并清醒地认识到CMDB建设的“宜”和“忌”到底是什么。如果没有他们的认知改变，我们想做个场景都很难。真的！我们奉行的“Less is more”与“大而全”天生冲突。场景，实现很难吗？这个要看场景里的具体设计要求是什么。那么设计的边界和颗粒度如何确定？这个取决于客户在CMDB应用上的痛点到底是什么。而对痛点的分析、规划和设计又是我们的强项。
最后，再说一句：重构CMDB的时候别再只盯着功能看了。
以上是做完自动化运维培训之后的一些碎碎念......
