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

原文：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的最佳实践。有效的过后复盘是个很广的话题，但我但愿你将分享在故障应急时的观点与假设，没有反映系统行为的预期或可观察性的工具链。经过过后复盘，你会获得一组能够修复故障场景监控可观察性的改进项。你也会有一些关于如何改进故障恢复弹性的想法。

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

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

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

• 对于深陷“无止境”学习进度深感不适的
• 开发者会经历以最新系统行为造成的心智模型的故障，而不是在面临系统故障电话通知时才遇到。
• tl对于新团队成员是否已经准备好处理oncall电话而且有提升效率的有效方法会有信心。

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

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

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

---

本文来自微信公众号「麦芽面包」，id「darkjune_think」开发者/科幻爱好者/硬核主机玩家/业余翻译家/书虫交流Email: zhukunrong@yeah.net