一、重保规章制度

参考网联函【2021】61号：支付清算业务高峰时期保障需求申请指引：

• 行业峰值保障，应不迟于活动开始前4个月向网联平台（渠道对接人）提出书面申请.

• 提交《市场活动需求申请表》和《峰值预估明细》

• 应具备业务系统基础能力，带宽冗余、业务限流、全链路压测等

• 实际峰值流量（TPS）应在报备峰值的60%—110%之间，不在范围内时应填写故障报告并行业通报

• 活动结束5个工作日内进行重保复盘，对于实际重保现状与预期申请结果存在严重差异的情况，活动申请方应在10个工作日内提供整改方案。

二、重保产出

2.1、重保时序表

2.1.1、网联时序表

网联作为整个联合重保的统筹者，所公布的重保时序表需要所有参与方（机构、银网联、银行）统一听取指令并严格按其时序节点执行。以下表格为网联外发版本，内部还有更为详细的内部执行版本，会细化每一个时序节点的执行操作。

2.1.2、一行一策时序表

2.2、一行一策重保方案

一行一策即根据各银行的实际情况和处理能力，制定不同的保障方案。“各家银行在支付领域的数据基础、系统情况不一样，银行数据中心的分布模式、数据带宽和处理方式也不尽相同，因此要制定符合实际情况的差异化保障方案。

网联平台建立后，通过发挥行业居间枢纽作用，建立起了覆盖支付机构、网联、银行的支付全链路联合运维机制，并在重要时点实施联动协同保障。这种机制将原先相对分散、独立的保障资源整合成统一体系，对支付市场的运行支撑能力得到显著提升。连续的实战检验，各方的磨合配合也愈发顺畅，无论是我们自己还是联合保障机制都更加成熟稳定。站在行业视角，联合保障机制除了在技术层面已经证明成功之外，这种化零为整的模式对行业内的协同发展也具有更深远的积极意义。

2.3、应急方案演练

2.3.1、处理性能不足预案

• 银行性能不足时：首先会由WL执行梯度限流，如所承载能力不足且无法短期内恢复时将由支付机构下线该银行渠道（收银台不展示该银行渠道）。

• WL平台性能不足时：由机构切银联。

2.3.2、单机房故障预案

• WL机房故障：会在返回的流水号控制位中摘除故障机房标示，但由于流水号拉取报文是由机构周期性拉取的，所以重保期间的时效性会较差，此时需要机构具备切WL机房的能力，将流量引到其他机房。

• 银行机房故障：需要WL通过切银行专线来分流，将其流量引入可用机房，如可用机房无法满足峰值要求，还会进一步降级限流（按提前预案比例执行）。

2.3.3、专线故障预案

WL具备专线健康度探测和动态切专线能力，不同银行的专线数量和带宽均不一致，需要有针对性的计算制定定制化的专线切割方案（特定计算公式）。

2.4、联合压测报告

重保期间的压测主要分为联合压测、挡板压测和封板压测三类：

• 联合压测：目的是验证全链路系统性能指标，机构会按照各家银行的预估流量模型发起压测交易，压测交易所使用的银行卡又被压测银行负责提供，WL平台负责组织整体压测方案执行。（机构 → WL → 银行，通常在这一阶段的压测参与方不包括银联，但为了节约各方的压测投入成本往往会在同一时段进行）

• 挡板压测：实际上是指WL平台自身性能的极限压测，模拟机构发起交易，mock掉银行返回。压测交易会正常清结算但不会轧差上报大额，可以理解为只有信息流没有资金流。当然，各参与方也需要进行自身的挡板压测，只不过WL不负责统一管理。

• 封板压测：完全模拟大促重保场景，所有重保参与方（机构、银网联、银行）均需要参加，不符合压测预期的参与方将尽快整改，择机补充压测。压测通过的参与方将进行生产封网，停止一切生产变更（如有重大变更调整还需报备评估是否重新走联合压测）。

通常压测过程中都会掺夹着一些预案演练操作。

2.4.1、整体压测方案

2.4.2、压测排期计划

2.4.3、整体压测目标

压测的本质目的就是验证各参与方的系统性能瓶颈，而压测过程中的系统表现指标将是衡量扩缩容等操作的依据。由于WL是金融基础设施所以不存在动态扩缩容的情况，日常的资源储备要随时具备大促重保能力，有充分的资源buff。比较多的是专线带宽的扩缩容。

2.5、系统巡检

重保启动期间(封网期为准)需要各保障团队每天按照提前制定的checklist对系统进行巡检，分析问题并报备。

