混沌游戏日:混沌的手把手指南

Chaos Gamedays: A Step-by-Step Guide to Chaos

原文：Chaos Gamedays: A Step-by-Step Guide to Chaos

https://dzone.com/articles/chaos-gamedays-a-step-by-step-guide-to-chaos

翻译：时序

当你第一次在云上部署应用，感觉很棒。你只要告诉系统做事情，然后你的代码就可以给每个人用了。而过一会，你很可能就会经历系统失败。有可能是运行代码的实例，到用户的网络，到db的网络，或者其他东西产生失败。

再过会，失败就会看起来像混沌：失去控制，无确定性，不受欢迎。

进入混沌

你可能以前听过混沌工程，“为什么我会想做那个？” 混沌工程探索主动理解系统经历失败的行为，让开发者可以决定，设计，实现和测试弹性策略。它让你知道失败会发生，但你可以选择在下午两点脑子清醒时看到它，而不是半睡半醒，压力山大的凌晨2点。

混沌Gameday

混沌游戏日时一种走进混沌工程的好方式。在混沌游戏日，“灾难大师（MoD）”做决定，经常是秘密的，系统将会经历什么样的失败。他活她一般会从一些简单的问题如容量损失，或网络中断。你会发现，就像我们做的，直到你可以清晰简单地看出简单case，直接从更难或更复杂的失败不是一种建立信心的好途径。

所以，我们看看如何运作一个游戏日。

混沌游戏日：计划故障

将团队召集到一个房间（物理或虚拟的），灾难大师宣布“事件启动”并之后开始规划故障。一个团队的队员作为第一个应急响应来尝试发现，分类和缓解灾难大师导致的问题。这位队员可以尽量求助其他队员来让他们来帮助发现发生了什么事。正常情况，团队可以在花费低于75%给定时间发现并解决问题。当处理完或响应时间结束，灾难大师会恢复故障然后团队会开始做一个故障复盘。

混沌游戏日：升级

在刚开始是，很有可能发生的是，团队不能发现或解决问题。灾难大师可以升级故障将问题变得更可见，因为全部当机是唯一可观测到的故障。如果发生这种问题不要太担心：没有为故障场景测试过的可观测能力经常显示不出问题。清楚这个是修复你的可视化能力的第一步，最终可以给你的用户一个更好的体验。

混沌游戏日：事后复盘

事后复盘应该紧随事件处理（如果有）或随像[PagerDuty](https://response.pagerduty.com/after/post_mortem_process/)的最佳实践。有效的事后复盘是个很广的话题，但我希望你将分享在故障应急时的观点与假设，没有反映系统行为的预期或可观察性的工具链。通过事后复盘，你会得到一组可以修复故障场景监控可观察性的改进项。你也会有一些关于如何改进故障恢复弹性的想法。

对于混沌游戏日的核心是，至少，不断重复故障并检验对于应用上做的系统可观测性与弹性所做的改进。

混沌游戏日如何改进你的团队

如果你常态性的进行此内容，你可以看到你团队的变化。作为混沌游戏日的第一响应当班人员，尽管这不是“真的”，建立了生产环境宕机第一响应值班人的压力承受能力。你的开发人员并不只是获得了了解他们负责系统与系统如何失败的信心，他们也开始习惯承受压力。

一些具体的收益：

• 对于深陷“无止境”学习进度深感不适的

• 开发者会经历以最新系统行为形成的心智模型的故障，而不是在面临系统故障电话通知时才遇到。

• tl对于新团队成员是否已经准备好处理oncall电话并且有提高效率的有效方法会有信心。

系统中的变化是戏剧性的。开发者，常态性的经历系统故障已经是他们工作的一部分，所以他们开始进行面向失败的设计。他们决定如何进行变更并且让系统具有可观察性。他们小心地选择弹性策略因为弹性这个名词已经是他们知道并经常提到的。

系统并不是因为在混沌游戏日遇到的特定问题才变得有弹性的，它们变得更有弹性是因为，开发者知道了场景的已知问题而通过设计具有了弹性。

开始混沌工程的路程就像“sudo halt”一样简单。它可以让你的团队和系统以开始时不能想象的路径成长。如果你想在故障应急处理时更有信心，开心的开发者，弹性的系统，我鼓励你开始这个旅程。我们很高兴能提供帮助。尽管向@1mentat提问题。

---

本文来自微信公众号「麦芽面包」，id「darkjune_think」

开发者/科幻爱好者/硬核主机玩家/业余翻译家/书虫

交流Email: zhukunrong@yeah.net