筆記。 翻譯。：本文是 AWS 技術傳播者 Adrian Hornsby 一系列精彩文章的延續，他以簡單明了的方式解釋了透過實驗來減輕 IT 系統故障後果的重要性。
“如果你沒有準備好計劃，那麼你就注定會失敗。” - 班傑明富蘭克林
В 在本系列文章中，我介紹了混沌工程的概念，並解釋了它如何幫助在系統中的缺陷導致生產故障之前找到並修正它們。 它也討論了混沌工程如何促進組織內積極的文化變革。
在第一部分的最後，我承諾談論「將故障引入系統的工具和方法」。 唉，我的頭腦在這方面有自己的計劃，在這篇文章中，我將嘗試回答想要進入混沌工程的人們中最常見的問題： 首先要打破什麼？
好問題！ 不過，他似乎並沒有特別在意這隻熊貓…
不要惹亂熊貓！
簡短的回答：沿著請求路徑定位關鍵服務。
更長但更清晰的答案：要了解從哪裡開始嘗試混沌，請注意三個面向：
- 看看 崩潰歷史 並識別模式；
- 決定 關鍵依賴關係;
- 使用所謂的 過度自信效應.
這很有趣，但這部分可以很容易地稱為 “自我發現與啟蒙之旅”。 在其中我們將開始使用一些很酷的樂器「演奏」。
1. 答案就在過去
如果您還記得，在第一部分中，我介紹了錯誤修正 (COE) 的概念 - 一種我們分析錯誤（技術、流程或組織中的錯誤）的方法，以便了解其原因並預防以後再復發。 一般來說，您應該從這裡開始。
“要了解現在，你需要了解過去。” ——卡爾·薩根
查看故障歷史記錄，在 COE 或事後分析中標記它們並對它們進行分類。 確定經常導致問題的常見模式，對於每個 COE，問自己以下問題：
“這是否可以透過故障注入來預測並預防？”
我記得我職業生涯早期的一次失敗。 如果我們進行一些簡單的混沌實驗，這種情況就可以很容易地避免：
正常情況下，後端實例回應來自 ）。 ELB 使用這些檢查將請求重定向到健康實例。 當發現某個實例「不健康」時，ELB 會停止向其發送請求。 有一天，在一次成功的行銷活動之後，流量增加了，後端對健康檢查的反應開始比平常慢。 應該說，這些健康檢查 ，即檢查依賴關係的狀態。
然而，有一段時間一切都很好。
然後，在相當緊張的情況下，其中一個實例開始執行一項非關鍵的常規 ETL cron 任務。 高流量和 cronjob 的結合使 CPU 使用率幾乎達到 100%。 CPU 過載進一步減慢了對運行狀況檢查的響應速度，以至於 ELB 認為該實例遇到了效能問題。 如預期的那樣，平衡器停止向其分配流量，這反過來又導致群組中其餘執行個體的負載增加。
突然，所有其他實例也開始無法通過健康檢查。
啟動新實例需要下載和安裝軟體包，並且花費的時間比 ELB 在自動縮放組中一一禁用它們所需的時間要長得多。 很明顯，整個過程很快就達到了臨界點，應用程式崩潰了。
那我們就永遠明白了以下幾點：
- 建立新實例時安裝軟體需要很長時間；最好優先考慮不可變方式 .
- 在複雜的情況下，應優先考慮對運行狀況檢查和 ELB 的回應 - 您最不希望發生的事情就是使剩餘實例的生活變得複雜。
- 健康檢查的本地快取有很大幫助（即使是幾秒鐘）。
- 在困難的情況下，不要執行 cron 任務和其他非關鍵進程 - 為最重要的任務節省資源。
- 自動縮放時，使用較小的實例。 10 個小樣本一組優於 4 個大樣本一組； 如果一個實例失敗，在第一種情況下，10% 的流量將分佈在 9 個點上，在第二種情況下，25% 的流量將分佈在 XNUMX 個點上。
因此， 是否可以預見到這種情況，並透過引入問題來防止這種情況發生？
Да，並以多種方式。
首先，透過使用諸如 或 :
❯ stress-ng --matrix 1 -t 60s
壓力
其次，透過重載實例 和其他類似的實用程式：
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
這些實驗相對簡單，但可以提供一些很好的思考，而不必經歷真正失敗的壓力。
但 不要停在那裡。 嘗試在測試環境中重現崩潰並檢查您對問題的回答“是否可以預見到這種情況，並透過引入故障來防止這種情況發生？」 這是混沌實驗中的一個迷你混沌實驗，旨在測試假設，但從失敗開始。
這是一場夢，還是真的發生了？
因此，研究失敗的歷史，分析 核心競爭力，按「點擊半徑」（或更準確地說，受影響的客戶數量）對它們進行標記和分類，然後尋找模式。 問問自己是否可以透過引入問題來預測和預防這種情況。 檢查你的答案。
然後切換到範圍最大、最常見的模式。
2. 建構依賴關係圖
花點時間考慮一下您的應用程式。 是否有清晰的依賴關係圖？ 你知道如果失敗會產生什麼影響嗎？
如果您不太熟悉應用程式的程式碼或它變得非常大，則可能很難理解程式碼的用途及其依賴項。 了解這些依賴關係及其對應用程式和使用者可能產生的影響對於了解從何處開始混沌工程至關重要：起點是影響半徑最大的元件。
識別和記錄依賴關係稱為“建構依賴關係圖» （依賴關係映射）。 這通常是使用程式碼分析工具針對具有大型程式碼庫的應用程式完成的。 （程式碼分析） 和儀器儀表 （儀器儀表）。 您也可以透過監控網路流量來建立地圖。
但是，並非所有依賴項都是相同的（這進一步使該過程變得複雜）。 一些 批判的， 其他 - 中學 （至少在理論上，因為崩潰經常是由於被認為是非關鍵的依賴項問題而發生）.
如果沒有關鍵的依賴關係，服務就無法運作。 非關鍵依賴項”不應該» 跌倒時影響服務。 要了解依賴關係，您需要清楚地了解應用程式使用的 API。 這可能比看起來要困難得多——至少對於大型應用程式來說是這樣。
首先瀏覽所有 API。 突出最 重要且關鍵的。 拿 зависимости 從程式碼儲存庫檢查出來 連線日誌，然後查看 文件 （當然，如果它存在的話 - 否則你仍然有о更大的問題）。 使用工具來 分析和追蹤，過濾掉外部呼叫。
您可以使用類似的程序 netstat - 命令列實用程序，顯示系統中所有網路連線（活動套接字）的清單。 例如，若要列出所有目前連接，請鍵入：
❯ netstat -a | more
在AWS你可以使用 （流日誌）VPC 是一種允許您收集有關進出 VPC 中網路介面的 IP 流量資訊的方法。 此類日誌還可以幫助完成其他任務 - 例如，找到為什麼某些流量無法到達實例的問題的答案。
您還可以使用 。 X-Ray讓你看得細緻、“極致” （端對端） 概述請求在應用程式中移動時的情況，並建立應用程式底層元件的對應。 如果您需要識別依賴關係，非常方便。
AWS X-Ray 控制台
網路依賴圖只是部分解決方案。 是的，它顯示了哪個應用程式與哪個應用程式通信，但還有其他依賴關係。
許多應用程式使用 DNS 來連接到依賴項，而其他應用程式可能會使用服務發現，甚至在設定檔中使用硬編碼的 IP 位址（例如 /etc/hosts).
例如，您可以建立 在...的幫助下 iptables 看看有什麼問題。 為此，請輸入以下命令：
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS黑洞
如果 /etc/hosts 或是其他設定文件，你會發現你一無所知的IP位址（是的，不幸的是，這種情況也會發生），你可以再來救援 iptables。 假設你發現了 8.8.8.8 並且不知道這是Google的公共DNS伺服器位址。 透過使用 iptables 您可以使用以下命令封鎖到此位址的傳入和傳出流量：
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
關閉訪問
第一條規則丟棄來自 Google 公共 DNS 的所有資料包： ping 有效，但不傳回資料包。 第二條規則會丟棄所有從您的系統發送至 Google 公共 DNS 的封包 - 以回應 ping 我們得到 操作不被允許.
注意：在這種特殊情況下，最好使用 whois 8.8.8.8，但這只是一個例子。
我們可以進一步深入這個兔子洞，因為所有使用 TCP 和 UDP 的東西實際上也依賴 IP。 在大多數情況下，IP 與 ARP 綁定。 不要忘記防火牆...
如果你吃了紅色藥丸，你就會留在仙境，我會告訴你兔子洞有多深。”
更激進的方法是 斷開 一輛接一輛的汽車，看看有什麼壞了......成為「混亂猴子」。 當然，許多生產系統並不是為這種暴力攻擊而設計的，但至少可以在測試環境中嘗試。
建立依賴關係圖通常是一項非常漫長的工作。 我最近與一位客戶交談，他花了近兩年的時間開發了一種工具，可以半自動地為數百個微服務和命令產生依賴關係圖。
然而，結果非常有趣且有用。 您將學到很多關於您的系統、它的依賴關係和操作的知識。 再次強調，要有耐心：旅程本身才是最重要的。
3.謹防過度自信
“誰有夢想，誰就相信它。” — 德摩斯梯尼
你可曾聽說 過度自信效應?
根據維基百科的說法，過度自信效應是“一種認知偏差，即一個人對自己的行為和決策的信心明顯大於這些判斷的客觀準確性，尤其是當信心水平相對較高時。”
基於直覺和經驗...
根據我的經驗，這種扭曲是混沌工程從哪裡開始的一個很好的暗示。
謹防過度自信的操作者：
查理：“這東西已經五年沒有掉下來了，一切都很好！”
Crash：“等等……我馬上就到！”
由於影響因素多種多樣，過度自信導致的偏見是一種陰險甚至危險的事情。 當團隊成員全心投入一項技術或花費大量時間「修復」它時尤其如此。
加起來
尋找混沌工程的起點總是會帶來比預期更多的結果，太快開始打破事物的團隊忽略了（混沌）更全球化、更有趣的本質工程 - 創意運用 科學方法 и 經驗證據 用於（軟體）系統的設計、開發、操作、維護和改進。
第二部分到此結束。 請寫評論、分享意見或只是拍手 。 在下一部分中我 真 我將考慮將故障引入系統的工具和方法。 直到！
譯者PS
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com