CMDB与其他系统关系是什么?哪些数据需要归入到CMDB管理中? ...

银行企业为什么要建设CMDB项目？推行的难点主要在哪方面？与其他系统关系是什么？项目上线后怎样对运维工作举行管理安排？在产品选型过程中需要注意的要点？本文来自金融行业的社区会员分享。


■ 银行为什么要建设CMDB项目？
@周航 某银行 软件架构计划师：
此问题可以从三个角度出发：建设背景、建设痛点、建设代价，下面我为大家一一阐述：
银行业CMDB的建设背景：
银行业的CMDB建设基本上可以界说为三个阶段，第一阶段主要是台账式配置管理，其数据主要是通过手工维护的，基础需求是为了满意基础的硬件资源管理及监管要求。第二个阶段是面向IT基础资源的配置管理，其主要关注各类软、硬件资源的全生命周期的管理。第三个阶段是面向应用的全生命周期管理，其重点关注从应用的创建、研发测试、上线、变动、迁移、下线接纳整个过程，同时重点关注应用之间、应用内各组件以及组件的关系信息。目前大部门银行企业的CMDB建设处于第一、二阶段。
随着云盘算、大数据、微服务的不断发展，传统的CMDB逐渐已无法满意各类消耗需求，具体主要体现在：
1、以IAAS、PAAS为基础的云情况与传统的运维情况共存，双态模式使得数据中心的基础架构更加复杂，也使得CMDB的模型和关系建设更加困难。
2、微服务的发展使得应用内的拓扑关系、应用间的调用关系信息更加复杂，故障定位与变动影响分析等场景愈加困难，进而对CMDB的消耗依赖以及模型粒度，也从传统的应用级逐步向应用模块、应用服务级变化。
3、随着ITOA（大数据运维）、AIOPS（智能运维）等理念工具引入运维领域，对配置数据的消耗需求越来越旺盛，对CMDB的准确性、全面性、实时性也越来越高。
CMDB系统的建设痛点：
1、数据标准不统一
各专业运维工具各自维护一套配置数据，数据之间有交织有重复，缺少统一的数据标准和唯一的数据源。
2、数据准确性差
（1）大量技能属性仍通过手工维护，配置自觉现本领不足。
（2）大量管理类属性数据以台账方式手工维护，没有现有的管理流程和工具深度集成，数据准确性和实时性差。
3、消耗场景难以发掘：
CMDB消耗场景往往跨条线、跨领域，需要CMDB的产品经理具备跨专业的技能知识储备，同时要与各专业工具举行实时有用的沟通交换。
CMDB系统的建设代价：
1、制止配置数据被重复维护，降低数据管理的总成本；
2、整体运维共享同一套配置数据，使各运维专业对IT资产的基本配置情况达成共识，并驱动各流程的自动化协同；以CI为核心，拉通各个运维工具中孤立的数据，并通过面向管理场景的数据分析和可视化，使IT管理者能更加全面的把握CI的运行状态和管理现状，提升管理的透明度。
3、促进如下四类消耗场景的实行和落地，提升运维实行工作的处理效率以及运维管理工作的精致化。
监控与故障分析场景：CMDB的应用、主机、数据库、中间件等基础配置信息可促进监控覆盖率的提升，同时CMDB的组件间关系、应用关系数据为告警压抑与故障定位提供数据基础。
变动操作实行场景：CMDB为应急启停、灾备切换、应用发布与部署等自动化操作提供基础情况数据，为变动影响范围分析提供关系数据。
管理协同场景：CMDB的主机、应用、构造等信息，为监控处理权限、关照范围、自动化操作权限、堡垒机访问权限提供数据基础。
安全管理场景：CMDB的主机、应用、中间件、数据库等信息，为漏洞扫描、入侵检测等安全管理工作提供数据基础。
综合上述三点，我们就可以明白银行为何要上CMDB系统。
@he7yong  研发工程师：
不仅仅是银行企业，几乎所有中大型的企业都会建设CMDB
CMDB的建设核心是为了支持ITSM工具和监控、自动化等这种运维工具的，从而提升企业IT运维的质量，效率。
@atpeace331 某 银行 数据库管理员：

