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. 白盒技術與編程語言和開發框架之間的耦合更為緊密
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556747.html
標籤：架構設計
上一篇：讀發布！設計與部署穩定的分布式系統（第2版）筆記20_實體層之代碼
下一篇：返回列表