1. 面向恢復的計算

1.1. ROC,recovery-oriented computing

1.2. 加州大學伯克利分校和斯坦福大學的聯合研究項目

1.2.1. 其大部分工作致力於消除系統失效的根源，但也承認系統失效不可避免

1.2.2. 旨在提高系統面臨失效時的生存能力

1.3. 創始原則

1.3.1. 無論在硬體方面還是軟體方面，失效都是不可避免的

1.3.2. 建模和分析永遠都不會足夠完備，用推導的方法預測所有系統失效方式是不可能的

1.3.3. 人的行為是系統失效的主要原因

1.4. 如果在每次配置更改後，都必須重新啟動那些伺服器，則無法恢復服務

1.5. 重啟組件而不是重啟整台伺服器的能力，是面向恢復的計算的一個關鍵概念

1.5.1. 在不重啟所有伺服器的情況下恢復服務

1.5.2. 花費超過6小時的時間來完成所有伺服器的重啟

1.5.3. 僅僅動態重新配置和重啟連接池這件事，只需不到5分鐘的時間

2. 為生產環境而設計

2.1. 將在生產環境中發現的問題視為頭等大事

2.2. 為執行運維操作的人們而設計

2.3. 圖示

3. 基礎層

3.1. 瞭解系統的物理基礎設施

3.2. 系統所有其他部分所依賴的機器和電纜

3.3. 釐清有關網路、主機名和IP地址之類的事情

3.4. 考慮持有代碼的那些設備：物理主機、虛擬機和容器等

3.5. 當系統跨越多個數據中心時會出現的一些特殊問題

4. 數據中心和雲端的聯網

4.1. 相比桌面網路，包含更多冗餘和安全性建設

4.2. 聯網時最大的誤解就是機器的主機名

4.3. 主機名可以用兩種方式來定義

4.3.1. 主機名是操作系統用來識別自身的名字

4.3.1.1. 機器的管理員可以設置該主機名和“預設搜索域”，將主機名和搜索域拼接在一起就構成了FQDN（全限定功能變數名稱）

4.3.1.2. 即在運行hostname命令時所看到的內容

4.3.2. 系統的外部名字

4.3.2.1. 其他電腦希望使用這樣的主機名連接到目標機器

4.3.3. 無法保證機器自身的FQDN與DNS為該機器的IP地址所提供的FQDN相匹配

4.4. 兩個定義的根本區別

4.4.1. 機器使用其主機名標識整個機器

4.4.2. DNS名字僅用來標識IP地址，多個DNS名字可以被解析為同一個IP地址

4.4.3. 對負載均衡服務來說，一個DNS名字也可以被解析為多個IP地址，這意味著“DNS名字到IP地址”是一種“多對多”的關係

4.4.4. 許多實用程式和應用程式都假定機器自分配的FQDN是合法的DNS名字，解析後不會發生改變

4.4.4.1. 對開發機器來說基本上是正確的，但對生產環境的服務來說一般是錯誤的

4.5. 多網卡的多對多的關係

4.5.1. 一臺機器可能有多個網卡

4.5.2. 每個網卡可以連接到不同的網路，每個活動的網卡能在其特定網路上獲取IP地址，這被稱為多宿主（multihoming）

4.5.3. 數據中心中的每台伺服器一般都是多宿主的

4.5.4. 不知道存在多個網路介面的應用程式，最終就容易接受來自錯誤網路的連接

5. 備份操作

5.1. 會以突發的方式傳輸巨量的數據

5.2. 如果備份發生在生產環境網路上就會堵塞網路

5.3. 良好的數據中心網路設計，是將備份用的數據流量分流到其專用的網段上

5.3.1. 由單獨的交換機處理

5.3.2. 由生產環境交換機上的單獨虛擬區域網處理

5.4. 備份流量從生產環境網路中分離出來後，當執行備份操作時，應用程式用戶不會因此受到影響

6. 多網路編程

6.1. 預設情況下，監聽一個套接字的應用程式，會監聽所有網路介面上的連接請求

6.2. 編程語言庫總是有一個“簡單”的套接字監聽版本，這個“簡單”版本只是在主機的每個網路介面上打開一個套接字

6.3. 在生產環境中配置多個網路介面的另一種常見方法，是綁定或分組

6.4. 要確定綁定的網路介面，必須提供應用程式的名字或IP地址

6.5. 需要在套接字上監聽的伺服器應用程式，必須添加可配置的屬性來定義伺服器應綁定的網路介面

6.6. 應用程式還必須指定發出流量的網路介面

6.6.1. 數據可以通過多條路由，流經目標IP地址所屬的不同網卡，併到達同一個目的地