【经验分享】银行应用运维平台设计与建设建议

本文主要介绍银行业务的发展趋势、应用架构演进以及在此背景下应用运维面临的挑战和解决方案。文章目录如下，是笔者过去5年作为乙方在多个银行设计和落地应用运维自动化的经验分享，共11000字，阅读时长大约10分钟。

一、银行业务的发展趋势 1.1互联网金融的兴起 1.2银行业务的转型与发展二、银行信息系统的演进 2.1分布式系统的大量应用 2.2银行信息系统混合式架构 2.3银行数据中心“双活”或“多活的”的逐步完善三、银行应用运维面临的挑战 3.1银行应用运维的组织与职责 3.2银行应用运维面临的挑战 3.3挑战与机遇四、银行应用运维平台设计建议 4.1如何定义应用？ 4.2做好银行应用运维的建议 4.3银行应用运维平台设计建议五、银行应用运维平台关键能力建设建议 5.1应用配置管理 5.2应用发布自动化 5.3应用灾备演练 5.4银行跑批 5.5应用巡检 5.6智能业务巡检 5.7应用健康度监控 5.8APM 5.9应用启停 5.10应用自动化运维关键能力一览六、银行应用运维的展望

银行业务的发展趋势

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等。

银行应用运维平台关键能力建设建议

以下对嘉为蓝鲸应用运维平台上的部分关键产品设计理念与功能进行一一介绍：

01 应用配置管理

面向应用运维的、以CMDB为基础的应用配置管理是应用运维的基石和前提，它的设计和建设决定了能否同时支持多种架构的应用的配置管理及自动化运维。简单来讲，应用配置管理需要包含以下几个重要功能或重要原则：

以应用为中心的CMDB

CMDB的建设需要着眼于应用，而不是以资源对象、数据中心来进行划分。比如CMDB中的第一层级，应该是OA系统、电子商城、ERP系统等应用，而不是Windows服务器、数据库主机或者北京数据中心、广州数据中心。

应用拓扑应该以服务树拓扑（或称为业务层次拓扑）

服务树拓扑主要是指从纵向的角度进行模块化划分，并把相同功能的模块划分到一个子系统中，服务树拓扑一般不要超过3层，最末端对应具体的应用模块，模块之下再是主机：

例如：

服务树拓扑中关于环境和集群的插入

环境概念：指生产环境、测试环境、灾备环境等。
集群概念：适用于分布式系统，一般以地域划分，如广东集群、北京集群。广东集群提供给华南用户优先访问，并且在北京集群出现故障时可以在服务树拓扑中按需插入环境和集群节点形成新的服务树拓扑。

例如：

以服务树拓扑，做好IT资源的关联

服务树末端为应用模块或资源组件，是作为与实际IT资源实例发生关联的节点：

CMDB中可自定义IT资源对象模型及添加实例

提供程序包管理功能

应用配置管理需要面向应用运维，首当其冲就是应用发布。因此对于运维来说，需要把用于发布的程序包的所有版本及其与应用模块、部署主机的关系管理起来：

实际功能效果：程序包统一管理

多版本文件管理、上传与自动分拣等功能

应用模块关联：

提供配置文件管理功能

配置文件统一管理、变更和发布也是应用运维的重点工作之一。配置文件也需要与应用模块进行关联：

配置文件管理：

配置文件的版本管理、在线编辑、基于可自定义mako语法的变量管理等功能：

配置文件与应用模块的关联：

进程管理

针对应用模块下的进程进行管理。进程管理在进行设计时，需要考虑到一些传统的架构，一个模块下的不同主机可能运行着不同的进程（或是进程不同，或是端口不同，或是启动命令不同），但大家使用的程序包是一样的。

进程管理主要用于一些较旧的单模块多进程的传统应用的发布场景、应用启停场景和监控场景。

其他

基于银行分布式和集中式架构并存的考虑，服务树拓扑最末端可以是应用模块，也可以是资源组件模块，如数据库、消息队列等。

以上的各种资源对象模型、拓扑节点模型、包/配置文件/进程模型等均可自定义参数模型，以便于适应不同企业的应用配置管理需求。

02 应用发布自动化

应用发布需要基于CMDB和应用配置管理之上进行构建，将应用的各种对象资源及发布对象管理起来后，自动化发布就成为一个简单的事情了，我们可以选择任何一个模块按照一定的策略（并行、滚动、分批等）进行快速的发布：

关于发布的编排，分为技术维度的编排和业务维度的编排。

技术维度，就是具体的一台主机需要执行的具体步骤编排：

在上图中，我们可以编排一个通用的发布流程，将参数剥离出来，在应用配置管理中统一管理，这样，不同的应用模块就可以使用相同的执行流程进行发布，仅需从应用配置管理中传入应用相关的参数即可。

业务维度，是指应用模块之间的发布顺序编排：

