监控，是每一个运维人避不开的话题。运维工作中，最让人担忧的是花了很多时间和精力配置了很多监控，但在关键时刻发现不了问题。

随着金融业的发展，银行业务功能变得越来越复杂，信息系统技术架构也变得多种多样，单纯从技术层面来设置监控规则越来越难以发现问题，迫切需要一套不区分技术架构，仅以描述业务运行情况为目的的业务类监控。

笔者结合自己运维经验及对业务监控的理解，讨论一下业务类监控的指标和监控规则，以供各位聊作参考。

笔者个人认为监控的发展分为三个阶段，第一阶段需要运维人员自行设定监控指标、规则、运行参数。我们最常见的监控模式是：在某监控系统中配置脚本，设置一个具体报警项，然后在服务器运行脚本获取一个特定值，设一个阈值，高于或低于阈值即触发告警，比较成熟典型的是zabbix监控系统。

监控第二阶段为监控系统约定监控指标、规则，运维人员维护运行参数。第二阶段监控指标和报警规则应在第一阶段的基础上进行归纳整理，设置尽量具有统一性，尽量兼容所有系统的运行情况。本文重点对此进行分析并尝试提出一些针对业务运行情况、能够下探到交易码级别的监控指标和报警规则。

监控的第三阶段由监控系统约定监控指标、规则，同时根据监控自身和生产系统运行情况计算出最佳的运行参数，运维人员基本不参与维护。

图1 监控发展的三个阶段

银行信息系统最小业务功能管理单位是交易码或接口，每一支交易都共有的特征是应答码、交易量、响应时间，笔者就围绕这几个特征尝试设置一些通用监控指标和报警规则，以供大家作为参考。

这项指标是监控系统最实用、最基本的一个指标。一般的成功率监控，在系统不返回系统级别错误，例如网络不通，文件未打开等系统级别异常时，均认为交易成功。但没有返回该类错误并不意味着业务处理没有问题。例如交易A001的功能是查询挂账，正常情况下返回查无记录，在交易异常产生挂账时返回挂账交易信息。

如果A001某天大量返回挂账，监控是否应该感知到该种情况呢？理想中是的。所以可以引入系统成功率和业务成功率，系统成功率用于计算生产系统技术层面失败率，业务成功率计算每支交易在返回某种业务返回码时的成功率。每支交易每天返回返回码量的量和比率都是基本固定的，甚至可以针对每一个交易码设定返回码的比率范围，而不拘泥于成功率。

图2 交易成功率页面

图3 实时交易明细二级页面

银行系统的特点之一，是每一笔交易都有确定的调用系统和服务系统，如果我们可以感知服务系统是否正常，对于确定故障点是非常有用的。

这一项的实现很简单，只要确定每一支交易有无调用服务系统，确定调用的服务系统是哪一个，将调用到该服务系统所有交易确定为计算样本，对服务系统给定的返回码进行成功率计算，即可得到该服务系统的成功率。如果维度更细致一些，可以计算服务系统的哪一个交易码成功率低。

对于高频交易，可以设定在一个统计周期内，如果没有指定交易发生，可判定触发无交易发生报警（可细化到某节点无xx交易发生）。但细想的话，经验老到的运维同事应该能想到，还是有点复杂的，因为交易的发生情况在高峰期和低峰期不同，工作日和节假日不同。这需要针对每一支交易进行交易量的统计分析，选定在当前条件内符合条件的交易码。我们可以引入“忙时”、“闲时”的概念。
 

举例：可以设定工作日早8点至晚19点为忙时，其余时间段及节假日全天为闲时，统计后发现交易码A002全天交易都很多，那么就设置为忙时、闲时均进行监控；交易码A003只有高峰期交易量多，闲时交易量很少甚至无交易，就设置为忙时监控、闲时不监控；交易码A004全天交易量都很少，断断续续只有很少的交易量，那么就设置为忙时、闲时均不监控。

这一项的设置目的，一方面在于能够发现处理节点是否损坏，另一方面也能够监控各个高频交易能否正常发生。

在日常工作中会发现，系统正常时，同一支交易在同时段交易量不会有太大起伏，往往在系统异常时，交易量也会随之产生变化。我们需要一种手段来发现交易量的突增或突减。可以计算指定交易码的交易量环比，如果起伏太大，则可以判断系统发生了一些需要管理员注意的情况。

举例：A005交易，目前15点08分属于忙时，参数为忙时有效，符合条件，计算14点08分至当前时间点15点08分A005交易发生量为a，该交易码基线工作日14点08分至15点08分交易总量为b，则环比比率c = a / b ，如果c在0.8~1.2之间（上限、下限均可调），可认定为正常，如果c=0.4或c=1.6，认定为交易量偏低或偏高，给出报警。

该指标对低频交易无效，交易量数值小会造成比率起伏较大。

图4 交易量环比骤变页面（每小时交易量）

如果交易成功率指标下探至交易码级别，对于低频交易或超高频交易适用度都不高。低频交易会频繁触发报警，而超高频交易可能感知不到问题已经发生。

