银行设备智能运维系统设计的必要必有哪些？

随着网络的发展，银行每天借贷的数据量是十分庞大的，想要对这些数据量进行分析和统计，需要使用到高智能的设备。下面就一起跟faceui小编来了解一下银行设备智能运维系统设计的相关内容吧。

　　银行业务的发展趋势

　　01 互联网金融的兴起

　　随着数字化和互联网技术的发展，用户在“花”、“存”、“贷”等方面都在发生巨大转变：

　　花：短短几年，移动支付已经代替了现金支付和刷卡支付。

　　存：大量的用户资金不断往互联网迁移。

　　贷：用户希望有各种贴合自己使用需求的个性化金融产品。

　　银行过去标准化的产品模式已经不适应这个时代的需求，而以BATJ为代表的互联网企业，创造了一系列互联网金融产品，满足人们日常生活的各种需求，这些，对商业银行的传统业务形成了跨界渗透和直接冲击，甚至具有一定的替代作用。因此，在支付、理财、信贷方面，银行都面临着互联网行业不同场景的挑战。

　　银行设备智能运维系统设计（图片来自网络）

　　02 银行业务的转型与发展

　　著名美国银行家布莱特•金(BrettKing)在《Bank 2.0 ~ 4.0》中，给出了银行业务发展的历程和展望，从网上银行到智能手机，到物理网点消除，到通过开放实现与其他行业服务的融合形成泛金融服务，到在AI、AR（现实增强）、语音识别等等技术普及于大众的背景下银行将业务嵌入到用户日常生活的体验升级聚焦。

　　基于种种挑战和对未来的展望，数字化转型以及加速转型成为银行业务的重要发展策略。

　　政府举措方面，2015年7月，人民银行等十部门发布《关于促进互联网金融健康发展的指导意见》，该指导意见按照“鼓励创新、防范风险、趋利避害、健康发展”的总体要求，提出了一系列鼓励创新、支持互联网金融稳步发展的政策措施，积极鼓励互联网金融平台、产品和服务创新，鼓励从业机构相互合作，拓宽从业机构融资渠道，推动信用基础设施建设和配套服务体系建设。

　　2018年10月，中国银行保险监督管理委员会发布《中国普惠金融发展情况报告》摘编版，中国财政也加大了普惠金融发展专项资金的投放。

　　01 分布式系统的大量应用

　　面对业务的转型与发展，银行引进分布式系统在所难免：

　　支持普惠金融服务和复杂交易模式，集中式系统的处理能力瓶颈逐渐凸显。

　　“跨界融合”、移动金融要求银行业务创新和迭代的节奏要越来越快。

　　银行要不断提升用户体验，就需要利用先进的大数据技术对海量业务数据进行分析。

　　集中化架构的成本问题越来越突出。

　　各种闭源软硬件产品逐步不能满足监管安全可控的要求。

　　在互联网企业的系统架构模式的启发下，很多银行结合互联网金融战略需求，引进开源软件和技术，开始构建基于x86平台、分布式计算的分布式IT技术体系。

　　当然，在当前业务现状下，“集中+分布式”的融合架构仍然是大型商业银行的最佳架构选择：

（图片来自网络）

　　因此，银行保留面向“稳态”的、基于集中式的传统核心，注重安全、稳定，如存款一类账户、借记卡、传统贷款、支付等业务，新建面向“敏态”的、基于分布式互联网核心，支撑海量客户、高并发，适合管理二三类账户、直销银行等业务。

　　02 银行信息系统混合式架构

　　继分布式的引进后，银行也开始了对云原生技术的探索，银行的信息系统不可避免的呈现混合式的架构：

　　而对于银行IT运维来说，不同架构的业务系统，对运维的能力和侧重点要求并不同，运维的要求、难度和压力也在不断的增大。

　　03 银行数据中心“双活”或“多活”的逐步完善

　　《中国金融业信息技术“十三五”发展规划》指出，金融机构主动探索系统架构完善升级，继续深入研究数据中心“双活”或“多活”模式应用。

　　截至目前，大多数银行已经完成了“两地三中心”的建设，并且定期进行灾备演练工作，银行系统的可用性得到进一步提升。

　　银行应用运维面临的挑战

　　01 银行应用运维的组织与职责

　　银行的IT组织很大，部分银行还成立了单独的金融科技公司。本文主要聚焦于银行IT运维组织中的应用运维，分析应用运维如何提升自己的运维水平和方式以适应业务转型、信息系统架构异构化的发展要求。

　　应用运维的核心职责在于确保应用系统高效稳定运行，同时响应研发、业务人员诉求完成版本变更或上线的业务价值交付，并提供相关的数据和服务给到业务、运营和测试等外部人员。应用运维团队的日常职责及与其他团队的工作交互简要如下：

　　02 银行应用运维的面临的挑战

