本文要點
- 軟技術模式是經證實可解決常見問題的個人和人際交互行爲的組合。
- 系統故障幾乎不可能完全避免，但同時每次故障也都帶來了改進的機會。
- “從無意識的故障中學習”模式指導我們在故障事件後改進系統的彈性。
- 該模型有四個獨立的步驟：識別故障、快速解決即時影響、分析根本原因和故障期的系統行爲，最終形成並實現改進思路。
- 召開事件分析會時必須開放、坦誠、不加責備，這樣才能促成藉助故障改進系統彈性。
什麼是軟技術模式？
軟件開發人員需要強大的軟技能以有效地解決我們所面對的許多問題。
Peter F Drucker ，著名的管理教育家，他告訴我們，“做正確的事比正確地做事更重要。”直觀上，這句格言說得很對。對於程序員來說，做一個沒人需要的偉大產品又有什麼價值？
軟技能，包括交流、協作，以及解決問題，界定了我們“做正確的事”的能力。我們的硬（技術）技能只能幫我們“正確地做事”。所以，從有效交付價值這一方面來說，我們的軟技能自然比硬技能更重要了。
自1995年“四人幫”向我們提出“ 設計模式：可複用面向對象軟件的基礎 ”以來，軟件開發人員就已經清楚知名模式的好處了。我們知道，儘管我們所遇到的問題不可能完全一樣，但經常還是能從中找出共同點的。
一旦我們找出這樣的共同點，就能夠把實證有效的解決方案轉換成確定的可複用模式了。這些模式不僅幫我們有效地解決常見硬技能問題，還可以降低我們的決策時間，提升對解決方案的共同理解。
那麼，如果我們可以從解決硬技能問題的模式中獲得收益，能不能也從軟技能問題獲得同樣的收益呢？
在本文中，我們將看一下能幫我們從下述系統故障中促成重大改進的“ 軟技能模式 ”。我們將步入“從無意識的故障中學習”模式。
爲什麼是這個模式？
軟件系統有時就是會出故障，這是無法迴避的現實。這些故障會影響系統的用戶，於是開發人員的首要目標就成了把故障及其影響降到最低。幸運的是，每個故障也都同時帶來了改進系統彈性的機會。
“從無意識的故障中學習”的模式是個四步法，其中先識別無意識的系統故障，儘可能快地解決以降低影響，然後進行分析以確定根本原因，基於分析結果得出改進思路並予以實施。
這個模式看上去說得非常直白，很多人乍一看都覺得平平無奇。然而，只有有效徹底地分析，把改進思路落到實處執行，才能從這種做法獲得實際的收益。這種模式說了一種在系統故障發生後獲得實際系統提升的有效方法。
從無意識中學習的實際案例就在我們身邊。防洪堤、建築物裏的自動噴水滅火系統、保險絲，還有汽車裏的安全氣囊，這些只是人類對之前故障作出迴應的一小部分案例。
什麼是“從無意識的故障中學習”模式
“從無意識的故障中學習”模式描述了一個確保從系統的非預期故障中獲取最大價值的有效方法。爲了這個模式的目的，考慮系統涉及的任何基於軟件的解決方案或產品。
這個模式的靈感是受到了 Matthew Syed 的《黑盒思考》一書的啓發。Syed介紹這本書說：“……它講的是積極自發地研究那些發生故事時常常存在但我們又很少予以開發的經驗教訓”
事實上，說每次系統故障都可以避免純屬事後諸葛亮。然而，故障在所難免，即使做了最大努力的準備，有些故障仍然有可能發生。這個模式幫我們從所有嚴重的故障中獲得有價值的經驗教訓：從未遂故障到已造成嚴重運行中斷。在廣泛關注的故障中通常都會浮現出可顯著改善系統的新思路，用心去發現吧。即使用於未遂故障和一般故障，這個模式也能形成改進思路。這些思路會對系統彈性有很大幫助，只要它們得以落實。
怎麼使用這個模式
讓我們來看看怎麼使用這個模式，一步一步地來。你將發現該模式中的每一步在上文圖表中都已經定義好了。我將重點介紹每一步中最主要的軟技能。
第一步：系統發生故障
這是此模式的切入點。系統以非預期和非最佳的方式運轉。這可能就會導致對系統使用或輸出的負面影響。以下步驟將幫助你解決這個問題，並從長遠出發改善你的系統。
第二步：解決故障導致的即時影響
如果這個故障導致了負面的影響，那麼就應該立即予以解決。“ 破損系統的危機處理 ”模式針對這個行動詳細詳細描述了一個有效方式。需要重點考慮的是確保任何行爲不帶來更糟的影響。
在這一步中，將應用的軟技能包括：冷靜、問題解決技能、風險意識、協作和交流技能。
一旦系統恢復到正常狀態，你就可以前往下一步了。
第三步：分析什麼出現了差錯：根本原因和系統的行爲
在這一步，會用到許多的軟技能。需要執行根本原因分析以理解什麼導致系統出現了故障。需要用邏輯思維和分析思維去理解在故障期系統到底有着怎樣的行爲。使用協作能力發揮更多人的力量。
有許多 理解和實踐 可用於執行根本原因分析。研究系統故障時，經實驗證明有個稱之爲“五個爲什麼”的方法通常比較有效。維基百科爲這個“五個爲什麼”法提供了簡單的示例：
- 汽車打不着火了。（問題）
- 爲什麼？電池不行了。（第一個爲什麼）
- 爲什麼？交流發電機不運轉了。（第二個爲什麼）
- 爲什麼？交流發電機履帶斷了。（第三個爲什麼）
- 爲什麼？交流發電機履帶超過使用壽命後沒有更換。（第四個爲什麼）
- 爲什麼？汽車沒有按照建議的售後日期保養。（第五個爲什麼，根本原因出現）
“五個爲什麼”確保充分深入地研究，以找出實際的根本原因，而不只是浮在表面上的影響。修改這些影響是很有必要的，但是解決根本原因能得到更多的好處。在上例中，我們應更換交流發電機的履帶，而不應該只解決這個具體的問題。修正根本原因，按期保養，會得到更多的好處。
找出根本原因能避免同樣的故障再次發生。在故障發生時，把系統行爲徹底想清楚可能會得到更多的益處。根本原因讓你的系統按反常的方式來運轉。修正根本原因也就掐死了進入這種反常方式的入口。分析反常方式本身經常爲帶來額外的改進機會，比根本原因覆蓋更多的可能性。
爲了理解故障發生時分析系統行爲時可能帶來的好處，讓我們假設正在森林遠足。因爲我們不瞭解這一區域，所以得依賴些路標。不久，我們到了一個路口，它的路標牌倒在地上。我們不清楚該往哪裏走了。現在，我們就處於了反常方式，做些什麼呢？根本原因很清楚，那就是路標倒了，但我們的行爲將決定其影響。如果我們選擇了錯誤的道路，或者驚慌尖叫着到處亂跑，可能就想回到原路了，認爲“回到之前的路上可能會更好”。我們得到的經驗，不是出自於根本原因，而是出自於對行爲的分析。
第四步：在經驗總結的基礎上進行改進
在上一步，你找出了故障的根本原因，對故障發生時的系統行爲有充分的瞭解。在這一步，你將使用這一新的經驗去形成改進思路，決擇實現其中的哪些思路。最後的環節將是試驗並度量改進思路的效果。
形成思路
在許多情況下，根本原因和系統行爲會帶來明顯的改進思路。繼續延伸上一步中提到的汽車的那個例子，通過分析清晰可見，除了替換履帶之外，我們還需要按時進行保養。
通過定義故障期間希望系統採取什麼行爲，也可以形成改進思路。有這麼一個例子，對一次系統故障進行原因分析，得出結論是因爲你僅有的服務器上的硬盤驅動器壞了。在這種情況下你可以發現，如果有第二臺“熱”服務器在跑的話，故障帶來的影響將得到極大地降低。
形成的思路不應侷限於實體的系統，也就是運行中的代碼。改進系統被使用的方式，以及分析系統故障時識別易界定故障的能力。
思路的形成應具有創新性和“遠大夢想”。要了解一些約束，如成本、時間、所需的技能等，但不能被其束縛。
選擇要實現的思路
選擇要實施的思路時，你可以最終選擇一個、一些或所有思路，也可以一個都不選。選擇要實現哪個思路時，需要做三個主觀測驗：
- 其預期收益是否會高於預期的成本？
- 你相信這個思路可以得到有效地實現嗎？
- 有高級管理者支持這個思路，可以爲也這個思路的實現清除障礙的嗎？
如果任意一個測驗回覆爲否，那麼就應該放棄這個思路。至於尚存的思路，還要通過一項最終測驗：你們有資源實現所有這些的思路嗎？如果沒有，就使用競爭分析敲定最終的選擇。
實現選擇的思路
只有實現了思路所描述的預期變化，才能從思路中得到價值。在真正實現之前，思路只是組織的成本而非收益。就像買了本從未閱讀的書一樣。
按這個模式來做，選中的只是那些有最大可能實現的思路。通常，最難的一步就是邁出第一步。就像書架上那些你還未閱讀的書一樣，翻開第一頁看起來總是那樣艱難。果斷開始動手吧。如果你們遇到障礙，就請支持這個思路的高級管理者去解決它們。
度量和檢驗取得的價值
有效的開發過程會不斷地評估是否正在實現預期價值，並有針對性地調整整個過程。從改進思路中實現價值也沒有什麼不同。定期重新評估這三項測驗：這個思路仍然具有收益、價值和支持者嗎？隨機應變，如有必要，也可以放棄它。
當一個思路已經實現時，就該評估取得的收益了。有兩種評估方法可以用於評估和檢驗。
儘可能客觀地比較相關度量值的前後變化。以量化數據比較清楚地展示這一變化帶來的價值。比如這樣的一個度量，“在這個變化之前，系統可以處理10個併發事務。而現在，它可以處理100個併發了。”
量化度量也不是總有效。也可以通過測試一個特定的場景來證明價值。例如：“以前，錯誤通常是由第一個受到影響的用戶發現的，這往往會帶來投訴。改變之後，所有系統錯誤都由系統來捕獲，並立即自動地把短信發給支持團隊。這就有機會在影響到用戶之前就予以修復了。”
結果1：改進系統彈性
遵循這一模式得到的主要結果是現在系統比故障發生前更有彈性了。按照這一模式中的步驟來做，應可以幫助你找到改進思路，選擇最有收益的那一個，並通過實現它們得到價值。至少，系統再次遇到相同的問題時能有更好的結果。當然，獲取的價值依賴於實現思路的數量和效力。
結果2：更充分地理解系統
這一模式的步驟需要你深入理解你的系統在正常和非正常情況下的行爲。這個過程涉及到了許多的人，所以理解不僅要更加深入，還得更加廣泛。更充分地理解很可能對下一步增強系統和改善過程產生積極影響。更好地理解系統，能讓你可以更好地控制它。
結果3：更有效的響應故障的文化
正如我們看到的，積極坦誠地處理故障能對系統帶來重大改進。此外，如果組織有隱瞞故障的文化，大家爲了怕受到責備而拒絕承認或找藉口，那麼就錯失了學習的機會。失敗驅動過程的重複模式將消除恐懼，讓大家更加坦誠，推動繼續前進。當然，坦誠的文化比推卸責任的文化能讓人更加愉快地工作。
行動的模式
注意：本故事及其人物純屬虛構（除了我）。
我的手機在1點24分響了：那隻意味着一件事。“Kevin，生產系統宕了——什麼都不工作了！新加坡的用戶非常生氣。你們改過什麼？”我們的支持團隊領導慌亂地叫着。“早上好，ED…”，我儘量條理清晰、冷靜地回覆他，“…你看能否和Fiona一起開個電話會議，給我5分鐘。我們看看問題出在哪裏。”
我（Kevin，倫敦研發經理）、ED（紐約，支持領導）和Fiona（新加坡研發經理）召開了一個電話會議。在其他人的幫助下，花了大約4個小時搞明白什麼出了差錯，然後把系統回退了一個版本。我們遵循“破損系統的危機處理”模式，將保留這四個小時的細節。這個“從無意識的故障中學習”的模式主要關注危機解除和系統恢復正常之後發生了什麼。
不久之後，系統被修復了，Ed和我收到Gail的郵件，她是新加坡銷售團隊的領導，我們系統的一位主要用戶。郵件中說：
“新銷售系統無法使用了，這是最近兩個月裏第15次了。怎麼沒測試過新的數據？我正在親自做事件分析，一個小時了。打電話給每個與此相關的人。馬上！”
我知道要發生什麼了。很明顯，Gail對已經對發生了什麼事和誰應該捱罵已經有了判斷。那一刻，我都忍不住想按她說的去做了，畢竟，她發火的主要目標並不是我。Hardeep是這次變更的開發人員。他幫我們發現並解決了問題。但是，他解釋不了爲什麼在他執行的大量測試中沒暴露出來。
我拿起電話小心謹慎地打給Gail。我清楚我必須做正確的事，即使要冒招致負面責備的風險。“嗨，GAIL。對於這次分析會，我只想先簡單地聊一聊。我們可以把它推遲24小時嗎？在我們修復這個問題的同時，我發現了有些東西看起來有些不太對。它們可能解釋了爲什麼Hardeep那麼確信他適當地測試了變更。”Gail聽起來很激動，回覆道，“真的？好吧。我現在有很多事得解決。明天，不能再晚了。必須做到。銷售系統宕掉了我們還怎麼賣東西呢？”
我們的銷售系統從許多來源接收數據。Hardeep開發的變更增加了一些新的字段到已有的營銷數據的輸入提要中（一個純文本文件）。該輸入提要是我們系統的關鍵，流程的其餘部分都依賴這個數據。
根本原因分析確定了發生的問題，因爲更新的數據提要中首次包含了一些以科學符號表示的值（就像1.5E-5）。我們的生產系統因爲“E”這個字符沒把這些值看作數字，於是就報了錯。在大量的測試期間沒發現它，因爲測試環境使用的數據與生產環境差異很大。在測試環境使用科學符號表示的值沒出現問題。
我草繪了一張圖，展示了變更之後正常的系統流程和實際做出的行爲，以便會議期間使用。
在故障期對系統行爲的研究得到了一些驚人的發現。首先，我們發現不良數據導致的這個錯誤沒有被拋出，一直都到了整個過程非常靠後的階段。因爲數據是以非結構化方式存儲的，所以數據加載過程並沒受到影響。發現不良數據太晚了，也就是說沒時間去修正它。第二，很明顯整個系統依賴於這些數據。沒有它系統就沒法用。它不僅僅包括營銷數據，還有很多其他數據。
Ed在第二天主持了這個分析會。我們花了兩個小時過了一下所有的細節。爲使再次發生同一事件時能有更好的系統行爲，我們給這張草圖加了點變化。第一個變化是會立即捕獲到異常並通知數據提供者。第二個變化是，如果他們不能在臨界時間發送正確的數據，就讓我們能夠複用最近的好數據。有這兩個變化，再次出現這個問題的影響就微不足道了，銷售系統仍然可以使用。
會上對故障相關內容進行了總結記錄，作爲本次會議的結束，內容包括一條根本原因和一個解決措施列表。每個人都同意這些措施是我們當前優先級最高的事，比下一批要開發的特性更加重要。Hardeep很高興有機會向大家展示他費盡心血執行過的測試。甚至Fiona也對結果非常滿意。在分析會結束時她提到“感謝每個人對此做出的如此認真的付出。我發現這不像我之前所想的那樣，僅僅是因爲懶惰造成的宕機。我有信心，這些措施能帶來很大的變化。大家動起手來，實現它吧。”
故障總結
“九月九日在銷售系統上做了一個變更，打算將四個新的字段添加到營銷數據提要中。這次變更無意地修改了一些已有字段以科學記數法發送的值。這些非預期值被系統當成非數字來處理了。在日常批處理中試圖讀取這些值時沒有拋出異常。但後續流程步驟卻由於這些錯誤無法啓動。因爲日常批處理失敗，銷售系統就無法使用了。”
根本原因
“發生故障的原因是因爲測試環境不太完備。因爲測試和生產環境的差異，未在測試期間發現數據類型的問題”。
解決措施
- 環境：確保測試環境與生產環境一致，盡最大可能提升測試效力
- 數據質量：爲所有數據提要加載過程增加一個校驗，確保所有的值都符合預期的數據類型。發現任何不匹配時發送警告，予以緊急處理。
- 批處理依賴：修改日常批處理，如果新的數據不能及時有效，則複用前一天的數據。必要時採用舊數據總要強過無系統可用。
反模式：要避免的陷阱
在本例中，遵循該模式確保了一些良好的系統改進得以實現。在制定決策中使用該模式時，有幾件重要的事應特別注意。
我們不犯錯
我們趕緊制止這個神話吧。人人都會犯錯，如果你是一名開發人員，犯的錯就可能導致系統發生故障。關鍵是從錯誤中總結教訓，不重複犯同樣的錯誤。你所能做的，就是接受錯誤並採取措施。
學習之後不見行動
我經常見到這種反模式。首先是對危機的恐慌。然後是對解決方案興奮不已。盲目樂觀。以及最後一點：行動無優先級。直到下一次出現危機，由同樣的問題導致的。以同樣的措施進行修復。不言而喻，只有你真的行動起來這些偉大的措施才能真正幫到你。把它們丟在待辦事項中什麼用也沒有。
得出不成熟的結論
對故障原因很容易就會做出一個過早的判斷。這很難避免，所以給你個建議，先不要把這個判斷與別人分享，直至實際上真的搞清楚了。公開發布過早的觀點，經常會導致兩種有害的影響。首先，人爲帶動其他人持有同樣的觀點。甚至它完全就是錯的，公開聲明觀點也會讓人當真，而有時它其實與事實相反。在 玩計劃撲克 時，如果有人提前些打出了牌，會不會影響到你的選擇呢？第二點， 認知失調理論 告訴我們，一旦我們把觀點告訴其他人，再去改變這個觀點的個人犧牲會非常大，以至於會讓我們閉上眼不願去看任何有矛盾的證據。在我們的例子中，把分析會推遲了24個小時，讓每個人在分享觀點和下結論前有機會去收集事實依據。如果直接開會，很可能根本就得不出有價值的結論。
責備與自保
事實上，所有有價值的經驗都來自於導致出錯的故障。其實它基本與涉及到的人沒有關係。當然，也有極個別過失或故意造成損害的情況。在這種情況下，就應該對個人採取相應的措施了。開始陳述你的事實觀點時，評估一下是否存在過失或故意的情況。將精力集中在出錯的東西和如何做出改變以避免其再次發生上。在流行責備的文化中，個體將回避深入研究故障，以求自保，若不這麼做就會因爲無法避免的錯誤受到責罰。這兩種情況會使組織越來越軟弱，從失敗中學習的機會也就喪失了。
我們光忙着分析了。
你做過事後分析嗎？如何沒有，打算如何從這些故障中總結經驗教訓呢？是的，有效的分析得花時間，但是這幾個小時就能發現系統的重大改進。不要在錯誤的方向上衝刺，在正確的方向上慢跑，你將更快到達終點。
簡單化和從經驗中吸取教訓
軟技能模式歸根結底是通過從經驗中吸取教訓以找辦法讓工作更簡單。我們自己的經驗，和其他人的經驗。將事情簡單化使我們的工作和生活更有效率，並幫我們不斷“做正確的事”。
我們可以使用模式去解決與軟技能（交流、協作、問題解決）的問題，就像我們使用它們去解決硬技能問題一樣。
考慮一下軟技能模式的潛在價值，嘗試一下“從無意識的失敗中學習”模式。我希望，如果你發現它對你有用，你也可以考慮嘗試一下其他的模式。