說實話，一個運維團隊的運維能力如何，其實看一個自動化管理系統便知！
********文章較長，索引目錄如下*******
一、概述
二、運維自動化的三重境界
三、運維自動化的多維解讀
******第一、基於應用變更場景的維度劃分
******第二、基於系統層次的維度劃分
******第三、基於和業務程式耦合緊密程度的維度劃分
四、運維自動化的方法論
******第一、全域性驅動
******第二、分而治之
******第三、自底向上
******第四、邊界清晰
******第五、外掛化
五、運維自動化系統的實現
******第一、DNS管理系統
******第二、CMDB管理系統
******第三、名字服務中心繫統
******第四、持續部署管理系統
******第五、業務排程管理系統
六、運維自動系統的API參考實現
七、運維自動化依賴的團隊模型
******第一、團隊的能力模型
******第二、團隊的驅動模型
******第三、團隊的技能模型
******第四、參考的運維組織結構
一、概述
在前面的文章中，提到【運維的本質—視覺化】，在其中著重強調是自動化的視覺化和資料化的視覺化。在這個文章中，全面解碼看看自動化的極致狀態為什麼是視覺化？在前面的另外一篇文章【運維平臺全體系介紹】中，也講到運維平臺體系的構成，提出“**及服務”的理念，其中有幾部分和自動化密切相關，比如說資源及服務、配置及服務、架構及服務，持續整合服務，最終都服務於面向業務的視覺化排程平臺目標上去。讓我們再回顧一下平臺規劃體系（涉及自動化部分的，我用紅色框中）：
二、運維自動化的三重境界
宋代禪宗大師青原行思（六祖門下首座）提出參禪的三重境界：
參禪之初，看山是山，看水是水；
禪有悟時，看山不是山，看水不是水；
禪中徹悟，看山仍然山，看水仍然是水。
這三種境界其實和我們眼中運維自動化的三重境界類似。
自動化第一重界：看山是山，看水是水。開始接觸運維自動化的時候，我們看到了很多工具認為就代表著自動化，比如說早期把expect+ssh封裝之後，就以為可以實現批量運維。看到有人說puppet可以做配置管理，這個時候也就認為puppet可以做配置管理，甚至是釋出管理。這個時期的典型問題，就是以偏概全，對於某個開源自動化工具來說，還沒法去界定它的使用場景和範圍，直接影響系統的建設效益。這個時候已經開始知道我們看到的山不是真正的山，是迷霧環繞的深山。
自動化第二重界：看山不是山，看水不是是水。此時我們知道expect+ssh不夠，隨著業務規模的變化，我們需要一個更完整的概念來做釋出系統，真正的釋出系統要做版本管理、環境管理、配置管理、還要做他們的生命週期管理等等；puppet真正要做自動化，其實還依賴OS和應用層很多標準化。對於其他資源物件的管理來說，生命週期的概念都在穿行其中，比如說DNS、LVS、介面、配置、應用包等等。為了有效標識資源的生命週期狀態，需要用大量的資料來實時反饋。這是運維自動化的更具體了，把一個個的山貌看清楚了。
自動化第三重界：看山還是山，看水還是水。這是一種自動化本質上的追究，站在山頂之巔，俯覽眾山，會發出原來如此的感嘆：所有自動化的本質都是為了視覺化，讓所有的人看到一致的服務，確保結果一致；從底層來說，你會說所有自動化的本質都是指令+檔案分發的組合；你會進一步抽象系統的能力，提供即插即用的機制；結合服務化的需求，進一步雲化所有的運維繫統，確保內外一致性的使用。這是化境！
三、運維自動化的多維解讀
第一、基於應用變更場景的維度劃分
我們增加探討過所有的運維價值導向最終都是面向業務、面向使用者，所以自然而然就需要從業務的維度進行劃分。而運維是有很多種場景的，但從業務的角度來說，核心的幾種業務場景就那麼幾種，如：業務上線、業務下線、業務擴容、業務縮容、應用升級等五種。我用一種場景為例帶大家把整個流程穿越起來看看，讓大家和我一起識別流程的節點到底對接了哪些系統？那麼針對其他的業務場景，你也可以用同類的方法去分析。首先預設架構如下：
1、業務上線。表示一個完整的應用上線，從無到有部署整個業務上線。具體的流程如下：
仔細看其中的流程，我們會發現涉及到多個系統，每個系統完成職能都有不同，這個地方只是大概的描述了一下。但這個流程一清晰的梳理出來，就知道我們真正要實現一個應用全部上線有多麼複雜了。但看完這個圖又覺得簡單了，因為其實從業務上線的流程來看，我們只需要一個上層的流程排程引擎調加對應的執行器，執行器通過API和底層各個系統對接。所以說之前在框架圖中，為什麼要求各個專業系統一定要向上提供API，並且要求這個API的風格是一致的。
最複雜的業務上線已經梳理完成之後，其實業務下線就很簡單，它是上線過程的逆過程，上線負責裝，下線負責拆。
業務上線之後，隨著使用者活躍度的上升，此時業務的容量會有出現不足的情況，此時就需要進行業務擴容。擴容就很簡單，當哪類節點不足的時候，對他進行擴容。至於擴容要做哪些變更，其實都是業務上線的子流程。比如說web層容量不夠，那就無非申請機器，安裝元件、下發應用包，自動化測試。這個時候需要注意：在業務上線的過程中，我們把很多的配置資訊都下放到CMDB中了，但我們選擇擴容的時候，就從CMDB把資訊讀取出來，指導變更。
應用升級，目前持續整合講的自動化都是在這塊。簡單來講，就是升級程式包、升級配置、執行額外指令等等，逃脫不了這幾種模式。如果你說的這麼簡單，是不是我把ssh封裝一個UI出來，就可以了。當然不是，這個時候需要你帶著運維的理解，需要在底層做一些標準化的工作，否則你提供的是一個工具，完全沒有運維的思路，比如說程式執行屬主、執行路徑、監控的策略等等。另外建設應用釋出平臺的目的，就是要讓測試、Production環境的運維變更可控。
是不是以上幾個運維場景的自動化要一次全部做完呢？不是，是有先後和主次之分。對於以上的運維場景，我在當前我負責的遊戲運維中下做過統計，資料如下：
A、持續部署的數量，一個月2000次左右
B、其他場景的分佈情況.一個月上線一次、下線兩次、擴容一次左右。
有了這個資料，我們建設一個自動化系統的時候，就能識別先做什麼後做什麼。當然不同的企業有不同的實際，還是要找到核心痛點。不是一上來就建設完整的業務變更系統，見效不快，且容易讓專案收益不大，而遇到很大的阻力。
第二、基於系統層次的維度劃分
給出這樣的分層體系圖，其實是為了讓大家更好的識別系統的職責和範圍，下層幹上層的活，上層幹下層的活都是越界，越界帶來的是耦合。舉個例子，系統服務層puppet（或者chef）配置管理，在網上看到的很多資料都說可以來做釋出，就是說可以做應用服務層的事情。後來我看過幾家公司，用puppet來做應用服務層的釋出，最後都走不下去，應用包的需求變化太大，靠puppet編寫factor的模式來適應所有的場景，基本上是不可能，所以說它適合的是系統配置管理。以上說的就是一種越界！
第三、基於和業務程式耦合緊密程度的維度劃分
這點非常重要，這個劃分其實是確定系統建設的Owner，避免讓運維團隊承擔過多的系統建設職能，而讓運維能力提升緩慢。那怎麼來判斷和業務程式的耦合緊密程度？我的準則就非常簡單，程式直接呼叫的就是緊耦合，類似api/SDK類的後端服務，比如研發建設；程式不直接使用的就是鬆耦合的就是運維來建設。
那有一種情況，我們很多應用程式中,DNS和LVS服務也在程式呼叫鏈中存在，怎麼辦？在我的方案中，絕對不允許內部服務走DNS和LVS。我們都知道DNS和LVS的服務對於服務異常的處理（DNS無狀態、LVS是七層能力弱），遠遠達不到線上服務的要求，所以要堅決拒絕。如果他們真的要使用，第一告訴他們業務風險；第二，故障產生的時候，需要讓研發參與處理。另外這也是系統的邊界沒劃清楚，是讓運維元件去承擔業務上應該具備的容災容錯功能，會給後面的運維繫統建設增加很多不必要的功能。
我這邊的分類就很簡單，如下：
四、運維自動化的方法論
第一、全域性驅動
無論是從全部的自動化管理平臺規劃，還是某個平臺的規劃，都希望大家都能找到一個全域性的立足點。比如說我們當時成立持續部署服務平臺的時候，大家把全域性目標一說，開發、測試、運維很快就達成共識了。目前這個平臺建設完成之後，運維已經徹底的退出釋出變更流程之中，真正實現了讓運維變成的稽核者。
第二、分而治之
在上面的幾個維度看到了很多系統，我們發現每個系統都要建設的話，其實週期和難度都很大。所以需要分而治之，特別是線上架構元件的管理系統，更需要隨著元件的交付一起交付管理能力。之前我也表達過類似的觀點，所有隻交付元件，不交付管理能力的研發都是耍流氓。因為從運維的角度來說，越來越多這樣低價值的交付產品，會導致運維不堪重負。而讓運維從頭去構建這個管理，則需要花費運維很多的時間去了解，讓系統建設週期拉長。舉個例子，比如說某個分散式cache服務，做的不好的，通過讀取日誌然後對其監控，做的好的，給你開啟一個管理埠，從埠中讀取狀態資訊。這就大大降低的系統的複雜度（不用日誌採集和處理元件了）。
分而治之，其實就是讓不同的團隊做不同的事情，不要全部壓給運維；其次不同的時期建設不同的系統，不要在同一時刻做很多系統，避免戰線過長。當然如果有很多運維研發人員來說，另當別論哈。
第三、自底向上
自底向上，其實是讓大家找到一個更清晰而具體的系統建設目標來展開工作。從系統分解上，來規避大家被一個龐大而模糊的目標帶入歧途。如果一上來，我們就說要做一個全自動的運維管理系統，很容易讓運維研發團隊迷失方向。所以這個地方可以把全域性和最終目標設定在哪兒（全自動化），然後從底下逐步構建地基，做框架，最後再蓋一個完整的房子。
第四、邊界清晰
邊界有兩個維度，一個是管理邊界；一個是職能邊界。第一個邊界是從Owner者的角度出發的，誰產生服務，誰就是owner，管理統一都是運維。比如研發提供一個統一分散式訊息佇列服務，Owner是研發，他應該對可運維性負第一責任，不要讓運維去承擔這個服務的webAdmin管理系統建設任務。其次是職能邊界，深層次的理解是元件的功能範圍。有時候對運維架構師的考驗就在這兒，比如說讓LVS去承擔業務異常的容災和容錯切換，不合適；讓DNS跨過LVS層，負責對後端服務異常的自動容錯處理，也不合適。沒有把職能界定清楚，會導致系統做很多無用功。
第五、外掛化
外掛化的思維無處不在，但我們面對紛繁複雜的管理物件時，我們進行抽象，提供管理模式，具體的實現交給使用者，這個我們日常所見的運維繫統中經常可以簡單。比如說nagios就是一種外掛化的採集思路。對於配置管理來說，puppet也是採用這個思路。到我們最上層的排程管理系統來說，可以讓運維自己去編寫自己的執行器，特別是和業務緊密相關的，但最終運維整形控制權還是交給平臺。而我的經驗是，在【應用服務層】和【架構服務層】，不要引入外掛化的管理方案，過多的外掛化部署，會讓我們生產環境的管理最終混亂不堪，最終失控。所以提供類SSH介面的運維釋出和部署平臺，是沒有任何運維價值的。
五、運維自動化系統的實現
挑戰一個自動化的極致場景（視覺化），是運維人對極致的追求。接下來，我會拿幾個典型的運維自動化系統供大家參考。
第一、DNS管理系統
簡介：DNS系統傳統web形態下的一個重要入口，使用者服務的訪問嚴格依賴這個服務入口。現在外面一般都叫GSLB（全域性服務負載均衡排程），目前是CDN服務裡面的重要服務節點。實現的目標都是要解決運維從哪裡來，到那裡去最快，當目標機房故障的時候，如何把服務排程走。概念圖如下：
在移動app的今天，DNS協議的缺點已經逐漸暴露出來了，DNS解析時間長，另外還經常被劫持的。因為有端的控制，現在逐漸開始走httpDNS的服務，通過http服務的方式獲取域名對應的IP地址，此時由DNS平臺直接提供http服務對外。在有端APP的情況下，還可以識別非自己權威DNS域名是否存在被劫持的情況下，這個可以藉助端的資料探勘技術。此時系統需要保持和業務的與時俱進。
這個地方還有一個問題要注意的，內部DNS是不是可以統一管理？理論是可以的，把一個一個機房當成一個個的view，不過我不建議兩個場景耦合在一起，雖然能夠實現。
系統Demo：
第二、CMDB管理系統
簡介：在之前的【運維平臺之CMDB系統建設】，我有全面的體系化介紹，不再細述。
系統Demo：
第三、名字服務中心繫統
簡介：概念最初來自於zookeeper，我們結合我們的實際，實現了名字服務中心。把程式介面之間的呼叫抽象一個一個的服務之間的呼叫，在服務中心來實現排程的統一註冊、鑑權、acl、容災容錯控制。說這是線上服務最核心的系統，一點不為過，並且是收益最大的系統，直接替換掉DNS、LVS。我後面挑一個專門的章節來介紹這個系統，以便給你們的線上服務架構提供參考。
系統Demo：
第四、持續部署管理系統
簡介：持續部署，是我們應用升級的核心繫統，每個月承擔著大量的變更。在系統規劃之初，我們就給他設定了清晰的業務管理目標：做持續整合的一部分，實現四個下圖的四個維度管理目標；也設定了具體業務運維目標：結果所有的包、配置升級，且讓業務運維徹底的退出業務變更流程。如下：
系統Demo：
這個介面實現了最複雜的配置管理職能。
第五、業務排程管理系統
簡介：面向業務的排程管理系統，是一個流程排程引擎+執行器來完成的，目前我們當前正在實現中。其實大家可以看看雲編排服務，基本原理類似。
Demo（09年左右實現的一鍵化變更系統），如下：
還有資料庫運維管理平臺和分散式cache管理系統……都有相應的實現，這個地方不貼圖介紹了。
六、運維自動系統的API參考實現
所有底層的系統對外提供服務都是通過API暴漏的，供各個系統使用。介面的使用需要通過授權獲得，建議這個授權可以基於系統級別，也可以到介面級別，而不是統一開放的模式。另外介面內需要有相應的一些許可權控制，避免底層服務被任意操作。
可以仿照AWS的介面實現方式，統一實現API的介面開放訪問地址，同時協議統一（http、https），協議可以使用Get的方式進行訪問。
七、運維自動化依賴的團隊模型
我從能力模型、驅動模型和技能模型三個角度來闡述運維團隊和個人的能力要求，最後給出一個參考的組織結構。
第一、團隊的能力模型
在我帶過的應用運維團隊中，我都會從如上三個方面的能力對組員提出要求。
業務運維。在我們的考核體系中放的比重越來越低，因為這塊能力要求越來越低。日常的變更、擴容、故障定位、運維規劃對人的能力要求都非常的低，這些工作都能模式化且平臺化，可以減少對人的倚重，
運維研發。我希望每個應用運維人都有運維研發的能力，但現實是不可能的。但對於一個應用運維團隊和一個運維部門來說，運維研發的配備必不可少。在應用運維團隊內部，可以讓有研發能力的人迅速承擔面向業務運維平臺的建設或者參與到部門的運維繫統建設中，可以50%時間參與研發。運維研發能力是讓團隊價值迅速達成的保證，沒有研發能力的運維不是一個好運維（包括我自己）。
技術研究。運維是個技術團隊，需要通過技術體現價值，當找到好的技術就想著如何應用到業務上，給使用者帶來價值，比如說使用者體驗提升，成本減少等等。
這個時候有個問題，應用運維團隊裡面的人也會運維研發，然後又有專職的運維研發團隊？那他們的職責分工如何解決，在工作上是否會存在重複建設？我的回答是這樣的：
首先，可以把運維研發初期定位在公共服務平臺研發上，比如說DNS、LVS、配置管理、監控系統、CMDB、資料分析平臺等等。
其次，運維研發還需要制定相應的運維研發規範，程式碼規範、UI規範、測試規範等等，讓所有參與運維研發的人統一遵守，包括應用運維研發的組員。
最後，說一下應用運維小組內的研發能力該如何發揮的問題。其實在很多運維團隊中，運維都是跟隨業務，一則可以讓應用運維研發人員開發面向業務的運維繫統，他們最懂該業務的需求，實現自己想要的；另外一種更好的操作方式，讓應用運維小組內的研發人員50%時間參與到以運維研發牽頭成立的虛擬研發小組中。一則可以進一步提高應用運維的研發水平；另可以提高運維研發對業務運維的理解，同時提高帶隊作戰的能力。
關於運維研發和應用運維的比例該設定成多少？2:1吧，這也是初步拍的。大家也可以自檢一下，自己的運維團隊到底設定了多少運維研發人員？另外運維研發配備是否足夠，可以週期性看看運維團隊取得的進步，特別是效率、質量維度。
第二、團隊的驅動模型
團隊的驅動力不同，帶來結果的就完全不同。為什麼很多運維人員都說自己很苦逼，這個地方可以看看到底是什麼在引導著你在做運維工作？傳統的維護，都是集中在第一和第二階段，而進入到高階運維體系之後，我們需要迅速切換到價值驅動、使用者驅動的維度上來。有了使用者驅動和價值驅動，對運維的效率、質量都有了更高的要求，反向驅動我們必須走自動化和平臺這條道路。
第三、團隊的技能模型
在BAT很早就實施了職業通道體系，對於運維人員的成長有明確的要求和衡量體系，在此我就不詳細介紹了。下圖是騰訊的高階應用運維工程師的技能要求雷達圖，供大家參考：
第四、參考的運維團隊組織結構
不一定要按照這個結構明確設定運維小組，但是運維的職能差不多是這樣。我還有另外一個建議，最好公共服務研發團隊最好和運維團隊放在一個組織結構下，會有利於公共化服務的推廣，而公共服務化對運維的效率影響是最大的。
至此，自動化平臺的深度解碼已經完成。從多個層面帶大家瞭解運維自動化，其實還是希望給大家帶去一點借鑑意義。大膽的往前走吧，一切都有可能，唯獨那些實現不了，都是我們人的問題，別無其他。