难点一：如何选择自动化运维项目的技术路线？1、基于开源工具的自研基于社区活跃度高、口碑好、功能强大的开源自动化工具，进行二次开发，实现自身需求的完全定制。这条技术路线有两个层次的理解，第一个层次就是在开源工具的使用上，对工具的所有模块的使用都非常熟练。二次开发也是在工具调用、集成、接口定制方面；第二层是开源工具的代码定制。优化定制，嵌入自己的内容，一级调用集成。能够实现自研路线的银行，技术比较强，有专门的自动化运维开发团队，对开源社区有深入研究，有较强的开发和运维能力。2、基于开源平台的自研除了开源工具的自研之外，还有一种是开源平台的自研。在开源工具之上，向上发展。基于统一研发平台，实现从底层工具到自动化运维的“平台”自主开发，开源平台提供部分开发框架、接口标准、技术工具供开发者使用，加速开源工具和“平台”研发的效率和进步。3、基于闭源研究的技术路线与前两条技术路线类似，均属于自研范畴。不同的是，前者是站在开源工具/平台的肩膀上进行二次开发，而后者则是在底层工具、代理、平台、接口、接口等各个方面完全自研。它也是最困难的。国内研发能力强的大银行基本都是采用这种技术路线，需要大量的运维工具开发和维护团队，耗费了大量的时间和精力。但是好处也很好。其他运维线的工作效率大幅提升，自主性高，迭代能力强。4、现有第三方产品定制是目前最流行的技术路线，也是大多数中小银行的选择。开发团队一般用于业务软件开发，很少有中小银行会自己研究自动化。运维系统和平台。目前自动化运维产品的厂商很多，也有不少厂商可以提供一整套的解决方案，包括DevOps、自动化运维、集中监控等。银行企业需要仔细辨别这种技术路线，不仅仅是自动化运维产品本身，更重要的是它的可扩展性和平台能力。从整体上看，严格划分功能边界，运维体系比较庞大，厂商的各种解决方案都是大而全的解决方案。在引入的过程中，难免会出现各个厂商的功能边界混淆不清的情况，需要仔细区分。难点二：如何选择自动化运维项目的底层工具和产品？1、自动化运维的底层工具产品是开源还是闭源。目前开源和闭源都可以满足银行的运维需求。开源产品的选择无非是银行自身的技术实力。开发实力，或者结合火爆的开源产品与第三方外包进行二次开发。当然，选择开源产品要慎重。如果银行采用开源产品，建议选择无代理模式的自动化运维工具。更重要的是不侵入系统。否则，应该深入了解开源代理的底层。代码。如果开源的二次开发与有技术实力和案例的第三方外包一起进行，那么agentless和agent-based都是一种选择，因为开源的风险可以通过外包来转嫁。目前选择的闭源产品还是比较多的，基本都是通过代理模式，代理模式的效率比没有代理的要高，而且客户端不需要和服务端建立互信关系，弱化了用户服务器的权限，但是客户端的代理基本上都是通过ROOT账号运行的，可能会有后门。2、通用底层工具产品包括哪些部分（1）自动化底层运维工具：CMDB和配置自动化发现工具；脚本和作业管理中心；代理和控制中心，用于执行命令获取数据；自动化编排引擎；集成中心，API集成和访问权限管理；(2)在此基础上构建的专业现场运维工具：网络自动化工具；防火墙自动化工具；操作系统运维工具；中间件运维工具；云资源管理工具；应用发布（3）基于各种运维场景的运维工具：巡检工具；补丁和基线管理工具；软件安装和配置工具；自助日志查询工具；数据采样工具等难点三：如何合理规划自动化运维项目的实施步骤？大致步骤如下：1.规划自动化运维场景、模块和整体架构2.部署自动化运维管理节点和模块软硬件资源3.在节点上安装自动化运维服务器软件并进行相关配置4.建立自动化运维关系的两种方式：(1)服务端与客户端建立互信，在客户端安装必要的依赖软件，如Python(2)安装相应的代理和依赖包5.验证服务端与客户端的自动化运维关系6.自动化运维场景及功能模块分类开发与测试7.自动化运维对外接口开发与测试8.构建统一平台自动化运维门户，并与不同场景和功能模块对接9、自动化运维运维系统正式上线的难点四：如何从整体和“平台”的角度规划自动化运维平台？1.把监督、管理、控制和其他运维系统作为一个整体来考虑充分集成，而不仅仅是一个自动化工具。自动化运维作为运维技术体系中的一员，旨在降低运维成本、提高运维效率、规范运维任务、通过自动化自愈等方式提高业务连续性，其意义在于不言而喻。这一点从国内各大银行、股份制银行对运维人员招聘的技术要求也可以得知。往往需要一些既懂运维技术又懂运维开发的人员。然而，这些自成一体的自动化运维开发为自己提供便利，往往无法站在全局的角度思考问题，导致开发工作重复、边界不清，甚至出现功能冲突。这是需要避免自动化运维的地方。从一开始涉足这个领域，就应该从全局的角度明确划分不同运维团队的自动化运维边界，真正实现运维端到端的自动化服务。为了实现这些服务，需要明确哪些地方有哪些自动化工具支持，哪些工具可以共享和合并，最后从集成的角度，如何统一管控，对外提供服务等。2、从平台的角度来看，是一个具有集成能力、服务开放、功能扩展性好的平台。在我们的理解中，“平台”应该是一个集成者和统一的控制器，它有别于“系统”。系统是一个功能和处理个体，就像银行系统架构中前-中-后台的概念一样，系统属于后台的概念，“平台”属于中台的概念。所有后台对外服务都需要通过中台中转。一个中台，可以有多个后台，是一对多的关系。因此，从一个自动化运维平台的角度来看这个问题，这个平台不需要有强大的功能，不需要完成批次调度、自动化生产、自动化检测、自动化操作、自动化操作等具体操作。自动化的软件和硬件配置。重要的是对底层的自动化运维技术进行抽象和服务，同时实现对整个自动化技术的统一管理，包括自动化服务注册、自动化服务模板、自动化服务集成、自动化服务权限管理等等在。至于具体的技术实现，会通过底层的各种自动化运维工具来实现，或者通过一个独立的“系统”来实现。此外，“平台”还可以是多个“系统”和工具的调度器。单一工具无法实现的自动化任务，可以通过多工具任务编排实现，形成大平台小系统格局，突破传统小系统过于臃肿，各个系统都想完整，争先恐后boss，造成职能边界模糊的问题。难点五：自动化运维平台如何融入整体运维体系，划分功能边界？自动化运维平台需要很好的融入整体运维体系，明确划分功能边界，包括云管理平台、流程平台、监控平台、配置管理平台、智能运维平台等。统一CMDB为所有系统和平台提供统一的配置基准数据，提高联动数据的质量和效果；自动化运维平台自动收集和发现有价值的数据和数据关联，供其他系统和平台使用，与各种资源关系建立自动化关联，提供不同的自动化运维场景调用API，供其他系统和平台调用；集中监控平台连接所有监控系统和平台，实时采集所有事件和告警，并结合CMDB配置数据，第一时间匹配丰富事件告警内容。以丰富的通知方式和详细真实的报警详情通知相关负责人；运维大数据通过多样化、不同渠道整合各系统、平台的实时或历史结构化、非结构化数据，并进行过滤、清洗、加工、整合、分析、输出、数据持久化；IT架构可视化系统采用三种架构图：业务系统部署架构图、业务逻辑架构图、业务网络拓扑图，结合运维中的大数据。实时展示来自数据源的数据，包括智能运维产生的建议，让数据和图表联动起来，更直观地展示业务系统的整体运行状态。运维以IT架构可视化为主，智能运维为辅，强调运维人员的不可替代性。可以参考如下规划图：
