|
银行企业为什么要建设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灵活性和丰富性是选型的关键要点。
|
|
|
