作者 Vipin Bharathan 原文：https://medium.com/@vipinsun/…
第一部分. 应用混沌工程理论到区块链框架。
混沌与工程两个字是没有什么关系的。在这篇文章，我们会探索下为什么他们会组合在一起并且应用在区块链上。第二部分我们会看到混沌工程在 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 的实现。
微信公众号「麦芽面包」，id「darkjune_think」开发者 / 科幻爱好者 / 硬核主机玩家 / 业余翻译家 / 书虫交流 Email: zhukunrong@yeah.net