混沌工程企业实践之经验教训

灾难结论围绕这三种结果来展开分析:已知事件和预期后果,已知事件和意外后果,未知事件和意外后果。

关注出现意外后果时是否有自动终止的能力,是否学到了意外故障的成因,以及从故障中恢复的知识。有些外部事件是系统不可控的,定期操练可以提前预防多数问题。

出现未知事件对团队最有价值,可以帮助我们找到盲点,了解上下游组件产生的累积效,应明确在哪里要投入更多的时间。

混沌工程实验出现的故障,其优先级可以从发生频率,发生可能性,优雅处理该事件的可能性来确定,并和客户期望相匹配。如何确定故障/指标误差是业务原因造成的,还是混沌实验本身带来的。

最后,我们看看团队的教训:

  • 观察团队在实验过程和故障排除中的沟通是否充分沟通?这次实验是否有足够的余量来避免灾难性的故障?
  • 关键角色是否就位?如果无法找到他,团队该如何处理?

人们永远不可能在事故发生前拥有避免它所需要的完备知识,只能对意外持开放态度。

灾难剧场的人为阻力,如何应对?

1、允许业务受影响的团队申请本次灾难测试的豁免。但这个豁免本身就暴露了系统目前的脆弱风险,值得未来深入分析图片

2、有些业务服务等级长时间处于健康的SLO水平,这也有可能是团队不希望上报故障,而容忍短停机事件。对此,灾难测试可以针对他们实施尽量长时间的故障注入,鼓励(逼迫图片)这些团队采取行动制定长期解决方案。

长期稳定运行的可靠子系统,拥有工程师对它的深度信任,但一旦真的发生故障,它本身就可能成为巨大风险的载体。

3、某些业务团队强烈抵制混沌工程,担心生产环境损失金钱。

不管是金融机构业务还是生命保健业务,系统都可能发生停机事故。那我们要问对方一个问题:你选择以无法预测的频率和严重程度来对待它,还是采用混沌工程主动了解风险,预防失控?
对于生命至上的医疗领域,医学就是在双盲临床实验上发展的,这就是一种“混沌工程实验”。

正如墨菲定律所言:凡能出错,必定出错。

混沌工程吸收各个领域的经验教训,可以在各行各业进行探索,受益的也是所有行业。

混沌工程的工具支持

大型技术公司会提供一个共享的、拿来即用的灾难测试通用平台,给实验团队提供方便,这些自动化测试涉及负载均衡,区域任务终止,延迟存储复制,高速缓存的刷新,RPC的延迟及错误注入等。在Neflix公司,这个平台叫ChAP

故障注入工具支持的故障模式主要有三种:错误,延迟,超时,以便工程师准确模拟实际生产事故。

平台能给工程师提供“一键发现请求中涉及的所有服务”能力,并可以勾选哪些服务要被注入故障,可定期执行并自动发送报告。平台还可以通过“大红按钮”一键终止这些自动化测试,快速恢复正常。

好的混沌工具平台,需要对可观测性进行投资,能在仪表盘上让大家更好地了解系统,并提供一些可解释信息,对特定服务/硬件中出现故障的可能性进行排名。

混沌工程平台,和持续验证/DevOps平台可以深入融合,提供灰度测试比对能力,也提供可视化的实时系统总体状态。在持续验证平台自动运行实验,最大程度提高产生洞见的速度。

未来,持续验证的混沌用例包含性能,数据制品,分层正确性验证(基础设施,业务逻辑,应用三层),这三种类型。

人和组织的能力提升

混沌工程旨在建立一种韧性文化,识别并增强人员和组织的正向能力。

人们在设计混沌实验时,更愿意讨论彼此的思维模式差异,因为安全环境下的实验能消除故障发生时的羞耻感。

很多团队只有在被要求时,或者重大活动(如双十一)来临之前才执行实验,其他时候只有专职团队在做混沌实验。为了打消大家的顾虑,构建一个安全的混沌工程平台非常重要,需要混沌平台开发者和用户(产品经理和工程师团队)的深度交流,包括这些问题:

  • 了解各团队的设计实现机制:超时,重试,调用回退,定期服务的流量百分比等等。
  • 你对系统各种配置参数设置是否有信心?哪些日常操作最让你害怕。
  • 当你的服务出问题,如何影响上下游服务?
  • 你的系统(包括上下游),最近是否可能引入新的漏洞?通过以上的访谈,讨论清楚混沌实验的范围和四大步骤,达成共识。
  • 对于一个组织本身,混沌工程的精神也能提升组织的韧性。比如把一个工程师抽调到其他团队工作一段时间,等同于给系统注入了故障,经常性的训练能够让组织更加适应人员切换,承载挑战的能力更强,员工也获得了更多的跨团队技术经验。

Casey Rosenthal描述了一项“疼痛紧身衣”的思维实验:把基础设施捕获的风险信号转换为穿戴者皮肤的疼痛感觉,比如早上醒来,感觉左肩膀痛,你就会想,微服务X又在胡闹了。这套衣服穿一段时间,你很快就对整个服务情况有直观的理解了。

但是疼痛紧身衣和混沌工程的目标并不相同,前者只是反应本能,并不能转换成可传播的知识。

混沌工程能够增强只有人才具有的灵活性和上下文相关的判断力,人最擅长的是就是提供解释。

人总是要做软件的“决策”,因为人能负责,而软件不能。

源自公众号  敏捷测试转型

上一页12下一页


留言