1. 導致運維失誤的兩大因素

1.1. 隱秘的連鎖反應

1.2. 暗藏的高複雜度

1.3. 影響著配置屬性

2. 配置

2.1. 配置屬性是系統用戶介面的一部分，供支持其開發和運維的人員使用

2.1.1. 最易被忽視

2.2. 生產級別的軟體都有大量可配置的屬性

2.2.1. 主機名

2.2.2. 埠號

2.2.3. 文件系統位置

2.2.4. ID號

2.2.5. 用戶名

2.2.6. 密碼

2.3. 任何屬性出現錯誤，系統都會遭到破壞

2.3.1. 即使該系統大部分時間能夠正常工作，也仍有可能在某個重要時刻中斷服務

3. 配置文件

3.1. 由於同一個軟體需要在不同的實例上運行，因此某些配置屬性可能會因機器而異

3.2. 代碼應該在部署目錄之外查找適合相應部署環境的配置

3.3. 配置文件會包含整個企業中最敏感的信息：生產資料庫的密碼

3.3.1. 要避免將不同部署環境的配置值保存在版本控制系統中

3.4. 只要將配置信息存放在與源代碼不同的存儲庫中，將其鎖好，僅對有權訪問的人開放，並且管理員能夠根據過程、程式和執行人等授予或撤銷對相關配置信息的訪問許可權，那麼配置信息也可以存放在版本控制系統中

4. 易處理基礎設施的配置

4.1. 基於鏡像的環境中無法針對不同的實例改變其配置文件

4.2. 方法

4.2.1. 在啟動時註入配置信息

4.2.1.1. 提供環境變數或文本blob來註入配置信息

4.2.1.2. 對大多數小團隊來說，註入配置信息更為適用

4.2.2. 使用配置服務

4.2.2.1. 將配置信息註入鏡像的方法通過配置服務完成

4.2.2.2. 實例會對配置服務產生嚴重的依賴

4.2.2.2.1. 配置服務只要一中斷，就立即會引發嚴重級別高達1級的事故

4.2.2.2.2. 當配置服務不可用時，實例就根本無法啟動

4.2.2.3. ZooKeeper、etcd以及其他任何配置服務，都是複雜的分散式系統軟體

4.2.2.3.1. 必須依賴一個精心設計的網路拓撲才能最大限度地提高可用性，並且必須對其容量進行精細的管理

4.2.2.4. 配置服務需要高度的運維成熟度，並會帶來一些顯著的開銷

4.2.2.4.1. 只是服務於一個應用程式，那麼就不值得使用配置服務

4.2.2.4.2. 只有服務於組織中更廣泛的應用程式時，才適合進行配置服務

5. 定義配置屬性

5.1. 屬性名稱應足夠清晰，幫助用戶避免“自我失誤”

5.2. 主機就定義為hostname，這樣的命名雖然沒錯，但毫無幫助

6. 明晰性

6.1. 指的是系統容許運維工程師、開發工程師和業務負責人瞭解其歷史趨勢、當前狀況、即時狀態和未來走向的程度

6.2. 系統級的明晰性視圖將呈現歷史分析、當前狀態、即時行為和未來走向，每個實例都可以提供足夠多的數據構建系統級視圖

6.3. 當且僅當具有某種程度的明晰性時，系統才能更加成熟

6.4. 良好的數據有助於做出正確的決策，在缺乏可信數據的情況下，決策就只能根據某人的影響力、偏見

6.5. 缺乏明晰性的系統無法在生產環境中長期運行

6.5.1. 如果系統管理員不瞭解系統在做什麼，就無法對其進行調整和優化

6.5.2. 如果開發人員不瞭解生產環境中系統各個部分的運行狀況，那麼他們就不能隨著時間的推移，提高系統的可靠性或韌性

6.5.3. 如果業務負責人不瞭解系統是否在幫助他們賺錢，那麼他們將不會投資系統未來的工作

6.5.4. 如果缺乏明晰性，那麼每次發佈都會讓系統變得更糟，從而令系統發生退化

7. 明晰性設計

7.1. 嚴格的局部可見性只能實現嚴格的局部優化

7.2. 如果每次僅提升一個應用程式的可見性，則會掩蓋擴展效應引發的問題

7.3. 監控和報告系統應該像在系統周圍構建的外骨骼，而不是交織在系統內部

7.3.1. 要密切關註系統內耦合現象，監控框架侵入系統內部相對容易

7.4. 從進程中獲取信息

7.5. 在實例上運行的進程是完全不明晰的

7.5.1. 除非能在該進程中運行調試器，否則進程幾乎不會揭示任何關於自己的信息

7.6. 黑盒技術在系統外部運行，通過外部觀察到的事物檢查進程

7.6.1. 可以在系統發佈後實施，通常由運維人員完成

7.6.2. 易用的日誌抓取系統（如Splunk）就是黑盒技術的例子

7.7. 白盒技術在系統內部運行，通常這種技術看起來像是由特定語言庫提供的代理

7.7.1. 在開發過程中，白盒技術和進程必須要集成到一起

7.7.2. 白盒技術與編程語言和開發框架之間的耦合更為緊密