扫码阅读
手机扫码阅读

聊聊混沌工程的企业实践

36 2024-01-31

这是鼎叔的第五十五篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

上一篇文章回顾:聊聊混沌工程。

知名公司的混沌工程实践有:谷歌的DiRT计划(灾难恢复测试,已经进行了数千次),Slack的灾难剧场,微软云平台混沌工程等。很多公司把混沌工程实验做成“Game Day”,用游戏比赛的有趣竞争状态来进行混沌实验,而不是制造如临大敌的气氛。

混沌工程的系统方法、原则和步骤,不止应用于分布式大型软件,也应用于软硬件一体的互联系统,如汽车自动驾驶系统。混沌工程也应用到了网络安全领域。

本文详细介绍各大企业实践混沌工程的优秀流程,经验教训,人为阻力,人和组织的能力提升,我们能从中学习到一些宝贵的洞见。

演练前须知

一 设计模式的容错性

始终让备用容量在线,然后考虑如何让出故障的计算机从服务中移除,进一步实现自动替换故障机器。整个替换的耗时短暂且合理,重试次数合理。

二 保持数据持久性

所有演练规划和涉及的故障都必须确保数据不会丢失。因此可能需要保留额外的数据副本。

三 高效协作和开放心态

当这些人讨论灾难实验计划时,一些被孤立的知识就能浮现出来,对某个人而言显而易见的漏洞,对其他人则是不确定的风险。这个讨论环节立马就获得收益,相关的假说和实验就没有必要安排了,先解决该漏洞再说。

混沌工程在高效协作下最有价值。但混沌工程团队对其他人的系统进行实验,双方很可能会形成冲突关系,导致混沌工程遭到拒绝。

如果混沌工程师的心态是帮助其他团队,并通过工具提供支持,那冲突就能大大降低。混沌工程参与者就拥有对系统可靠性的共同所有权。

如果发现系统漏洞的证据都被锁定在专有系统或专有协议中,其真实价值就会被损害,所以应该遵循开放的原则来实践混沌工程,鼓励开放培训资源、获取权限、同行评审、方法论、源代码和数据。

灾难剧场演练流程

每次演练都始于担忧。例如,如果一个园区因为地震,和其他园区发生通信中断,会发生什么?

针对故障引入后会发生什么,建立可靠的稳态假说。将所有专家和感兴趣的人聚集在一个房间或视频会议(包含上下游依赖组件的工程师),有助于缓解混乱。可以邀请管理层参与灾难剧场,得到他们的支持。

演练的准备工作如果没有确认就不要启动演练,它包括:

  • 本次演练的学习目标是什么?如何评估从演练得到的价值?

  • 初期进行灾难实验时,先从小处着手,以尽量小的单元作为目标。再逐步加大规模。

  • 实验安排的时机,是否考虑了特定场景,比如具有潜在意外行为的新特性/新子系统正在发布,新的基础设施正在引入?

  • 在哪些服务区域/机器引入故障,如何模拟故障?实验流量是否足够让故障被检测出来?

  • 针对注入的故障,会发生传递性故障么?会传递到什么范围(爆炸半径)?

  • 可观察性如何保障,仪表盘在哪看?能快速检测哪些告警,日志和指标?推荐指标有线上问题工单数,服务出错率,延迟,自动容量伸缩耗时,资源占有率等。

  • 识别应对故障的冗余和自动补救机制,以及执行手册。

  • 预留充分的演练时间,让所有人能听清指令和讨论。

  • 公开发布演练公告,鼓励关注。让值班同学密切监控。

  • 演练时间通常要错开重大假期和公司各种年度活动的安排。

  • 指定一个经验丰富的主持人来指导混沌工程的全流程。

  • 指定过程记录员,记录故障发生及解决的事件、跟踪行动和时间。

  • 其他可选角色包括:执行命令者,观察者,协调者等。

