1. 概念

1.1. 事務

1.1.1. 系統處理的抽象工作單元

1.1.1.1. 與數據庫事務不同

1.1.1.2. 單個工作單元可能包含許多數據庫事務

1.1.2. 系統存在的原因

1.1.2.1. 如果一個系統只能處理一種事務，那么它就是專用系統

1.1.2.2. 混合工作負載是系統能處理的不同事務類型的組合

1.2. 系統

1.2.1. 用戶處理事務所需的一套完備且相互依賴的硬件、應用程序和服務

1.2.1.1. 單個應用程序

1.2.1.2. 龐大的多層應用程序和服務器網絡

1.2.2. 即使在瞬時沖擊、持續壓力或正常處理工作被失效的組件破壞的情況下，穩健的系統也能夠持續處理事務

1.2.2.1. 指服務器或應用程序仍能保持運行

1.2.2.2. 更多地是指用戶仍然可以完成工作

1.3. 沖擊

1.3.1. 對系統快速施加大量的訪問流量

1.3.1.1. “用錘子猛擊”系統

1.3.2. 一萬個新會話在一分鐘內全都擠過來，任何服務實例都難以招架

1.4. 壓力

1.4.1. 長時間持續地對系統施加訪問流量

1.4.2. 信用卡處理系統的容量不足以滿足所有顧客的需求，因此其響應速度變得十分緩慢

1.5. 失效

1.5.1. 系統不再響應

1.6. 長時間

1.6.1. 兩次代碼部署的間隔時間

1.7. 勞損

1.7.1. 壓力產生勞損

1.7.2. 來自信用卡處理系統的壓力，會導致勞損波及系統的其他部分，進而導致系統運行異常

1.7.2.1. Web服務器的內存使用率升高

1.7.2.2. 數據庫服務器的I/O占用率超出正常范圍

1.7.2.3. 系統的其他部分發生異常

1.8. 失誤

1.8.1. 軟件出現內部錯誤

1.8.2. 原因

1.8.2.1. 潛在的軟件缺陷

1.8.2.2. 在邊界或外部接口處發生的不受控制的狀況

1.9. 錯誤

1.9.1. 明顯的錯誤行為

2. 沒有保持杞人憂天的心態

2.1. 陷入了對新興技術和先進架構的興奮之中而不能自拔

3. 威脅系統壽命的主要敵人

3.1. 內存泄漏

3.2. 數據增長

3.3. 會在生產環境中摧毀系統，卻很少能在測試中被發現

4. 墨菲定律

4.1. 凡是沒有被測試出的問題，將來都會發作

4.1.1. 在實驗室里不會發生而在現實世界中發生的事情，通常不是好事情

4.1.2. 只有連續運行7天之后，系統才會顯露內存泄漏問題，而如果沒有提前測試，那么系統在上線7天后就會遭遇內存泄漏

4.1.3. 負載測試服務供應商每小時收取一大筆金額，所以沒有人會請他們一次將負載測試連續運行一周

4.2. 測試使問題浮出水面，從而使人們可以修復系統

5. 應用程序在開發環境中運行的時長永遠不足以暴露關乎系統壽命的缺陷

5.1. 發現它們的唯一方法就是運行自己編寫的壽命測試

5.1.1. 運行JMeter、Marathon或其他負載測試工具

5.1.2. 讓腳本每天有幾個小時不怎么向系統發送請求，來模擬半夜的低峰時段

5.1.3. 暴露連接池和防火墻的超時問題

5.2. 至少要測試那些重要的組件，用測試替身替代其余組件

5.3. 生產環境便自動成為壽命測試環境

5.3.1. 那里肯定存在軟件缺陷

6. 糟糕的穩定性會帶來巨大的損失

6.1. 對交易系統來說，單筆交易中斷就可能造成高達100萬美元的損失

6.2. 在線零售商獲得每位顧客的成本高達150美元。如果每小時有5000位獨立訪客，假設其中10%最終選擇別家，就會浪費7.5萬美元的營銷資金

6.3. 聲譽損失雖然不那么觸手可及，但企業在這方面所承受的痛苦是一樣的

7. 要使系統獲得良好的穩定性，不一定非得支付巨額的費用

7.1. 當構建系統的架構、設計甚至底層實現時，許多決策點對系統的最終穩定性具有很大的影響力

