1. 第一個擁有10億用戶的網站

1.1. 2016年，Facebook宣布其每日活躍用戶數量為11.3億

1.2. 對整個應用程序來說，“五個9”的可靠性遠遠不夠，這每天會讓成千上萬的用戶失望

1.3. 假如按照六西格瑪質量標準來衡量，那么Facebook每天會惹怒768000個用戶

1.4. 每頁200個請求，每日11.3億個活躍用戶，每百萬次機會有3.4個缺陷

2. 當集成一個個的系統時，系統相互之間的緊耦合就會變為常態

2.1. 大型系統往往比小型系統更快地陷入失效

2.2. 緊耦合會令系統某一部分的裂紋開始蔓延并成倍增大，最終跨越層級或系統的邊界

3. 問題膨脹

3.1. 輕微的失誤轉化為重大的系統失效

3.2. 冷卻監控和控制系統中隱藏的連鎖反應，就是導致美國三里島核反應堆事故的部分原因

4. 每一個反模式都會在系統中產生、加速或增加裂紋

4.1. 僅僅避免使用這些反模式還不夠，因為所有事物都會出問題，失誤不可能避免

4.2. 不要假裝可以消除所有可能的失誤來源，無論是系統本身的失誤還是人為引起的失誤

4.3. 要做最壞的假設，失誤肯定會發生

5. 集成點

5.1. 集成點是系統的頭號殺手

5.2. 所有的都是集成項目

5.3. 蝴蝶圖

5.4. 蜘蛛圖

5.4.1. 精心設計

5.4.2. 隨意設置

5.5. 所有這些連接都是集成點，它們中的每一個都有可能破壞系統

5.6. 小型服務的數量設計得越多，與SaaS提供商的整合程度就越高，越是采用API優先的策略，越會讓情況變得更糟

6. 套接字協議

6.1. 較高層級的許多集成協議通過套接字運行

6.2. 除了命名管道和進程間通信（共享內存），幾乎所有的通信都基于套接字來實現

6.3. 最簡單的系統失效方式是遠程系統拒絕連接

6.4. TCP部分則是一個關于如何在離散的數據包基礎上，構建出看似連續連接的協議

6.4.1. TCP還定義了“同時打開”的握手方式，即在發送SYN/ACK之前，這兩臺機器會互相發送SYN數據包。然而在基于客戶端-服務器交互的系統中，這是相對少見的

6.5. 如果想要結束阻塞調用，就必須設置套接字超時時間。在超時情況下，程序能夠處理相關的異常

6.6. 網絡系統失效按速度分為快慢兩種

6.6.1. 快速的網絡系統失效，會讓調用代碼立即出現異常

6.6.1.1. “拒絕連接”是非?？焖俚南到y失效，只需要幾毫秒的時間就能返回給調用方

6.6.2. 緩慢的系統失效，比如一個被丟棄的ACK，會讓線程在拋出異常之前被阻塞幾分鐘

6.6.2.1. 一個緩慢的響應比沒有響應糟糕得多

6.7. 問題

6.7.1. 防火墻內的“已建立連接”表

6.7.1.1. 該表是有時長限制的

6.7.1.2. 即使TCP本身允許無限時長的連接，該表也不允許

6.7.1.3. 防火墻丟棄了這些數據包，而不是通知發送方無法到達目標主機

6.7.1.4. 閑置時長會輕松超過防火墻中配置的1小時閑置連接超時

6.7.2. TCP從來也不是為處于網絡連接中間的那種智能設備而設計的，任何第三方都無法告訴連接終端它們的連接正在被拆除

6.8. 方案

6.8.1. ping數據包本身就是解決方案所需要的，其可以用來重置防火墻連接的“最后數據包”時間，可以使連接保持活動狀態

6.8.2. “無效連接檢測”既能讓連接保持活動狀態，又可以讓人睡個安穩覺

6.8.3. 為了更好地理解問題，需要知道如何繼續深入至少兩個抽象層次，才能了解層次的“實際情況”，找到問題所在

6.9. tcpdump是從網絡接口捕獲數據包的常用UNIX工具

6.10. Wireshark可以在網線上嗅探數據包

6.10.1. 類似tcpdump，但它也能在圖形用戶界面中顯示數據包的結構

6.10.2. 需要在X Window系統上運行

6.10.2.1. 無法安裝在Docker容器或AWS實例中

7. HTTP協議

7.1. 所有基于HTTP的協議都使用套接字

7.2. 可能會給調用方帶來的影響

7.2.1. 服務提供方可能會接受TCP連接，但不會響應HTTP請求

7.2.2. 服務提供方可以接受連接但不能讀取請求

7.2.3. 服務提供方可能會發回調用方不知道該如何處理的響應狀態

7.2.4. 在服務提供方發回的響應中，可能帶有調用方不期望或不知道如何處理的內容類型

7.2.4.1. 當DNS查找失敗時，互聯網服務提供商可能會注入一個HTML頁面

7.2.5. 服務提供方可能聲稱要發送JSON，但實際上發送了純文本，或者是內核二進制文件，抑或是Weird Al Yankovic創作的MP3音樂

7.3. 建議

7.3.1. 避免使用那些將響應直接映射到領域對象的客戶端程序庫

7.3.2. 要將響應視為數據，除非已經確認響應符合設計預期

8. 供應商的API程序庫

8.1. 阻塞是影響供應商API程序庫穩定性的首要問題

8.1.1. 無論是內部資源池、套接字讀取指令、HTTP連接，還是最一般的Java序列化，處處可以發現不安全的編程實踐

8.2. 供應商可能會對其銷售的服務器軟件進行強化，但對客戶端API程序庫則很少這樣做

8.3. 程序庫的代碼只是出自常規開發工程師之手，與其他任何隨機抽樣的代碼一樣，在質量、風格和安全性等方面具有不穩定性

8.4. 它們幾乎不受控制

8.5. 需要等待供應商官方補丁版本