随着互联网技术的发展，系统架构因此也不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，系统扩展性和开发效率大幅提高。但同时，由于系统自身复杂度的激增，传统的测试方法已经不能全面理解和覆盖系统所有可能的行为，测试的有效性也大打折扣，加之开发者在引入复杂性的同时对风险的低估和忽视，成为目前系统可用性面临的两大挑战。

2008年8月，某厂商由于单点系统架构故障，导致了三天宕机，在此期间无法观看任何视频。随后该厂商开始将服务从数据中心迁移到云上，之后就开始尝试在生产环境中开展一些系统弹性的测试。

随着Chaos Monkey的出现，混沌工程原理应运而生，它被描述为“在分布式系统上进行实验的学科，目的是建立对系统承受生产环境中湍流条件能力的信心”。如今，谷歌，亚马逊，IBM，耐克等公司，都采用某种形式的混沌工程来提高现代架构的可靠性。

京东云在混沌工程领域的实践——破坏性演练

破坏性演练，是京东云在混沌工程中的实践。一方面，2018年京东云新增200+产品，实现爆发式增长；另一方面由于微服务化，大大增加了系统间依赖关系的复杂性；保障整个云的持续可用是巨大的挑战。

基于混沌工程的理论依据，京东云在实践过程中用系列实验，真实验证系统在各类故障场景下的表现，通过频繁地进行大量实验，使系统本身的反脆弱性持续增强，让云有信心抵御生产环境中难以预知的问题，也让客户对云的稳定性放心。

开始混沌工程之前，京东云在底层架构上，已经实现支持多Region和多AZ高可用，包括物理层、IaaS层、PaaS层以及控制面。但是京东云并未持乐观态度，而是谨慎的认为：业务垂直化的质量保证，更多关注纵向细分产品的质量和高可用能力，但对云整体横向的高可用的验证方面，存在天然的弱点。另一方面，实践出真知，不验证就没有底气。这些情况坚定了京东云做混沌工程的决心。

仿真环境建设。云是一套非常复杂的整体，它的资源数量、地域分布、流量体量等，都决定了无法在生产环境直接演练。为了确保演练不会影响到生产，京东云建立了隔离故障区域，将云的预发环境和测试环境都迁移至此，并投入大量服务器做1：1仿真部署，包括物理层、IaaS层、PaaS层以及控制面，及安全、CDN、视频等核心产品，相当于搭建了一个缩小公有云环境。在环境建设完成后的第二天，京东云就进行了第一次破坏性演练。

首次演练，投入近百人，两天时间，即收获117个改进点。之后，混沌工程成为京东云每个季度的例行工作。并由此不断推动应急预案的升级和技术架构的改进。

应急预案升级。当前产品的主要故障场景，都已具备自动化预案能力。自动故障检测以及自动故障恢复能力逐渐成熟，故障恢复耗时大大缩短。

技术架构改进。协同京东云架构师委员会，从验证双AZ的可靠性，到完善和发展基于3AZ的高可用架构。如存储产品，由原来的单AZ 3副本，改进为3AZ 3副本，可用性进一步提高；同时，排查依赖成环的问题，进行解除依赖或完善降级能力。

演练平台的建设。经过不断打磨，实现了演练触发自动化、多租户场景模拟、结果快速验证等能力的建设，提升了演练的效率。之后，演练不断深入，场景不断丰富。覆盖了服务、机器、随机硬件等场景，并结合IDC、基础网络，对整个云基础设施进行高可用性验证。

混沌工程实战检验 京东云为客户保驾护航

截止目前，京东商城、物流等全部核心系统都已经运行于公有云之上。依据内部混沌工程的经验，结合云高可用技术方案，京东云总结出了一套面向云上用户的快速验证方案，与用户一起，通过最佳实践解决用户可靠性的问题。