1. 康威定律

1.1. 梅爾文·康威

1.1.1. Melvin Conway

1.1.2. 1968年

1.1.3. 在設計系統時，組織受制於其自身的溝通結構，這使得它設計的系統結構與溝通結構相一致。

1.1.3.1. 社會學現象

1.2. 要在系統內部或系統之間構建介面，兩個人必須以某種方式溝通有關該介面的規範

1.2.1. 沒有溝通，就無法建立介面

1.3. 如果系統不是用穩定性模式構建的，那麼它可能採用了典型的緊耦合架構

1.3.1. 發生失效的總體概率，是其中任何一個組件發生失效的概率之和

1.4. 應用程式的某些組件是針對QA環境的網路拓撲結構進行設計的，而這與生產環境不匹配

2. 負載測試

2.1. 併發用戶是無法衡量的

2.2. 不存在長久的用戶連接，只存在隨著請求的到達而形成的一系列離散的訪問

2.3. 對於不再點擊的用戶和尚未點擊的用戶，伺服器無法區分

2.3.1. 會在用戶最後一次點擊之後的幾分鐘內，保持活動狀態

2.3.1.1. 意味著會話的持續時間絕對比用戶的持續時間要長

2.3.2. 如果對會話進行計數，那麼就會高估用戶的數量

2.4. 伺服器會使用超時

3. 會話

3.1. 會話是每台應用程式伺服器的致命弱點

3.2. 每個會話都會消耗資源，主要是消耗記憶體

3.3. 啟用會話複製功能後（該網站確實啟用了），每個會話都會被序列化，併在每個頁面請求後傳輸到會話備份伺服器上

3.4. 意味著會話消耗了記憶體、CPU和網路帶寬

4. 測試

4.1. 所有的測試腳本都是遵守規則的

4.2. 按照應用程式的使用方式對其進行了測試

4.3. 應用程式開發人員沒有採取某種能夠阻止惡劣情況蔓延的防護措施

5. 混沌工程

5.1. 混沌工程源於悖論，穩定的系統會變得脆弱

5.2. 混沌並不總是涉及軟體中的故障，有時也出現在組織成員身上

5.2.1. 組織中的每一個人都是普通人，難免會犯錯

5.2.2. 高可靠性組織也使用演習和模擬的方法，在人的方面尋找相同的系統性弱點

5.3. 基本的做法

5.3.1. 規劃一段時間

5.3.2. 把一些人指定為在此期間“無行為能力”

5.3.3. 看業務是否可以繼續照常開展

5.3.4. 僵屍來襲模擬

5.3.4.1. 能立即發現一些關鍵的過程在人們離開後無法完成

5.3.4.2. 也許存在一個需要特定角色的系統，而這個角色只有一個人來擔任，或者另一個人掌握著關於如何配置虛擬交換機的關鍵信息

5.3.4.3. 當知道在無人參與的情況下，公司能讓業務正常運作一整天時，可以創造一個有20%的“僵屍”存在的異常情況，增加系統的壓力

5.4. 在分散式系統上進行實驗的學科，旨在建立系統能夠應對生產環境中的動蕩狀態的信心

5.5. 用來應對分散式系統，而且通常是應對大規模的系統

5.6. 由於規模問題，我們既無法在非生產環境中模擬上述問題，也不能通過單獨測試組件來獲得信心

5.7. 強調要從整個系統的視角看問題，它需要應對在單個組件中無法觀察到的那些新冒出的屬性

5.8. 系統

5.8.1. 由人員、技術和過程所組成的整個集合，而不僅僅是信息系統

5.9. 通過優化系統獲得可用性，還要獲得對來自惡劣和動蕩的世界的干擾的容忍性，而不是在理想化的環境中追尋高吞吐量

5.10. “大眾微型麵包車”悖論

5.10.1. 你能學會修複經常壞的東西，但無法學會如何修複那些很少壞的東西

5.10.2. 意味著當很少壞的東西壞掉時，情況就會更加可怕

5.11. 在使組件更穩健與使整個系統更穩健這兩者之間

5.11.1. Netflix公司並不是做“二選一”，而是選擇了“全都要”

5.11.1.1. 運用穩定性模式，讓單個實例更容易存活下來

5.11.1.2. 讓這些失效發生得更頻繁，使它們變成一種常態

5.11.1.2.1. 對很痛苦的事，要更頻繁地做。

5.12. 集群服務應該不受實例失效的影響

5.13. 關掉實例是最基本和最直接的混沌註入，絕對能發現系統中的弱點

6. 調節器

6.1. 調節器的任務是消除變化，但這種變化正是系統工作質量信息的最終來源

6.2. 調節器做得越好，能夠獲得的有關如何改進系統的信息就越少

6.2.1. 在IT人員休假之前，你不知道對他們有多依賴

7. 爆炸半徑

7.1. 指不良體驗的嚴重程度，這涉及受影響的顧客數量及顧客體驗被破壞的程度