【穩定性】從專案風險管理角度探討系統穩定性

背景：

在軟體開發過程中，系統穩定性是一個重要的考量因素。它直接影響到軟體的效能、可靠性和使用者體驗。然而，由於各種原因，如需求迭代、架構升級、配置變更、人力變動、系統不熟悉等，系統穩定性可能會受到影響。一直想寫一篇風險管理的文章，想著從專案管理的風險維度出發，對系統穩定性進行有效的風險管理，來保證系統穩定性。



文章中會出現一些專案管理知識的專業術語，先來個日常生活中上班堵車風險的案例對 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