第 6 章. 微软的变化与实验的优先次序
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
在 Microsoft,我们为大规模云基础设施构建并运营自己的混沌工程计划。我们发现,实验选择尤其对系统应用混沌工程的方式有重大影响。实际生产系统中不同故障场景的例子说明了各种实际事件会如何影响生产系统。我将提出一种确定服务实验优先级的方法,然后提出一个考虑不同实验类型变化的框架。本章的目标是为您提供可用于工程流程的策略,以提高产品的可靠性。
为什么一切都如此复杂?
现代 软件系统非常复杂。即使是最小的软件产品,也有成百上千的工程师在工作。有成千上万,甚至上百万的硬件和软件组成一个系统,成为你的服务。想想那些为英特尔、三星、西部数据等硬件供应商以及其他设计和制造服务器硬件的公司工作的工程师吧。想想思科、Arista、戴尔、APC 以及所有其他网络和电源设备提供商。想想微软和亚马逊为你提供的 Cloud 平台。您在系统中明示或默示接受的所有这些依赖关系反过来又会产生各自的依赖关系,一直到电网和光纤电缆。您的依赖关系组合在一起,就形成了一个具有大量活动部件的复杂黑盒子,而您就是在这个黑盒子上创建了自己的系统。
意外并发症实例
在我职业生涯的早期,我曾研究过潜艇声纳设备中使用的算法。在那些日子里,我简直可以说出我的代码所依赖的每一个组件(包括软件和硬件)的负责人:每一个库、每一个驱动程序、每一台我们运行的机器。潜艇是一个非常封闭的环境,因此只有那么多的计算机参与处理任务,只有那么多的电线和硬盘驱动器。传感器数量有限,系统中通常只有一个用户。即便如此,我记得我还是看到了一本又一本关于这些组件的巨著,数千页的文档。
每次会议都至少有十几个人参加:每个组件都被无休止地仔细检查,每个用例都被记录在案,每种情况都被审查。我的团队负责的模块涉及一些信号处理,我们在实验室里进行了我们能想象到的最严格的测试。我们使用了其他潜艇录制的信号,尝试了不同的天气和位置模拟。一切都非常彻底。
当我订机票去一艘真正的船上进行第一次测试时,我确信这次旅行不会超过几天。这有什么难的?安装、检查、庆祝、起飞。不幸的是,一切都不尽如人意。这是我第一次去俄罗斯北部旅行。在那里长大的妻子建议我多带些衣服。当然,我告诉她:"不用担心,只是几天而已。毕竟现在是八月,还是夏天,你知道的。"飞机降落时下起了雪。恶劣的天气耽误了我半天的时间,在接下来的旅途中,我还患上了小感冒。
当我终于能够安装我们的模块并试用时,它根本无法工作。第一次尝试使系统从头到尾运行了 40 天。我们遇到了几十个没有预料到的问题,遇到了我们没有考虑到的各种因素的组合,遇到了在绘图板上从未出现过的新挑战。从天线到信号处理器的连接线路涉及 200 多个连接点,其中没有一个是正确的。我们不得不回过头来重新追踪每一个连接点,通过编程调整机械错误。
所有这些充分的准备和努力都是在计划中投入的,但在第一次测试中还是出现了这样的混乱。我们做错了什么?我们没有考虑到系统在现实世界中会发生的所有事件。我们只关注了信号处理的数学和计算机科学问题,却没有考虑到糟糕的布线、极端的温度,以及在恶劣天气下船在波浪中翻滚时用户输入的质量。这些都是我们事后才知道的,而且付出了巨大的代价:项目延误和远离家人。
混沌工程高级原理的一个 ,就是在实验中改变真实世界的事件。如果我们能花些时间探索系统内外的实际效果,而不是一味追求完美,也许我们的安装会更成功,也能更快回家与家人团聚。