前期不具备系统化时都是通过人工方式统计数据，后期均实现了系统自动化巡检分析。

三、降级方案

在整个重保生命周期范围内，降级主要分为事前、事中、事后三大类。同时所有的降级方案都需要有配套的check反馈结果，并且要有AB角可执行。

3.1、事前降级

事前降级主要是对非核心业务进行降级操作以换取核心业务的稳定性。WL平台在原有降级手段的基础上进一步丰富能力，在不降低客户体验的前提下，尽可能减少交易高峰期发送给银行的交易请求数，缓解对银行系统的压力。主要体现在交易状态查询、入账通知和终态通知3个方面。

事前降级应该是随着不同的重保策略而改变的，所以在将事前降级操作设计成工程化时一定要保证其动态可编辑性。

事件降级主要分类：

3.2、事中降级

事中主要是应急预案的执行，应急预案的触发主要是靠监控，在重保期间更多的是靠业务监控，即使是因为一些系统故障造成的影响最终也会呈现在业务监控上面。

3.3、事后恢复

针对事前和事中的降级操作进行恢复，所有回复执行操作都要有检查结果反馈。

四、监控告警

重保期间的监控主要分为业务监控和系统监控两种，业务监控的核心是业务状态码的聚合计算，系统监控往往只有基础组件团队关心，业务团队是不需要系统监控的。

4.1、业务监控

4.1.1、合理的埋点数据

monitor log demo：

4.1.2、实时计算

4.1.3、样例展示

• 业务监控

• 机房维度监控

• 单机房维度

4.2、系统监控

业务团队关注自身应用所使用的虚机资源（CPU、memory、disk、IO、JVM）监控指标，基础组件团队关注中间件、硬件设备、网络IO等监控指标，所有监控数据通过grafana看板展示。

五、多维度备份

在重保过程中很容易被忽略的一点是备份补位，前期的准备工作做的很充足，所有预案场景考虑的很周全，所有演练操作执行的很顺利，此时最容易被忽略的就是备份补位。预案准备的再好无法有效的被执行，一切都是空谈。针对多维度备份WL投入了很多工作：

• 场地备份：由于发生不可抗力的外在因素导致重保场地不能支撑重保（断电、疫情）。在没有疫情之前主要通过主分两个会场进行相互备份（由于资源优先，分会场只具备最小单元执行能力）。19年疫情后也增加了远程备份场景。

• AB角备份：理论上所有有操作执行能力的岗位都要有AB角，重保常态化后B角与A角将不分主次，可动态调整重保参与优先级。

• 设备备份：主要沟通都是靠电话会议完成，在主要节点将设置备份电话会议，电话会议无法正常服务时还可通过微信、钉钉等沟通软件进行沟通。

• 服务备份：主要是为重保提供支撑服务的节点进行备份。比如监控平台故障，无法准确获取到实时数据，此时的备份预案是执行提前准备好的脚本，绕过监控平台直接对原始数据进行查询分析。配置中心无法下发配置，同样通过提前准备的脚本推送配置等。

六、重保任务总结

6.1、重保生命周期

6.2、重保任务清单

6.3、重保成果

七、重保实战场景

• 指挥中心：由各参与方的高管组成，负责听取和处理重大异常问题决策（动员、点名、舆情）。

• 响应中心：由WL各模块负责人组成，负责整个重保活动调度。

• 临时协调沟通人员：主要负责随时传达重保状况和下发指挥中心指令。

• 其他重保人员：也叫机动人员，负责保障基础重保服务支持（基础组件、网络环境、后勤宣传）以及处理不在重保预案范围内的临时操作任务。

• 一行一策：整个重保的核心执行团队，每两人一组（技术 & 运营）通过电话会议链接支付机构、银行、响应中心，负责重保期间的绝大部分预案执行工作，属于重保核心执行团队。

• 支付机构：重保活动主要参与三方支付机构。

• 银行：重保活动主要参与18大银行（工、农、中、建、交、招商、邮储、光大、广发、华夏、平安、浦发、中信、农信银、民生、兴业、微众、网商）。

整个重保主要靠电话会议进行沟通，重保开始前先由指挥中心进行点名，各参与方答到并报告系统运行状况。后续操作指令均由响应中心按照重保预案下发，各重保单元负责执行。

八、对比分析

维度	WL	JD
认知高度	政治任务	商业活动
投入权重	第一优先级，近乎全员	第一优先级，相关成员
复杂度	自上而下，短链路，集中备战	长链路，分散备战
频次惯性	重保常态化	疲惫懈怠期，尚不成体系
奖罚机制

待讨论问题：