银行自动化运维建设的技术难点分析.docx

? ? ? ? ? ? ? 银行自动化运维建设的技术难点分析 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  目 录 TOC \o 1-3 \h \z \u 银行自动化运维建设的技术难点分析 1 难点一：自动化运维项目，如何进行技术路线的选择？ 3 难点二：自动化运维项目，如何进行底层工具产品选型？ 4 难点三：自动化运维项目，如何合理规划工程实施步骤？ 4 难点四：如何从整体上和“平台”角度规划自动化运维平台？ 5 难点五：自动化运维平台如何融入整体运维体系，划分功能边界？ 6 难点七：自动化运维对接的CMDB里主要存放哪些数据，颗粒度如何定义，如何维护准确性？ 8 难点八：开源工具建设自动化运维系统的瓶颈问题如何解决，其处理效率如何满足日常运维工作？ 8  随着银行业务的迅猛发展，金融科技引领的效果不断增强，业务系统数量不断攀升，对应的软硬件基础架构也越来越庞大，各系统相应的运行与维护工作的难度和复杂度与日剧增，规范化、精细化运维得不到有效施展，越来越多的运维痛点问题开始不断涌现，与此同时带来各种运维风险，影响业务连续性。为有效解决运维工作现有痛点，推动运维领域工作迈向信息化、数字化、自动化、智能化、场景化转型，自动化运维项目建设迫在眉睫。 为有效帮助各银行科技的运维同仁们在自动化运维项目前期规划及建设过程中，有的放矢，消除疑虑，切合自身运维工作实际现状，现总结该项目建设的八大难点问题及相应解析，供大家参考。 难点一：自动化运维项目，如何进行技术路线的选择？ 就笔者所了解的，自动化运维项目有以下四条技术路线供大家参考 1、基于开源工具自研 基于社区活跃度高、口碑好、功能强大的开源自动化工具，进行二次开发，实现自身需求的完全定制化，该技术路线有两个理解层次，第一个层次只是开源工具的使用上，对该工具的所有模块的运用都非常娴熟，二次开发也是工具的调用、整合、界面定制方面；第二个层次是开源工具的代码定制上，深入开源代码，进行重新优化和定制，嵌入自身的内容，并在第一个层次上去调用和整合。能够实现自研路线的银行科技力量都比较强大，有专门的自动化运维开发团队，对开源社区研究的比较深入，有强大的开发和运维实力。 2、基于开源平台自研 除了开源工具的自研之外，还有一种是开源平台的自研，在开源工具之上，往上发展，基于统一的研发平台，实现从底层工具到自动化运维“平台”的自研，开源平台提供了一些开发框架、接口标准、技术工具供开发人员使用，加速开源工具和“平台”的研发效率和进度。 3、基于闭源自研 这条技术路线和前面两种技术路线类似，都属于自研类，区别是，前者是站在开源工具/平台的肩膀之上，进行的二次开发，而后者是完全从底层工具、代理、平台、界面、接口等方方面面都是自研，难度也是最大的，国内大行研发实力强的，都基本是这条技术路线，需要大量的运维工具开发和维护团队，耗费大量时间和精力。但受益也是很不错的，其他各运维条线的工作效率大幅提升，自主化高，迭代能力强。 4、第三方现有产品客户化定制 这条技术路线是目前选择最多的，也是中小银行绝大多数的选择，开发团队一般都用来做业务软件开发了，很少中小银行会将自研自动化运维系统和平台。目前自动化运维产品提供厂商也非常多，而且相当一部分厂商都能提供一整套解决方案，包括DevOps、自动化运维、集中监控等。这种技术路线，银行企业需要仔细甄别，不仅仅是甄别自动化运维产品本身，更重要的是甄别其拓展性和平台的能力，同时银行企业，也要在多个系统引入过程中，站在整体视角，严格划分好功能边界，运维体系比较大，厂商的各类解决方案，都是大而全的方案，在引入过程中，难免各家厂商的功能边界会出现混淆和不清晰的地方，需要仔细区分。 难点二：自动化运维项目，如何进行底层工具产品选型？ 1、自动化运维底层工具产品是选用开源产品还是闭源产品 目前来看，无论是开源还是闭源都可以满足银行的运维需求，选用开源产品无非就是银行自身的技术实力允许，有一定的开发实力，或者和第三方外包一起结合热点开源产品进行二次开发。当然对开源产品的选型要慎重，如果是银行自己采用开源产品，建议选择无代理模式的自动化运维工具，对系统无侵入还是比较重要的，否则的话，就应该深入介入了解开源代理的底层代码。如果是和有技术实力和案例的第三方外包一起进行开源的二次开发的话，那么无代理和有代理都是可以选择的，因为可以通过外包转嫁开源风险。选择闭源产品目前也是很多，基本是通过有代理的模式进行的，有代理模式的效率要比无代理更高，而且客户端无需和服务端建立互信关系，弱化服务端的用户权限，但是客户端的代理基本是通过ROOT账户运行，可能会有后门。 2、通用的底层工具产品包括哪些部分 （1）自动化底层运维工具