银行自动化运维建设的八大难点

原创

mob604756f19185 2021-04-23 08:23:05 ©著作权

文章标签 java 文章分类 Java 后端开发

©著作权归作者所有：来自51CTO博客作者mob604756f19185的原创作品，请联系作者获取转载授权，否则将追究法律责任

随着银行业务的迅猛发展，金融科技引领的效果不断增强，业务系统数量不断攀升，对应的软硬件基础架构也越来越庞大，各系统相应的运行与维护工作的难度和复杂度与日剧增，规范化、精细化运维得不到有效施展，越来越多的运维痛点问题开始不断涌现，与此同时带来各种运维风险，影响业务连续性。为有效解决运维工作现有痛点，推动运维领域工作迈向信息化、数字化、自动化、智能化、场景化转型，自动化运维项目建设迫在眉睫。

为有效帮助各银行科技的运维同仁们在自动化运维项目前期规划及建设过程中，有的放矢，消除疑虑，切合自身运维工作实际现状，现总结该项目建设的八大难点问题及相应解析，供大家参考。

难点一：自动化运维项目，如何进行技术路线的选择？

就笔者所了解的，自动化运维项目有以下四条技术路线供大家参考

1、基于开源工具自研

基于社区活跃度高、口碑好、功能强大的开源自动化工具，进行二次开发，实现自身需求的完全定制化，该技术路线有两个理解层次，第一个层次只是开源工具的使用上，对该工具的所有模块的运用都非常娴熟，二次开发也是工具的调用、整合、界面定制方面；第二个层次是开源工具的代码定制上，深入开源代码，进行重新优化和定制，嵌入自身的内容，并在第一个层次上去调用和整合。能够实现自研路线的银行科技力量都比较强大，有专门的自动化运维开发团队，对开源社区研究的比较深入，有强大的开发和运维实力。

2、基于开源平台自研

除了开源工具的自研之外，还有一种是开源平台的自研，在开源工具之上，往上发展，基于统一的研发平台，实现从底层工具到自动化运维“平台”的自研，开源平台提供了一些开发框架、接口标准、技术工具供开发人员使用，加速开源工具和“平台”的研发效率和进度。

3、基于闭源自研

这条技术路线和前面两种技术路线类似，都属于自研类，区别是，前者是站在开源工具/平台的肩膀之上，进行的二次开发，而后者是完全从底层工具、代理、平台、界面、接口等方方面面都是自研，难度也是最大的，国内大行研发实力强的，都基本是这条技术路线，需要大量的运维工具开发和维护团队，耗费大量时间和精力。但受益也是很不错的，其他各运维条线的工作效率大幅提升，自主化高，迭代能力强。

4、第三方现有产品客户化定制

这条技术路线是目前选择最多的，也是中小银行绝大多数的选择，开发团队一般都用来做业务软件开发了，很少中小银行会将自研自动化运维系统和平台。目前自动化运维产品提供厂商也非常多，而且相当一部分厂商都能提供一整套解决方案，包括DevOps、自动化运维、集中监控等。这种技术路线，银行企业需要仔细甄别，不仅仅是甄别自动化运维产品本身，更重要的是甄别其拓展性和平台的能力，同时银行企业，也要在多个系统引入过程中，站在整体视角，严格划分好功能边界，运维体系比较大，厂商的各类解决方案，都是大而全的方案，在引入过程中，难免各家厂商的功能边界会出现混淆和不清晰的地方，需要仔细区分。

难点二：自动化运维项目，如何进行底层工具产品选型？

1、自动化运维底层工具产品是选用开源产品还是闭源产品

目前来看，无论是开源还是闭源都可以满足银行的运维需求，选用开源产品无非就是银行自身的技术实力允许，有一定的开发实力，或者和第三方外包一起结合热点开源产品进行二次开发。当然对开源产品的选型要慎重，如果是银行自己采用开源产品，建议选择无代理模式的自动化运维工具，对系统无侵入还是比较重要的，否则的话，就应该深入介入了解开源代理的底层代码。如果是和有技术实力和案例的第三方外包一起进行开源的二次开发的话，那么无代理和有代理都是可以选择的，因为可以通过外包转嫁开源风险。选择闭源产品目前也是很多，基本是通过有代理的模式进行的，有代理模式的效率要比无代理更高，而且客户端无需和服务端建立互信关系，弱化服务端的用户权限，但是客户端的代理基本是通过ROOT账户运行，可能会有后门。

