在系统中放一只随机杀死服务的“猴子”，落地的六个步骤
作者丨焦振清、杜宾
策划丨田晓旭
编辑丨小智
只要你有过在生产环境中实际运行过分布式系统的经历，你就应该清楚，各种不可预期的突发事件一定会发生。分布式系统天生包含大量的交互、依赖点，可以出错的地方数不胜数。硬盘故障、网络不通、流量激增压垮某些组件，我们可以一直列举下去。这都是每天要面临的常事儿，处理不好就会导致业务停滞，性能低下，或者是其他各种无法预期的异常行为。
在复杂的分布式系统中，人力并不能够阻止这些故障的发生，我们应该致力于在这些异常行为被触发之前，尽可能多地识别出会导致这些异常的，在系统中脆弱的，易出故障的环节。当我们识别出这些风险，我们就可以有针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。我们能够在不断打造更具弹性（弹性：系统应对故障、从故障中恢复的能力）系统的同时，树立运行高可用分布式系统的信心。
2008 年 Netflix 开始从数据中心迁移到云上，之后就开始尝试在生产环境开展一些系统弹性的测试。过了一段时间这个实践过程才被称之为混沌工程。最早被大家熟知的是“混乱猴子”（Chaos Monkey），以其在生产环境中随机关闭服务节点而“恶名远扬”。不久以后，“混乱猴子”进化成为“混乱金刚”（Chaos Kong），能力进一步提升。
2 混沌工程：未来系统标配
Netflix 随后确立了混沌工程的若干原则，用以将这个实践规范的学科化 ，同时推出了混沌工程自动化平台，能够在微服务体系架构上，24*7 不间断地自动运行混沌工程实验。
在开发这些工具和实践的过程中， Netflix 逐渐意识到，混沌工程并非是简单的制造服务中断等故障。当然，尝试破坏系统和服务很简单，但并不是全都可以有建设性、高效地发现问题。混沌工程的意义在于，能让复杂系统中根深蒂固的混乱和不稳定性浮出表面，让 Netflix 可以更全面地理解这些系统性固有现象，从而在分布式系统中实现更好的工程设计，不断提高系统弹性。
除了适配于互联网场景，混沌工程也同样适用于传统行业，如大型金融机构，制造业和医疗机构。交易依赖复杂系统吗？有大型银行正在使用混沌工程来验证交易系统是否有足够的冗余。是否有人命悬一线？在美国，混沌工程在许多方面被当做模型应用在了临床试验系统中，从而形成了美国医疗验证的黄金标准。横跨金融、医疗、保险、火箭制造、农业机械、工具制造、再到数字巨头和创业公司，混沌工程正在成为复杂系统改进学科的立足点。
未来，混沌工程或将成为系统的标配。届时，你可能在每个系统中都找到这只“猴子”。
3 混沌工程六个阶段
从笔者所在团队的实践出发，我们将混沌工程总结为六个阶段，并对各个阶段的落地过程加以总结，希望能够对大家落地混沌工程有所帮助。今天主要是抛砖引玉，后续针对每个阶段，陆续会有专门的文章进行介绍。而混沌工程理论相关的部分，大家可以参考由 Netflix 出版的《混沌工程》迷你书。
上述各阶段涉及的部门和人员的数量，远远超过了当初的预估，因此该部分成为我们确定顺序的最主要因素，强烈建议大家实施混沌工程，一定要争取来自于管理层的支持以及周边团队的理解和配合，否则很容易导致项目虎头蛇尾。
4 单机破坏
重要性说明
以集群选主机制为例说明单机破坏的优先级和重要性，如果单机在某些场景异常后，集群无法选主，进而导致系统整体不可用。该问题如果在单机房破坏场景时才发现，那系统整体不可用了，你还能找出啥别的问题呢？一个机房的破坏场景，往往涉及多个部门的联动，大部分业务团队的各类角色均会参与其中，难道最后就得到一个结论：选主机制有问题。如果真是这样，你还打算继续干下去吗？
排序考虑
单机破坏能够在测试环境中发现绝大多数问题，并能扫清后续阶段的阻塞点，因此排在首位可谓是当之无愧。
破坏手段
在测试环境下，先从重启服务器开始，然后是关机，资源异常（如 CPU 打满）等场景。注意单机破坏场景不要把自己”拒之门外”。举个例子，把机器的 CPU 打满，但是没有设置打满的时长，结果自己也无法登录机器了，只能重启。
落地建议
初期仅在测试环境中进行，仅进行重启场景的验证就足以发现很多问题；
给出单机破坏的全部场景和验收方法，由各个团队自行落地；
不恋战，只要问题不阻塞单机房破坏环节，不影响黄金流程即可进入下阶段。
5 单机房破坏
重要性说明
单机房故障是造成服务整体崩溃的主要原因之一，全球互联网巨头大多发生过单机房故障导致服务崩溃的情形。诸如外网出口异常，内网跨机房专线异常，机房核心交换机异常，各种网络抖动和拥塞，IDC 供电设备异常等等，相信大家都不陌生，因此其重要性可见一斑。
排序考虑
高频故障场景，故障后影响较为严重，业界有较多的最佳实践可供参考，模拟单机房破坏的难度和风险均较低，因此紧随单机破坏其后。
破坏手段
将跨机房的专线端口关闭即可，恢复则是将端口重新 up 即可，整个耗时可以控制在秒级。演练前，业务方需要提前将流量迁移到其他机房，观察跨机房的残余流量符合预期后再进行操作，否则就对残余流量进行排查，从而避免发生较为严重的故障。
落地建议
如果近期公司内部发生类似的单机房故障，那是单机房破坏发起的最佳时机；
通过数据分析来揭示风险，如跨机房交互的模块数量及比例，跨机房的流量带宽的增长趋势、使用率和成分分析，每次机房级网络调整各个业务受影响程度的统计，各个业务方对较大网络操作的接受度等；借助网络调整的机会，来间接实现第一次单机房破坏；
如果仅仅破坏部分机房（如所有在线机房）是不足以发现所有的问题和隐患的，需要对所有机房逐一进行一次演练，才能发现一些潜藏的依赖和问题；
单机房破坏的时间点尽量参照网络调整的时间点，大多数在凌晨 1 点左右进行。
6 依赖治理
重要性说明
依赖主要是第三方依赖和基础设施，包括但不限于 Mysql、Redis、K8S、DNS、LB、ELK、Hadoop 等，上述任何服务的故障，对业务影响都极为严重。以近期发生的 AWS 的 DNS 故障为例，持续 15 小时，多个业务受损。
排序考虑
基础设施可谓是牵一发动全身，故障频率低，故障影响大，因此依赖治理放在了单机和单机房之后。
破坏手段
基础服务和一般的业务场景无区别，主要也是通过单机破坏和单机房破坏等通用手段来进行快速的问题识别。
落地建议
对于依赖的破坏，为了减少对业务方的影响，初期可以通过业务方的测试 / 预发环境 + 依赖的正式环境组合来进行破坏，也可以在离线机房对基础设施进行破坏；
基础设施很大占比是开源软件，进行 Trace 的改造成本较高，因此要了解第三方依赖内部的关键点，并针对性的进行破坏演练。以 Mysql 为例来说，一般 Mysql 前面都会有一层 Proxy，如果 Proxy 正常，而 Mysql 异常会发生什么问题呢？事实证明，很多坑都在这个地方，而要想发现这个坑，那必然需要对 Mysql 的业务有一定的理解，也就是所谓的白盒；
攘外必先安内，各类依赖大部分都是其他部门提供的服务，沟通成本和配合度上会有区别，因此需要先搞定自身的问题，然后再来进行第三方的依赖治理，不然很容易被人怼回去，毕竟很多依赖属于基础设施，牵一发动全身，人家配合的成本也是极大的；
对于循环依赖需要在架构层面明确原则，然后再进行整体的改造。
7 全链路故障注入
重要性说明
所谓的精准注入，只影响特定的客户 ID、地域、设备类型、接口，还可以对注入的行为和比例等进行精准控制，从而大幅缩小故障范围，将故障的风险收敛到最小。因为是精准注入，因此必须具备全链路的观测能力，才能够将上述的细微的注入影响进行描述，否则，你可能很难回答，延时增加了 3s，是哪些模块的作用导致的。
传统的破坏方式，粒度只能控制在单机级别，很多影响非预期且及不可控。以 TC 命令为例，如果是按照一定比例进行破坏，你无法精准控制哪些请求会受到影响，运气足够差的情况下，也许你不希望被影响的请求全军覆没，而你期望被影响的请求则无一命中。另外，传统的破坏方式也没有统一的标准，有些需要用 tc 命令，有些是 iptables 命令，有些是写死 /etc/hosts 文件，没有方便易用的方式，且本身存在较大的风险，很难进行大范围推广。下面是两者的对比：
排序考虑
全链路追踪能力是故障注入的基础，需要所有的模块全部进行适配改造，否则调用链就会在某个阶段中断，进而导致不可完全追踪。同时对于一些开源软件，也需要进行适配，其成本是前四个阶段中最高的，耗时最长的，因此，故障注入往往会放在后期。
破坏手段
微服务化一般是基于 Istio 进行注入，或者在接入层进行注入均可。此处我们也在 Istio 的紧张改造中，后面可以给大家写专门的文章进行分享。
落地建议
对系统进行分级，首先将黄金流程进行改造，确保最核心的功能具备了能力，然后慢慢外扩到所有功能
上述的四个手段，只能解决线上的存量问题，但无法阻止增量问题。因此，还需要将上述的各种能力，整合在 CI/CD 过程当中，在测试阶段进行拦截，从而彻底杜绝这类问题在线上发生的可能性。该部分目前我们也正在逐步建设和完善中，因此各种坑后续慢慢交流。
产品化
虽然通过 CI/CD 阶段的整合，可以将问题拦截在测试阶段，但这时候，每次都是测试阶段发现问题后让研发返工，对于研发就造成了极大的资源浪费。因此，需要将混沌工程形成的各种标准和规范，以产品化的形式交给研发同学使用，进而让大家都满意。
以单机起停脚本为例进行说明，每个模块的研发不同，可能存在的问题也不一样，这时候，发现问题后进行修改，不如提供一个统一的服务起停管理工具给研发使用，从而彻底解决该问题。开源软件类似 Systemd，Supervisor 和 Monit 都可以很好的解决这类问题，且对程序没有侵入性，不存在什么改造成本。
再高阶一些，就可以参考 Netflix 开源的各种软件：
InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！
今日荐文
大会推荐
国内外一线互联网资深技术专家现身教学，京东物流首席数据分析官吴盛楠博士、Google 研究院主任工程师 & 技术主管经理程致远博士等技术大咖的实践经验必须让你知道！
ArchSummit 全球架构师峰会（北京站）报名倒计时 5 天，没上车的要抓紧了哦！了解详情请联系票务经理灰灰： （同微信）。
点个在看少个 bug