随着互联网技术的发展，系统架构因此也不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到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、基础网络，对整个云基础设施进行高可用性验证。

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

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

　　以某客户为例，在服务建设完毕后正式上线前，京东云都会根据客户的用法和要求，做抗脆弱性验证来保障客户服务问题，让客户放心;而针对客户用到的京东云专有云产品JD Cloud Stack，京东云会对每一个发布版本做完整的混沌工程验证，保证交付给客户的是可靠的产品。

　　在刚刚过去的京东11.11期间，京东云全业务，全场景云端监控，流量同比增长300%，云搜索查询每日峰值达13.3万次/秒，云缓存每秒操作数每日峰值120万次，负载均衡接入请求量同比去年上涨36%，CDN整体峰值流量同比去年上涨44%。在大促之下，京东云仍然保障了AI、物流、广告等核心业务稳定。这充分证明了京东云以混沌工程理论为指导的可靠性设计和实践经受住了严酷的考验，值得信赖。