2、通用的底层工具产品包括哪些部分

（1）自动化底层运维工具：CMDB及配置自动化发现工具；脚本及作业管理中心；Agent及管控中心，用来执行命令获取数据；自动化编排引擎；集成中心，API集成和访问权限管理；

（2）在此之上构建的专业领域运维工具：网络自动化工具；防火墙自动化工具；操作系统运维工具；中间件运维工具；云资源管理工具；应用发布工具；

（3）基于各种运维场景构建的运维工具：巡检工具；补丁及基线管理工具；软件安装配置工具；日志自助查询工具；抽数工具等等。

难点三：自动化运维项目，如何合理规划工程实施步骤？

大致的步骤有以下几个方面：

1、规划自动化运维场景、模块和整体架构

2、自动化运维管理节点和模块软硬件资源部署

3、在节点上安装自动化运维服务端软件，并进行相关配置

4、两种方式建立自动化运维关系：

（1）建立服务端和客户端的互信，客户端安装必要的依赖软件，如Python

（2）客户端安装相应代理和依赖包

5、验证服务端和客户端的自动化运维关系

6、进行自动化运维场景和功能模块分类开发和测试

7、自动化运维外部接口开发和测试

8、自动化运维统一门户搭建，并对接不同场景和功能模块

9、自动化运维系统正式上线

难点四：如何从整体上和“平台”角度规划自动化运维平台？

1、整体上

考虑监、管、控、及充分结合其他运维系统，而不是像Ansible、Puppet仅仅是一个自动化的工具。

自动化运维作为运维技术体系中的一员，其目的就是为了减轻运维成本、提升运维效率、规范运维任务、通过自动化自愈提升业务连续性等等，其重要意义不言而喻。这点从国内各类大行、股份制银行等的运维人员招聘的技术要求中，也可以略知一二，经常是需要一些既懂运维技术的，又懂运维开发的人员。但这些各自为政的自动化运维开发都为自己提供便利，往往没有站在全局的角度去思考问题，造成开发工作重复，边界不清晰，甚至功能冲突的情况，这是自动化运维需要规避的地方，从一开始介入这个领域，就应该从整体的角度，清晰的划分不同运维团队的自动化运维边界，真正实现运维端到端的自动化服务，为实现这些服务，需要理清哪些地方要有哪些自动化工具支撑，哪些工具能够共用合并，最后再从集成的角度，如何统一管控和对外提供服务等。

2、平台角度

是一个具备集成能力，具备服务开放性，具备很好的功能扩展的一个平台。

“平台”在我们的理解中应该是一个集成者和统一管控者，这有别于“系统”，系统是一个功能和处理个体，就好比银行系统架构中的前置-中台-后台的概念，系统属于后台的概念，而“平台”属于中台的概念。后台所有对外的服务都需要通过中台来流转，中台有一个，而后台可以有多个，是1对多的关系。因此，从自动化运维平台的角度来看这个问题，这个平台不需要有多强大的功能，不需要完成例如批量调度、自动化投产、自动化巡检、自动化操作、自动化软硬件配置等具体操作，更重要的是将底层的自动化运维技术实现抽象化，服务化，同时对整个自动化技术实现统一管理，包括自动化服务注册、自动化服务模板、自动化服务集成、自动化服务权限管理等等。至于具体技术实现，则交由底层的各类自动化运维工具去实现，或者独立的“系统”去实现。另外，“平台”也可以是一个多“系统”和工具的调度者，单一工具无法实现的自动化任务，可以通过多工具任务编排实现，形成大平台，小系统的格局，突破传统的小系统过于臃肿，每个系统都想做全，争老大，造成功能边界模糊的问题。

难点五：自动化运维平台如何融入整体运维体系，划分功能边界？

