没事爱在线上制造故障？这位程序媛有话说

作者 | 伍杏玲

出品 | CSDN（ID：CSDNnews）

• 故障发生时的沟通协调是顺畅的？
  
• 增加重试就能解决问题？
• 应用重启后能自动投产？
• 非关键应用的故障不会影响业务？
• 单分片的故障不会影响全局？
• 这仅是一个部门的调用关系，简直是“不可描述”！
• 有人说“我们对生产环境有敬畏之心”，但一般有敬畏之心是源于不了解，所以我们不仅有敬畏之心还要有探索之心。
• 有个开发说我这个接口坏了，是不是你们弄的？我调接口查服务，终于发现——他这个接口就从来没有好过。
• 要十分悲观大胆地猜测这些问题在线上会发生，然后小心谨慎地去求证。

你以为最新一期程序员吐槽大会来了？不，这是11月9日在上海举办的2019携程技术峰会现场，来自携程网站运维总监方菊真实的工作总结。

俗话说，程序员每个段子的背后绝对有一条泪的教训。

为什么方菊过于真实地说出程序员“不能说的秘密”？

源于她在携程内部推行“混沌工程”。

混沌工程等于线上制造故障？

混沌工程（Chaos Engineering）是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。混沌工程适合揭露生产系统中未知的弱点。

混沌工程最重要的一点是：通过不断失败避免失败。因为通常我们对故障何时会发生一无所知，但故障无可避免地一定会发生。

“凡不能毁灭我的，必使我强大”。用尼采的话来诠释混沌工程的思想是最适合不过。 

为什么需要混沌工程呢？

随着企业业务的发展和技术架构的演进，我们需要保持稳定的用户体验，避免发生重大故障。以前往往是在大故障发生后，开发人员才去补救，才总结和实施改进的措施，但这终究已造成损失。

而混沌工程是将这些“痛苦”放在事前，用“以毒攻毒”的方式来使风险在可控的范围内及早暴露。这就像人打疫苗一样，先将一部分疫苗注入人的身体，产生抗体。通过这样才能做到“不破不立”，持续地验证系统的容灾能力。

对于开发团队来说，还能“常练常新”，因为在一个大型的故障排查过程中，考验的不仅是技术人员的技术，还会考验其临场的决策判断力，但肯定不会拿一个真实的故障来锻炼新人，所以在实施混沌工程中，能锻炼团队成员，增强团队抵御风险的能力和信心。

混沌工程的五大原则

那么如何开始做混沌工程呢？方菊列举以下五大原则：

1、假设稳定的状态

做混沌实验时，是将预期会发生的结果和实际会发生的结果做一个对比。所以我们需要假设一个稳定的状态，然后引入实验变量，例如服务器崩溃、网络中断等，再观察实验结果的稳态差异，最后发现问题。

另外，混沌工程关注的是结构性的风险，所以我们需了解关键业务指标在稳定时的状态，比如说广告投放转化率、支付成功率、订单提交量等，这需要监控工具来收集业务数据。

2、在生产环境进行演练

由于测试环境的数据覆盖度、第三方系统依赖、基础设施架构和生产环境是不同的。方菊表示，在实际操作中，有一些团队在测试环境做好了混沌实验后，在生产环境中依然会发现很多问题。所以她建议，为了保持真实性和有效性，推荐使用生产环境进行混沌实验。

但方菊补充道，这不是说明知道系统有一个Bug，非得到生产环境去复现。所以她推荐的是一种柔性的方式：如果你知道有Bug，先在测试环境修复好测试后，再把它放到生产环境。所以说，混沌实验的环境越真实，其越有价值。

3、持续地、自动地运行实验

如果是手动运行实验的话，实验成本较大，最终导致不可持续的。

方菊举例道，携程曾实行过Disaster Recovery（灾难恢复）演练，即将一个部门所有的非核心服务关掉，然后验证核心业务流程的健壮性。由于这个演练操作起来很复杂，每个业务部门每年演练1-2次。携程每周运维的变更有数千次，每一个变化都有可能会引来一个新的风险。

那么我们做演练的有效性也会随着时间来变化，如果要持续地验证系统的话，需要有一个好用简单的工具来代替人工的操作，它自动收集、自动验证异常、自动诊断，降低人力成本。

4、最小化爆炸半径

可能有人会想，混沌实验是否就是在生产环境随机操作呢？正好是相反的，实验是需要非常谨慎地在事前评估风险，做混沌实验的预期是将系统的隐患暴露出，但不会产生更大的影响。

方菊推荐采用“点线面体”的循序渐进过程来操作，当这个风险超过控制范围时，实验能马上终止。故此，方菊团队在故障平台上设计了“一键中断”功能，并将权限交相关人员。所以方菊强调，做混沌演练时，每个故障场景是随时均可放可收的。

5、多样化的故障场景

我们需要对历史故障事件分析，并且对故障场景进行抽象总结。如下图，便是方菊团队根据携程历史上发生过的故障整理成一个个场景：

在做实验时，可根据上述故障进行注入与恢复的实现。

实施混沌工程时主要围绕两个态：稳态和新态来进行。第一步是制订计划，定义稳态，评估风险。第二步是执行实验，在控制爆炸半径的基础上做故障。第三步，在故障输入后，通过监控对比稳态和新态。第四步是在故障恢复后，对新态进行结果评估，记录问题，进行修正。

混沌工程的实践应用

目前在携程内部已完成一千多次混沌实验，覆盖上万个实例场景。具体实践是怎么做的呢？方菊列举在核心应用对点评服务的弱依赖验证。

通过监控发现，点评服务出现响应延迟，于是在做混沌实验时，先定义一个稳态：产品详情应用QPS 1000，RT 300ms，此时点评信息显示完整。假设实验结果是产品详情页熔断对点评服务的访问，产品详情页可正常显示其他信息。

开始执行实验：可以根据不同的爆炸半径选择在服务端或者客户端注入服务延迟故障，通过实验，得到核心应用页面空白的结果，最后进行修复和总结。这样便完成一个混沌实验。

谈及未来携程在混沌工程上的布局，方菊表示将从接受度和复杂度两个方面来加强。

1、复杂度：工具覆盖常见故障，生产和测试环境少量演练，生产关键应用的定期演练。生产设定场景的随机演练，生产全自动化演练和验证。

2、接受度：验证历史故障的修复，主动设计故障场景并发起挑战，形成Design for failure和混沌工程的文化。

最后方菊重复强调道，混沌工程的核心不在于怎么制造故障，而是在一个可控的风险范围内，将系统已经存在的隐患给暴露出来。

系统：“凡不能毁灭我的，必使我强大”。你们团队实施混沌实验了吗？谈谈你的看法？

【END】

 热 文 推 荐 

☞微软“杀”不死的数据库软件

点击阅读原文，即刻报名参会！

你点的每个“在看”，我都认真当成了喜欢