管理系統中風險是系統可用性和可擴充套件性的關鍵

© dylan nolte  

孫子說：是故智者之慮，必雜於利害。

雖然我們經常提到風險管理，但還沒有闡述我們對風險的觀點，以及如何進行風險管理。本文大致涵蓋了在任何的技術或業務決策過程中如何確定和管理風險。風險管理是提高和保持可用性及可擴充套件性的最基本和最重要的方面。

風險管理的重要性

商業在本質上是一種冒險的嘗試。舉一些風險的例子，比如業務經營模式不成立或者過時，產品成本太高或者產品不再受客戶的青睞。在經營中，你必須能夠識別和平衡風險與相關的回報。比如，推出一個新版本，顯然會有風險，但也應該有回報。

大多陣列織監控風險並聚焦在降低風險事故發生的概率。在產品開發生命週期中引入更多的測試是降低風險的典型方法。這種方法的問題是，測試只能減少錯誤或者降低錯誤出現的概率，但是畢竟這還是有限的非零數量。而且需要在長時間裡持續測試，比如儘管衛星軟體已經研發完成，但是仍然不能確保程式碼沒有缺陷。1999年9月23日，美國航空航天局失去了價值1.25億美元的繞火星軌道飛行的衛星，原因是有一個關鍵的航天器計算，洛克希德·馬丁公司的工程團隊使用英制的測量單位，而NASA團隊則使用標準的公制測量單位。為什麼在測試中沒有發現這種不一致的問題呢？正如質量專家所熟知的，答案是：即使是中度複雜程度的系統，要想確保軟體無缺陷，在數學上也是不可能的。

在AKF，我們傾向於把風險看成是一個多元化的產品，如圖所示。我們將風險分為事件發生的概率，以及如果該事件發生會產生什麼樣的影響。事件的概率部分是由在版本釋出中所涉及的變更量和每一個變更所涉及的測試量而所決定的。變更的量越大，事件發生的機率就越高。測試做得越多，事故發生的概率就越低。降低事故概率的主要措施應該包括較小的版本和更有效的測試。

相比之下，事故的影響包括影響範圍（按客戶的百分比計算的使用者影響或交易的百分比）和持續時間。如圖16-1所示，架構決定如故障隔離和X、Y和Z軸分割（所有這些都會在第三部分中討論），將有助於降低影響範圍。有效的監控以及問題和事故管理將有助於縮短持續時間。我們曾經在第一部分涉及這些領域。

如果從本質上看企業都是有風險的，那麼那些成功企業的風險管理難道就是做得好嗎？我們認為，這些公司要麼是風險管理很有效，要麼是迄今為止非常幸運。我們都知道，運氣遲早會耗盡的。

如果只是因為幸運，那麼你現在應該開始擔心了。人們可能爭辯說，風險遵循馬爾可夫特性，這意味著未來的狀態是由現在的狀態決定的，與過去的狀態無關。我們認為，在某種程度上風險是一個累積的過程，也許是呈指數衰減但仍然是不斷增加的。今天的一個危險事件，可能會導致未來的失敗，不是直接相關（例如，今天的變更是未來某個事故產生的原因）就是間接相關（例如，組織對風險容忍度的增加會導致未來更大風險的行為）。無論是哪種方式，行動都可能會帶來近期和長期的後果。

有些人可以自然地感知和管理風險。這些人可能經過多年的技術工作累積了這方面的經驗和技能。也可能有一種與生俱來的感知風險的能力。雖然有這樣的人很好，但是這樣一個人仍然是一個單點故障。因此，我們需要培養組織裡其他的人更好地測量和管理風險。

因為風險管理對可擴充套件性非常重要，我們需要了解風險管理過程的組成和步驟。試圖準確地確定風險的方法有很多，有些比較準確，有些涉及的面比較廣。重要的是為你的組織選擇合適的方法，這意味著要平衡嚴密性和精確性。在對風險進行評估後，必須對急性風險和整體風險積極管理。急性風險是與特定行為相關聯的風險，例如在伺服器上更改配置。整體風險是由於在過去數天、數週甚至數月內發生的所有行動在系統中所累積的風險。

測量風險

