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