混沌工程入门

可观察性（指标、日志、请求跟踪）

你想探索的现实世界事件或故障清单

通过领导力支持来赞助组织韧性

根据潜在的业务影响，优先考虑关键发现，而不是在进行混沌实验时发现的新功能

业务指标-稳定状态表示系统的正常运行，由您的业务指标定义。它可以用每秒交易量 (TPS)、每秒点击流、每秒订单数或类似的衡量标准来表示。当您的应用程序按预期运行时，它会显示出稳定的状态。因此，在运行实验之前，请验证您的应用程序是否运行正常。稳定状态并不一定意味着故障发生时不会对应用程序产生任何影响，因为故障的百分比可能在可接受的范围内。稳定状态是您的基准。例如，支付系统的稳定状态可以定义为处理 300 TPS，成功率为 99%，往返时间为 500 毫秒。从视觉上看，可以将稳定状态想象成心电图 (EKG)。如果系统的稳定状态突然波动，则表明您的服务存在问题。

服务器端指标 — 要了解您的资源在实验期间的表现，您需要深入了解其在实验之前、期间和之后的性能。要衡量您的资源对的影响 AWS，您可以使用 Amazon CloudWatch。 CloudWatch 是一项监控应用程序、响应性能变化、优化资源使用并提供对运行状况的见解的服务。在实验期间，您需要捕获服务器端指标，例如饱和度、请求量、错误率和延迟。

客户体验指标 — 开启后 AWS，你可以使用 CloudWatchRUM 通过 Locust、Grafana k6、Selenium 或 Puppeteer 等工具模拟用户请求，从而捕获真实的用户指标。真实的用户指标对于进行混沌工程实验的组织至关重要。通过监控实验期间真实用户受到的影响，团队可以准确地了解故障和中断将如何影响生产中的客户。关键的客户体验指标包括第一字节时间 (TTFB)、最大内容绘制 (LCP)、下一次绘制的互动 (INP) 和总屏蔽时间 (TBT)。

操作指标 — 干预措施衡量您以自动方式缓解故障的成功程度，例如，在使用复制控制器或自动扩展等机制重启 pod、任务或 EC2 实例期间，成功的客户端请求延迟。能够在故障期间进行自动干预与良好的用户体验直接相关。了解这些缓解机制随着时间的推移是否存在任何偏差至关重要。通过定义成功和失败的自动缓解措施的指标，您可以创建指导方针，帮助识别整个系统的潜在回归情况。

降低事故率 — 跟踪一段时间内的生产事故数量，并将该数字与混沌工程的采用相关联。预计严重事件的发生率将下降。

改善平均解决时间 (MTTR)-计算解决事件所需的平均时间，并跟踪这些数据，以查看混沌工程是否会随着时间的推移而有所改善。

提高应用程序可用性-使用服务级别指标来显示随着应用程序弹性通过混乱实验提高可用性的提高。

缩短上市时间 — Chaos 工程可以让您有信心更快地推出创新产品，因为您知道自己的应用程序具有弹性。追踪产品发布速度的提高。

降低运营成本 — 量化诸如警报噪音、操作负荷和管理应用程序的人工工作量之类的指标是否随着混乱实践的到位而减少。

增强信心 — 调查开发人员、站点可靠性工程师 (SREs) 和其他技术人员，以评估混乱工程是否增强了他们对应用程序弹性的信心。感知很重要。

改善客户体验 − 将混乱工程与客户的积极成果联系起来，例如减少服务中断、回滚和中断。