我以前很崇拜那些能修復各種軟件缺陷的“救火”高手。很多年前，我還是一個維護遺留系統的團隊的普通開發人員。那時，團隊的每個開發人員，都輪流帶一個7x24小時開機的手機，處理用戶問題。團隊里有一位英雄。他戴眼鏡，經常身穿一件白大褂。我們要是有搞不定的生產事故的各種疑難雜癥，就會找他。

[[440921]]

只有他能搞定我們這些普通開發人員搞不定的問題。所以過去了十多年，我依然很佩服他，覺得他是英雄。但當我后來讀了《第五項修煉》中描述的“負擔轉移”系統基本模式后，醒悟到團隊有這樣的“英雄”，看起來值得“慶幸”，但會帶來一個意想不到的后果——團隊不再想花時間和精力，提升普通開發人員解決生產事故的能力，因為“英雄”出馬，以一當十。當年團隊所維護的遺留系統火情不斷，但我們這些普通水平的開發人員，一直救不了火。

真英雄，要么能賦能團隊成員，提升他們處理生產事故的“救火”的能力，而不僅僅靠他一人；要么能把需要半夜爬起來搶修的生產事故，化解成一個個小任務，在白天上班時間給解決了。

有人會問，作為開發人員，如何才能把生產事故化解成一個個小任務呢?

首先，可以在自己日常開發新代碼，或解決軟件缺陷時，時時思考面前的代碼，是否出現了以下分布式計算的8個謬誤：

1. 網絡是可靠的
2. 延遲為零
3. 帶寬無限大
4. 網絡很安全
5. 網絡拓撲不會改變
6. 只有一名網管
7. 傳輸成本為零
8. 網絡是同質的

比如你發現要修改的代碼，存在“網絡是可靠的”這樣的謬誤，接下來就可以借助“復雜系統穩定性的12個反模式”(每個反模式的詳細描述，參見《發布!》第2版第4章)列表，來思考哪里會存在“暗債”。

1. 集成點
2. 同層連累反應
3. 層疊失效
4. 用戶
5. 線程阻塞
6. 自黑式攻擊
7. 放大效應
8. 失衡的系統容量
9. 一窩蜂
10. 做出誤判的機器
11. 緩慢的響應
12. 無限長的結果集

將思考產生的所有“暗債”集中起來，并按照“暗債”爆發的“影響度”和“可能性”這兩個維度，把這些“暗債”進行排序，然后選擇其中“影響度”最高且“可能性”最大的一個“暗債”，優先處理。

假如你發現代碼中存在一個“集成點”的“暗債”需要優先處理，那么就可以借助下面“復雜系統穩定性的12個模式”(每個模式的詳細描述，參見《發布!》第2版第5章)列表，來尋找償還“暗債”的思路。

1. 超時
2. 斷路器
3. 艙壁
4. 穩態
5. 快速失敗
6. 任其崩潰并替換
7. 握手
8. 考驗機
9. 中間件解耦
10. 卸下負載
11. 背壓機制
12. 調速器

比如上面那個“集成點”的“暗債”，可以使用“快速失敗”的思路來解決，那么就可以根據修復工作量的大小，要么順手修復，要么將其加入迭代開發待辦列表中，納入日常開發活動中。如果每位開發人員都能在日常開發過程中，持續進行如上的思考，那么就能在白天上班時，將生產事故的相關“暗債”，逐一解決，讓自己能睡個好覺。

當然你可以把上面那套方法及其成效，分享給你的隊友。但更有效的方法，是設法影響你的技術領導，請他參考2021年6月中文版新上市的《混沌工程》關注與該書同名的這一新實踐。

早在2008年，Netflix公司在把數據中心遷往亞馬遜云平臺的時候，踩了一個大坑，經常會出現生產事故。為了能在白天上班時間解決生產環境的事故，而不是半夜爬起來解決，他們摸索出一套行之有效的方法——混沌工程。

該如何做混沌工程?

借鑒Netflix的實例，可以從“擺正心態、人員主動和試點業務”三方面入手，來啟動混沌工程。

擺正心態

承認暗債為復雜系統所固有，而不是一味要求工程師“不能也不該出現失誤”。否則在故障面前，大家就只會花大量時間相互甩鍋，而忽視了提升團隊發現更多暗債和快速修復生產故障的能力。

人員主動

根據Ashby的必要多樣性法則(用于控制系統B的系統A，需要和系統B同樣復雜)，要建立對系統能夠承受生產環境的動蕩的信心，需要針對生產環境“豐富多彩”的暗債，設計同樣“豐富多彩”的防范手段。而技術骨干一個人，是發現不了那么多暗債，并找到那么多的防范手段的。所以，就需要發揮各位工程師的主動性。此時，領導者要創造能調動工程師主動性和創造性的企業文化，來促進工程師更安全地發現與修復更多“花樣”的暗債。在修復暗債的過程中，就可以使用上述8大謬誤、反模式和模式列表。

試點業務

• 選擇一個出現生產事故頻率較高的業務系統，嘗試混沌工程。因為事故的反復，出現會讓發現與解決暗債的動力更大

• 基于能反映用戶體驗的業務穩態行為建立假設，而不是先聚焦于在系統內尋找弱點。因為這樣能更利于進行全局優化，讓成效更大

• 為了讓暗債浮現出來，設計引入足夠多樣化的現實世界可能發生的事件，而不是設計那些易于生成但在現實中不大可能出現的事件，以便切中要害。針對每一個所引入的事件，參考上述模式列表，來進行穩定性設計

• 可以先從準生產環境入手進行混沌實驗，等條件成熟后，再逐漸過渡到生產環境

• 自動化地持續進行混沌實驗，以起到回歸實驗的效果，持續發現并解決暗債，避免系統隨著時間的推移，在韌性方面逐漸“掉隊”

• 設計更安全的實驗方式，以最小化爆炸半徑，讓實驗所導致的業務損失降到最低，而不是明知故障難以控制，還要貿然進行實驗。如果實驗的假設被證偽，那么就遇到了發現新的暗債的好機會。在尋找暗債的過程中，可以參考上述反模式列表，來啟發尋找漏洞及修復

總結一下，真英雄最終都不會在半夜里爬起來搶修生產事故，因為他們會聰明地使用分布式系統穩定性設計，以及混沌工程，避免將自己陷入如此凄慘的境地。

作為一名開發人員，如何能讓自己能逐漸減少在半夜爬起來搶修生產事故的次數?可以嘗試使用本文要介紹的8個謬誤、12個反模式和12個模式。

如何讓隊友不會半夜把你喊起來幫著搶修生產事故?影響領導，嘗試使用混沌工程，來讓團隊成員都在上班時間，主動發現并修復分布式系統的漏洞，逐漸減少夜里喊你的次數。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文