第7章 Google的自動化系統的演進
==================================================================
自動化 與GoogleSRE 聯繫
自動化價值
- 一致性
可以準確執行重複可能出錯的命令或者行爲
- 平臺性
可以搭建一個可擴展的平臺，解放運維
- 修復速度更快
對於出錯的處理更好的指定修復
- 行動速度更快
自動操作人來操作重複無意義的事情
- 節省時間
操作與人解耦
自動化對Google SRE 的價值
- 每一個組件自動化不合適
- 基本系統由快速原型開始
- 谷歌一般不會購買特定任務的軟件，會選擇自己去實現，因爲自己所實現的接口有長期價值
自動化使用案例
- 創建用戶賬戶
- 某個服務在某個集羣中的上線與下線過程
- 軟件或者硬件安裝的準備和退役過程
- 新軟件版本的發佈
- 運行時配置的更改
- 一種特殊情況下的運行時配置更改：依賴關係的更改
…
Google自動化使用案例
從抽象層次的角度上來描述Google SRE 自動化使用
- 不會特別詳細對高層實體建模的通用部署工具
生產環境複雜，容易被採用
類比於Perl 提供的POSIX 級別的接口
- 在非常抽象層次上描述服務部署語言
更加通用，更符合通用平臺
類比於Chef ,Puppet
==================================================================
Google 的自動化與實例
自動化演進遵循的路徑
- 沒有自動化
如手動將數據庫著進行在多個位置之間轉移
- 外部維護的特定系統的自動化系統
如在某一主目錄中保存一份通用故障轉移腳本
- 外部維護的通用自動化系統
如將數據庫支持添加到每個人都在使用的通用故障轉移腳本
- 內部維護的系統特定的自動化
如數據庫自己發佈故障轉移腳本
- 不需要任何的自動化系統
數據庫注意到問題發生，在無需人工干預的情況下進行故障轉移
手動操作不可避免
相對於特定系統相關配置上變更的自動化，另外一種自動化是面向整個生產領域的變更
自動化數據庫操作
讓自己脫離工作，自動化所有東西 。形成一個良性的循環
- 將標準副本替換流程的常規工作最糟糕的部分自動化掉，但沒有全部自動化
- 將mysql 遷移到Google集羣調度系統Brog 之下，部署了一個原型實例，但需要手動故障轉移，滿足不了需求
- 完成自動故障切換後臺程序，“決策者”。快速進行數據庫故障轉移流程。
- 在應用程序中增加許多錯誤處理邏輯
將自動化應用到集羣上線中
- 使用Prodtest檢測不一致情況
![增加檢測用例，線性並行測試]()
- 冪等的解決不一致情況
單元測試指出哪個測試失敗，在失敗的地方增加修復程序解決問題
在測試，修復，再測試之間的延遲引入了不穩定測試，時好時壞。並不是所有的修復程序都具有等冪性，一個不穩定的測試可能造成系統處於不一致的狀態
3. 專業化傾向
自動化程序的不同體現在三個方面
1 能力
2 延遲
3 相關性
變化導致自動化難以維護
安全認證一定程度上擺脫了自動程序三個方面的不佳
Admin 服務器 , 支持認證，ACL驅動，以及基於RPC本地管理進行。擁有本地執行更改權限，所有人必須經過審計跟蹤來安裝或者修改服務器其。對Admin服務器和Package 倉庫的修改通過代碼評審來把關。Admin 服務器會記錄RPC 請求者，全部參數，以及所有RPC的結果，以提高調試和安全審計功能。
- 服務爲導向的的集羣上線流程
找到一種以服務爲導向的架構（SOA）來解決集羣上線問題的方法：服務擁有者將負責創建一個Admin服務器，處理系統在集羣就緒後發出的上線/下線RPC。反過來，每個團隊按照合同提供自動上線所需要的自動化，然而可以隨意改變底層實現細節。隨着一個集羣進入“網絡就緒”，自動化系統將給每個負責上線的Admin的服務器發送RPC。
Borg: 倉庫規模計算機的誕生
- 把集羣管理變成可以發送API 的中央協調主題
- 最終使得連續性，自動化的操作系統升級只需要很少的持續工作，這種工作不會根據生產部署的總規模而增加
- 可靠性是最基本的功能
爲了有效進行故障測試，自我檢查中所依賴的內部運作細節也應該暴露給管理整體系統的操作員