背景：

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

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

一、风险概念

分类	已知风险	未知风险
概念	包括已知的已知、已知的未知	未知的未知
共性	▣ 已知风险和未知风险都是不确定性事件，本质上都具备风险的四个要素，即：事件、原因、概率和后果 ▣ 两类风险一旦发生，都需要执行应急措施来处理，相关费用最终都应计入到项目成本中。
联系	▣曾经的未知风险一旦发生后，就变成今后的已知风险。▣ 对已知风险的应对，可能带来次生的未知风险。

已知风险 VS 未知风险

区别	已知已知风险	已知未知风险	未知未知风险
风险事件	已识别出	已识别出	未识别出
风险原因、概率、后果	清楚	不完全清楚	完全不清楚
应对策略	规避/解决	主动承受	被动承受
应对计划	可规划	无法清晰规划	不可规划

二、规划及识别风险

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

【需求】需求不明确或不完整是一大风险因素。如果产品经理的需求文档存在不明确或不完整的情况，那么项目的开发和测试都会面临较大的风险。在这种情况下，如果能够及时与产品经理沟通、明确需求，就能够减少风险，否则，项目上线后就会面临更大的稳定性挑战。
【架构】系统架构设计维度，思考是否存在风险
【编码】开发代码，思考技术是否向前兼容，如果有问题，如何快速发现问题，解决问题
【测试】测试边界是否覆盖周全、引流场景是否覆盖周全，比如Promise有些场景可能只有大促才有。
【上线】上线doublecheck，配置变更、如果灰度、验证、监控等
【验证】业务是否验收完成等

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

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

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

三、定性定量风险分析

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

分类	定性风险分析	定量风险分析
概念	定性风险分析是对已经识别出的每一个风险进行主观分析，判断各风险发生的可能性和后果，并通过综合考虑可能性和后果来确定各风险的严重性，对各风险进行初步排序。定性分析的结果要写入风险登记册，例如风险的可能性和后果、风险级别、风险排序、紧急风险、需进一步定量分析的风险、只需待观察的风险、风险归类。	定量风险分析是对被定性分析确认为严重而且又可量化分析的风险的客观分析。定量分析的结果要写入风险登记册。
共性	▣ 都是风险管理知识领域的项目管理过程，都要用“专家判断”这个工具与技术。 ▣ 都要根据风险管理计划中的相关规定进行。 ▣ 定量风险分析要用到数字，定性风险分析也有可能要用到数字。例如：在定性分析中，可以用数字表示风险的可能性和后果；定性风险分析的工具“风险概率和影响矩阵”可以是由数字组成的。 ▣ 要根据定性分析和定量分析的结果来制定风险应对策略和措施。
联系	▣ 定性分析的结果是定量分析的基础。
区别	▣ 对已识别的每一个风险都要做定性分析，但不是对每一个风险都要做定量分析。许多风险，可在定性分析之后，跳过定量分析，直接进入规划风险应对过程。 ▣ 定性分析是主观的分析，即：不同的人很可能会得出不同的分析结果。定量分析是客观的分析，即：只要所依据的数据是一样的，不同的人会得到相同的分析结果。 ▣ 定性分析，作为主观分析，灵活性较大。定量分析，作为客观分析，灵活性较小。在定量分析中，必须采用一些硬性的分析技术，如决策树、敏感性分析、蒙特卡洛模似

四、风险防范

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

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

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

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

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

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

五、监督风险

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

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

六、案例实践：

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

风险监督：由于事先知晓该需求存在很多已知已知风险，故每日站会会单独review该需求进行风险监督。在过程中发现进度有风险（日常打扰事宜较多、范围评估不准），进行了人员调整投入（从2人增加到3人）
识别风险：研发编写代码后，在编写单测场景中遇到很多特殊场景，不断确认，最终发现改动牵扯范围比预期的广（很多场景影响了其他业务），存在很多已知未知、未知未知风险。
定性定量风险分析：针对特殊场景登记到PRD中（类似风险手册），并且备注影响范围等
风险防范：

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

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

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

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

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

思考：

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

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