灾难结论围绕这三种结果来展开分析：已知事件和预期后果，已知事件和意外后果，未知事件和意外后果。
关注出现意外后果时是否有自动终止的能力，是否学到了意外故障的成因，以及从故障中恢复的知识。有些外部事件是系统不可控的，定期操练可以提前预防多数问题。
出现未知事件对团队最有价值，可以帮助我们找到盲点，了解上下游组件产生的累积效，应明确在哪里要投入更多的时间。
混沌工程实验出现的故障，其优先级可以从发生频率，发生可能性，优雅处理该事件的可能性来确定，并和客户期望相匹配。如何确定故障/指标误差是业务原因造成的，还是混沌实验本身带来的。
最后，我们看看团队的教训：
- 观察团队在实验过程和故障排除中的沟通是否充分沟通？这次实验是否有足够的余量来避免灾难性的故障？
- 关键角色是否就位？如果无法找到他，团队该如何处理？
人们永远不可能在事故发生前拥有避免它所需要的完备知识，只能对意外持开放态度。
灾难剧场的人为阻力，如何应对？
1、允许业务受影响的团队申请本次灾难测试的豁免。但这个豁免本身就暴露了系统目前的脆弱风险，值得未来深入分析图片
2、有些业务服务等级长时间处于健康的SLO水平，这也有可能是团队不希望上报故障，而容忍短停机事件。对此，灾难测试可以针对他们实施尽量长时间的故障注入，鼓励（逼迫图片）这些团队采取行动制定长期解决方案。
长期稳定运行的可靠子系统，拥有工程师对它的深度信任，但一旦真的发生故障，它本身就可能成为巨大风险的载体。
3、某些业务团队强烈抵制混沌工程，担心生产环境损失金钱。
不管是金融机构业务还是生命保健业务，系统都可能发生停机事故。那我们要问对方一个问题：你选择以无法预测的频率和严重程度来对待它，还是采用混沌工程主动了解风险，预防失控？
对于生命至上的医疗领域，医学就是在双盲临床实验上发展的，这就是一种“混沌工程实验”。
正如墨菲定律所言：凡能出错，必定出错。
混沌工程吸收各个领域的经验教训，可以在各行各业进行探索，受益的也是所有行业。
混沌工程的工具支持
大型技术公司会提供一个共享的、拿来即用的灾难测试通用平台，给实验团队提供方便，这些自动化测试涉及负载均衡，区域任务终止，延迟存储复制，高速缓存的刷新，RPC的延迟及错误注入等。在Neflix公司，这个平台叫ChAP。
故障注入工具支持的故障模式主要有三种：错误，延迟，超时，以便工程师准确模拟实际生产事故。
平台能给工程师提供“一键发现请求中涉及的所有服务”能力，并可以勾选哪些服务要被注入故障，可定期执行并自动发送报告。平台还可以通过“大红按钮”一键终止这些自动化测试，快速恢复正常。
好的混沌工具平台，需要对可观测性进行投资，能在仪表盘上让大家更好地了解系统，并提供一些可解释信息，对特定服务/硬件中出现故障的可能性进行排名。
混沌工程平台，和持续验证/DevOps平台可以深入融合，提供灰度测试比对能力，也提供可视化的实时系统总体状态。在持续验证平台自动运行实验，最大程度提高产生洞见的速度。
未来，持续验证的混沌用例包含性能，数据制品，分层正确性验证（基础设施，业务逻辑，应用三层），这三种类型。
人和组织的能力提升
混沌工程旨在建立一种韧性文化，识别并增强人员和组织的正向能力。
人们在设计混沌实验时，更愿意讨论彼此的思维模式差异，因为安全环境下的实验能消除故障发生时的羞耻感。
很多团队只有在被要求时，或者重大活动（如双十一）来临之前才执行实验，其他时候只有专职团队在做混沌实验。为了打消大家的顾虑，构建一个安全的混沌工程平台非常重要，需要混沌平台开发者和用户（产品经理和工程师团队）的深度交流，包括这些问题：
- 了解各团队的设计实现机制：超时，重试，调用回退，定期服务的流量百分比等等。
- 你对系统各种配置参数设置是否有信心？哪些日常操作最让你害怕。
- 当你的服务出问题，如何影响上下游服务？
- 你的系统（包括上下游），最近是否可能引入新的漏洞？通过以上的访谈，讨论清楚混沌实验的范围和四大步骤，达成共识。
- 对于一个组织本身，混沌工程的精神也能提升组织的韧性。比如把一个工程师抽调到其他团队工作一段时间，等同于给系统注入了故障，经常性的训练能够让组织更加适应人员切换，承载挑战的能力更强，员工也获得了更多的跨团队技术经验。
Casey Rosenthal描述了一项“疼痛紧身衣”的思维实验：把基础设施捕获的风险信号转换为穿戴者皮肤的疼痛感觉，比如早上醒来，感觉左肩膀痛，你就会想，微服务X又在胡闹了。这套衣服穿一段时间，你很快就对整个服务情况有直观的理解了。
但是疼痛紧身衣和混沌工程的目标并不相同，前者只是反应本能，并不能转换成可传播的知识。
混沌工程能够增强只有人才具有的灵活性和上下文相关的判断力，人最擅长的是就是提供解释。
人总是要做软件的“决策”，因为人能负责，而软件不能。
源自公众号 敏捷测试转型