【譯】混沌工程與區塊鏈

作者 Vipin Bharathan
原文：https://medium.com/@vipinsun/chaos-engineering-the-blockchain-51e60ae74d27

第一部分. 應用混沌工程理論到區塊鏈框架。

混沌與工程兩個字是沒有什麼關係的。在這篇文章，我們會探索下為什麼他們會組合在一起並且應用在區塊鏈上。第二部分我們會看到混沌工程在Hyperledger Indy的實現。我們用一個工業界不常見的縮寫，混沌實驗框架(chaos experimentation framework(CEF))。在這篇文章裡為了使用方便，我們使用這種縮寫形式。

這是一個使用微服務組成巨型可伸縮分散式系統的時代。Netflix,Linked-In,Medium,Amazon,Microsoft Azure,Uber,AirBnb等。沒有一個人甚至整個架構和程式設計師團隊的腦子中可以容納這個分散式系統的複雜架構。這種系統的靜態配置也包括在不同硬體或雲端上執行的多種服務，通過網路的多種SLA和執行在許多邊緣裝置的使用者介面相連線。由於這種靜態的複雜性，這種系統的實時行為引入了在不可信網路系統元件上來自使用者與程式上獨立輸入的層次。

這些元件可能崩潰，降級，或行為異常。惡意使用者到處都是。同樣在這個時代，混沌工程上出現了，最初作為一種粗略測量此種系統的方法；通過實踐變成一種哲學，通過會議,工具和廣泛傳播得到接受。

你可以抗議混沌環境在像Bitcoin與Ethereum這種許可權不足的公共區塊鏈網路上是否存在。他們已經不知不覺中被混沌捲入了。節點在網路中加入或重加入，惡意攻擊者持續的探測系統，網路中斷。混沌與混沌工程有一個不同。混沌工程，繼承了混沌字面上的意思，其實是使用實驗資料來發現系統弱點的一種工程手段。

開始我們使用混沌工程的一些基本原則設定場景，就像存在在分散式系統的應用中一樣。有一個混沌工程的開源倉庫叫chaos tookit。chaos toolkit是開源的，其使用open API來生成混沌工程的互動步驟來描述實驗。工具可以使用open API來擴充套件而且在Kubernetes,AWS,Azure上已經有驅動存在了。它也可以被用來在持續整合和構建時自動化混沌工程。

我們調研了開源chaos toolkit並瞭解這些實驗是如何在這個系列的第二篇文章Hyperledger Indy被適配的。希望這可以鼓舞人們可以更瞭解自己的DLT平臺並建立一個成熟的混沌實驗套裝來加固他們自己的平臺。

歷史

從2008年，當Netflix開始將他們的伺服器從資料中心移到雲端，他們的工程師實踐了一些在生產環境進行類似彈性測試的活動。在之後這些被稱之為混沌工程。Chaos Monkey開始被使用，大家知道它是用來在生產環境將服務關掉的工具。混沌原則開始進入正式規範。Netflix 混沌自動化平臺在微服務生產環境7*24小時執行混沌實驗。

這些紀律作為混沌工程的關注點，有些資料清單可以看看。O’Reilly出版了一本很棒的關於混沌工程的免費書。由於O’Relly需要註冊一下才能得到下載連結。我們很感謝在很多企業裡實踐混沌工程的作者。名字是“混沌工程：通過實驗建立對系統行為的信心”。

混沌工程實踐

要定位分散式系統中的弱點，混沌工程可以被視為通過建立和執行實驗來發現系統的弱點。發現的弱點可以被記錄為系統的約束。關於弱點的證據可以被檢查並被實驗重複執行。

第一步是對系統的穩態進行度量。系統可以被它的輸出內容所理解。系統穩態的度量需要一個穩定和輕便的監控系統。輕便意味著度量的動作不會顯著的對系統本身產生影響。發現穩態需要對以下問題作出解答。

• 什麼需要被度量？是像cpu使用率，記憶體利用率這種系統變數還是想響應時間這種業務變數，還是像其他應用的特定度量單位？ 有些時候以上所有方面都需要。
• 穩態有沒有對時間的依賴？資源利用率的模式在每天/每週/每月或每個季度或每年或更大的週期裡不同的時間都會不同。穩態確實是一個不穩定的狀態。

以下方式可以作為在區塊鏈視角下的設計混沌工程實驗框架(CEF)並執行的指導原則。

