一种保障系统可用率的风险管理方法与流程

本发明属于计算机数据处理领域，具体涉及一种保障系统可用率的风险管理方法。

背景技术：

系统的可用性，英文名字为systemusability，即系统服务不中断运行时间占实际运行时间的比例。所以，可用性其实是一个百分比，如99.9％。金融系统通常采用系统全年的停机时间来衡量一个系统的可用性，采用n个9作为系统可用性的度量指标。比如：系统可用率99.99％代表全年系统的停机时间不能高于52分钟，其计算公式：365*24*60*(1-99.99％)。目前，金融系统在进行监管报送系统可用率时，通常使用系统全年运行时间的百分比来进行报送。

在当代互联网技术中，绝大多数系统在设计时就充分考虑了不停机发布与系统高可用方案，系统全年停机时间基本为0，停机时间已无法准确对系统的可用率进行衡量。但系统中存在的各种交易超时、各类异常经常导致业务交易失败，在使用停机时间衡量系统可用率时，这部分因素往往被忽略掉。

使用停机时间也只能事后衡量一个系统的可用率，粒度相对较粗，且未能将系统运行过程中的所有异常场景进行全面覆盖，无法实时对系统的可用率进行管控，只能对系统的可用率进行度量，本质上无法实现对系统可用性进行实时监控和稳定性整改，从而不能提升系统的可用率。

技术实现要素：

针对现有技术存在的问题，本发明提供了一种有效的手段来监控并保障系统的可用性，并在发生生产故障后的第一时间对故障的影响范围进行评估，精确到系统中每笔交易的成败，关注到系统运行过程中发生的各类异常，通过对这些异常数据的记录与分析，及时控制系统的发布频率，排除影响系统可用性的内外因素，最终从根本上保障系统的可用性，提升了系统的可用率。

本发明采用的技术方案如下：

如图1所示，一种保障系统可用率的风险管理方法，其步骤如下：

步骤1：根据系统一个周期的调用量计算系统在满足系统可用率的情况下，允许失败的交易笔数，将这部分允许失败的交易笔数设为系统风险沙漏的可用风险指标总数；

步骤2：当出现交易异常时，对系统风险沙漏中的可用性风险指标总数进行扣减；

步骤3：定期检查系统可用风险指标的消耗率是否超过阈值，当系统的可用风险指标的消耗率超过阈值时，则视系统为不稳定状态，执行步骤4，如果没有超过阈值，则系统视为稳定状态，重复步骤3；

步骤4：通过查看系统稳定性与系统发布关系图来对系统不稳定因素进行衡量，如果系统变更频率过高，则对系统执行版本发布禁令,停止系统的任何功能发布请求，并责令系统进行稳定性的整改，所述整改方案参考以记录在案的异常交易，整改完毕后，执行步骤5；

步骤5：检查系统是否整改完毕，如果整改完毕则恢复系统的可用性风险指标总数为初始值，并解除系统发布禁令，允许系统发布新功能；

步骤6：监管报送，基于系统运行时间与风险沙漏可用风险指标消耗百分比，对系统的可用性进行报送。

进一步的，所述系统可用风险指标总数＝系统的交易笔数*(1-系统可用率百分比)。

优选的，所述交易异常的定义包括接口响应耗时超过阈值、交易返回码为业务失败、发生生产事件并影响到业务的笔数。

进一步的，所述接口响应耗时超过阈值判定方法为，使用分布式链路跟踪系统对每笔交易的链路及接口响应耗时进行分析，检查接口的内部耗时是否超过接口响应阈值，针对内部耗时超过阈值的接口，对可用风险指标进行扣减，并记录异常交易的详情，方便后期排查，所述接口内部耗时计算公式如下：接口内部耗时＝交易总耗时-外部耗时。

进一步的，所述分布式链路跟踪系统包括：

(a)在发生接口调用时，服务端/客户端通过打印携带链路id的接口调用信息进行链路采集；