管理風險的第一步是要準確地確定某一具體行動所涉及的風險有多大，保持必要的準確性。在這裡為什麼我們要使用“必要”而不是“可能”這個詞？你可以更準確地測量風險，但基於目前產品或組織的當前狀態這可能是不必要的。例如，對一個產品做beta測試，因為客戶預期會有一些小故障，可能決定沒有必要進行復雜的風險評估，粗略的分析就夠了。有許多不同的方法來分析和評估風險。在工具箱中的測量方法越多，就越有可能在最合適的時間、對最合適的活動、用最合適的方法來測試風險。在這裡，我們將涵蓋三種確定風險的方法。對於每種方法，我們將討論其優點、缺點和精度。

第一種方法是直覺法。當相信自己可以感知風險時，人們經常使用這種方法，同時賦予風險管理者做出重要決定的權力。正如我們之前提到的，有些人天生就有這種能力，在組織中有這樣的人肯定是很好的。然而，有兩個非常重要的問題需要提醒你。首先，這個人是否真的有能力在潛意識層面理解風險，或者你只是希望他能做到？換句話說，你是否查證了這個人的準確性？如果沒有的話，在你認為這僅僅就是個猜測之前，你應該去查證。如果有人聲稱可以“感知”風險的水平，讓他或她把預測寫在白板上。這是為了好玩。其次，注意我們事先警告的關於故障的單點。你需要在組織中多幾個人來了解如何評估風險。理想情況下，每個人都熟悉風險的重要性，並掌握現有的評估和管理方法。

薄切片（Thin Slicing）是心理學和哲學中的一個術語，用來描述只根據“薄切片”或狹窄的經驗視窗在事件中發現模式的能力。作者馬爾科姆·格拉德威爾，在《無思維的思維力量》（The Power of Thinking Without Thinking）一書中，認為這種即時決策的過程與經過精心策劃、深思熟慮的決策過程往往一樣好、甚至更好。

課堂上的研究已經表明，專家可以從教師的簡單舉止中，區分出有偏見的教師和公正的教師。此外，法院的研究也表明，法官在審判中的隻言片語可以讓專家們預測法官對審判的期望。

格拉德威爾聲稱專家經常做出快速決策，這往往比經過大量分析的決策更好。有時過多的資訊會干擾判斷的準確性，導致俗話說的“分析癱瘓”。這種在非常有限的資訊基礎上做出決策的能力似乎很理想，格拉德威爾還指出，專家的薄片決策能力可能受個人的喜好、偏見和成見的影響。

風險評估方法的核心優勢在於非常快速。一個真正的專家，如果能從根本上理解某些任務所固有的風險，可以在幾秒鐘內做出決定。正如我們所討論的那樣，直覺方法的缺點包括這個人可能沒有這個能力，因為幾次巧合的成功，被誤以為他可以。另一個缺點是，這種方法很少可以複製。人們往往在行業內工作了許多年，積累和磨鍊了不少經驗，這可不是在一小時的課堂能就完成講授的東西。這種方法的另外一個缺點是，很多的決定取決於一個人一時的衝動，而不是一個團隊或小組集思廣益得出的結論。該方法的準確性是高度可變的，這取決於人、行動和其他因素。本週一個人的風險可能會評估得很好，但下星期可能會徹底地失敗。因此，如果時間是至關重要的，風險是在最壞的情況下和有一個久經考驗的專家，你可以謹慎使用這種方法。

測量風險的第二種方法是交通燈法。在這種方法中，通過將行動分解成最小的元件，並用綠色、黃色或紅色來標明其風險等級。最小的元件可能是應用版本釋出中的一個功能或維護列表中的一個配置變化。粒度取決於幾個因素，由團隊進行這些評估，包括可用時間和演練的次數。下一步我們確定行動的整體或集體風險。為每種顏色分配一個風險值，計算每種顏色的數目，用不同顏色的數目乘以響應的風險值。然後，將計算得到的風險總值除以動作總數。風險評估的結果是最接近得分的顏色。圖16-2個描述了三個功能元件的風險等級，它提供了一個對整體系統版本釋出的累積風險的評估。

對微觀層次元件很熟悉的人應該去評估風險值，併為每個微觀元件標定顏色。標定顏色應根據完成每個元件的任務難度，需要的工作量，元件之間的關聯關係等來分配。圖中展示了一些最常見的屬性及其相關的危險因素，可由工程師或其他專家衡量在某個特定功能或顆粒專案的風險。