自动化运维平台需要很好的融入整体运维体系，清晰的划分功能边界，包括云管平台、流程平台、监控平台、配置管理平台、智能运维平台等。统一CMDB为所有系统和平台提供统一的配置基准数据，提升联动的数据质量和效果；自动化运维平台自动采集和发现价值数据和数据关联，供其他系统和平台使用，和各项资源建立自动化关联关系，提供不同自动化运维场景调用API，供其他系统和平台调用；集中监控平台对接所有监控系统和平台，实时收集所有事件和告警，结合CMDB配置数据，第一时间匹配和丰富事件告警内容，以丰富的通知手段和详尽真实的告警详情告知相关负责人；运维大数据通过多样化、不同通道的方式，集成各系统和平台的实时或历史的结构化、非结构化数据，并进行过滤、清洗、加工、整合、分析、输出和数据持久化；IT架构可视化系统通过业务系统部署架构图、业务逻辑架构图、业务网络拓扑图三类架构图的方式，结合运维大数据中，不同数据源的数据，包括智能运维产出的建议，进行实时的展示，让数据和图联动，更为直观的展示业务系统整体运行状况。运维以IT架构可视化为主，智能运维为辅，强调人在运维中不可替代性。可以参考以下规划图：

银行自动化运维建设的八大难点_java

难点六：通过开源工具自主开发自动化运维系统，最大的难点主要体现在哪些方面？

最主要的还是开发上和架构集成上的难点：

1、就这次ANSIBLE的使用来看，没有关注ANSIBLE本身层面的开源代码，用SHELL也好，PYTHON也好，更多的体现的是这个工具的使用上。首先是要结合企业自身的需求，量身设计不同的自动化运维场景，这点与直接采用第三方的产品有所不同，第三方是基于他们的理念，设计出的通用性的产品，适当进行定制化开发。而我们要做的是，直接将实际的问题场景化，更贴切实际需求，没有冗余的内容。这点有好处也有弊端，弊端就是场景需求可能会变化，量身定做不一定今后就适用，所以既要量身开发，又要有通用性的思维，场景设计尽量参数化、模块化。再往深一点的话，就是需要对开源工具源码比较熟悉，复杂场景都可能面临要动开源产品的底层代码；

2、其次是本身系统的架构设计和如何和其他运维系统做集成的问题，一方面需要具备比较强大的架构能力，开源产品通常都是解决特定问题，如Zabbix，ELK，itop(CMDB)等这些工具这些工具如何集成，需要架构师的规划；另一方面需要和其他运维系统集成，运维的其他系统不可能都是开源的，尤其是银行而言，还是以商用产品为主，集成是最大的麻烦，需要厂商的支持，如果没有厂商的支持，那就需要对这个商用产品有非常的了解，才能很好的对接。像我们的ANSIBLE和Tivoli平台对接，就是得到了IBM的大力支持，专门有相关工程师和我们一起配合，在Tivoli端也写了很多的SHELL代码。

难点七：自动化运维对接的CMDB里主要存放哪些数据，颗粒度如何定义，如何维护准确性？

1、 CMDB应该是存放对象的元数据

2、CMDB的颗粒度如何定义

CMDB颗粒度取决于维护CMDB的人数量，维护能力越强，人数越多，可以将颗粒度提高，数据间关系可以做得越复杂。如果维护能力不足，人数不多，颗粒度尽量精简。因此，建议遵循最小化的原则，理清ITSM和自动化运维工具到底可能会消费什么数据，才管理什么数据。CMDB工具本身可以支持CI属性的灵活扩展即可；

3、准确性如何维护

要看你的业务需求，如果仅仅给到ITSM用，准确性不用要求太高，CMDB是台账而已，如果和监控，自动化联动，CMDB要求要很高。准确性要通过自动发现、管理流程、数据消费（消费发现数据不准确，及时更新）等来管控这些数据，模型搭建好，尽量减少人的作用和直接参与，人更多体现在流程的审核和管理上，让流程来驱动CMDB数据（如交付资源自动注册到CMDB中）落地，让自动发现来审核落地数据的准确性，互相牵扯。