1. 配置服務

1.1. 配置服務本身就是分散式資料庫

1.1.1. 像ZooKeeper和etcd這樣的配置服務

1.1.2. 受CAP定理和亞光速通信的限制

1.1.3. 可實現容量擴展，但不具備資源可伸縮性

1.1.4. 也會遭受相同的網路創傷

1.2. 信息並不僅僅從服務流向客戶端實例，實例也可以向服務報告其版本號（或提交SHA演算法）和節點標識符

1.3. 每次寫入配置服務，都必須經歷某種共識機制才能生效

1.4. 確保實例可以在沒有配置服務的情況下啟動

1.5. 確保實例在配置服務無法訪問時不會停止工作

1.6. 確保配置服務的某個被網路分隔的節點不具備關閉整個系統的能力

1.7. 要跨地理區域進行複製

2. 環境整備和部署服務

2.1. 部署是運維工作中的必經環節，是連接開發和生產的橋梁

2.2. 部署工具本身應該配備一個部署包庫

2.3. 對一些組織來說，部署就是DevOps

2.4. 推式部署工具

2.4.1. 使用SSH或其他代理工具，因此中央伺服器可以連接到目標機器上來運行腳本

2.4.2. 這些目標機器事先並不知道自己的角色，伺服器會統一將角色分配給它們

2.4.3. 對於長壽命的虛擬機甚至物理主機，推式部署工具就可以更簡單地進行設置和管理

2.5. 拉式部署工具

2.5.1. 特別適用於資源可擴展的場景

2.5.2. 拉式部署工具更依賴各台機器瞭解自己的角色

2.5.3. 機器上的軟體可以訪問配置服務獲取有關其角色的最新信息

2.6. 用於生產環境的構建包需要使用已知來源的程式庫，在一臺“乾乾凈凈”的伺服器上運行

2.7. 可重覆的構建工作非常重要，要確保在機器上可以運行的代碼在生產環境中也能運行

2.8. 任何廣泛使用的伺服器軟體都可用作攻擊武器，包括構建伺服器，諸如Jenkins、Bamboo或GoCD

2.8.1. 構建系統本身的插件是直接從網上下載的

2.9. 金絲雀部署是構建工具需要完成的一項重要工作

2.9.1. “金絲雀”指一小組實例，它們率先獲得了系統的新版本

2.9.2. 在一段時間內，運行新版本的實例會與運行舊版本的實例共存

2.9.3. 如果金絲雀實例行為異常，或者其度量指標一直很低，那麼該構建就不會推送給剩餘的實例安裝

2.10. 金絲雀部署的目的就是在構建包到達用戶之前，拒絕其中糟糕的構建包

3. 命令與控制

3.1. 只有當實例需要花費很長時間才能做好運行前的準備工作時，實時控制才有必要

3.2. 控制點

3.2.1. 重置斷路器

3.2.2. 調整連接池大小和超時

3.2.3. 禁用特定的出站集成

3.2.4. 重新載入配置

3.2.5. 開始或停止接收負載

3.2.6. 特性開關

3.3. 開發人員不相信運維人員能正確地部署軟體並運行腳本

3.4. 運維人員不允許開發人員登錄到生產機器更新資料庫模式

3.5. 這個信任的破裂本身就是一個需要解決的問題

3.5.1. 絕對不要在生產代碼中構建一個自我毀滅“按鈕”

3.5.2. 許多服務會採取公開一些控制的方法來更新資料庫模式，或者刪除並重新設置所有數據

3.6. 刷新緩存按鈕，這也是非常危險的

3.7. 命令隊列

3.7.1. 一個共用的消息隊列或發佈-訂閱匯流排，所有的實例都可以監聽

3.7.2. 有了命令隊列，一窩蜂效應就更容易發生了

3.7.3. 為每個實例添加一個隨機的延遲時間，讓它們能夠分散地執行命令，這是避免一窩蜂效應的好方法

3.8. Watir或RoboForm這樣的圖形用戶界面測試工具

3.9. 對生產環境中長期的運維工作來說，圖形用戶界面是糟糕的管理界面。長期運維的最佳界面是命令行

3.10. 所有構建的軟體要麼必須維護，要麼被迫拋棄

3.11. 要選擇那些適合團隊規模和工作負載規模的工具

3.12. 可以從系統可見性開始，使用日誌記錄、跟蹤和度量指標來創建明晰性

3.13. 當面對更大或更動態的系統時，可以使用配置、整備和部署服務來獲得杠桿作用

3.14. 一旦系統（在某種程度上）穩定下來，並且問題顯露出來，就要建立控制機制，這樣就能進行更精確的控制，而不僅僅是重新配置和重新啟動實例

3.15. 相比那些高度動態的環境，部署到長壽命機器上的大型系統從控制機制中受益更多

4. 平臺廠商

4.1. 相對於雲供應商，平臺能夠提供一個與之不同的特性——位置無關性

4.2. Kubernetes、Apache Mesos、Cloud Foundry以及Docker的Swarm Mode

4.3. 既然已經在平臺上花了大價錢，就應該充分加以利用

4.3.1. 不要嘗試在它外面再包裝一層API，或自己提供一套腳本

5. 工具清單

5.1. 日誌收集和搜索

5.2. 度量指標收集和可視化

5.3. 部署

5.4. 配置服務

5.5. 實例安置位置

5.6. 實例和系統可視化

5.7. 調度

5.8. IP地址、覆蓋網路、防火牆和路由管理

5.9. 自動擴展控制器

5.10. ⑩告警和通知

6. 要點

6.1. 每個解決方案都會帶來新問題。隨著系統容量的水平擴展和垂直擴展，我們幾乎將一切虛擬化了

6.2. 一旦知道整個系統發生了什麼，就能採取干預措施

6.3. 需要瞭解自動化讓所有事情都運行得更快帶來的問題

6.3.1. 自動化缺乏人的判斷力，所以當出錯時，錯誤會發展得很快，這就需要我們在自動化中建立安全機制