• 已知的弱點不能作為實驗的目標。如果1/3的攻擊破壞共識(BFT)，關閉一個致命比例的共識成員會造成已知的後果，從這個實驗無法獲得更好的洞察結果。而在重要閾值上維持一個較小的數值是可以作為實驗的。
• 對於區塊鏈，混沌工程實驗應該關注在共識，網路，儲存層和通過隨機實驗組合交叉切斷身份,智慧合約，中央，使用者互動等方面。
• 當我們在第二篇文章裡討論在Indy我們是怎樣進行混沌實驗時會提到這些。當通過實驗發現了下層框架的問題時，將由實驗導致的問題的程式,API或相關的系統隔離掉以便儘可能多的收集相關資訊。這些資料可以幫助我們對系統進行加固。
• 混沌工程與單元測試和整合測試不同。與做故障注入和失敗測試也不同。一個CEF會使用一些故障注入工具，失敗注入和失敗測試通常一次瞄準的是同一種失敗。混沌工程瞄準的是通過隨機組合的事件來發現系統的新知識；包括客戶流量激增這種良性或有益的場景。除了通常的測試工具和實踐外還應該也實施混沌工程。
• 從開發和測試環境進行實驗，當保證待修復的問題都解決後，開始逐漸向生產環境進行。只有在生產環境才能真正觀察到混沌實驗的非線性效應。
• 從整個團隊，特別是devops工程師與開發團隊溝通獲得支援。需要強調混沌工程不是一種對抗，而且通過實驗可以對整個系統進行加固。從實驗獲得的知識一樣可以讓開發上層活動(架構，設計，工程實現)受益。並且與企業的業務團隊溝通也是必要的。
• 隨機化實驗，包括時間和實驗本身。注意在學習穩態時收集的資源利用率與系統響應的資訊，同時也要注意期間需要關注的一些特殊情況。
• 自動化執行實驗，包括快速關閉實驗的方式，尤其是當你在生產環境做實驗時。當然這也包括在混沌框架與監控系統間的自動化監控和一些反饋形式。
• 最小化爆炸半徑。實驗的結果不應該對生產系統造成重大干擾。多個步驟的討論可以對這個問題有所幫助。
• 在高階實驗中，可以將系統分成兩部分：一種是不會被實驗影響的控制系統，一個是需要在做實驗時看到度量效果的系統。這是混沌工程的高階實踐。
• 彈性:在Netflix，使用Chaos Monkey，只有獨立的程式或VM會被關閉，這些可以保證讓Chaos Kong來關閉整個資料中心或區域(region)。通過這種方式我們可以看到整個區域(region)建的故障轉移情況。
• Chaos成熟模型；講述了混沌工程裡成熟度的多個級別。不同的維度：開發系統到生產；混沌工程的自動化級別； 。。 ；取決於團隊走到了哪裡，有一些關於成熟度模型的一些大概的名字。
• 區塊鏈架構在federated或permissioned這種多個企業環境的區塊鏈場景比較有效。在公鏈上，環境不會被一種型別的實體所控制。具體到在多stakeholder，多企業環境的區塊鏈的建立，通訊和執行CEF。使用CEF的好處很清晰。如果在開發的起始階段執行CEF，在開發，業務使用者和運維同事那裡不會遇到很大的挑戰，因為此時對於平臺的穩定期望很低。CEF應該可以與其他的DLT(Distributed Ledger Technology )框架一起成長併成為生態系統的一部分。在permissioned setting的初始協議和管理方式討論中應該將CEF實踐作為一項條件。
• 對於公鏈，像與其他參與者與開發者社群溝通得到支援是必要的；需要一條為CEF部署準備的從完整測試環境到生產環境的路徑。這對於利益的stakeholder和governance視角的公鏈上來看並不容易，公鏈還在生成和開發。已存在的問題，像以太坊(Ethereum)的DAO事件或比特幣的scaling debate都暴露了系統的脆弱性，併產生了解決方案。一個基於混沌成熟度模型的完善的CEF可以更早的暴露這些風險並在早期尋求解決方案。核心和邊緣系統都有許多其他的弱點可以被完善設計的CEF來覆蓋。
• 企業區塊鏈需要有一套測試環境，讓CEF可以加速投入到生產。這對於大多數企業區塊鏈都是一樣。
• 對於特定架構領域的知識可以用來指導CEF工程實踐。例如，在Hyperledger Fabric(譯註：即超級賬本)，endorsement policies指導了共識的形成，所以不斷移除endorser直到到了endorsement規則支援的最小endorser數量可以暴露特定實現的風險。在Corda，移除一定比例的網路公證人，將使網路的一部分產生延遲，影響Corda的防火牆。會發現特定部署的脆弱點。

結論

通過觀察在大規模分散式系統中的混沌工程實踐展示了它的前景和力量。其在航空測試，醫院系統的生產系統這種敏感應用的實踐展示了它的實用性。

設計區塊鏈框架的實驗需要一系列的框架的特殊知識作為原則提供給CEF，並且需要工作在不同層面的團隊來隨著平臺增長來一起增加在特定實現上的信心。

我們會在這個系列的下篇來將在Indy平臺的CEF實踐作為案例。這可以幫我們指導我們在特定的DLT框架內進行CEF的實現。