交通燈方法的顯著優點是，它使風險評估開始變得有條不紊，這意味著它有可重複性，能夠記錄而且訓練。重複性意味著我們可以根據評估結果來學習和提高。許多人可以進行風險評估，所以你不再依賴於單一個體。再次，因為許多人可以進行評估，可以以組為單位對做出的決策進行討論，他們可以確定某個人的論點是否有優點。這種方法的缺點是，它是過程中的一個額外步驟，比直覺猜想法需要更多的時間。另一個缺點是，它依賴於每個專家來選擇屬性，並用這個屬性去評估每個元件的風險。由於專家之間存在著這種可能的變數，這種風險評估的準確性屬於中等水平。如果專家非常熟悉而且清楚地瞭解特定領域風險屬性的構成，那麼交通燈方法的結果可以相當準確。如果他們在評估的時候，對需要重點檢查哪些屬性沒有清楚的理解和認識，風險水平的評估結果可能會差一些。我們會在下一個風險評估方法的討論中看到這一點，新方法可以解決這種潛在的變動性，使評估的結果更加準確。

評估特定行動風險的第三種方法是故障模式及影響分析法（Failure mode andeffects analysis，FMEA）。這種方法最初是從20世紀40年代末的軍隊中開始使用的。從那時起，它被廣泛應用於包括汽車、製造業、航空航天和軟體開發等許多行業。進行評估的方法類似於交通燈方法，系統被分解成最小的組成部分進行風險評估。對於應用版本釋出，這些組成部分可能是功能、任務或模組。然後為每個組成部分確定一個或多個可能的故障模式。每個故障模式都有相應的效果，描述如果故障發生時的影響情況。

例如，註冊功能的故障有幾種情況，無法把新使用者的資訊適當地儲存到資料庫，為新使用者分配錯誤的許可權或其他的幾種情況。其影響將是使用者無法註冊或能看到沒有經過授權的資料。每個故障的現象可以依據下述三個因素來打分：故障的可能性、嚴重性和可檢測性。我們選擇使用1、3和9作為打分的範圍，這讓我們非常保守，同時可以把高風險因素和中低風險因素區分開來。故障的可能性基本上是這個特定故障真實發生的概率。故障的嚴重性是指如果故障發生，對客戶和業務產生的總體影響。這種影響可以用金錢損失、聲譽損失或任何與業務有關的其他因素來測量。故障的可檢測能力指的是如果故障發生你是否能夠注意到。正如你所能想象的，一個有災難性後果並極有可能發生的故障實際上卻無法檢測，那將是最壞的結果。

對單項失效模式和效果打分後，將這些分數相乘得到總的風險評分，即可能性得分×嚴重性得分×檢測能力得分。這個分數顯示了一個特定元件在整體行為中的整體風險。

FMEA過程的下一步是確定可以執行或落實到位的緩解步驟，以降低特定因素的風險。例如，如果一個功能元件的可檢測能力有非常高的風險分數，這意味著如果事件發生，那將很難發出通知。因此該團隊可能會決定提前準備一些查詢，在產品或服務釋出後，每小時檢查一次資料庫，檢測是否有故障發生的跡象，如丟失資料或資料錯誤。此緩解措施對該元件的風險因素有降低的作用，同時應該說明風險可以降低到什麼程度。

在表中，有兩個人力資源管理系統（HRM）的應用例項：公司客戶的新註冊流程和改用新的信用卡處理器。這些功能有幾種故障模式。讓我們來看看信用卡的支付功能，重點放在信用卡賬單錯誤的故障模式，它的影響是支付時被收取過多或者過少的費用。在我們的例子中，工程師可能會將這個故障的風險設成1分，或者是不太可能發生。也許這個功能經過了深入全面的程式碼審查和質量保證測試，因為它處理的是信用卡，所以風險度較低。工程師覺得這種故障會帶來災難性的影響，所以故障的嚴重性自評為9分。這似乎是合理的，因為錯誤的信用卡賬單會引發客戶的憤怒、昂貴的退款、潛在的退回許可證費用。工程師認為故障檢測難度將是中等，因此故障可檢測能力自評為3分。此故障模式的總風險評分為1×9×3＝27。已經確定了該功能集的補救行動，在beta測試中推出的新支付處理應用僅限於某些客戶使用。因為客戶的影響將是有限的，這樣將減少故障的嚴重性。採取這種補救措施後，因為故障嚴重性降低，風險將降低到3分，修訂後的風險評分僅為9分，大大好於以前。