银行在有限的发布窗口中进行应用发布时，有时会涉及到对大型应用进行批量发布，此时应用模块之间的发布顺序是需要严格定义的，包含每批应用发布的时间设定等，此时就需要提供应用间、应用内主机间的串并行发布顺序编排能力。

在发布过程中，我们需要实时掌握发布任务的执行详情，并且可以对发布任务进行干预，如暂停、恢复、忽略、继续、停止等。

关于发布，可以在此基础上继续扩展其他的能力，如sql发布、配置文件发布、与工单对接、快速回滚、发布审计、权限控制、配置回写等等。

03 应用灾备演练

在过往10年，大多数银行致力于“两地三中心”的灾备建设，到目前，基本都已经实现了核心系统的灾备建设。灾备建设的根本目的在于出现不可预知灾难时的应急切换，以快速恢复业务。

存储复制技术是银行灾备建设中常用的架构，以下是基于vplex和VMware HA集群的一种灾备架构设计（所有的虚拟机及数据文件均通过存储复制技术复制到灾备机房）：

当然，有些银行还会配合其他的技术来支撑灾备架构，如基于Oracle 的Dataguard/RAC技术、基于应用层面的高可用技术等等。

灾备切换一般涉及到多套应用系统、多个复杂步骤、多个业务部门，并且时间紧、质量要求高，银行能否顺利完成灾备切换，不仅取决于灾备系统的建设，也还取决于灾备演练是否充分，灾备切换步骤是否准确到位。

因此，一个好的灾备演练平台成为银行灾备系统建设完毕之后的迫切需求。一般来讲，灾备演练平台需要具备以下功能特性：

灵活、方便的编排能力，适用于各种灾备架构。
强大的通道能力，能够驱动的各种IT资源对象完成相关操作。
具有较好的可视化能力，能够清晰、实时的展示各业务的灾备切换过程和状态。
良好的扩展性，支持与监控、应用配置管理、测试等外部运维系统对接。
良好的性能，能支持整个数据中心级别灾备切换时的并发作业。

灾备演练平台架构设计如下：

案例分享：

《赣州银行增强科技创新，实现一键灾备切换》

04 银行跑批

什么是银行跑批

银行跑批就是产生总账，进行总分核对，再者就是进行大批量的非实时的交易。

银行跑批的时间

大部分批处理在晚上完成，但白天也有批量。

银行跑批的核心功能

进行会计核算

银行跑批的存在形式

一个个分布在不同服务器上的有各种依赖关系的作业。

跑批过程详细说明

银行业务结算不是所有的银行数据都是实时操作的，所有的帐都是即时入帐的，即使实时操作，后台会计部门也需要报表数据,进行对帐清算。因此跑批就是为此产生。跑批其实就是产生总帐,进行总分核对，再次就是进行大批量交易，如:结息,计提,代收付等(这一步可以在各分布平台做)。

再次就是生成报表,导出流水数据等。批量是相对联机来说的，并不一定是在晚上，白天也有批量，主要是完成业务处理的。批量的核心功能是进行会计核算，如总分核对、试算平衡等，这样保证全行的帐务没有偏差。

另外，为了提高联机交易的反应时间，一些对帐清算等不需要实时入账的功能也由批量来完成；类似的，还有一些为了减少柜员工作量和减少高峰时期资源争夺的交易，如待收代付等，也归入批量完成的功能。一些特殊业务，如记息记提等。还有一块批量就是为了统计和管理的需要而出的一些报表。

银行跑批系统，一般也称为ETL调度系统。

大部分银行已经有了跑批作业管理系统，那么为什么还要继续建设？

交易的不断增长引发巨大的数据吞吐，跑批的作业量不断增加，核心跑批可用的时间窗口不断受到压缩，跑批作业的流程日益复杂，作业与作业、作业流与作业、作业流与作业流之间存在复杂的依赖关系。

业务种类不断创新，跑批作业之间的关系也处于变化之中，涉及的系统越来越多，急切需要集中、灵活、可扩展的调度系统。

技术架构日益复杂，后台系统有AIX、Linux、Windows、中标等各种系统平台，主备、分布式等多样化的集群也增加了银行跑批作业管理的复杂性。

过去主要由国外产品提供跑批作业管理，国外产品逐步不满足安全可控、国产化以及灵活扩展等要求，因此银行需要建设更为先进的跑批作业管理系统。

跑批作业管理系统架构设计如下：

在作业编排与作业控制方面，跑批需要满足以下核心要求：

在作业执行架构上，跑批需要满足高可用分布式的要求，以支撑海量并发的跑批作业：

主要产品功能

作业流编排：

作业日历调度：

作业控制：

作业跟踪监控：

05	应用巡检

应用系统是由一组应用程序和系统资源组成。当用户访问应用系统发生问题时，可能是应用程序运行的问题导致，也可能是相关的资源对象（如数据库）出现问题导致。当一个应用系统越来越庞大和复杂时，确保系统中各应用程序和系统资源对象处于健康状态是应用系统正常运行的重要前提。

