如何管理風險？
- 編輯：admin -我們從根本上認為，風險是累積而來的。當你執(zhí)行了多個有風險的行動，或者進行了許多有風險的變更時，終究會到達一點，這時風險會變成現(xiàn)實，系統(tǒng)將出現(xiàn)問題。我們在 AKF Partnersl的做法是教會我們的客戶管理系統(tǒng)中的緊急風險和整體風險。所謂緊急風險，就是一個變更或者一次發(fā)布中的一組變更帶來的風險。整體風險來自于經年累月對系統(tǒng)執(zhí)行有風險的行動累積起來的風險。無論哪種類型的風險，都會給系統(tǒng)帶來危機。我們將討論如何管理這兩種類型的風險，以確保你對在某個時間點應該允許在系統(tǒng)中做什么以及
我們從根本上認為，風險是累積而來的。當你執(zhí)行了多個有風險的行動，或者進行了許多有風險的變更時，終究會到達一點，這時風險會變成現(xiàn)實，系統(tǒng)將出現(xiàn)問題。我們在 AKF Partnersl的做法是教會我們的客戶管理系統(tǒng)中的緊急風險和整體風險。所謂緊急風險，就是一個變更或者一次發(fā)布中的一組變更帶來的風險。整體風險來自于經年累月對系統(tǒng)執(zhí)行有風險的行動累積起來的風險。無論哪種類型的風險，都會給系統(tǒng)帶來危機。我們將討論如何管理這兩種類型的風險，以確保你對在某個時間點應該允許在系統(tǒng)中做什么以及不應該做什么能夠做出正確的決策。
通過監(jiān)控對系統(tǒng)計劃的變更(如發(fā)布)所做的風險評估，可以管理緊急風險。你也許想預先對能夠并發(fā)執(zhí)行的行動的風險大小設立一定的限制，或者想對一天的某個特定時間段或有一定客戶量的時間段所允許的風險大小設立一定限制。例如，你可以決定任何風險評分大于50(通過FMEA法計算得出)的行動，都必須通過補救措施把風險降低到50以下，或者拆分成兩個單獨的行動?；蛘?，你可能要求在午夜之前，只能對系統(tǒng)執(zhí)行風險評分低于25的行動，任何高于這個評分的行動，都要在午夜之后執(zhí)行。即使這里討論的只是一個行動的緊急風險，但這種風險也是具有累積性的，因為一個行動的風險中包含的具有風險的項目越多，發(fā)生問題的可能性就越大，而由于被改變的東西太多，發(fā)現(xiàn)問題或者判斷根本原因的難度也就越大。
作為一個思想實驗，不妨考慮兩種發(fā)布版本，一種只發(fā)布一個功能，該功能識別出的故障模式有兩種，另一種要發(fā)布50個功能，每個功能識別出的故障模式有兩種或多種。首先，由于出故障的機會多，所以后者更可能發(fā)生問題。打個比喻，同時拋50個硬幣。雖然每個硬幣頭像朝上的可能性是獨立的，但在整體結果中，你很可能至少有一個是頭像朝上的。其次，因為有50個功能，那么變更彼此互相影響或者以預料之外的方式改變同一個組件、類或方法的可能性就很高。因此，無論從累積的出故障機會還是從累積的負面交互的可能性來看，這都會增加發(fā)生問題的可能性。如果儆了這些發(fā)布后，出現(xiàn)了問題，假設所有功能的復雜性和規(guī)模差別不是很大，那么當發(fā)布的版本中只有一個功能時，確定問題的起因會比版本中包含50個問題要容易得多。
要管理緊急風險，列出所有的規(guī)則和可接受的風險水平。這樣做清楚明確。此外，你還應該確定一個例外策略，對于這些規(guī)則以外的情況，必須由軟件開發(fā)團隊的VP和運營團隊的VP批準，或者由CTO批準。
以及每個變更相應帶來的風險大小。就像我們在討論緊急風險時提到的，聯(lián)合的行動會造成負作 對于管理整體風險，有兩個因素可能引發(fā)問題。第一個因素是系統(tǒng)中已經發(fā)生的變更的總量，用。發(fā)布的版本越多，拆分數(shù)據(jù)庫的操作越多，或者配置的變更越多，那么某個行動引發(fā)問題的可能性就越大，或者它們之間的相互作用引發(fā)問題的可能性就越大。如果開發(fā)團隊是在只有一個數(shù)據(jù)庫的開發(fā)環(huán)境中進行開發(fā)的，在發(fā)布這個數(shù)據(jù)庫之前的兩天，才把它拆分成主數(shù)據(jù)庫和只讀副本，那么除非做了無數(shù)的協(xié)調和補救工作，否則下一次發(fā)布很可能會出問題。
在分析整體風險時，要考慮的第二個因素是人的因素。隨著人們執(zhí)行的行動的風險越來越高，他們能夠容忍風險的水平也會提高。當我們需要適應新環(huán)境時，這種自我調節(jié)功能很有用，但當要控制系統(tǒng)風險時，它則會讓我們誤入歧途。如果你的附近已經出現(xiàn)劍齒虎了，而你仍然不得不每天離開自己的洞穴去打獵，那么適應生活中這一新風險的能力對你存活下來至關重要。否則的話，你就只能整天待著自己的洞穴中，忍饑挨餓。但在生產環(huán)境中推送越來越多的變更，只是因為你還沒有遭殃，你就覺得自己是所向無敵的，這樣只會造成嚴重的問題。
特定時間段中建議APP開發(fā)的風險大小，風險的評分是通過FMEA方法計算出來的。如果你用的不是FMEA法，可能需要調整一下風險水平這一列的值，使它對你有意義，例如你可以用<5個綠色或3個黃色的行動來代替<150分。和緊急風險管理流程一樣，你需要考慮異議和反對意見。你應該預先規(guī)劃好，設立一個升級流程。一個思路是，對于任何風險水平，執(zhí)行主管可以額外增加50分，VP可以增加100分，CTO可以增加250分，但不能累計。無論你決定采用哪種方式建立這套規(guī)則，最重要的是，它要對你的組織是有意義的，而且它已經被記錄在文檔中，你的組織會嚴格遵守這套規(guī)則。