1.5 運維自動化的方法論

1．全局驅動

無論是全部自動化管理平臺的規劃，還是某個平臺的規劃，都希望大家能夠找到一個全局的立足點。比如說我們當時成立持續部署服務平臺的時候，大家把全局的目標對齊于提高產品交付的速度和質量，開發、測試、運維很快就達成共識了。目前這個平臺建設完成之后，運維已經從發布變更流程中徹底退出了，真正實現了讓運維變成審核者。

2．分而治之

從上面的幾個維度中可以看到有很多系統，如果每個系統都要建設的話，那么周期和難度都將很大。所以需要分而治之，特別是線上架構組件的管理系統，更需要隨著組件的交付一并交付運維管理能力，比如面向組件的自動化管理能力、運維的監控能力、運維的數據分析能力等。之前我也表達過類似的觀點，所有只交付組件，不交付管理能力的研發都是耍流氓。因為從運維的角度來說，這樣低價值的交付產品越多，越會導致運維不堪重負。而如果讓運維從頭去構建這個管理，則他們需要花費很多的時間去了解，從而導致系統建設周期拉長。舉個例子，比如說某個分布式cache服務，做得不好的，是通過讀取日志然后對其進行監控；做得好的，是給你開啟一個管理端口，讓你從端口中讀取狀態信息。這就大大降低了系統的復雜度（不用進行日志采集和處理組件了）。

分而治之，其實就是讓不同的團隊做不同的事情，不要將所有事情全部壓給運維；其次不同的時期建設不同的系統，不要在同一時刻做很多系統，從而避免戰線過長。當然如果有很多運維研發人員的話，就另當別論了。

3．自底向上

自底向上，其實是讓大家找到一個更清晰更具體的系統建設目標來展開工作。從系統分解上，來讓大家規避被一個龐大而模糊的目標帶入歧途。如果一上來，我們就說要做一個全自動的運維管理系統，那樣很容易就會讓運維研發團隊迷失方向。所以這里可以先設定全局和最終目標（全自動化），然后從底層逐步構建地基，做框架，最后再蓋一個完整的房子，詳見圖1-1。

4．邊界清晰

邊界有兩個維度，一個是管理邊界；一個是職能邊界。

首先是管理邊界，其是從Owner的角度出發的，誰產生服務，誰就是Owner，管理統一都是運維。比如研發提供了一個統一的分布式消息隊列服務，那么Owner就是研發，他應該對可運維性負第一責任，不要讓運維去承擔這個服務的WebAdmin管理系統建設任務。

其次是職能邊界，深層次的理解是組件的功能范圍。對運維架構師的考驗也就在這兒，比如說讓LVS去承擔業務異常的容災和容錯切換是不合適的；讓DNS跨過LVS層，負責后端服務異常的自動容錯處理也是不合適的。如果不把職能界定清楚，將會導致系統做很多無用功，這會增加系統建設的復雜度。

5．插件化

插件化的思維無處不在，在面對紛繁復雜的管理對象時，我們進行抽象，提供管理模式，然后將具體的實現交給用戶，這點在我們日常所見的運維系統中經常可以看到，比如說Nagios就是一種插件化的采集思路。對于配置管理來說，Puppet采用的也是這個思路。對于最上層的調度管理系統，可以讓運維自己去編寫執行器，特別是和業務緊密相關的，但最終運維整個控制權還是要交給平臺。我的經驗是，在應用服務層和架構服務層，不要引入插件化的管理方案，過多的插件化部署，會讓生產環境的管理最終混亂不堪，甚至失控。所以提供類SSH界面的運維發布和部署平臺，是沒有任何運維價值的。