FMEA風險評估過程很有條理性，這使風險評估能夠長期得以記錄、培訓、評估和改善。另一個優點是精度。特別是隨著時間的推移，團隊在識別故障和準確地評估風險方面可以做得更好，這種方法是最準確的風險確定方式。FMEA方法的缺點是它需要時間和思考。投入到分析中的時間和精力越多，結果就會越好、越準確。這種方法與測試驅動開發非常相似，而且互補。在研發前進行FMEA會提高設計和錯誤的處理水平。

我們將在下一節討論，風險測量的分數，特別是那些利用FMEA方法得到的，可以在系統任意時間間隔或任一應用版本釋出中管理風險的數量。風險評估的下一步是要有人或團隊可以對評估的精度進行評價，對決策提出質疑。這也是採用如FMEA這樣系統化方法的好處：人人都可以通過培訓學會使用，因此可以互查以確保用最高的質量標準進行評估。評估過程的最後一步是在行動後重新評估，看你和專家們在確定合適的故障模式和評估因素時的準確率。如果不可能發現的問題出現了，請專家調查詳細的情況並提供潛在的情況不能被提前發現的原因，警告其他專家注意這種型別的故障。

風險評估步驟

如果你正在計劃使用任何有條理的方法來進行風險評估，下面是適當的風險評估步驟。這些步驟適用於交通燈方法或FMEA方法：

1. 確定合適的粒度級別來評估風險。

2. 選擇一個可以複製的方法。

3. 對將進行風險評估的人進行培訓。

4. 安排事後評審每一個評估，或者集體回顧所有的評估。

5. 選擇一個合適的評分表（例如，1、3、9），並考慮好需要如何保守。

6. 完成程式碼釋出或系統維護後，對故障型別、可能性、嚴重性及可檢測性進行審查。

無論使用的是交通燈方法、FMEA或其他風險評估方法，一定要遵循這些步驟，確保可用於全面風險管理的風險評估的成功。

管理風險

從根本上說，我們相信風險是可以累積的。沒有緩解的風險越大，出現重大問題的可能性就越大。我們教導客戶管理系統的急性和整體風險。急性風險是個別變更或應用版本釋出中組合變更所帶來的風險。整體風險水平代表著在系統中小時、天、周所累積的風險。無論急性或整體風險，都可能會導致危機情況的發生。

急性風險管理通過監控系統變更，如應用版本釋出，來進行風險評估。你可能要提前設定一些限制以控制任何併發行動帶來的風險，比如允許系統在某天的某個特定時段或某些客戶範圍使用系統。例如，你可以決定任何通過FMEA方法計算的風險值大於50的相關單獨行動，必須採取補救措施把風險值降低，或者把這一變更分裂成2個單獨的行動。或者在午夜前，你可能只允許風險值在25以下的行動在系統上發生，任何風險值高於25的行動必須在午夜之後發生。即使這個討論是針對單一行動的急性風險，風險具有累積性，變更事項越多，累積的風險越多，出問題的可能性就越大、越難檢測，出現問題後找出根源也越難。

想象應用版本釋出中有一個功能，其中包含兩個故障模式，與有50個功能的應用版本釋出相比較，每個功能中有兩個或更多的故障模式。首先，在後一種情況下，由於機會很多，所以出現問題的可能性很大。作為一個模擬，考慮在同一時間拋50個硬幣。雖然每個硬幣人頭朝下的概率是獨立的，總的結果中很可能至少有一次出現人頭朝上。其次，如果有50個功能，那麼變更之間相互影響或程式碼以意想不到的方式動到相同的元件、類或方法的可能性更高。因此，無論是從機會累積的角度來看，還是從負面相互作用概率累積的角度看，50個功能與一個功能相比，出現問題的可能性都大大地增加。假設所有功能的複雜度和規模比例相同，兩個故障模式的應用版本釋出後，即使出現問題，也遠比50個功能的釋出更加容易確定根源。

為管理急性風險，我們建議做個圖表，其中列出所有的規則和相應的可以接受的風險水平。這種方式對每個風險級別的行動都是明確的。你也應該建立一個例外的政策，例如，這些規則之外的東西必須經工程部副總裁、運營副總裁或技術長單獨批准。

