loading外的其它组织就做不成CMDB，在下一篇文章中我将尝试总结一些相对通用的CMDB建设经验，分享给还在与CMDB搏斗的各位同好。
经验教训 训
通过成功的道路往往曲折艰难。建设CMDB也是如此。那些年，我们做了大量的尝试，有些成功了，有些失败了。抛开华为的特殊性，在这里总结一些通用的经验教训：
1. 拆迁不如搬迁
运维环境中已经存在的自建库，虽然粗糙，但有其存在的意义。贸然拆迁会有巨大的风险。比较保险的办法是保留原有的数据维护模式不变，只进行数据的复制搬迁。历史的经验也告诉我们，包产到户比人民公社更有效。
2. 配置模型要接地气
抑制设计完美配置模型的冲动。CI的粒度和关系要与当前的运维管理粒度一致。
3. 开放心态和数据分级管理
配置管理范围和CMDB管理范围是两回事。CMDB是一个大的数据管理舞台，有需要但没有合适管理工具的数据都可以放入CMDB中。但只有最重要的数据（如果错误会导致下游业务异常）才纳入配置管理。
4. 数据维护流程要简化
与其担心别人把你的数据改错，你更应该担心别人不愿更新数据。而复杂的审批流程，只会降低大家维护信息的意愿。
5. 保障数据的完整性
数据错了，可以在使用中被发现。但数据少了，是很难被发现的。同时，CMDB数据的完整性（就是家底）对于有广覆盖要求的业务有巨大的吸引力，因此要重点保障。
6. 数据消费要有反馈
如果无法捕捉反馈，就无法做到“在使用中促进数据准确”。
7. 可视化
可视化能够降低信息的理解门槛，也能够更好的暴露数据质量问题。是引爆消费、提升数据质量的重要手段。
8. 在初创阶段，要克制数据分析的冲动
CMDB高级阶段的能力，对数据量和数据质量的要求极高。在CMDB建设初期还是要务实一些，以与系统对接、供应原材料数据为主。
通向未来的路配置管理深深的“摧残”了我。几年下来，我逐渐形成了一种“非确定性悲观”的心态。我总觉得数据有问题，但又不知道哪有问题。随着使用配置的客户越来越多，我总担心哪天因为配置不准而摊上大事。
因此，我想尽办法搞一大堆的数据质量检查措施，有变更后的检查、定期的审计、逻辑合理性分析、CI责任人的定期自
我审视。这些措施，除了逻辑合理性分析有用外，其他基本没啥用。但这不重要，真正重要的是：当我摊上事的时候，起码可以跟领导说，你看，我该做的都做了…
可是，难道我们不应该更愉快的工作吗？
未来，肯定有更好的实施CMDB的方法。
这种方法，能够更大限度的提升人们生产信息的原动力和创造力，能够以非侵入的方式与各业务流程无缝集成，最重要的是，能够降低实施CMDB的门槛和风险，使大量中小型的IT组织能够从中受益。当然，也使配置管理员不那么的辛苦……
经过两年的探索以及与国内大量顶尖IT管理者面对面的交流，我们忽然发现，“自服务+可视化”的CMDB也许是一条通向未来的道路。CMDB与架构图的亲密接触会发生什么呢？这是我近两年一直研究的课题，相信在不远的将来，大家能会看到一个全新的方案。（虐心，但蕴含着无限可能）
谨以此文，向那些曾经在配置岗位上一起奋斗过和至今仍在
奋斗的战友们致敬。