　　由上可见，应用运维团队肩负着业务系统正常运转的重大责任，也同时负担着一系列繁杂琐碎的运维工作。随着银行业务的飞速发展，应用运维团队面临的挑战越来越大：

　　运维难度增加：技术栈复杂，运维技能要求高。从单体、SOA到分布式到云原生架构，从闭源到开源，组成应用系统的技术组件成倍增长，应用运维需要持续增加强化自己的技术能力才能满足运维的基本要求。

　　运维工作增多：线下业务不断线上化，应用数量也在成倍增长。

　　运维效率要求提升：业务发展也带来了大量的更新发布需求，而发布时间窗口并没有延长。部分新业务也对运维提出了持续交付的实时性要求。

　　成本控制越来越严格：不断增加的应用系统占用了大量的IT资源，运维需要通过先进有效的监控和分析手段在性能和成本之间取得一个平衡，并且主动持续优化应用系统性能。

　　运维质量及安全级别要求高：在运维工作复杂度和负担不断增加的情况下，运维如何保持既有运维质量、保障和提升系统可用率，成为应用运维的难题。

　　运维工作如此繁重，运维人员在横向扩展自己运维技能的同时，还有时间往运维开发、大数据或AI等纵向技术领域转型吗？

　　另外，应用运维掌握了应用系统的配置、日志、监控等数据，能否效仿一些互联网企业，通过有效的技术手段将这些数据进行统一采集分析，为业务/运营带来增值服务，做到主动运营，从而提升应用运维组织的价值？

　　03 挑战与机遇

　　银行应用运维的转型和运维能力提升已经迫在眉睫，但挑战同时也是机遇，业务发展和应用架构演进赋予应用运维的责任越大，应用运维所能创造的价值也就越高，也就越发得到重视。

　　银行设备智能运维系统设计（图片来自网络）

　　01 如何定义应用？

　　应用，一般可以从两个维度进行解读，一个是狭义的应用，指的是应用程序，也就是由开发人员提供的二进制文件的运行时状态；另一个是广义的应用，指的是应用系统，也就是由一组应用程序和系统资源的有机组合。这里的系统资源泛指支撑应用运行的数据库、os、中间件、负载均衡甚至域名、存储等等。

　　应用运维，指的是对应用系统的运维，既包含对应用程序的发布、变更等运维工作，也包含对应用系统整体的健康巡检、监控等运维工作。

　　02 做好银行应用运维的建议

　　效率提升：建设应用运维自动化系统，将所有能自动处理的工作全部自动化掉，如发布、巡检、变更、启停、数据查询与提取、银行跑批统一调度等等。彻底消灭重复性人工操作，释放运维人员。

　　质量提升：面向稳态和敏态业务，以应用为中心建设CMDB，从多个维度完成对应用系统的监控，及时发现应用系统的问题和隐患，并基于自动化手段快速处理问题，提升应用系统可用性。另外，自动化推广的同时也会带来操作规范的梳理和标准化，如发布流程流程标准化、灾备切换流程标准化，从而减少人工操作失误。

　　成本控制：建设容量分析与管理系统，为系统性能优化提供指导，提升资源使用率，控制资源成本。

　　组织转型：以上目标的实现，不太可能通过一次性外采一个功能齐全、场景完美契合的应用运维平台就能解决，是需要企业运维人员也持续投入到平台上的新场景研发来满足个性化或增长性的运维需求。在组织转型这一块，可以参考Google SRE组织架构，让运维团队中50%的人员从事着运维工具的开发。

　　智能化：基于智能化技术，实现容量预测和智能扩缩容从而应对在互联网化和跨界融合背景下流量峰值的挑战，实现对故障定位、故障预测以快速解决或避免业务异常或故障，提升用户体验。

　　从应用上线开始，自动化技术应覆盖应用运维整个生命周期。

　　综上，要做好银行应用运维工作，需要建设一个支持双态架构的、可扩展的、先进的、能促进组织转型而自增长的应用自动化运维平台。

　　03 银行应用运维平台设计建议

　　基于以上分析，应用运维平台功能架构推荐如下：

　　服务层能力

　　服务层能力——效能：

　　CMDB：以应用为中心建设CMDB，应用拓扑遵照服务树拓扑进行设计，并关联应用系统相关的各种系统资源，使CMDB能够服务于应用运维各种消费场景。

　　应用配置管理：基于CMDB，提供制品库管理、配置文件管理、进程管理、环境管理等功能。

　　应用发布：与应用配置管理集成，对应用模块进行包、配置文件、sql文件的快速发布或回滚，支持滚动发布、蓝绿发布、灰度发布等方式。同时支持在一个发布时间窗口下的多应用发布任务的复杂编排。

　　资源交付：与虚拟化平台或云平台集成，根据应用资源配置要求自动完成各种组件资源的自动交付和软件配置。

　　一键扩容：基于资源交付和应用发布提供的能力，还可以做到对应用的一键扩容。