演练过程须知:

  • 如果发生计划偏移,出现对客户的意外故障,则终止实验。

  • 把演练故障当成真实停机事故一样对待

  • 尽可能一次只测试一个假说,并把自动化反应和人的反应区分开来。注意一个假说也可以是多个故障同时注入的组合。

  • 不要开发使实例失效的新方法,掩盖了现有失效行为的根因。

演练结束时,参会者花一点时间进行即时反思。并在会后为大家汇报演练发现的事实。让更多人了解组织可以使用哪些技术来容忍生产环境的各种故障,为系统可靠性和开发环境质量提出建议。

演练帮助这些不常合作的参会者,朝着改善系统安全性的目标共同努力,当事故真正发生时就能非常高效的协作。

同时,反思我们如何让用户注意不到故障的发生,我们的盲区在哪里?

哪些手工行为可以自动化。哪些行为不能,也不应该自动化?新的自动化除了付出成本,也可能会给运维工程师带来新的任务行动。可高效自动化操作的系统往往是脆弱的,允许低效率有时是个好事,人们有足够的时间针对未预期故障制定补救决策。

演练是系列化的,当漏洞被发现,我们会规划再次演练以验证补救措施是否生效。

常见的灾难测试类型与启发

1 场景一:异常大的流量峰值导致服务的平均延迟,但是不会违背SLO。

当被服务用户足够多时,哪怕没有承诺的合同,用户也会把稳定服务下的性能看作应当如此(即SLO-隐形合同)。

2 场景二:非关键后端服务发生故障,不会导致连锁反应失控。

通过大量故障注入测试,尽可能发现关键的依赖关系,建立“如果失效后发生什么”的充分认知。

3 场景三:特定网络区域中的计算资源意外丢失。

对于分布式系统,流量高峰达到多少就应该考虑紧急情况的资源分配?确保团队能自如地转移容量和主备切换。

4 场景四:数据损坏时,能从系统的最新备份中还原。

确保恢复过程正确,备份可以正常工作,这个过程是否发生数据不一致问题,如何处理?

5 场景五:区域性的网络故障导致机器离线。

应该从不同大小的规模对网络故障进行测试,通过精心设计的防火墙规则,证明系统的容忍故障能力。

6 场景六:关闭告警组件后,故障注入行为能否被发现?

7 场景七:所有系统都重启,能否尽快重新开机并正常服务?

灾难该如何总结

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

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

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

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

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

观察团队在实验过程和故障排除中的沟通是否充分沟通?这次实验是否有足够的余量来避免灾难性的故障?

关键角色是否就位?如果无法找到他,团队该如何处理?

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

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

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

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

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

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

不管是金融机构业务还是生命保健业务,系统都可能发生停机事故。那我们要问对方一个问题:你选择以无法预测的频率和严重程度来对待它,还是采用混沌工程主动了解风险,预防失控?

对于生命至上的医疗领域,医学就是在双盲临床实验上发展的,这就是一种“混沌工程实验”。

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

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

混沌工程的工具支持

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

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

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

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

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

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

人和组织的能力提升

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

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

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

  1. 了解各团队的设计实现机制:超时,重试,调用回退,定期服务的流量百分比等等。

  2. 你对系统各种配置参数设置是否有信心?哪些日常操作最让你害怕。

  3. 当你的服务出问题,如何影响上下游服务?

  4. 你的系统(包括上下游),最近是否可能引入新的漏洞?

    通过以上的访谈,讨论清楚混沌实验的范围和四大步骤,达成共识。

对于一个组织本身,混沌工程的精神也能提升组织的韧性。比如把一个工程师抽调到其他团队工作一段时间,等同于给系统注入了故障,经常性的训练能够让组织更加适应人员切换,承载挑战的能力更强,员工也获得了更多的跨团队技术经验。

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

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

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

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

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484184&idx=1&sn=92491818b47161e476496e7bb37d7d03&chksm=c24fb67af5383f6c57a3559732e52a8847beae880ad8f2b7f337bef6509ea962cea17cf6c1ad#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 4625
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线