(b)应用在收到服务请求时，打印服务端日志；

(c)应用在调用其他服务时，打印客户端日志，打印时先判断环境中是否存在链路id，如果不存在则生成一个全局唯一的链路id，创建链路id后，当前节点就做为接口调用的源点；如果存在，则复用该链路id；

(d)通过采集各个服务的服务端和客户端的调用日志，汇总到分布式链路跟踪模块，该模块通过链路id将接口调用分组，再通过服务端、客户端的当前ip和下游ip关系，串联出调用链路，以及耗时关系。

进一步的，所述交易返回码为业务失败处理判定方法为，在系统的业务维度，通过定制系统的业务交易日志，来追踪每一笔业务交易的执行结果；当交易失败时，将该笔交易对应的数据记录到异常交易中，并对可用风险指标进行扣减；当出现生产事件后，我们通过统计系统接口调用与业务交易的成功、失败总笔数来对该事件影响的渠道、产品、交易类型、金额进行报表统计，用实际交易的影响数量来对事件进行有效定级。

进一步的，所述业务交易调用成败判定方法为，当发生系统接口调用时，应用服务打印本次接口调用的业务交易日志和业务金额以及本次交易的返回码，分布式链路跟踪模块对该业务交易日志进行采集，使用链路id与接口调用时的链路id进行关联，最后通过业务响应码来进行判定。

所述业务交易日志为包括：渠道码、产品码、事件码、链路跟踪号以及交易金额。

进一步的，在系统发生生产事件时，查看事件的影响范围及影响笔数，并排除接口异常笔数和交易响应码异常笔数，作为扣除风险沙漏中可用风险指标的依据。

综上，本发明技术方案所带来的有益效果是：

1.通过系统的可用风险指标、发版频率、生产事件数量来综合衡量系统的可用性，而非简单的按照系统的停机时间进行衡量，粒度相对较细，且能将系统运行过程中的所有异常场景进行全面覆盖，实时对系统的可用率进行管控，系统可用性监管报送的准确率更高。

2.通过对可用风险指标消耗的情况进行持续监控，并对系统的变更频率进行控制，进而对影响系统可用性的因素进行及时的预警并监督整改，实现不仅能够度量系统的可用率，还对系统可用率进行提升。

3.通过采用风险沙漏的形式对系统的可用率进行展现，使用沙漏中沙子的不同颜色来对系统可用率进行预警，可以更加直观的实时查看系统的可用率变化情况。

4.通过分布式链路跟踪系统对接口的调用链路进行排查，可以方便的记录接口全天的调用总量、最大耗时、平均耗时，对后续进行接口的性能优化有很大的参考意义。

5.通过对业务交易日志进行逐笔排查，可以方便的统计到每条业务流水线的失败比例，以及失败总金额，对后续的业务运营及业务方向的调整起到较大的参详价值。

6.通过查看系统稳定性与系统发布关系图，查看系统在象限中的分布关系，可以分析出一个系统是否因为变更引起的不稳定，以及可以进一步筛选出哪些系统在版本控制与稳定性方面做的比较好。

附图说明

本发明将通过例子并参照附图的方式说明，其中：

图1是本发明中一种保障系统可用率的风险管理方法流程示意图；

图2是id为0a8428251820662400677871692785的链路调用图；

图3是风险管理方法系统界面展示图；

图4是系统稳定性与系统发布关系图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例的描述中，需要说明的是，术语“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

下面结合图1～图4对本发明作详细说明。

一种保障系统可用率的风险管理方法，其中涉及到的具体步骤如下：

步骤1：设置系统风险沙漏的可用风险指标总数：

根据系统一个周期的调用量来计算系统在满足可用率(比如99.99％)的情况下，允许失败的交易笔数。我们将这部分允许失败的交易笔数定义为系统风险沙漏的可用风险指标总数。计算公式：系统可用风险指标＝系统的交易笔数*(1-系统可用率百分比)