　　应用启停：管理应用相关的所有进程，可在控制台上进行快速进程启停，也提供自定义的编排能力以完成对一个复杂应用的一键启停。另外，也对进程异常进行监控告警。

　　银行跑批：提供一个功能强大的、可扩展的工作流调度引擎，结合底层成熟的分布式作业执行架构，管理银行的大量跑批作业，提供对作业、作业流、调度任务的编排、执行、控制与监控等管理能力。

　　服务层能力——稳定性&可用性：

　　应用巡检：应用系统是由一组应用程序和系统资源组成的，这些组成部件的健康性会影响着整个应用系统的健康性。基于CMDB中维护的完整应用系统信息，结合原子化的、可扩展的巡检框架，我们可以以应用维度对整个应用系统进行健康性巡检，从而发现应用运行的隐患或问题。

　　应用健康度监控：应用健康度监控提供了一个框架，对接企业的监控系统或告警系统，从应用维度对组成应用系统的应用程序和系统资源的监控和告警信息进行实时汇总，并以服务树拓扑或应用逻辑拓扑的形式展现出来，以便于应用运维人员进行快速故障定位和应用异常发现。

　　应用拨测：可建立拨测任务对应用的网站、接口进行拨测监控。

　　智能业务巡检：模拟用户对应用功能的完整使用，从用户端角度确认应用功能的顺畅使用。由于传统的运维通道能力（文件传输、命令执行、数据采集、API调用、协议驱动）未必能支持一些C端操作自动化，在这里我们应用了rpa技术（集成selinium脚本、Windows窗口句柄识别、OCR）来适配用户的各种ui操作场景。

　　日志检索：对应用系统的各种类型日志进行统一采集、清洗、存储、告警、分析和展示。

　　灾备演练：提供灵活的灾备切换和恢复流程编排框架和可扩展的原子化能力，支持多应用多步骤的一键切换和大屏跟踪展示，并且对灾备切换的预案进行管理，以自动化和规范化保障银行定期灾备切换活动的成功进行。

　　APM：基于字节码注入技术自动发现应用拓扑关系、应用代码级运行性能、接口性能及调用链分析，基于js注入获取和分析每个用户对应用业务功能的使用体验。从而对应用进行更深层次的监控和更有效的故障定位。

　　服务层能力——效能：

　　容量管理：对应用的资源指标、服务指标、业务指标进行统一采集存储，并基于多关联算法分析业务波动或吞吐量变化时对系统资源的影响，从而评估应用的容量状况，为性能优化、成本控制提供切实有效的指导。

　　服务层能力——效能：

　　故障自愈：基于自动化编排引擎，对接告警系统，实现常用的故障自动化处理，包括日志清理、服务重启、参数调整等操作编排。

　　故障定位：基于应用的服务调用信息、资源关联信息，对应用系统各个时间段的告警事件进行分析，从而提供故障定位能力。

　　服务层能力——流程/工具

　　运维流程管理：一款面向IT人员的运维流程管理软件，提供IT运维的请求管理、事件管理、发布和变更管理、日常运维管理等核心模块。使得IT运维工作更加规范和敏捷，从而提升运维的协作效率和工作质量。

　　报表可视化：报表可视化是面向运维人员的轻量的web报表制作工具，核心功能有仪表盘和报表两大模块，实现企业IT运维各项数据的实时呈现和分析。例如，基于报表可视化我们可以灵活构建银行应用运维的监控仪表盘，嵌入到应用监控、APM等运维工具中。

　　大屏可视化：大屏可视化，主要应用于大屏幕投放。提供大屏可视化设计器，便于无编码的方式快速拖拽、配置来形成前端大屏。例如，基于大屏可视化及应用健康度监控，可以构建应用墙大屏，实时展示所有应用运行状态。

　　银行设备智能运维系统设计（图片来自网络）

　　平台层能力

　　平台层提供服务层所需的公共模块能力，例如CMDB、Agent、作业执行等；应用自动化工具链，提供满足企业应用自动化运维生命周期的工具链，并基于平台整体能力实现融合。

　　iPaaS层：API GateWay（统一接入模块），将配置管理（CMDB）平台、作业平台、数据平台、挖掘平台等原子平台统一接入、集成、驱动和调度，供上层运维场景APP驱动和调用。

　　aPaaS开发者中心（提供前后端开发框架）：开发者中心提供完整的前后端开发框架，当企业在未来出现新的运维需求的时候，企业可以快速利用开发者中心完成相应的运维系统开发，支持一键部署和持续部署。

　　管控接入：提供分布式、高可用、可扩展的通道能力：文件传输、命令执行、数据采集、通用协议驱动、API调用、RPA等。

　　通过上文faceui小编的介绍，大家应该知道银行设备智能运维系统设计的必要必有哪些了吧。高智能的运维设备，才能对庞大的数据量进行精确分析和统计。