混沌遊戲日:混沌的手把手指南

原文：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