看上图， ITIL 运维管理流程的实行，都离不开 CMDB，无论是 事件管理、照旧问题管理，或是变动管理，都需要 CMDB中的基础设施信息和软件信息的查询，ITIL的5 大运维流程还会经常更新 CMDB中的配置信息。


■ 推行的难点主要在哪方面？
@zhh321 某人寿数据中心 系统架构师：
CMDB的核心收益是主数据库带来的较低的综合成本。只不过结合不同场景，其代价又体现在安全内控管理（账号、堡垒机、防火墙、漏洞补丁、合规查抄、IP端口）、监控告警、自动化运维、资产管理、资源交付、发布管理、应急管理、ITIL流程管理、容量管理等具体领域。没有主数据库，上面这些工作都要自建配置库，大型数据中心情况下整体成本会很高。
但主数据库这种架构天然导致了推广的悖论，因为人们总是对全局和个体、长期和短期之间纠结平衡，且整体上会朝着熵增的趋势发展。CMDB建设者从长期、全局的视角来做配置管理工作，但造成各(ge)个(huai)部(gui)门(tai)短期成本提升，这对向导都是一件有难度的事，何况几乎没有什么权利的CMDB团队？换句话说，CMDB自己是一件短期成本高，但从全局和长期才气体现收益的事情，想想人们买保险的心情！
解决办法抽象的说就是：
1.要获得高层支持
2.通过具体场景来落实收益
3.设法转嫁和降低管理成本（蹭热度，抱大腿；和其他系统、流程形成利益绑定；把要求纳入现有惩罚考核）
4.提升用户犯错成本（以产品为单位明确责任人；流程自审计；公开审计结果）


■ CMDB的定位是什么？与其他系统关系是什么？哪些数据需要归入到CMDB管理中？
@he7yong 研发工程师：
CMDB的业务定位是IT战略相关项目；技能定位是IT运维管理的主数据。这个地方非常多的人有误解，许多人以为CMDB是为配置管理服务的，CMDB是为整个IT管理提供主数据服务的。
CMDB实现的作用：提供准确的IT对象及关系的数据服务。
其他系统如监控，事件管理、自动化运维，运维分析等和CMDB之间的关系，都是访问CMDB的数据关系，ITSM流程比较特殊，如变动流程通过后，变动执行完成，需要修改CMDB。
哪些数据要放到CMDB中？我们的原则是最小化原则，分析自己的业务需求，不停以为哪些数据是其他系统要去访问的，就放入到CMDB中，如果未来需要增长，可以通过流程快速扩展。


