了解火的最佳时机就是当你身在火中。
-Jen Hammond, New Relic工程经理
几个月前，一个Cassandra数据库属于新的遗物工程团队之一的节点消失了。pof。走了。当时，团队有三个新成员，以及跑步手册和Ansible剧本他们通过管理Cassandra集群，他们很快就学会了，既有日期。
尽管如此，他们必须在没有任何帮助的情况下再次获得这个数据库节点 - 他们所做的任何帮助 - 但任务需要超过半小时。这是30分钟，新的遗物客户无法在该特定数据库节点上访问它们的数据。
除了这一点都是真的。Cassandra节点故障是一个模拟，我们所谓的“对抗的比赛日”的一部分是新的遗物高级站点可靠性工程师创造的一词David Copeland.。
一个homespun子集混沌工程-in您将故意引入系统的故障，以了解系统和团队如何管理它们的恢复 - 对抗性游戏日是一部分新遗物的网站可靠性最佳实践。在对手游戏日，恶意演员（对手）引入了我们系统的非生产版本的故障，以了解我们的团队准备恢复的程度。
在我们的日常运营中，我们通常不会进入一个游戏日子可以投掷我们的情况，所以我们没有看到潜在的问题。During adversarial game days at New Relic, for instance, we’ve discovered that a team didn't have a rollback mechanism for failed deploys or that cross-functional teams didn't have access to systems they needed access to in order to troubleshoot a failure.
我们使用游戏日来证明我们的可靠性实践。在现代软件世界中，失败是不可避免的。我们经常想到我们的系统令人难以置信的正常运行时间，然后被禁止进入自满状态。正如我们在开放式示例中所看到的那样，这可能会影响我们对计划响应意外事件的能力。在一天结束时，混乱的工程和对抗性游戏日子都是关于管理混乱——有可行的计划和明确的方向感。
阅读以了解更多关于为什么以及新的遗物运行对抗性游戏日的更多信息。
为什么要举办比赛日?
在里面斯特拉报告，由一群叫做的研究人员SNAFUcatchers,理查德·库克博士，“审查了后期的后期，以更好地了解工程师如何应对异常的复杂性......以及如何支持它们。”该报告确定，处理系统相同部分的团队成员通常具有系统所需的不同心理模型。这是一种正常的事态。
根据STELLA报告，你有你的代码和它所在的存储库;您有您的测试和验证套件，您生成的工件，以及这些工件运行的系统。所有这些东西都在表示线以下，表示线由部署工具、监视和观察工具以及ui和cli组成。你不直接和系统交互，而是用这些表示。你所拥有的关于系统的唯一信息来自这些表示——你从来没有真正“看到”你的代码运行，只有通过表示的反射。每个团队成员都看到了不同的反映。
这类似于柏拉图的“洞穴的寓言”一个哲学寓言，其中囚犯在洞穴中被背光投影所感知到墙上的阴影;直到他们释放出“无知的链条”，迫使洞穴，他们可以正确地看到和合理化自然界。以同样的方式，我们命名在我们的笔记本电脑显示器中运行的工具，我们称之为现实。如果我们没有完整的系统，我们的系统不可靠，我们忽略了我们危险的现实。
你什么时候有一个游戏日？
至少，您应该每季度运行一次游戏日，特别是如果您的系统擅长他们的服务水平目标（SLO）。如果将与客户的服务水平协议(Service Level agreement, sla)量化的性能指标(例如响应时间、吞吐量和可用性)超过了您为本季度设定的目标，那么您应该运行一个比赛日。团队往往会将越来越多的依赖项加载到高性能服务上，而不测试它们的弹性，这些依赖项在事故中会像多米诺骨牌一样倒下。
在奴役新团队成员是举办游戏日的一个很好的借口。在新的遗物，我们经常有一个对抗的游戏日，以准备新的团队成员“寻呼机义”。这不仅会练习他们对系统的知识，还会熟悉它们我们的事件反应过程。
最后，在向用户释放新功能之前，您肯定应该有一个对手游戏。没有对抗性比赛日，你不确定跳道顾客可能会击中什么。如果您有一个“摇滚实心”产品，则一般可用性游戏日可能会变得相当无聊，但您的随叫随到的工程师可能会在发布后的前几个晚上更容易睡觉。他们也可以更好地装备来处理紧急情况，应该有一些新功能出现问题。
谁应该发挥对手？
对手是一个关键角色，通常由对你要攻击的系统具有最完整心智模型的人扮演。这也是测试“公共汽车因素”的好方法——如果这个(通常是高级)人去度假(或被公共汽车撞了)会发生什么?在这个人不知情的情况下，团队的其他成员将如何应对现实世界中的事件?
在分配对手角色时，您也可以是创意：S也许您最新的团队成员应该是对手？撰写计划来测试退伍军人团队是新成员快速升级的好方法。
在制定对抗计划时，我们通常会考虑上一季度发生的事件。我们真的解决了潜在的问题吗?这一事件改善了还是恶化了我们对自身系统的心智模式?复制事件是确保您的团队的心理模型实际反映系统现实的好方法。
普通的软件知识应该不是成为游戏日的一部分。换句话说，如果您对您的系统有关可以在五分钟内回答的问题，那对对手游戏日不是适当的目标。请记住，游戏日是发现您团队集体知识中缺少的东西;您想揭示您的团队对系统不了解的事情。考虑到这一点，新遗物的典型游戏日可以跑到三个小时。
谁应该参与?
最后一次在预期一个主要的新功能GA期间将游戏日放在一起，我包括两个工程团队，因为我希望他们能够为其他团队练习管理事件 - 在一个真实的事件中，第一个响应者可能不是部分拥有根本原因的团队。
在这个特殊的游戏日，我混合团队创造了一个团队的反应和一个团队的对手。对手对新功能发起了攻击，随着比赛的进行，响应团队发现即使他们正在使用报警的最佳实践，他们有警报，不发送通知。设计该功能的团队意识到他们在警报中犯了一些错误。他们回到了绘图板，修复了他们的警报，然后我们有另一个游戏日，他们的警报正常表现。
在对手游戏日蜷缩在一起可能会有很多乐趣，但不要让地理物流妨碍。当您有计划生意见的事件时，您并不一定会在同一个房间内，所以有远程参与者是一个好主意。事实上，包括远程参与者将帮助您测试在现实世界事件中使用的通信工具。
你的游戏日可能会给其他团队带来意想不到的结果，所以一定要提前进行社交活动。实际上，具有依赖于您的下游服务的团队可能会发现，这是一个很好的机会，可以查看他们的系统是否对上游停机具有弹性，或者他们的警报是否配置正确。
等等，我们不能在生产中进行游戏日
在理想的世界中，您可以在生产环境中运行您的对抗性游戏日子;但是，您可能无法在您的系统中引入故障，这些系统可以追待您的用户。如果你没有服务水平指标(SLIs)或者错误预算如果你不知道自己的正常运行时间是否能够支持一个游戏日，那么不要让这些问题阻碍你在任何环境中运行游戏日。使用开发或分段环境，或在沙箱中启动系统的一个版本。重要的是，你的游戏日运行系统版本应该与用户的日常体验非常相似。你在任何对抗性游戏日的目标都是改善你系统的心智模式，从而改善你的平均分辨率(MTTR)当事情不可避免地出错时。
您在对抗的比赛日中使用了哪些工具？
有很多巧妙的工具可以用来将故障注入系统，但有时简单最好。看看你的建筑图，然后问可能出错了什么。您的客户可能会对您的系统进行误认为是什么？恶意演员可以做些什么？弄清楚这些答案，然后写一个简单的Bash脚本来模拟该行为。
在新的遗物，我们喜欢毒性，一个开源工具Shopify。Toxiproxy允许您通过代理和客户机“篡改”相互依赖的服务之间的网络连接。例如，在最近的一个游戏日测试API时，我们使用Toxiproxy来切断API服务和数据库之间的连接。当我们这样做时，API响应一个错误消息，其中包括数据库的IP地址——这很有趣，但我们不希望客户看到。
你可以在自己的游戏日使用许多工具。看看这是GitHub上的混沌工程资源列表。
像实际事件一样运行您的游戏日
把你的比赛日当成真实世界的意外事件。指派一名抄写员记录故障排除中的软点以及监控和警报中的漏洞。邀请客户支持代表参与，这样他们就可以解释可能的客户影响。您可能正在测试您的团队对系统的心理模型，但是他们需要了解系统故障如何影响客户。
在游戏日期后48小时内，持有一个回顾一下，并询问有很多问题。例如：
- 什么可能更好？你的团队学习了什么？您的系统的心理模型是否有所改善？
- 你的监控和警报工作是否按计划进行?
- 你的MTTR是什么？你能改进它吗？
- 您的团队能够将运行本自动化以更快地进行缓解吗?
- 您应该更新您的架构图吗?
- 对依赖团队的警报和监控是否有效?
- 您是否需要重构这些依赖服务之间的关系?
复古的关键结果很简单：您分配工作以提高系统的弹性。
分享您的学习
最后，分享你学到的东西。希望你能激励其他球队举行自己的对抗性比赛。
最后，除了所有这些建议之外，没有错误或正确的方法来拥有对抗的比赛日，不同的团队就应该对他们应该测试的不同需求。使用对抗游戏日子迫使你的球队出于寓言洞穴。您系统的完整统一视图可能很难看，但这通常是揭示真理的最佳方式。
