【譯】混沌工程與區塊鍊

作者 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的實作。