混沌工程的主要目的是為幫助你提高對系統的信任度。在一些已知或未知的風險下若這些風險發生時還能夠持續運作下去，所以釐清整個系統的維運風險清單是你建立混沌工程的第一步需要做的。但不是直接做測試，例如斷開網路，或增加系統或網路的延遲性。你需要一套科學的方式來找出這些風險清單，並利用混沌工程驗證這些風險是否真的存在。
從試驗開始嗎？
既然chaos engineering是一套科學的方式方式，哪直接試驗應該就能很快驗證了。但什麼樣的試驗呢？但一套複雜而龐大的系統所需要的花費也是複雜而龐大的，而且可能會花費更多的資源及時間來計畫與執行。
但我們必須先弄清楚什麼樣的試驗對我們的系統是最有價值的，避免資源與時間的浪費。在開始之前我們要先問自己，我們的系統有什麼可能出錯的地方，製作假架設性問題，而這些架設性問題清單就是我們的的風險清單而我們必須使用chaos engineer來驗證這些風險是否真的會發生。
這個風險清單通常會來自兩種地方
1. 從過去發生的事件來分析學習, 也就是lesson learned
2. 沒有發生過的事件，但我們會自問。這一套系統什麼狀況可能發生？或是在維運這一套系統時什麼 事會讓我們擔心的呢？
從過去的發生的事件來做分析學習應該是一個不錯的開始，但這些事件既然已經發生了你應該也會在事後修正它。chaos engineering能做的事是再次驗證這些已知發生的事件再次發生時系統能不能地承受它而不影響系統的正常。而且若要從leesson learned來做驗證學習代價通常是龐大的，代表發生的當下公司的營運已經發生問題了。用公司的營運來當lesson learned，我想如果你是老闆你應該也不會同意這種做法。
Chaos engineering採取的是更主動的作法，在問題還沒有影響到系統維運之前就發現它修正它。哪麼從“沒有發生過的事件”這種假設性問題的清單我們可以怎麼做呢？這種假設性清單其實就已經在描繪你的整個系統架構。
從何處開始建立這種假設性問題呢？
有幾個地方可以供參考
1. 人員/流程/施作方式
例如：
什麼人/部門在為這套系統服務？目前CI/CD流程是怎樣的？我們有什麼監控系統？什麼人/部門需要回應監控？等等這一些非關技術面問提。
2. 應用程式
例如：
程式對timeout的回應是什麼？接受到不認識的資料格式會怎麼處理？
3. 平台
例如：
什麼樣的平台服務是系統在使用的，是K8s?還是Cloud 的serverless 功能？
4. 基礎建設
例如：
什麼樣的VM/網路/資料中心是系統在使用的
根據以上這幾個部分來描繪你的系統架構，你就會能更清楚在每一個部分裡。有哪些問題可能會存在，細節越清楚你就越能發現整個系統可能有哪些風險/弱點存在。
在詳細描述系統架構的同時你可以問自己這一些問題
Q1 : 這部分可能會失效嗎？
Q2 : 這一部分以前有發生過問題嗎？
Q3 : 如果發生問題了，哪系統將承受怎樣的衝擊？
寫下這些架設性問題，並且能描述這些問題的更多細節這需要相關的人員作出腦力激盪。我們可以讓相關人員在腦力激盪時把問題一一的寫在卡片上，例如
“DB cluster失效”
每個架設性問題都是一張卡片。
為了讓這些收集的的問題更具使用性，你需要一種工具來驗證。這是可靠性工程師會用到的工具箱，稱作Failure mode and Effect Analysis，這個工具會幫助你驗證哪一個假設性問題真的應該進到Chaos engineering的試驗清單中。如果對FMEA不了解的，這裡有一段YouTuBe影片的介紹可供參考。
之後建立“衝擊-可能性表”(如下圖）將這些卡片貼上。越往右上角衝擊性與發生的可能性越大，反之亦然。
在這個圖表完成後，看一下有哪些事件是系統目前可以承受或是這個是事件的風險小的是可以被接受的或是即使發生還是有達到維運目標的SLA/SLO，一切都要取決與公司的維運要求。
但你可能還需要多一點的資訊才能決定，例如根據維運目標系統需要。以下要求
可靠性
可用性
安全性
可用性
耐用性
資安保護
等等
依剛才的範例，DB的Cluster 。我們就可以這樣寫
DB cluster失效
狀況： 失去耐用性/可用性
以上就是簡單的介紹如何建立風險清單。
