背景：

在软件开发过程中，系统稳定性是一个重要的考量因素。它直接影响到软件的性能、可靠性和用户体验。然而，由于各种原因，如需求迭代、架构升级、配置变更、人力变动、系统不熟悉等，系统稳定性可能会受到影响。一直想写一篇风险管理的文章，想着从项目管理的风险维度出发，对系统稳定性进行有效的风险管理，来保证系统稳定性。

文章中会出现一些项目管理知识的专业术语，先来个日常生活中上班堵车风险的案例对 PMP 中风险管理有个初步概念

一、风险概念

已知风险 VS 未知风险

二、规划及识别风险

识别风险是风险管理的第一步。对于系统稳定性，小组长需要密切关注需求的各个环节，及时发现可能导致系统不稳定的因素。

1.【需求】需求不明确或不完整是一大风险因素。如果产品经理的需求文档存在不明确或不完整的情况，那么项目的开发和测试都会面临较大的风险。在这种情况下，如果能够及时与产品经理沟通、明确需求，就能够减少风险，否则，项目上线后就会面临更大的稳定性挑战。

2.【架构】系统架构设计维度，思考是否存在风险

3.【编码】开发代码，思考技术是否向前兼容，如果有问题，如何快速发现问题，解决问题

4.【测试】测试边界是否覆盖周全、引流场景是否覆盖周全，比如 Promise 有些场景可能只有大促才有。

5.【上线】上线 doublecheck，配置变更、如果灰度、验证、监控等

6.【验证】业务是否验收完成等

风险识别技术非常的多，包括：信息收集技术（头脑风暴、德尔菲技术、访谈、根本原因分析），假设分析，图解法（因果图、系统或过程流程图），SWOT 分析，专家判断。

集思广益会：针对复杂的场景可集思广益，目的是取得一个详尽的风险清单，可将风险分解结构作为：框架分类汇总，是最常用的风险识别方法。

风险登记册：记录已识别单个项目风险的详细信息，一般团队内部使用。始于风险识别过程，以后的风险管理需要对其更新。包含：已识别的风险清单、潜在风险应对措施、风险跟进人。

三、定性定量风险分析

对识别出的风险进行定性和定量分析，可以帮助团队更准确地评估风险的影响程度和可能性。

四、风险防范

风险防范的目标并不是让风险出现的可能性降到零，这是不切实际的想法，专业的风险防范要做的其实是两件事情。

第一：要将【未知的未知】尽可能转化为【已知的未知】，再将【已知的未知】转化为【已知的已知】，当然这里面要考虑成本问题。比如梳理历史代码逻辑等等。

第二：对于无法防范的风险，做好应急预案，将它的损失维持在最小

根据系统论的原则，一个系统在受到刺激之后会做出响应，如果一个刺激是完全未知的，那系统受到刺激做出的响应就是未知的未知。

越是稳定的系统，刺激和响应之间的关联性就越好，响应所带来的风险也越容易控制。因此要防范风险就要把系统做稳定了，尽量让系统对于各种刺激做出的响应是可预期、有应对方案的。

对于一个不很稳定的系统，最好的做法就是尽量不要给它新的刺激，以免出现意想不到的反应。比如对于一个情绪不稳定你又不了解的人，就不要去刺激他，否则结果就难以控制

五、监督风险

TL 组长要定期对风险进行监督，以确保风险管理措施的有效实施。

例如可以通过每日站会、每周周会了解项目进度和遇到的风险问题；通过持续集成和自动化测试，监控系统的运行状态；通过定期的代码审查和性能测试，确保系统的稳定性。

六、案例实践：

背景：团队最近开发了一个 XXX 需求，牵扯时效内核计算底层变更，原计划 2 人日*3 周开发。

1.风险监督：由于事先知晓该需求存在很多已知已知风险，故每日站会会单独 review 该需求进行风险监督。在过程中发现进度有风险（日常打扰事宜较多、范围评估不准），进行了人员调整投入（从 2 人增加到 3 人）

2.识别风险：研发编写代码后，在编写单测场景中遇到很多特殊场景，不断确认，最终发现改动牵扯范围比预期的广（很多场景影响了其他业务），存在很多 已知未知、未知未知风险。

3.定性定量风险分析：针对特殊场景登记到 PRD 中（类似风险手册），并且备注影响范围等

4.风险防范：

4.1、将【未知的未知】尽可能转化为【已知的未知】，再将【已知的未知】转化为【已知的已知】

经过定性定量风险分析后产品同事牵头、研发、测试一起跟业务反馈风险点。并且弄清楚本次需求背后要解决的问题优先级到底是什么？每个问题影响面多大?是否有其他方案解决？

4.2、应对策略，即满足业务需求又能将风险降低到最少

经过跟业务沟通，本次需求背后需要解决 3 个问题，其中 1 个问题不紧急，业务可人工干预调整，第 2 个问题是上游需要去解决的，核心是第 3 个问题是必须要解决的。针对这找出了核心问题。本次需求只需要覆盖问题 3，经过分析调整，问题 3 改动范围明确并且改动范围小，当场输出排期并且制定上线日期

最终是即满足了业务的最大诉求、研发对改动范围又小、也规避了最大风险、保障了系统稳定性。

思考：

1、隔离:系统 A 业务 和 B 业务 隔离

2：思考需求背后是要解决什么问题？现在方案对系统风险大吗？是否还有方案？最终取舍平衡。

七、总结：

从管理风险维度出发，通过对风险的规划、识别、分析和监督，团队可以有效地管理系统风险，从而提高系统稳定性。

附： 项目管理的风险管理：包含成本风险、进度风险等多维度

参考：

已知风险 VS 未知风险：https://blog.csdn.net/david_520042/article/details/118784646

定性风险分析 VS 定量风险分析：https://blog.csdn.net/david_520042/article/details/118887635

项目风险管理： https://blog.csdn.net/sun_meiko/article/details/127902352