例如：a系统去年的交易笔数为：1000w笔，a系统对外承诺的系统可用率为99.99％，那么a系统一个周期的可用风险指标＝1000w*(1-99.99％)＝1000。

步骤2：扣减系统风险沙漏的可用性风险指标总数：

当出现交易异常时，对风险沙漏中的可用性风险指标总数进行扣减，交易异常的定义为：接口响应耗时超过阈值、交易返回码为业务失败、发生生产事件并影响到业务的笔数。

例如：a系统的转账接口异常，共计造成50笔转账失败，那么系统风险沙漏中的可用风险指标总笔数＝1000-50＝950。

1)接口响应耗时超过阈值判定逻辑：

使用分布式链路跟踪系统对每笔交易的链路及接口响应耗时进行分析，检查接口的内部耗时是否超过接口响应阈值(使用内部耗时作为检测条件是为了防止调用下游的接口超时对上游链路的统计产生错误影响)，针对内部耗时超过阈值的接口，对可用风险指标进行扣减，并记录异常交易的详情(包括：交易链路id、发生时间、系统名称、接口名称、响应耗时、交易返回码等信息，方便后期排查)。

接口内部耗时计算公式如下：接口内部耗时＝交易总耗时–外部耗时。

其中，分布式链路跟踪系统工作原理如下：

在发生接口调用时，服务端/客户端通过打印携带链路id的接口调用信息进行链路采集，日志分为：服务端日志与消费端日志。

应用在收到服务请求时，打印服务端日志。接口调用完成后，服务端日志打印以下内容：调用时间、链路id、当前服务名称、当前服务ip、接口、接口的调用总耗时、调用方的服务名称、调用方的服务ip。

应用在调用其他服务时，打印客户端日志。打印时先判断环境中是否存在链路id，如果不存在则生成一个全局唯一的链路id，创建链路id后，当前节点就做为接口调用的源点；如果存在，则复用该链路id。客户端日志打印以下内容：调用时间、链路id、当前服务名称、当前服务ip、下游服务名称、下游服务ip、调用下游的接口、调用下游接口的总耗时。

最后，通过采集各个服务的服务端和客户端的调用日志，汇总到分布式链路跟踪模块，该模块通过链路id将接口调用分组，再通过服务端、客户端的当前ip和下游ip关系，串联出调用链路，以及耗时关系。

举例：链路id为0a8428251820662400677871692785的链路调用图如图2所示：

2)交易返回码为业务失败处理逻辑：

在系统的业务维度，通过定制系统的业务交易日志(包含：渠道码、产品码、事件码、链路跟踪号以及交易金额)，来追踪每一笔业务交易的执行结果。当交易失败时，我们将该笔交易对应的数据记录到异常交易中，并对可用风险指标进行扣减。当出现生产事件后，我们通过统计系统接口调用与业务交易的成功、失败总笔数来对该事件影响的渠道、产品、交易类型(事件)、金额进行报表统计，用实际交易的影响数量来对事件进行有效定级，使事件的监管报送更准确。

业务交易日志采集的工作原理为：

业务调用的追踪需用使用链路id作为唯一主键来追踪。当发生接口调用时，应用服务打印本次接口调用的链路id和业务金额以及本次交易的返回码。分布式链路跟踪模块对该日志进行采集，使用交易日志中的链路id与接口调用时的链路id进行关联，最后通过业务响应码来判断本次交易调用的成败。

3)生产事件影响的处理逻辑：

在系统发生生产事件时，查看事件的影响范围及影响笔数，并排除接口异常笔数和交易响应码异常笔数，作为扣除风险沙漏中可用风险指标的依据。因为，有些交易是由于程序bug导致的，表现在账务数据错误，但接口响应正常，这部分同样需要进行可用风险指标扣减。

步骤3：定期检测可用风险指标的消耗率。