对一个应用系统进行全方位巡检，类似于医院中的专家会诊场景。应用系统的每个技术栈（资源对象类别）都会需要相应的巡检脚本/方法支持，对应医院的专科专家。

当对应用系统的所有资源类别都有了相应的巡检方法，我们也从CMDB中获取到一个应用的所有资源实例，那么我们就可以以应用维度对应用系统进行快速整体巡检和健康度评估。巡检工具架构设计如下：

应用管理：主要对接CMDB获取应用系统的各种资源实例。
指标库：一个可扩展的框架，可针对每种资源对象定义相关的巡检方法，包括基于脚本的巡检，也可调用第三方运维系统进行健康数据获取（通用编写python适配器）。
任务管理：定义巡检哪些应用，巡检时间等
报告管理：以应用角度展示巡检结果。

巡检示例报告如下：

巡检错误概览如下：

06 智能业务巡检

应用巡检是从应用内部进行巡检，但还无法直接反馈用户的真实使用情况。针对重要的业务系统，从特定办公地点模拟用户发起对该业务系统的访问并且验证该系统业务功能，我们称之为业务巡检。

为满足更多的用户模拟场景，可以采用业界流行的rpa技术。只要是用户在电脑终端上的所有键鼠操作，rpa均能实现将操作流程自动化。

基于rpa的智能业务巡检架构设计如下：

07 应用健康度监控

随着监控技术的不断应用，企业开始逐步建立立体化监控平台，所谓立体化监控平台，是指从多个维度对不同层级（一般从上到下划分为用户层，业务层，应用层，组件层，主机、硬件与网络层）的监控对象进行指标采集、统一存储和监控告警。立体化监控覆盖的对象范围如下：

应用健康度监控，出发点和技术实现方式与应用巡检类似，基于立体化监控平台之上构建的一个对应用系统的各个资源对象实例的健康状态进行监控的上层应用，应用健康度监控的用户故事，主要有以下几个：

作为应用运维人员，我想从应用系统维度对应用系统进行全方位的监控，并以拓扑的形式展现出来，以便于在接收到用户报障之后，能够快速的定位到应用系统具体哪个组件存在异常，为解决报障提供指导。
作为应用运维人员，我想把关键应用的关键健康度指标都监控、汇合展示出来，以便于我及时发现应用运行过程中的异常。
作为应用运维领导，我想随时可获取所有应用的整体健康状态，以便于感知我们当前应用运维的水平和运维目标达成情况

应用健康度监控的功能架构设计如下：

主要功能介绍：

应用运行拓扑展示（服务树拓扑、逻辑拓扑）。拓扑自动生成、应用资源对象实例会自动填充到各拓扑节点上。
可自定义监控仪表盘，通过拖拽各种图表控件生成仪表盘，控件可接入外部数据源。
告警查询，以应用维度展示告警动态。支持多种查询。
应用墙，根据资源实例信息生成应用墙，如下图：

08 APM

APM是应用运维体系中必不可少的能力。嘉为蓝鲸APM解决方案共有五大能力：

Server监控：以字节码注入为核心技术，通过应用服务器上的Agent实现应用拓扑自动生成、实现服务间的调用链监控、实现服务内方法级的调用链监控。
浏览器监控：用户通过浏览器访问应用时，会自动下发js探针到真实用户浏览器上，从而获取用户对应用的各种访问行为和效率，形成对真实浏览器用户的使用体验监控。
Mobile SDK监控：在APP开发中嵌入SDK，手机用户使用APP时，SDK获取用户对应用的各种访问行为和效率，形成对真实手机用户的使用体验监控。
互联网浏览器用户模拟访问：主要面向互联网应用，利用全球十万级以上浏览器拨测点实现。
互联网手机用户模拟访问：主要面向互联网应用，利用全球十万级以上手机拨测点实现。

APM系统架构设计如下：

09 应用启停

应用启停是一个小工具，主要提供以下功能：

进程定义
进程管理。快速启停
进程监控。异常停止时发出告警
应用一键启停。对应用各模块、各主机进程的启停提供编排能力，实现应用的一键启停

10 应用自动化运维关键能力一览

11 其他

本文先聚焦于银行应用运维的关键场景和相应产品能力。文中提及的嘉为蓝鲸资源交付、蓝鲸立体化监控平台、告警中心、日志检索、报表可视化、大屏可视化、容量管理、故障自愈等产品后续再进行详细介绍。

银行应用运维的展望

银行业务正处于飞速发展和变革的阶段，支持业务系统的信息技术也在发生翻天覆地的变化，传统运维方式已完全无法应付业务和技术变革带来的挑战，银行应用运维只有与时俱进，不断吸收国内外顶级互联网企业的先进运维理念与技术，实现组织转型，运维不再局限于运维，运维要投入到构建动态发展的、契合银行业务发展需求应用运维平台中来，向自动化、数据化、智能化稳步迈进，才能最终实现应用运维组织效能与价值。