90 论某市城市商业银行互联网核心系统整体上云项目的风险管理

ONEPSOFT | 软考学习知识库

---

2021年9月，我作为系统规划与管理师主持了某市城市商业银行互联网核心系统整体上云项目。近年来，监管部门陆续出台金融科技发展规划，鼓励中小银行加快云计算架构转型，把面向互联网场景的主要系统逐步迁移到云平台。这家城商行成立于上世纪九十年代，近年来零售业务发展迅速，手机银行、互联网收单、消费信贷、直销理财等线上业务规模不断攀升，原有多套分散部署的系统和机房设备已经难以支撑业务在线化的连续性要求，运维成本也居高不下。为了提升基础实施保障能力，行方决定把互联网核心系统整体迁移上云。该系统整合了手机银行、互联网收单、消费信贷、直销理财等主要线上产品，是行里互联网金融战略的重要载体，迁移范围涉及账户、支付、信贷、理财等多个产品线，既是一次技术架构的升级，也是一次业务流程的再造。通过邀请招标，我们公司作为云服务提供方中标，我全流程参与了从规划设计、部署实施到运营保障的各项工作。

从技术角度看，这次上云并非简单的资源搬迁，而是要对系统的部署架构、中间件选型、数据迁移方案、安全合规边界进行通盘设计。原有系统运行在传统机房，对外服务窗口、安全防护、容灾能力都有一定局限；迁移上云后，系统弹性伸缩能力增强，但也引入了新的不确定性，比如云平台与行内现有系统的兼容性、数据迁移期间的业务连续性、云上数据的安全合规等，这些都为风险管理提供了具体场景。

IT服务风险是服务过程中各种不确定性的总和，一旦发生会给业务带来连锁影响。这个项目时间紧、涉及面广、监管要求高，我格外重视风险管控，从风险管理计划编制、风险识别、风险定性分析、风险定量分析、风险处置计划、风险监控与跟踪六个方面展开了细致的工作，最终项目按计划完成，系统平稳上线运行。

一、风险管理计划编制

在项目启动初期，我召集行方相关人员和团队召开风险规划会议，依据服务范围说明书、服务级别协议、进度管理计划以及公司过往项目的组织过程资产，结合项目实际，共同编制了风险管理计划和风险模板。考虑到金融行业的特殊性，我额外邀请了公司金融领域专家参会，逐阶段分析风险影响，明确责任分工，并约定每两周召开一次风险评估会，把风险议题常态化地纳入项目例会议程，确保风险管理不是停在纸面上，而是贯穿于每一个里程碑。

二、风险识别

为了让全员有准备地参与识别，我通过在线协作文档发布了风险管理计划、风险模板和公司项目风险库，开放阅读权限，让大家提前熟悉风险分类和识别方法。在头脑风暴会议上，大家结合项目实际，以风险分解结构的方式把服务风险划分为技术风险、需求风险、沟通风险三大类，形成详细的《风险登记册》。比如：部署阶段，支付交易在高并发场景下若缺乏高可用的消息中间件支撑，可能出现订单丢失的风险；作为金融机构，系统上云要接受人民银行、银保监等部门的监管检查，存在业务需求调整和对外参数变更的风险；项目干系人众多，涉及行内多个部门、设备供应商、多家第三方服务商和监管机构，信息传递链条长，容易滋生沟通风险。这些风险都被逐一记录并标注了初步的影响判断。

三、风险定性分析

在定性分析阶段，我们逐项评估风险发生的可能性和影响程度，通过概率影响矩阵确定优先级。我组织服务团队并邀请两名金融行业技术专家共同参与，对识别出的风险进行认真评估，把分析结果更新进《风险登记册》。高并发掉单风险、监管变更风险、干系人沟通风险被确定为高优先级风险，成为后续处置的重点对象。定性分析的过程本身就是一次风险教育。通过逐项打分，团队成员对哪些环节容易出问题、出了问题影响有多大有了直观认识，后续执行风险应对措施时也更有自觉性。我们还把定性分析结果与行方项目负责人进行了沟通对齐，确保双方对风险优先级认知一致，避免因理解差异导致资源投放错位。定性分析的输出为我们排定了风险处置的先后顺序，哪些风险必须立即采取措施，哪些可以纳入常规监控，一目了然，避免了眉毛胡子一把抓。

四、风险定量分析

为了在不确定中做出更恰当的决策，我们采用决策树方法对关键风险进行量化比较。以高并发掉单风险为例，当时存在两个备选方案：一是使用行方现有的开源消息中间件，二是采用云厂商提供的托管消息队列。我们结合性能、扩展性、业务安全性和统一运维等因素做了决策树分析，发现开源方案在高性能、高扩展性和运维保障方面存在明显短板，整体可靠性受影响，且会增加服务成本，最终选择托管消息队列作为应对手段。类似的分析帮助我们避免了多笔不必要的投入，也让应对方案建立在数据支撑之上，而不是凭经验拍脑袋。

五、风险处置计划

根据定量分析结果，我们把应对成本和措施纳入服务预算与进度。针对掉单风险，采用云消息队列方案从根上解决；针对监管政策引发的需求与参数变更风险，我们建立了完善的变更控制流程，并协调公司政策研究部门协助行方准备监管汇报材料，确保合规与进度两不误；针对干系人沟通风险，我们统一使用即时通讯工具建立沟通群，消息已读未读状态一目了然，对未及时响应的干系人还可以通过电话或短信提醒，确保信息准确传达，沟通效率大幅提升。每项处置措施都明确了责任人，并设定了效果评估的节点。为保证风险识别不遗漏，我们还梳理了迁移全过程的检查清单，按系统调研、方案设计、环境准备、数据迁移、联调测试、上线切换、运行保障七个阶段逐项核对，把可能的风险点与阶段对应起来，让识别工作更加系统，也为后续制定应对措施提供了清晰线索。

六、风险监控与跟踪

整个项目过程中，我们通过风险审计、差异分析和技术绩效测量等手段实施监控，利用每两周一次的风险会议及时捕捉潜在风险，同时把风险意识渗透到每位成员，团队凝聚力也得到增强。风险监控不是项目经理一个人的事，我们建立了全员参与的氛围，鼓励成员在各自岗位上及时上报异常苗头，把被动等待变成主动发现。对已识别的风险持续观察记录，对突发的新风险及时纳入清单，动态调整应对措施，保证风险应对计划始终有效。在监控手段上，我们结合上线演练和压测数据，设置了关键指标预警阈值，比如消息积压量、支付成功率、接口响应时间等，一旦触达阈值即触发告警并启动核查流程，把风险消灭在变成故障之前。迁移切换的关键节点，我们实行专人值守、双人复核，每一步操作都留有记录，确保出现问题能够迅速定位和回退。

经过团队五个多月的努力，2022年3月，互联网核心系统整体迁移上云顺利完成并上线运行。到2022年6月，系统承接的在线客户数已超过二十五万，较原系统增长约四倍，系统处理能力、安全性和稳定性都上了一个台阶，行方给予高度评价。回顾这次上云项目，我更加深刻地认识到风险管理对系统规划与管理工作的价值，它不是一个阶段性的动作，而是贯穿项目始终的思维方式。同时，我也看到自身在资源分配、风险清单完整性、信息收集等方面仍有不足，好在通过应急处理和及时协调都未影响项目进度。这些经验教训已写入项目总结，为后续同类项目提供参考。