引言
ITIL将IT服务管理分为十个核心流程管理和一项管理职能,目前国内银行的运维体系大多基于ITIL规范建立。在ITIL十个核心流程之一的事件管理中,事件是指任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的操作。银行的IT系统中,“事件”的表现形式五花八门,但处理事件的要诀只有一个“天下武功,唯快不破”,根据事件的分类、影响范围和紧急程度,用一切可能的办法“不择手段”地快速解决。本文想浅谈G行应用管理中事件的发现过程,即应用监控的建设,以及从应用监控到可视化运营的发展方向。
传统监控体系概况
传统的应用监控指从应用层对应用交易的处理性能、流量、带宽占用、用户行为、渠道来源、服务占用等进行实时监控、分析、报警,下表简单罗列了通用的应用基础监控。
应用基础监控 | |||||
类别 | 监控方式 | 指标 | 类别 | 监控方式 | 指标 |
资源层 | 进程 | 进程数量 | 应用层 | 应用功能 | 健康检查 |
进程 | GC次数/分钟 | 业务层 | 联机交易 | 整体交易成功率 | |
文件 | COREDUMP | 整体交易响应时间 | |||
异常文件 | 整体交易量 | ||||
文件 | 缺失关键文件 | 整体交易响应率 | |||
文件 | 密钥交换状态 | 联机交易 | 单支交易成功率 | ||
文件 | 日志关键字 | 单支交易响应时间 | |||
网络 | 端口监控 | 单支交易量 | |||
网络 | 网络长连接 | 单支交易响应率 | |||
组件层 | 线程池 | 线程池状态 | WEB页面 | 页面监控 | |
数据库连接池 | JEDIS连接池 | 批量任务 | 批量任务状态 | ||
应用API | 加密API连接 | 集群环境 | F5池可用率 | ||
应用队列 | 队列深度 | 部署层 | 集群环境 | 集群状态 |
应用监控主要确保应用基础环境和运行性能正常,并提供积极的用户体验,应用监控工具为IT管理提供必要的信息,帮助进行事件处置:隔离、服务降级或重启。
1. 传统监控体系下的应用基础监控
Google SRE 定义了四个需要监控的关键指标。延迟(Latency),流量(Traffic),错误(Errors)和饱和度(Saturation)。
延迟 (Latency)
延迟是服务处理传入请求和发送响应所用时间的度量。测量服务延迟有助于及早发现服务的缓慢。
- 流量 (Traffic)
流量可以更好地理解服务需求。通常称为服务 QPS(每秒查询数),流量是服务请求量的度量。此信号可帮助您决定何时需要扩大服务规模以应对不断增长的客户需求,或缩小服务规模以提高成本效益。
- 错误 (Errors)
错误是对客户端请求失败的度量。这些故障可以根据应用程序的响应返回码、日志中的关键字轻松识别。在某些情况下,由于错误的结果数据或违反了约定,响应被认为是错误的。除了响应码之外,可能还需要其他的代码逻辑输出的错误日志来捕获错误。
- 饱和度 (Saturation)
饱和度是服务器资源利用率的度量。这个信号告诉你服务资源的状态以及它们有多“满”。这些资源包括内存、cpu、网络 I/O 等。在资源利用率达到 100% 之前,服务性能也会缓慢下降。因此,有一个利用率目标很重要。延迟的增加是饱和度的一个很好的指标。
正如Google SRE所讨论的,通过各类技术工具Zabbix、Prometheus、grafana等实现衡量服务的四个指标,可以实现对一个业务系统最基础的监控。
2. 传统监控体系的痛点
- 以交易为中心而不是以客户为中心
传统的应用监控大多是以技术组件可用性和交易性能为中心。在Bank4.0时代,场景金融被广泛提及,其将视角从传统以产品和交易为中心投向以客户为中心,将服务的物理空间从银行为中心转向以场景为中心,通过连接客户生活、生产场景中产生的金融需求而提供端到端的服务,带来金融的创新和业态转化。应用管理中的监控体系也必须不断的进化和迭代以适应业务的快速发展,其出发点也必须转变:从以交易为中心到以客户为中心,未来的实践方向或为监控场景化。
- 业务和技术监控视角不统一
另外我们需要讨论的一个问题是,在传统监控推送一个监控信息后,如何判断业务影响范围?由于业务人员和IT管理人员的视角存在明显的偏差,对业务影响的准确判断也存在明显的偏差,这里我们可以通过埃舍尔的视错觉的图来描述这一现象,结果到底是鸭还是兔?
当银行IT系统监控平台推送一个联机服务拥堵的信息,从应用管理的角度事件定义为服务拥堵,某几支联机交易无法正常处理,但是从业务管理角度看到的是支付系统贷记往报出现宕账。业务视角和IT视角的不同,对事件的重要性和紧迫程度会有截然不同的判断,对事件处置的决策会产生重大影响。当信息不足以准确分析环境中的复杂情况时,我们会根据固有的认知、逻辑和习惯进行猜测和补充。如何统一技术和业务视角、精确定位业务影响范围是必须要思考的另一个难题。
G行从应用监控到业务可视化运营的探索
为适应“科技、敏捷、生态”战略转型要求,实现打造一流财富管理银行”战略目标,G行投入建设了“可视化运营”项目。该项目遵循数字化转型战略,切实做好安全运营保障、提升运维治理能力,为提升信息系统整体可用性、科技赋能业务发展、促进数字化银行转型提供有力支持。
可视化运营最大的特点就是:由业务人员和IT管理人员共同提出监控需求,解决“鸭兔”问题;实现重点应用系统重点业务场景化监控覆盖、全流程管理。业务监控功能将从交易量、客户、商户等维度,利用生产数据,通过全国热点地图、柱状图、动态展示图等形式对业务运行现状进行呈现,以完成下述目标:
1. 通过监控掌握业务发展趋势,对业务发展方向提供预判。
2. 通过对客户行为数据的监控掌握客户的行为轨迹,促进交易量提升。
3. 通过对业务的实时监控可及时发现业务功能是否能够正常处理,如遇异常可及时做到科技业务联动、总分行联动、集中指挥,统一应急处理,提高业务整体运营能力。
4. 风险违规防范的监控功能,对重要业务场景深挖可能存在的业务风险点;通过对实时数据的监控,及时发现隐患进行应急处置。
5. 对监管考核事项重点监控,确保在各监管机构的合规率100%。
针对支付清算业务,G行定义了本币支付清算5大业务场景(分别是:大额支付、小额支付、超级网银、CIPS、ACS)和外币清算场景。与传统监控全流程只需要科技人员不同,可视化业务运营需要业务人员、开发人员和运维人员一起来指定场景的设定范围、指标、阈值。项目实施的关键是整体需求的制定,整个过程需要大量和业务沟通确认的工作。G行可视化运管管理平台在本币支付清算场景,整体上梳理4个本币场景中系统监控、系统管理、业务管理、统计分析、工作管理5大类123个重点需求,具体实现如下文所述。
对各场景整体状态、交易量、交易金额、系统响应率等全面覆盖。
传统监控更多的是对一个点的监控,业务场景下更注重对业务流程化的运营管理。重点清算支付业务场景分级层层下钻,按业务类型实时分析和统计,异常时在来往报告警信息中予以显示,处理成功后根据终态结果自动核销,自动判断清算异常、流动性异常(头寸预警、清算排队)。
行内考核指标和监管考核指标全面覆盖,G行关注信息(大额来往报异常、小额来往报异常、超网来往报异常、CIPS来往报异常、ACS异常数据);人行考核数据回复率及发起应答报文数量(查询查复、退回申请、人行状态查询、客户信息查询、支付申请)。异常业务可自动推送通知至总分行管理人员,实现科技——业务,总行——分行实时联动。
外币清算一体化运营。
结语
未来银行在业务及产品服务模式创新方面,有必要结合第一性原理进行开创性创新。对银行本身而言,也应以第一原理思想,不断突破固有思维模式,走出一条适应自身发展的创新之路。未来银行的金融服务与我们的生活场景、消费场景深度融合,作为应用管理中业务监控的探索也必将深入场景,实现从以交易为中心到以客户为中心的转变:第一时间发现问题,准确做出业务判断,及时解决问题,有效提升客户体验,从技术层面的应用监控走向业务可视化运营。