韧性工程与混沌工程
在分布式系统中，跨进程边界的事情会出错。你无法预测什么时候会出错。它会在应用程序级别打击你。
尤其是最后一句话很重要：它将在应用程序级别打击您。这就是您需要韧性工程的原因。
韧性工程可让您系统地评估业务用例的重要性，检查潜在的故障模式并决定对策。如果操作正确，它是一种强大的风险管理工具，还可以考虑您行为的经济后果。
关于 AWS 中断，韧性工程会问如果发生更长时间的云基础设施中断会产生什么后果。如果影响太大，下一个活动是确定最关键的用例。然后识别潜在的故障场景并定义对策。
最后，这是简单的风险管理：你能承受多少停机时间，你想怎么做？
通常，韧性工程与混沌工程相辅相成。韧性工程可帮助您解决已知的故障模式，而混沌工程可帮助您检测未知的故障模式（并验证韧性措施的有效性）。
与探索性测试类似，您可以模拟任意故障情况并观察系统如何响应它。请注意，您始终小心控制故障模拟（称为“实验”）的“爆炸半径”，即限制实验的潜在影响。
通常，你会在所谓的“游戏日”中捆绑一整套实验。在更高级的组织中，您不断运行故障模拟并观察结果。
即使这个术语听起来有点儿戏，混沌工程也绝不是一场游戏。它是风险管理的重要组成部分。如果您有必须启动并运行的关键用例，则需要探索未知的故障源。在分布式系统中，这不是可选的，但可以决定成败。
您可能会争辩说您没有时间或预算。好吧，步履蹒跚的公司可能采取同样的方式。问题是：这些公司在停电期间没有完成韧性和混乱工程作业，损失了多少金钱和声誉？他们中的一些人可能无法幸免于难。
因此，您需要问自己一个问题：您负担得起吗？
就个人而言，我认为大多数公司都不能忽视韧性工程和混沌工程。他们中的一些人仍然忽略它，希望事情会顺利进行。但如果涉及风险管理，希望是一个糟糕的顾问。
总结起来，这篇博文比我承认我只是触及了表面。我的主要信息是：
说在中断期间运行在其基础设施上的应用程序停机是 AWS 的唯一错误，IMO 是不正确的。
步履蹒跚的公司对分布式系统的影响不够了解，并陷入了 100% 可用性陷阱。
步履蹒跚的公司对 SLA 的评估不够好。从 SLA 的角度来看，中断是意料之中的事。
韧性工程有助于评估和减轻可用性，从而降低经济（或更糟）风险。这不仅仅是一场 IT 秀，而是业务和 IT 的共同努力。
混沌工程通过发现未知的故障模式来增强韧性工程。
韧性工程和混沌工程是当代风险管理的重要、非可选工具。忽略它们意味着让自己步履蹒跚——或者更糟。
