以线上事故驱动混沌工程更能展现价值
与运维团队一起实践了近一年的混沌工程后，获得了以下启发：
- 混沌工程的价值，就是要提升应对云生产环境线上事故的时效性和有效性
- 混沌工程实验与故障注入测试相辅相成，在证实稳态假说后，前者可以转化为后者
- 稳态行为假说，要具备全局性、用户价值性和可证实性的特点
- 以线上事故驱动混沌工程能更好度量成效
- 优选“严重级别”高且“业务影响时长”长的线上事故，有助于多样化地在实验中引入现实世界事件
一些企业实践混沌工程的痛点
奈飞公司提出混沌工程实践后，伴随着业务上云，国内企业纷纷仿效，不少工具厂商也推出了相应的工具。但有些企业的运维部门在实践混沌工程时，主要是用工具厂商所提供的工具，或使用自研的工具，进行故障注入探索性测试。其间缺乏针对该企业以前所发生的生产环境线上事故设计混沌工程实验。这导致将“混沌工程实验”做成了场景较为简单和单一的针对基础设施层的“故障注入探索性测试”。其后果就是测试做了不少，但发现的未知的复杂系统的失效模式却不够多。另外这些测试与线上事故缺乏直接关联，导致难以体现混沌工程实践的价值。
如何才能以线上事故驱动混沌工程，从而体现混沌工程实践的价值？让我们看看能否从混沌工程的起源获得启发。
云生产环境线上事故驱动混沌工程
2008年，奈飞DVD租赁业务因数据库故障中断3天。于是他们决定上AWS云服务，摆脱单点故障。但业务系统运行所依赖的AWS服务实例会突然消失，使得流媒体业务中断。如何规模化地解决这个问题？在试用了不少方法后，在生产环境随机关闭服务实例的“混沌猴”实践胜出。这个实践能有效驱动研发人员提升系统稳定性设计。
2012年，AWS的ELB（弹性负载均衡器）不断发生停机故障，导致AWS区域无法使用，使得在其上运行的奈飞流媒体业务中断。循着“混沌猴”的理念，2015年奈飞发布“混沌金刚”，有效提升了AWS区域故障切换效率。
从上面两个例子能够看出，云生产环境线上事故驱动出混沌工程。混沌工程的价值，就是要提升应对云生产环境线上事故的时效性和有效性。而国内有些企业的混沌工程，驱动的原因虽然各不相同，但很少有能从线上事故来驱动的。这些企业大多会把混沌工程当作另一种测试来实践。
说到了测试，那么混沌工程实验与故障注入测试的区别是什么？
混沌工程实验与故障注入测试相辅相成
混沌工程实验是要证实或证伪复杂云系统在故障注入后的稳态假说是否成立，并研究其间系统的运行模式、未知的失效模式以及监控告警的有效性，以便增强系统稳定性设计。
可以用证实或证伪“稳态假说”，来驱动团队研究未知系统失效模式和监控告警的有效性。
故障注入测试一般是回归测试，即要验证之前所证实的稳态假说，不会随着代码不断变更而被证伪。即要保证之前能正常运行的功能，不能在代码改动后失效。
回归测试是要验证修复了稳定性和监控告警缺陷的复杂云系统，能在故障注入后，实现自愈和快速有效的监控告警。
可以用回归测试用例，覆盖已知漏洞和监控告警问题的修复，以验证这些修复是否长期有效。
混沌工程实验与探索性测试有点像。两者的区别是什么？
探索性测试是要探索待测目标，以发现有价值的信息。探索性测试的目的是发现新信息，而非证实或证伪稳态假说。这一点可以用来区分两者。
既然稳态假说如此重要，那么如何才能设计好？
如何才能设计好稳态假说？
一个好的稳态假说，具备3个特点：1）全局性；2）用户价值性；3）可证实性。
比如，下面是一个较好的稳态假说：“即使在实例失效的条件下，系统仍然能在3秒之内，完成已受理的用户的交易，否则能在5秒之内提示用户业务暂时不可用。”
下面是两个供参考的稳态假说模版。
可用性实验稳态假说模版： 即使在XXX条件下，用户依然拥有良好的使用体验，具体表现为XXX（可观测性指标度量）。
安全性实验稳态假说模版： 一旦XXX情况发生，安全团队将在XXX时间内收到通知，具体通知样例为XXX。
有些团队在进行混沌工程实验时，没有写稳态假说的习惯。而只是用以下指标描述和测试目标代替。
混沌工程演练主要关注系统在故障演练期间以下稳态指标：1）系统业务指标：系统交易错误率统计；2）系统性能指标：系统交易TPS和响应时长；3）系统资源指标：系统服务器CPU、内存、磁盘IO以及网络资源指标变化情况”。
测试目的：测试集群在VM实例服务器CPU爆满时的系统表现情况。
上面两个例子，有些能看出隐含的稳态行为的假说，如系统交易错误率。但这没有站在用户视角，而只是站在测试人员的视角，加大了“局部优化而忽视全局用户体验”的风险。另外，这些稳态指标描述都不够具体，缺乏可证实性，无法准确评判实验是否证实还是证伪。这样就难以评判实验的结果，而更像是在做探索性测试。
只有在创建好合理的稳态假说后，才能说我们在做真正的混沌工程。那之后该如何度量混沌工程实践的价值？
以线上事故驱动混沌工程能更好度量成效
如果能以线上事故驱动混沌工程，那么就可以在用混沌工程实验和测试覆盖 * 线上事故 * 的系统缺陷和监控告警改进点后，计算所能挽回的线上事故业务不可用时长，并可换算成可挽回的经济损失。当然，这里说到的“覆盖”，发生在我们已经修复了混沌工程实验所发现的漏洞之后。只有在此时，度量成效才有意义。
可以使用下面公式来计算混沌工程实验与故障注入测试的成效。
混沌工程实验与故障注入测试成效 = 所覆盖的线上事故业务不可用时长 * 单位时长所造成的经济损失金额 * 实验执行次数
明确了如何度量混沌工程成效之后，对于运维部门来说，该如何选择适合的线上事故设计混沌工程实践呢？
哪些线上事故适合进行混沌工程实验？
企业IT团队一般分为研发、测试、运维三个部门。这三个部门的工作会各有侧重。每个部门都可以基于本部门的关注点，从以往线上事故中选择适合的事件，来驱动混沌工程实践。
如何从众多的线上事故中，选出适合运维部门来进行混沌工程实验的事件呢？
可以优选“严重级别”高且“业务影响时长”长的线上事故，来设计混沌工程实验。
下表包含了6个“严重级别”高且“业务影响时长”长的线上事故。哪些是适合运维部门来进行混沌工程实验的事件？
线上事故 | 严重级别 | 业务影响分钟数 | 业务影响描述 | 主要原因 | 主要改进点 |
|---|---|---|---|---|---|
1 服务器磁盘空间满导致故障 | 严重 | 几百分钟 | 业务出现故障 | 服务器磁盘空间满 | 优化监控告警；优化负载均衡配置；优化服务器扩容 |
2 交易网站因高频登录攻击引发业务异常 | 严重 | 上百分钟 | 业务异常 | 因高频登录攻击，导致流量猛增 | 优化流量管控，对短时高频交易做好熔断处理；调用方优化旁路策略 |
3 交换机在变更过程中出现网络丢包导致业务功能异常 | 严重 | 上百分钟 | 业务功能异常 | 交换机在变更过程中出现网络丢包 | 优化应用的重启机制；优化应用监控 |
4 因业务量增大使得数据库连接数占满，导致批量作业部分用户业务报错 | 严重 | 几百分钟 | 批量作业部分用户业务报错 | 因业务量增大使得数据库连接数占满 | 优化配置，增大数据库连接数；优化异常处理，批量程序增加应用失败后重试机制 |
5 因sql语句在对大表进行查询时未使用索引，造成服务器CPU和IO耗尽，业务出现异常 | 严重 | 几百分钟 | 业务出现异常 | 因sql语句在对大表进行查询时未使用索引，造成服务器CPU和IO耗尽 | 优化SQL语句，增加索引；优化监控算法；落实数据库性能容量问题整改机制 |
6 因版本控制失误，不该本次上线的配置变更提前上线，导致上千笔交易失败 | 严重 | 上千分钟 | 上千笔交易失败 | 因版本控制失误，不该本次上线的配置变更提前上线 | 版本控制；优化应用逻辑；上线前配置检查；完善监控 |
因为前4个线上事故都是有关磁盘、流量、网络丢包、数据库连接数等适合运维部门模拟的故障，可以考虑交由运维部门来设计混沌工程实验。而后面两个是有关sql语句建索引和版本控制失误，或许交由研发部门设计混沌工程实验更加合适。但最终是否合适，还需要听两个部门的意见。
总结
因为运维部门离线上事故更近，所以可以用线上事故驱动混沌工程，来体现混沌工程的价值。一方面，运维部门可以用“故障注入回归测试”验证容器平台等基础设施自带的自愈功能和相关监控是否长期有效；另一方面，可以选择“业务影响时间长且值得在基础设施层进行故障模拟”的线上事故，用故障注入实验证实或证伪稳态假说，并研究未知失效模式和监控告警有效性。待相关缺陷修复且证实稳态假说后，转化为“故障注入回归测试”，验证已知漏洞的修复和监控是否长期有效。最后，可以用混沌工程实验和测试所覆盖的线上事故业务不可用时长、单位时长所造成的经济损失金额、实验执行次数三者的乘积，来度量成效，让团队看到混沌工程的价值。