例如A006交易10分钟交易量10000笔，其中50笔有问题，成功率仅仅下降了0.5%，但50笔足以引起很大问题。例如A007交易10分钟交易量2笔，而且它是重要金融交易，就比较难设定成功率。这时候我们可以设A006一个周期内失败10笔以上，A007失败1笔以上，其他交易码根据交易量统计结果各自给定报警笔数，即可解决这个问题。而且，可以专门设计一个页面，显示出所有异常交易的基础交易信息，例如：处理节点、流水号、请求系统、交易码、服务系统、返回码等，在应急处置中加快定位到故障点。

图5 异常交易明细页面

银行系统在发生故障时，可能会降低系统性能，造成响应时间拉长或者技术层面判为超时。某些监控依靠响应率应对这种现象，但响应率无法发现响应时间拉长但又短于监控等待时间的情况，另外对于较高频交易，部分交易异常不一定能够突破响应率阈值。

同异常交易一样，可以对响应时间异常的交易进行每周期笔数监控。例：交易A008，从基线中统计得到响应时间一般在300ms，那么设定超时时间over_time为600ms或900ms。如果有某一笔A008响应时间超过over_time，可以认定该笔交易超时，1个统计周期内超时超过3笔（可修改），给出报警。

日终对于银行系统的重要不言而喻，某些步骤直接影响次日的开门营业，需要专门的指标来监控。只要指定为日终步骤的交易码，在指定的最晚开始时间前开始，指定的时长内完成，且在最晚完成时间前返回成功即可。对于有对账需求的系统，在指定的时间内，发生指定类型的对账，且对账不一致的笔数、金额与往期相比没有太大浮动，可认为正常。

除上所述之外，还有一些比较通用的指标，例如进程类、长链接、队列、日志、文件、自身等就不再赘述。

经过上面的讨论，我们已经明确了一些通用的业务指标和监控规则，后面似乎只需要维护好描述业务运行的参数就可以了，但在实现过程中还会碰到诸多难点，主要集中在以下几方面：

想要实现上述功能，需要监控系统准确无误收集到生产系统每一笔交易的基础信息，至少要包括请求系统、交易码、重要交易标志、服务系统、处理节点、交易开始时间、交易结束时间（或处理时长）、流水号、机构、金额、服务系统应答码、本系统返回码、返回信息等。

这些基础信息很多生产系统都无法完整提供，例如服务系统应答码，如果在生产系统设计之初没有考虑记录这个字段，就很难提供，没有该数据，服务系统交易成功率无法计算。例如全局流水号，如果生产系统均可以提供该数据，各种形式的数据统计均可由监控系统完成。

另外，所有生产系统均向监控提供明细交易信息，数据量将会非常大，同时需要进行交易码级别的并发计算，非常考验监控系统的处理性能。

第二阶段监控的指标、监控规则会覆盖至所有生产系统，因此，对生产系统开发的统一性、规范性是有要求的。例如需要强依赖交易码参数。

为了实现上述功能，交易码参数至少要包含请求系统、交易码、交易名称、服务系统、金融标志（重要交易标志）、忙闲标志等，且单一交易码只完成单一功能为佳。例如交易码A009，因开发不规范可能一个原子交易码A009程序内部用do_type之类的字段做了功能分支，一个交易码实现了多个业务功能，这种情况很难说清A009的业务功能，是查询交易还是金融交易。

开发代码的规范性也是一个较大的问题。报警触发是否准确，与生产系统给定的响应码、日志书写等息息相关。

笔者曾在Y行集中清算系统工作，该系统有一个非常经典的响应码：201999-系统错误。一般认为在系统严重故障，程序无法从技术层面处理又无法判定原因时给定该报错。但实际此响应码一天约返回80万笔，据此计算该系统每日整体交易成功率不足90%。

此外还存在返回码一码两用、多用的情况。例如返回码R00001，应指定一个标准含义如“查无记录”，但实际使用可能被开发人自定义为“余额不足”或“卡号xxx错误”，“地址错误”之类，甚至截然相反的含义，如“查询返回xxx条”。此时这个返回码已经无法界定一笔交易成功与否了。业务监控下探到交易码级别，这个问题会更加突出，指定交易码后交易量会比较小，对返回值会更加敏感，迫切需要推进返回码标准化的工作。

错误日志标准化是日志规范比较典型的问题。日志书写规范与否直接决定日志监控是否报警准确，错误日志输出过多会频繁触发报警，造成“狼来了”现象。

上述两点如果能够克服，剩下的就是运维人员需要长期对各种运行参数进行打磨。业务类监控，需要针对每一个交易码进行参数设定，每一个交易码至少要包含业务成功率、系统成功率、骤变比率上限、骤变比率下限、异常统计周期、异常交易每周期笔数阈值、响应时间超时统计周期、响应时间超时阈值、响应时间超时每周期笔数等参数，据此描述该交易码的运行情况。

规模比较大的系统交易码的量会很多，就意味着仅交易码参数一项要长期调整上万条运行参数。不过，在参数设置规则确定的情况下，可以设计算法，根据基线的运行情况自动修改运行参数。

制作一个监控系统可能不难，难的是我们是否具有运行它的条件。受限于笔者的水平，文中的一些观点可能不正确，也可能有一些讹误，仅发表一下个人的经验和看法，作为一些参考。