文章段落
Chaos Engineer Introduction
建立了你的資訊系統或IT服務平台給前端的使用者，大多數的人都是想到建立備援系統，或者是出事之後才從先前的事件/教訓中去強化這套系統或平台。但從已經發生的事件中去學習的代價是昂貴的。代表在事件發生的當下公司的業務停止運轉，企業承受著巨大的營業損失。
哪麼有沒有方式能夠減少這一類的事件發生呢？換句說我有沒有可能強化這一套系統平台服務呢？若你有這種想法的話，哪麼Chaos engineering混沌工程將會是你的解方。
哪麼什麼是Chaos engineering混沌工程呢？
簡單的來說“就是透過試驗性的方式來找出系統弱點的證據並在這個弱點發生前就先解決它“，這一個方式也是屬於風險管理中mitigation(減緩）的方式。
另外在這個混沌工程原則的網頁中，給混沌工程下了一段定義
Chaos Engineering is the discipline of experimenting on a system
in order to build confidence in the system’s capability
to withstand turbulent conditions in production.
透過這一套方式來增加平台的”可靠度“，這一套系統將著中在一些預期幾乎不會發生但又不可並避免會發生的灰犀牛事件來增加系統的高度彈性。而透過尋找系統點的稱呼有時也稱為”Dark debt”，開發人員稱為 technical debt。
讓我們假設一個簡單的系統，
User —–>Service A—>Service B
幾個簡單的假設
如果Service B失效，Service A會發生何事？
如果Service B回應很慢，Service A會如何處理？
如果Service A與B 之間的網路連線異常會發生麼事？
等等諸如此類會影響系統服務的事件。
也許你會很有信心的說，這一些我在設計時都“完全”的考量到了。但你敢百分之百保證你的系統沒有問題嗎？可以承受任何的狀況或事件嗎？
如果沒有，哪麼透過混沌工程將可不斷增加系統的穩定度。而在雲端服務中實作此類的測試更為方便，例如透過chaos tool kit你可以透過這一套工具針對你的GCP的VM做此類性的測試。
混沌工程不只著重在技術面而是著重在整個“社會技術系統(Sociotechnical system)”的方式，從Developer/Operation/Application/Service/Infra/Platform/Monitoring/Pipeline/Documentation/Tickets/Traffic/Users/Third party等等全面性探索的方式來找出系統的弱點。
鎖定系統的Dark Debt
有三個方面是可以探索系統可能的弱點，分別是
1. Platform 平台
2. Application 應用程式
3. People,Practices and Process 人員/作法/過程
平台的部分是整個Infrastructure level 基礎建設, 從硬體，虛擬層到K8s等都算是平台的一部分，Application就是程式再來就是公司的組織文化/流程/人員等管理面的部分。而上述的這一些層面都會影響到系統的弱點。
哪流程會有哪些呢？基本上有三個步驟
1. 我們完全了解這套系統的運作方式嗎？
2. 探索–利用一些混沌工程的工具來做根據你的假設來做自動化探索。如上面介紹針對GCP平台的自動化工具
3. 找到弱點–針對弱點加以改進
然後再重新重第一個步驟做起週而復始的循環。為什麼要這麼做呢？因為現今的雲端環境之下系統可能一直都在變動。一天可能有兩三次的小改版，一週可能有一次大改版。在這種狀況下弱點始終可能都不盡相同。
該從哪個環境開始呢？
既然是探索式且為主動的試驗性，哪麼我們該從哪裡開始呢？因為每個環境的狀況可能不盡相同，即使現在IaS(infrastructure as a code)，能夠讓所有環境(Prd/Stage/Dev/Sandbox等）趨近ㄧ致，但非正式環境可能就沒有真正的外來使用者，哪麼測試起來可能也不盡相同。
哪麼我們需要做的就是控制“影響範圍”，在這套理念下我們先從非正式環境且測試時能夠控制影響的服務。就是測試中發生最糟的狀況我們都能排除。
為了能控制影響範圍，在過程中“監測”系統所有的反應就變得極為重要。每次試驗的範圍逐步加大之前都需要看到所有的監測指標的反應。
以上就是混沌工程簡單的介紹，之後還會介紹其他細節的部分。