7.2. 高度穩定的設計與不穩定的設計投入成本通常是相同的

8. 系統失效方式

8.1. 突發的沖擊和過度的壓力都會引發災難性系統失效

8.2. 系統的某些組件會先于其他組件失效

9. 系統失效應對

9.1. 查看每個外部調用、每個I/O操作、每次對資源的使用和每個預期結果，并詢問“這里都有可能出什么錯”，同時思考可能出現的各種沖擊和壓力

9.1.1. 除了關乎生死的關鍵系統和火星探測器，對其他任何系統來說，蠻力法顯然都是不切實際的

9.2. 一旦接受“系統必然會失效”這一事實，就有能力使系統對特定的失效做出相應的反應

9.2.1. 汽車工程師創造出的碰撞緩沖區

9.2.1.1. 為保護乘客而首先被撞毀的區域

9.2.2. 可以為系統創建一種安全失效模式，這種模式包含被損壞區域，并且為系統其他部分提供保護

9.2.2.1. 這種自我保護決定了整個系統的韌性

10. 裂紋阻斷器

10.1. 先確定系統的哪些特性是必不可少的

10.1.1. 然后內建系統失效方式，防止重要特性出現裂紋

10.2. 如果不設計系統失效方式，那么系統就會出現各種不可預測的問題，一旦出現，這些問題通常都是危險

10.3. 系統架構的耦合度越高，編程差錯蔓延的機會就越大

10.3.1. 多度耦合且高度復雜的系統，會為裂紋提供更多的蔓延途徑

10.3.2. 緊耦合會加速裂紋的蔓延

10.4. 低耦合的架構可以起到減震器的作用，這能減少編程差錯的影響

10.5. 裂紋始于對SQLException異常的處理失誤，但在其他許多環節上能夠阻止其蔓延

10.5.1. 可以將資源池配置為在可用資源被耗盡時能創建更多的連接資源

10.5.2. 可以將其配置為當所有連接資源被占用時，短暫地阻塞資源請求者

10.5.3. 在RMI的套接字上設置超時時間

10.5.3.1. 默認情況下，RMI調用永遠不會超時

10.5.3.2. 被阻塞的那些調用方會一直等待從CF系統的EJB中讀取它們期待的響應

10.5.4. CF系統服務器本身可以分隔出多個服務組

10.5.4.1. 其中一個服務組出現的問題就不會拖垮CF系統的所有用戶

10.5.5. CF系統本可以通過請求-回復這樣的消息隊列方式來構建

10.5.5.1. 調用方知道可能永遠不會收到回復，因此它必須將其作為處理協議本身的一部分來處理

10.6. 失誤一旦被觸發，就會產生裂紋。失誤會變成錯誤，錯誤會引發失效。這就是裂紋的蔓延方式

11. 系統失效鏈

11.1. 在每次系統事故的背后，都有一條由一個個事件構成的失效

11.2. 如果試圖估算失效鏈上所有事件都會發生的概率，會發現概率極低，但這僅限于將每個事件都視作獨立事件

11.3. 導致失效的事件并不是相互獨立的

11.3.1. 一個點或一個層次的系統失效，實際上增加了其他點或其他層次發生系統失效的概率

11.3.2. 如果數據庫響應變慢，應用程序服務器更有可能耗盡內存

11.4. 這些層次是耦合在一起的，所以這些事件并非彼此獨立

11.5. 沒有兩起事故會完全沿著同一條系統失效鏈發展

11.5.1. 由相同的因素觸發，具有相同的損壞情況，以相同的方式蔓延

11.6. 生產環境中出現的每次系統失效都是獨一無二的

12. 如何處理失誤的分歧

12.1. 一方表示要構建具有容錯功能的系統

12.1.1. 應該捕捉異常、檢查錯誤代碼，并且通常要防止失誤演變為錯誤

12.2. 另一方具有防誤操作的設備一樣白費功夫，因為總會出現更傻的傻瓜

12.2.1. 應該任其崩潰并替換，這樣就可以從已知的良好狀態重新開始

12.3. 兩件事的看法是一致的

12.3.1. 失誤總會發生，且永遠無法杜絕，必須防止失誤轉變為錯誤

12.3.2. 即使在盡力防止系統出現失效和錯誤時，也必須決定承擔失效或錯誤的風險是否利大于弊