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