主要在生产环境中故意破坏东西是混沌工程中的口头禅之一。但是当你把你的计划告诉你的工程经理或产品负责人时，你往往会遇到一些阻力。
他们的担忧是有道理的。如果破坏东西是不可逆的怎么办？最终用户会怎样？我们的支持票系统会很忙吗？
本文将帮助您缓解这些担忧，并在您的组织中开始混沌工程。
什么是混沌工程？
行业领导者对混沌工程有多种定义。这是我的一个视频中的一张幻灯片：
混沌工程定义
混沌工程定义
入门
混沌实验的目标是了解我们的系统在生产中发生灾难性故障时的行为方式以及我们的系统的弹性。这使我们有机会优化和解决问题。
以下是您如何开始混沌工程实践。
从你的经理那里得到支持
第一步是获得经理的批准，以便在测试环境中进行实验。通常，混沌实验应该在生产中进行——但我建议您采取一些小步骤。您可以在任何有效环境中进行混沌实验。如果生产环境不可用，我建议在非生产（或阶段）环境中运行实验。
解释您通过执行混沌实验所带来的价值，例如：
识别故障和瓶颈
弹性验证
缩放验证
了解架构
系统总是失败。在运行你的混沌实验之前，彻底了解你的系统架构。与您的开发人员、架构师和 SRE 召开工作会议，并就应用程序架构集思广益。确保每个人都了解上游/下游组件、依赖关系、时间表、比赛日安排等。这将帮助您更好地了解系统可能出现故障的地方。
写假设
开始编写假设列表，例如，给定 Kubernetes 部署，删除一个 pod 不应增加典型负载下的服务响应时间。另一个例子：负载均衡器必须只将请求路由到健康和运行的节点。
写假设时没有对错之分。这是一个迭代过程。
我们的目标不是 让我们的假设“通过”或“失败”。检验每个假设将使我们有机会了解我们的系统。
最小化爆炸半径
总是从小处着手。通过最小化爆炸半径来减少运行混沌实验时对最终用户的影响，例如，不删除 Kubernetes 集群中的部署，而是删除 pod 并验证弹性。即使您要删除部署，也要确保 GitOps 有效，以便 GitOps 流程会自动创建部署。
另一个例子：不是关闭集群中的所有节点，而是关闭 50% 的正在运行的节点，或者不是关闭整个区域，而是关闭一个区域。
一旦混乱过程成熟并且您的团队处于舒适区域，您就可以慢慢增加爆炸半径。
计划比赛日
提前计划并始终为您的“比赛日”制定 B 计划。至少提前一周通知你的所有利益相关者，并在 Slack（或你公司的协作平台）中启动一个统一的沟通渠道，定期发布更新。我建议在你运行第一个实验时让你的开发人员随时待命——或者你的 DevOps 或 SRE 团队。
运行你的第一个实验
没有人是完美的。如果您在运行第一个实验时遇到问题，那也没关系。及时发布更新并通知所有利益相关者。
如果您能够成功运行您的第一个实验，这是我的虚拟表扬。
相信我，运行第一个混沌实验就像坐过山车一样刺激。如果事情进展不顺利，请确保您能够在 DevOps 或 SRE 团队的帮助下停止实验并恢复基础架构。
在实验期间，监控您的可观察性仪表板并观察诸如响应时间、磁盘利用率、通过/失败交易、健康检查等重要指标。
分析
实验完成后，将所有观察结果记录在电子表格中，对其进行分析，并确定您的假设结论。同样，没有通过或失败之分；这都是学习。
头脑风暴
安排与您的开发人员、架构师和 DevOps/SRE 团队的会议来讨论您的结论。这将帮助团队了解判决并解决您发现的问题。一旦问题得到解决，您就可以重新运行实验。
如果您发现系统具有弹性，您可以尝试增加爆炸半径并重新运行实验。
下一步
在运行各种游戏日后，您可以了解团队动态、系统性能等。下一步是将混沌实验嵌入到您的开发人员工作流程中，这样混沌实验就会自动化，这将为您的团队带来更多信心。