混沌工程入门

主要在生产环境中故意破坏东西是混沌工程的口头禅之一。但是当你把你的计划告诉你的工程经理或产品负责人时，你经常会遇到一些阻力。

他们的担忧是有道理的。如果破坏的东西是不可逆转的怎么办？最终用户会发生什么？我们的支持票系统会忙吗？

什么是混沌工程？

行业领导者对混沌工程有各种定义。这是我的一个视频中的一张幻灯片：

入门

混沌实验的目标是了解我们的系统在生产中发生灾难性故障的情况下将如何表现以及我们的系统的弹性。这使我们有机会优化和解决问题。

以下是开始混沌工程实践的方法。

从您的经理那里获得支持

第一步是获得经理的批准，以便在测试环境中进行实验。通常情况下，混沌实验应该在生产环境中进行——但我建议你采取一些小步骤。您可以在任何有效环境中进行混沌实验。如果生产环境不可用，我建议在非生产（或阶段）环境中运行实验。

通过执行混沌实验来解释您带来的价值，例如：

了解架构

系统总是失败。在运行混沌实验之前，请彻底了解您的系统架构。与您的开发人员、架构师和 SRE 进行工作会议，并集思广益应用程序架构。确保每个人都了解上游/下游组件、依赖项、时间线、比赛日安排等。这将帮助您更好地了解系统可能出现故障的位置。

写假设

开始编写假设列表，例如，给定 Kubernetes 部署，删除一个 pod 不应增加典型负载下的服务响应时间。另一个示例：负载均衡器必须仅将请求路由到健康且正在运行的节点。

写假设时没有对错。这是一个迭代过程。

我们的目标不是 让我们的假设“通过”或“失败”。测试每个假设将使我们有机会了解我们的系统。

最小化爆炸半径

总是从小处着手。通过最小化爆炸半径来减少运行混沌实验时对最终用户的影响，例如，不是删除 Kubernetes 集群中的部署，而是删除 pod 并验证弹性。即使您正在删除部署，也要确保 GitOps 生效，以便 GitOps 流程自动创建部署。

另一个例子：不要关闭集群中的所有节点，而是选择 50% 的正在运行的节点，或者不要关闭整个区域，而是关闭一个区域。

一旦混乱过程成熟并且您的团队处于舒适区域，您就可以慢慢增加爆炸半径。

计划比赛日

提前计划并始终为您的“比赛日”制定 B 计划。至少提前一周通知您的所有利益相关者，并在 Slack（或您公司的协作平台）中建立统一的沟通渠道，定期发布更新。我建议你在运行第一个实验时让你的开发人员——或者你的 DevOps 或 SRE 团队——随叫随到。

运行你的第一个实验

没有人是完美的。如果您在运行第一个实验时遇到问题，没关系。及时发布更新并通知所有利益相关者。

如果你能够成功运行你的第一个实验，这是我在后面的虚拟拍拍。

相信我，运行第一个混沌实验就像乘坐高惊险级别的过山车。如果事情不顺利，请确保您能够在 DevOps 或 SRE 团队的帮助下停止实验并恢复基础设施。

在实验期间，监控您的可观察性仪表板并观察诸如响应时间、磁盘利用率、通过/失败事务、健康检查等重要信息。

分析

实验完成后，将所有观察结果记录在电子表格中，对其进行分析，并定义您的假设结论。同样，没有通过或失败；这都是学习。

头脑风暴

安排与您的开发人员、架构师和 DevOps/SRE 团队的会议，讨论您的判断。这将有助于团队了解裁决并解决您发现的问题。解决问题后，您可以重新运行实验。

如果您发现系统具有弹性，您可以尝试增加爆炸半径并重新运行实验。

下一步

在跑完各种比赛日后，您可以了解团队动态、系统性能等。下一步是将混沌实验嵌入到您的开发人员工作流程中，以便将混沌实验自动化，这将为您的团队带来更多信心。

混沌快乐！