QA工程師剛出現時，大部分工作都需要手動完成。隨着自動化概念的出現，QA 工程師的重要性開始下降，美國互聯網公司中很大一部分已經不再由 QA 工程師負責。那麼，這些公司開始通過什麼方式保證系統穩態呢？在科技圈，很多技術概念的出現都要早於這一名詞的誕生，混沌工程也是如此。簡單來說，混沌工程旨在建立合成事件以測試彈性工程假設是否成立，雖然這一名詞聽起來有些陌生，但其實是一種歷史悠久的文化，只是最開始並沒有將這一系列方法稱作混沌工程，而是將其作爲“工程”的一部分。
多年來，軟件行業一直在利用混沌工程的方法支持單元測試，但隨着軟件組件變得愈發複雜且依賴性更強，行業開始迴歸舊有方法並對混沌工程進行重建。在 QCon 全球軟件開發大會（上海站）2019 即將召開之際，InfoQ 就這一話題採訪了 LinkedIn 的資深 SRE 工程師 Brian Wilcox，聽他聊對這一技術的具體想法以及可推薦的實踐工具。
混沌工程遵循路徑與 QA 並無區別
很多文章都會在開篇先闡述混沌工程的具體概念，對於這樣一個新的技術，確實需要在開篇理清邊界，這樣才方便接下來的討論。在 Brian Wilcox 看來，混沌工程遵循的路徑與 QA 並無區別。在 QA 工程師剛剛出現在軟件行業中時，大部分工作只能以手工方式完成。大部分 UI 測試以及“施加破壞以觀察其是否中斷”的方法都以混沌工程這一概念爲基礎。隨着集成測試、發佈 commit/pull 請求驗證以及持續集成等自動化概念的出現，QA 工程師的重要性開始下降。在美國，很多互聯網公司的 QA 工程師主要工作就是通過模擬與合成流量進行整體驗證。
隨着工程師們創建的系統越來越複雜，活動部件越來越多，出現的問題也就越多。組織希望建立自動或者手動流程來繞過生產故障，或者從故障狀態迅速恢復至穩定狀態。這些具體流程被稱爲彈性工程。彈性工程的核心問題在於糾正效果驗證。當然，企業可以選擇等待故障自然發生，也可以利用混沌工程等手段主動製造故障事件。後一種方式的優勢在於及時性更強、爆炸半徑更小，而且由此建立起的彈性信心也足以指導未來可能出現的真實故障事件。
混沌工程讓組織能夠將彈性從理論層面升級到實踐層面。接下來，組織就可以依據這些新的信息採取改進行動，或者藉此斷定“目前的彈性是否足夠大”。如今，大多數考慮採用混沌工程的企業都意識到，混沌工程在本質上與“施加破壞以觀察其是否中斷”沒什麼區別，這是個很好的起點。但一定得注意遺留問題以及預期目標：以小規模手動方式爲開端，努力引入自動化與驗證機制，而後將其直接集成至構建流程中。
那麼，組織應該從哪裏起步？
混沌工程的引入條件
組織的起步點應該是來看最嚴重的問題存在於哪裏，什麼地方出現變化會造成最大影響。——Brian Wilcox**
在開發混沌工程實驗時，牢記以下原則將有助於實驗設計。Brian Wilcox 同樣分享了自己對於這幾大原則的看法：
- 建立穩定狀態的假設；
- 多樣化現實世界事件；
- 在生產環境運行實驗；
- 持續自動化運行實驗；
- 最小化“爆炸半徑”。
先從穩態問題開始。Brian Wilcox 認爲，建立穩定狀態的第一步往往始於錯誤率——即當一切“順利”推進時，系統會向用戶返回多少錯誤。隨着企業走向成熟，大家往往會進一步轉向 SLO 或者 SLA。隨着 SLO 引入延遲與體積大小等指標，組織也將獲得更好的穩定狀態指標和手段。到目前爲止，Brian Wilcox 認爲最好的穩態類型是真實用戶監控與 SLO 的組合，這也是組織能夠獲得的、最接近“真實用戶體驗”的評估方式。
除此之外，混沌工程將“實驗”作爲基本單位，如上“在生產環境運行實驗”、“持續自動化運行實驗”，這有種科學研究的感覺。Brian Wilcox 建議，開發者可以先從假設起步，而後圍繞假設設計出實驗、儘可能減少其中的變量，以獲取一個能夠反覆驗證的可靠結果。對於混沌工程，問題在於開發者幾乎很少控制未知變量的數量，而這些變量確實會在實驗過程中對系統產生影響。“最小化爆炸半徑”正是爲了減少對系統的影響，同時得出足夠可靠的結果以帶來有意義的見解。
不過最重要的是，組織需要思考“需要多少指標才能對影響進行量化？”舉例來說，如果我在一家運送包裹的物流公司工作，那麼我爲整個系統設置的穩定狀態可能是包裹在未送達或者送達後發生損壞的機率。但是，如果單純分析最後一英里的交付過程，那麼我就不需要關注區域內損壞或丟失的包裹數量，而只需關注送貨人員造成的損壞或丟失數量，並把衡量範圍縮小到這一點上。
Brian Wilcox 也會採取這種方法確定該如何使用混沌工程：一切取決於到底想解決什麼問題。混沌工程目前在業界很有吸引力，但要想實踐，首先得思考如下基本問題：證明系統彈性水平的目標是不是爲了吸引客戶？是否經常因爲生產狀態不夠穩定而失去客戶？是否打算減少運營費用？是否正在努力與現有客戶建立信任關係？打算解決的問題究竟是什麼？
無論是分段環境還是生產環境，開發者都可以在任意階段啓動彈性工程機制。Brian Wilcox 表示，如果可以利用混沌工程證明系統能夠在分段環境中正常運作，那也會對系統在生產環境中的運作狀態抱有更強信心。當然，這種信心只存在於理論層面，即在理論上，系統應該能很好地應對生產環境的挑戰。根據谷歌 SRE 指南所言：“只要沒有經過實際測試，就可以默認其已經發生故障。”在混沌工程的推進中，可以最小化實驗爆炸半徑，從而避免引發嚴重問題甚至造成不可恢復的後果，但最終，我們仍然需要在生產環境中進行測試。
舉例來說，如果遇到寫入磁盤數據經常損壞這類問題，基本思路當然是不要破壞整個數據集，而是爲開發人員或者運營人員保留明確目標並執行測試。通過這種方式，開發者能夠瞭解到消費這部分數據的系統能否正常識別並更正損壞問題，或者說系統能否正常處理損壞問題。此外，雖然在生產環境中進行測試也很重要，但通過分段環境測試建立信心，也是減少爆炸半徑的一種好辦法。直接關閉生產環境中的系統可能沒有實際意義；不妨先從負載均衡器入手，確保自動化機制能夠處理生產環境中的這一類故障，而後再切入真實生產環境。這樣，無疑會對系統的應對能力抱有更充分的信心。
領英內部用到了一種流行機制，即利用 HTTP/RPC 標頭來指示客戶端何時將下游請求識別爲失敗。由於 HTTP 標頭被限定爲單一請求（與能夠在整個會話中持續存在的 cookie 不同），因此，開發人員能夠簡單通過停止發送標頭來輕鬆恢復至良好狀態。
實踐人員及工具
雖說混沌工程的呼聲很高，但組織將其應用到實踐中時還是需要考慮一些現實問題，畢竟如果對生產環境產生影響，後果將非常嚴重。Brian Wilcox 認爲，混沌工程最吸引人的地方在於：“讓我們破壞生產環境中的一切！”。但是，其它行業一直將故障測試標準視爲“工程”的固有組成部分。Brian Wilcox 表示，將故障因素剝離成單獨的“一類問題”纔是真正的風險。畢竟產品中包含數以千計的細小決策，因此，所有人都有必要了解彈性工程，這一點與應用程序安全性保障非常類似。之所以出現這麼多新的保障性模式，就是因爲軟件工程師面臨的保障環境越來越惡劣——大量新框架、新語言以及全新最佳實踐的出現，使開發人員很難保障產品彈性。人類總會選擇阻力最小的道路，因此除非能夠將混沌工程作爲單元測試中的必要元素，否則大部分人還是會把彈性工程視爲“別人的工作”。
遺憾的是，由於混沌工程的特殊性及其與應用程序堆棧的集成程度問題，目前的相關工具還很不完善。在工具方面，Gremlin 能夠與 AWS、GCE 以及 Azure 等順暢對接，感興趣的開發者不妨將它作爲混沌工程的起步選項。另外，網飛公司也在 GitHub 上發佈了大量 Simian Army 源代碼——但目前已經不再維護。
從 Brian Wilcox 的角度看，分佈式系統最大的控制面在於客戶端，從客戶端的角度出發，一切都屬於網絡節點。當存儲節點上的磁盤發生故障時，節點本身往往無法憑藉彈性設計解決這類故障。相反，遠程客戶端的靈活性可能更大，例如其在收取故障警告後決定繼續使用該數據存儲區、還是移動至運行狀態數據更好的另一存儲區。憑藉着這一優勢，最理想的模擬應用場景應該是以資源故障爲基礎，探索優雅而順暢的錯誤處理途徑。比如，網站能在發生故障時優雅地進行頁面降級嗎？網站能否繼續提供大部分內容，而非直接癱瘓且無法向用戶提供任何服務？
至於誰該關心這個問題，Brian Wilcox 的答案是每個人都該關心，這不僅僅是開發人員或者架構師，產品所有者以及管理者都需要權衡並描述應用程序“失效的可能性”，以及哪些組件“有可能導致站點癱瘓”，比如無法投放廣告時，是否應該同時停止頁面內容的正常顯示？或者說，應該繼續提供正常的頁面內容，並在廣告服務恢復後再考慮運營收益的問題？
事實上，大多數高級工程師與架構師都很清楚故障的不可避免特性，而且會在產品開發初期就考慮該如何處理某些故障；然而，用於站點運行的大部分代碼實際是由初級工程師們編寫的。初級工程師們可能還沒有建立起故障終會出現的意識，也無法理解應用程序失敗並不等同於職業失敗。如果能夠讓 CEO、項目經理以及軟件工程師以生產夥伴的姿態坦然討論失敗問題，相信各個層面都將獲得更好的解決方案。
混沌工程並不一定非常複雜。如果已經擁有了充分的信心，同時配合適當的監控，那麼“sudo poweroff”也不是什麼大事。Brian Wilcox 的一位同事最近談到了 LuanchDarkly，用 python Flask 中間件執行請求中斷。另外，也有不少經典的系統管理工具值得一試，例如使用“iptables”阻斷入口與出口，或者使用“tc”來提高延遲，並查看負載均衡器以怎樣的速度丟棄集羣中緩慢及損壞的節點等。具體方法很多，並不是只有粗暴地關閉機器電源。
結束語
最後，Brian Wilcox 建議組織應該把混沌工程視爲框架中的一種默認選項。gRPC、Rest.li、Django、Flask、Request Libraries 等都應該在此列，應該讓開發人員能夠更輕鬆地測試自己的應用程序。混沌工程就應該像單元測試裏的 Pytest 與 Java Mocks 一樣簡便易行，應該充分強調 pychaos 與 Java Chaos 的重要地位。雖然根據企業中原有監控方式的具體特性，可能很難了解全面引入混沌工程所帶來的影響。但這種標準化工作仍然意義重大，而且組織完全有能力實現這一目標。此外，Brian Wilcox 堅信豐富工具的全面出現將只是時間問題。
採訪嘉賓：
Brian Wilcox，現就職於 LinkedIn，任 Staff Site Reliability Engineer。Brian 是一位跨學科工程師和實踐愛好者，大部分時間，他都在試圖將結構的最佳原則、軟件和系統工程結合到可擴展、健壯和有彈性的系統中。他在 LinkedIn 工作了 5 年，最近專注於彈性工程和混沌工程工具。
相關文章：
《混沌工程的力量：阿里周洋親述這一技術背後那些事兒》
《TiDB 混沌工程實踐：如何打造健壯的分佈式系統？》
《PingCAP 唐劉：如何利用混沌工程打造健壯的分佈式系統？》
《披荊斬棘：論百萬級服務器反入侵場景的混沌工程實踐》
今年 10 月，Brian Wilcox 將在 QCon 上海 2019 分享混沌工程在 LinkedIn 的實踐經驗，讓你對系統的彈性建立起信心。更多精彩案例請關注 QCon 上海 2019 ，目前大會日程已經上線，感興趣的用戶可以訪問 QCon 全球軟件開發大會（上海站）2019 官網，目前大會 9 折報名中 ，現在報名立減 880 元，團購可享更多優惠！有任何問題歡迎聯繫票務小姐姐 Ring ，電話：13269076283 微信：qcon-0410。