■ 银行CMDB项目上线后怎样对运维工作举行管理安排？
@周航 某银行 软件架构计划师：
配置管理工作各银行都会制定配置管理相关的管理制度和实行细则，内容主要涉及配置管理的管理范围、岗位职员配置、工作职责等内容。
一样平常情况下，配置管理的日常工作主要涉及如下三类岗位和内容：
一 、配置管理员，牵头配置管理的日常管理工作，其主要工作内容包括：
1 从总体上管理和监控配置管理流程的运行情况，确保配置管理流程高效运行、管控到位。
2 牵头配置模型的创建、优化，并维护配置数据库，同时牵头制定配置管理数据库安全控制策略和审核策略。
3 牵头为其他管理流程或工具提供接口，有用地利用配置管理数据库，与各配置项负责人一起促进配置数据消耗场景。
4 负责根据审计、管理需求生配置成报表和数据分析。
5 负责引入新技能提高配置管理流程的自动化程度，以提升信息的完整性和准确性。
6 牵头制定配置数据标准。
二、配置项负责人，一样平常各应用、系统、网络、设备、机房等各专业条线独立设定各自的配置项负责人，其主要工作内容为：
1、牵头本专业内的配置项识别工作，协助配置管理员创建相关模型，并通过自觉现、手工维护、数据同步等方式将数据维护在配置管理数据库中。
2、牵头本专业内相关配置项的准确性，当数据存在问题的时候，牵头举行数据的修订和整改。
3、根据本专业内生产情况配置的稳定情况和配置管理数据库的审核结果，定期创建配置基线
4、协助配置管理员制定并维护配置数据标准。
5、梳理专业内的配置信息需求，推进各专业工具举行配置场景化消耗和使用。
三、配置项审核员，负责保证配置数据的准确性，主要负责：
1、牵头明确配置管理数据审核的范围，并制定审核计划。
2、基于配置数据标准，采用配置数据治理工具或手工对配置数据举行审核和查抄，记载审核发现的问题，并天生审核报告。
3、负责与配置管理员及配置项负责人沟通审核结果，并共同制定改善方案，并跟踪整改结果，保证配置数据的准确性。
配置管理的后期维护工作往往繁琐而负责，要配置管理员、各专业配置项负责人、配置项审核员共同协助，加强沟通，持续优化改进配置管理工作，主要重点关注：
1、结合用户需求与运维情况的演变，实时调整优化配置项模型，满意日益增长的场景化实行需求。
2、以标准为基础，以查抄为手段，持续提升配置数据的完整性、准确性和有用性。
@he7yong  研发工程师：
CMDB在规划阶段应该要思考CMDB的运维流程，在项目上线阶段应该要交付详细的CMDB的运维手册；
运维的管理流程，其中需要涵盖CMDB的产品负责人，CMDB的配置经理，CMDB维护职员，CMDB的审核职员，不同职员拥有不同的权限。
CMDB的历史教训，让大多数企业明白自动化对CMDB的紧张性，因为自动化可以大量淘汰CMDB手工运维的操作，而且保障CMDB数据的准确性：
1.配置对象自动化发现工具，配置信息自动化获取工具，配置数据自动化上报工具；
2.CMDB和资源交付自动化工具的整合，资源自动化交付后自动注册到CMDB中；
3.CMDB配置数据跟踪和审计自动化；
4.利用RFID等技能，对配置自动化的网络等技能；


■ 在产品选型过程中需要注意哪些要点？
@周航 某银行 软件架构计划师：
1、配置项自觉现的组件丰富性，其已支持的数据库、操作系统、中间件等组件是否包罗银行现有技能组件，如果产品默认支持，整个项目实行周期和工作量会相对较小。
2、配置自觉现的agent是否支持银行现有的操作系统版本，特别是一个特殊的操作系统例如：HP-UX、Windows，Solaris等，如果不支持，需要慎重考虑；或考虑自觉现功能与银行自己的自动化产品举行集成来替代。
3、配置自觉现的agent的稳定性和性能。配置信息采集过程中的性能需要评估和测试验证，保证其在采集过程中对现有的系统损耗和影响最小。
4 丰富灵活的API服务：包括标准的CI查询和更新服务、关系查询服务、变动信息实时推送等服务，考虑到CMDB的建设要与银行已有的监控、自动化、ITSM、DevOps等产品举行集成，其API灵活性和丰富性是选型的关键要点。

觉得本文有用，请转发或点击“在看”，让更多偕行看到

资料/文章推荐：

• CMDB 项目建设怎样制止失败？
  
  
• 为什么别的企业可以建好 CMDB ? 这份实践经验值得参考 | 周末送资料
  
  

接待关注社区 “CMDB”技能主题 ，将会不断更新优质资料、文章。地点：http://www.talkwithtrend.com/Topic/76027


下载 twt 社区客户端 APP

长按识别二维码即可下载
或到应用商店搜索“twt”


长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区态度


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！