通过监控风险沙漏中的可用风险指标的余量与每日的可用风险指标消耗百分比，我们对系统当前的可用性做出衡量。使用定时作业，定期检查系统可用风险指标的消耗率是否超过阈值。如果超过阈值，则执行步骤4，如果没有超过阈值，则重复执行步骤3。

计算公式：可用风险指标的消耗率＝异常交易次数/可用风险指标总量。

例如：a系统的可用风险指标为1000笔，某日系统由于转账失败共计消耗1500次可用风险指标时。定时作业在扫描时，发现当日可用风险指标的消耗率为150％，随即发出系统可用性告警。

步骤4：停止系统发布，进行系统稳定性整改

如图4所示，为四月份该系统变更频率与系统稳定性关系图，横坐标为系统的稳定程度，其中纵坐标为系统的发布频率，变更是造成系统可用率下降的源头，通过查看系统稳定性与系统发布关系图来对系统不稳定因素进行衡量，如果系统变更频率过高，则视系统为不稳定状态，对系统执行版本发布禁令,停止系统的任何功能发布请求，并责令系统进行稳定性的整改(整改方案参考以记录在案的异常交易)。整改完毕后，执行步骤5。

例如：a系统的可用风险指标消耗率为150％，超过可用性阈值(100％)，则触发发布禁令，那么应当停止系统当月的版本发布计划，并对转账接口进行整改。

步骤5：恢复系统可用性风险指标总数，解除发布禁令

检查系统是否整改完毕，如果整改完毕则恢复系统的可用性风险指标总数为初始值，并解除系统发布禁令，允许系统发布新功能。

例如：a系统的可用风险指标总数恢复为1000，允许a系统继续进行功能发布。

上述步骤5中，通过系统稳定性与系统发布关系图可以反应出系统在象限中的分布关系，分析出一个系统是否因为变更引起的不稳定，以及筛选出在版本控制与稳定性方面较好的系统，通过监控风险沙漏中的可用风险指标的变化趋势，来控制系统的版本发布频率，最终实现提升系统的可用率。

步骤6：进行监管报送

在监管报送时，我们基于系统运行时间与风险沙漏可用风险指标消耗百分比，对系统的可用性进行报送。报送逻辑如下：如果系统的运行时间小于99.99％,则以系统的运行时间百分比进行报送。如果系统的运行时间大于99.99％，我们采用基于交易量对系统可用率进行报送，公式如下：

公式：系统可用率＝(1-异常交易总数/交易总数)*100％

备注：异常交易总数包括以下指标的统计：接口响应耗时超过阈值、交易返回码为异常、生产事件影响的交易数量。交易总数是指当年交易的总量。

本实施例中，如图3所示，该风险管理方法系统界面展示图，包括中部的风险沙漏，所述风险沙漏右边数字为可用风险指标，所述风险指标下边的仪表盘为当前总共消耗的可用风险指标百分比，下部的表格里的消耗百分比为每日的可用风险消耗百分比，左边是所有系统可用风险指标消耗百分比的排行榜，右上角是每月的系统可用率，右下角是控制系统发版频率的提示。

本实施例中，本发明技术方案基于本领域使用99.99％衡量系统可用性的方法，把侧重点放在不可用的0.01％上，通过将交易量的0.01％指标装进系统风险沙漏中，系统风险沙漏图如图3所示，形成一个用于衡量系统可用性的风险沙漏，沙漏耗尽时，系统可用率将低于服务承诺水平99.99％，通过监控风险沙漏的消耗情况来对系统的可用率进行衡量，当风险沙漏消耗过快时，提前进行干预，放缓系统的发布频率，防止系统可用率低于服务承诺水平，另外，本方案在系统可用率的监管报送时，综合使用停机时间+风险沙漏消耗百分比进行报送，风险沙漏的消耗条件包括：系统的接口响应超时、交易返回码异常、生产事件数量，

以上所述实施例仅表达了本申请的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请保护范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请技术方案构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。