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

總結

以上是生活随笔為你收集整理的【译】混沌工程与区块链的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。