管理整體風險應該考慮兩個因素。第一個是系統發生變更的累積數量以及與這些變更相關的風險量的相應增加。正如我們在急性風險中討論的，組合的行動可能會產生不必要的相互作用。應用版本釋出越多、資料庫分割越多或配置變更越多，越有可能導致問題的發生，或越可能因為相互作用而產生問題。如果開發團隊一直在開發環境中的一個資料庫上工作，在應用版本釋出前兩天，資料庫被分割成讀寫主機和只讀主機，這很有可能導致在下一個版本釋出時出現問題，除非已經有大量的協調和補救工作完成。

在整體風險分析中應考慮的第二個因素是人為因素。隨著人們從事越來越多高風險的活動，風險承受能力也逐漸上升。當需要適應新環境的時候，這種人為的條件可以很好地發揮作用，但涉及控制系統中的風險時，它可能會使我們迷失方向。如果一隻劍齒虎已經搬到你的附近，適應生活中新風險的能力是生存下去的關鍵，你每天還是要離開洞穴出去打獵，否則只能整天待在山洞裡捱餓。相反，因為你還沒有被吃掉，自我感覺不錯，這會導致嚴重的問題。

我們建議為了管理系統中的整體風險，可以採用如下表所示的一組規則。此表列出了特定時間段按照FMEA所確定的風險量。如果你使用的是FMEA以外的方法，就需要用某些規則和分數範圍來調整風險水平列。例如，不用“低於150點”，而用“少於5綠色或3黃色行動”。在急性風險管理過程中，你需要考慮異議和否決。你應該提前計劃，並建立一個升級過程。一種做法可能是總監對任何風險水平有額外的50點，VP可以給100點，技術長可以給250點，但這些增加並不累積。不管你用什麼方式建立這套規則，最重要的是它對你的組織有意義，並且可以記錄並嚴格遵守。作為另一個例子，假設一個功能釋出需要一個主要的資料庫升級。FMEA的綜合得分是200點，超過了應用版本釋出的最大風險值（表16-3中150點）。技術長可以批准額外的風險，或要求資料庫升級與程式碼釋出分開。

結論

在本文中，我們專注於風險。我們從探索風險管理的目的開始，討論風險管理的構成以及它與可擴充套件性之間的關係。由此得出結論，風險普遍存在於所有的企業，特別是初創公司。在商業世界裡，要取得成功就必須冒些風險。在SaaS世界裡，可擴充套件性是這種風險–回報結構的一個部分。在系統的可擴充套件性方面必須冒險，否則系統會過度建設，而無法交付使企業成功的產品。通過主動的風險管理，提高系統的可用性和可擴充套件性。

雖然評估風險有很多不同的方法，本文對其中三個方法進行了分析。第一種方法是直覺法。不幸的是，雖然有些人天生擅長識別風險，但許多人被認為有這樣的能力，實際上卻沒有。

第二種是交通燈法，把元件的風險評估為低風險（綠色）、中等風險（黃色）和高風險（紅色）。所有元件的組合通過釋出、變更或維護形成整體風險水平。

第三種方法是我們推薦的故障模式及影響分析法。在這種方法中，專家通過識別每個組成部分或者功能可能的故障模式，以及這種故障將導致的直接影響，完成風險評估。例如，信用卡支付功能可能會失敗，這種失敗的表現是向客戶收取太多或太少的金額。根據失敗發生的可能性、嚴重性和發生故障後的檢測能力對這些故障模式和影響打分。這些分數相乘後得到總的風險值。利用該評分，專家們將推薦相應的補救措施減少一個或多個危險因素，從而降低整體的風險。

風險評估完成後，我們必須進行管理。這一步可以分解為管理急性風險和管理整體風險。急性風險針對單一行動，如應用版本釋出或者維護等等，而整體風險針對一段時間，如小時、天或周發生的變更所帶來的風險。對於急性風險和整體風險，我們建議採用規則，預定義每個行動或者每個時間段可以容忍的風險量。此外，準備好應付那些持反對意見的人，應預先建立一個投訴升級的路徑，以避免第一次危機在沒有想清楚，沒有來自各方合適輸入的情況下，陷入混亂。

與大多數的過程一樣，風險評估和風險管理最重要的方面是在特定的時間與組織匹配。隨著組織的成長和成熟，可能需要修改或增加這些過程。如果要使風險管理更有效，就必須使用它。若要使用，該過程就必須與團隊配合良好。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2285473/，如需轉載，請註明出處，否則將追究法律責任。