嘉賓介紹

老王：“互聯網運維雜談”公眾號作者，兩年電信boss系統研發、五年騰訊運維經歷，而后在YY和UC帶過業務運維和運維研發。

主題介紹

大家好，這些年來，我經歷了不同形態的業務和不同規模的運維，今天我主要和大家分享我這些年來關于運維自動化的一些認識和實踐，包括如下八點：

1. 自動化需要整體規劃

2. 自動化的基礎是標準化

3. 首先從持續交付開始

4. DevOps的四觀

5. 善于借助研測的力量

6. 不一定強依賴CMDB

7. 以NO OPS為最終目標

8. Docker等不是干掉運維

以下為詳細內容，敬請欣賞。

1.自動化需要整體規劃

沒有整體的規劃始終覺得運維是在建一個個的工具，沒法形成遞進式的實現策略。

邊界的識別是通過分層體系來構建DevOps自動化工具棧，而不是用一個工具解決所有問題，和智錦的觀點類似：

千萬不要以為puppet/salt/ansible所管理的配置工具能夠解決所有運維自動化的問題（不過小企業運維另論哈）。

運維場景是尋找自動化平臺實現的驅動力，可以衡量成本和收益比，不要為了自動化而自動化。

我把其中的每一塊都抽象成服務，比如說基礎設施及服務（IAAS部分）、配置及服務、流程及服務（ITIL部分）、架構及服務（PAAS部分）、數據及服務、監控及服務等等。

持續集成平臺，我把他單獨提出來，它很特別：是一個應用交付的主線，他涉及的點很多，自動化編譯、自動化測試、自動化部署等等，另外橫跨了多個團隊，帶來的收益很高。

監控及服務也很特別，對于我來說，一切數據都應該有監控的能力，所以我更多覺得監控是一種數據化的應用，和數據分析一樣，個人監控觀點是“先數據、后監控”。

我習慣把它們映射到對應的層次上，對每一層的自動化手段都不一樣，其實我覺得底層的資源及服務和系統服務層應該越簡單越好，最好不要在系統層面上有依賴，比如說特殊的網絡設置，特殊的DNS設置。

嚴格禁止系統內部調用通過運維系統路徑，比如說DNS、LVS，目的就是為了簡化服務間的依賴，對于運維來說部署一個完整的服務，就要做到部署一個包這么簡單。

另外一個維度就是運維場景的識別，業務形態不一樣，場景就不一樣，逐步挑選對運維收益最大的部分自動化實現它。

#p#

2.自動化的基礎是標準化

自動化平臺必須是經驗交付平臺，而非技術平臺。

技術是經驗的一部分，而我想強調的是，做每一個自動化平臺都需要搞清楚：

1. 自己的自動化平臺要解決的問題；

2. 能達到的收益；

3. 使用user是誰等。

我將在后面持續交付平臺中繼續體現這個思路。

我個人認為標準化能體現你對運維理解的精準度及勇氣。標準化的推進很需要運維的勇氣，否則沒法影響研發按照自己的節奏走：

標準化是讓人和系統更有效率和效力的做事：效率是快速的做事、效力是正確的做事。

在UC，我完全是按照這套方法論和節奏去推進運維工作，自動化一定是隨著業務發展而發展的。

更需要指出的是，越到后續階段，運維工作更是需要和研發、測試深度合作完成，所以運維自動化不能忽略研發、測試。另外：

• 各個部分對自動化都有影響，比如說標準化部分的配置標準化（讓配置管理更簡單）；

• 服務化部分的組件向公共服務組件遷移（服務通過API暴露，讓服務的管理更簡單）；

• 無狀態化的服務雙中心改造，服務高可用也是依賴技術而非人來解決。

接下來舉兩個小例子。

這個圖中兩個重要的標準化工作就是配置管理標準化和應用包的標準化，基于此構造的持續部署系統非常簡單，不用兼容業務的個性化特點。

很慶幸，我們把所有的java容器全部遷移到自研的容器上，我們的容器接管了所有共性的研發服務，比如http服務，緩存服務、配置服務…完全插件化的服務容器。這是可運維性一個很好的例子。

#p#

3.首先從持續交付開始

有些人問，運維自動化該如何開始？

我的一般建議都是把持續集成或者CMDB作為開始主線。持續交付帶來的是多個團隊的利益和價值，這個工作可以由運維牽頭來解決，運維解決的方法可以先從持續部署開始，然后在對接上面的持續集成：

持續部署系統的建設可以聯合研發、測試和運維來建設，方便推廣，降低噪音（反對聲）。

另外，持續交付系統會反向推動運維內部的一些標準化工作，比如說環境標準化、應用標準化等等，因為你的部署要越來越簡單。

持續集成+持續部署等于持續交付，實現面向用戶產品功能的持續交付。

但持續集成僅僅是面向應用交付的能力封裝，還不能夠成為運維自動化能力的全部，往上有面向業務的全流程自動化（調度平臺，實現任務封裝），往下有OS級的自動化（配置管理）等等。

這是我做持續集成系統定的一個業務目標（供參考）。持續部署必須要包含對要管理對象的生命周期的管理、一鍵化變更管理能力，同時還需要對變更后的結果做到持續反饋。業務和服務拓撲是基于之前配置標準化的一個能力實現，沒有放到CMDB中。

當前我們實現持續部署能力有有兩套方案，目前UC使用的基于Cloud Foundry封裝的UAE平臺。

這種對應用有改造要求的PAAS平臺不是太好：

一則太復雜，二則底層服務有依賴（比如agent重啟，業務進程也要重啟）

第二種方案，就是無侵入的運維方案，把運維對持續部署的控制，封裝成標準的事件，大家看看RPM包里面的能力就好理解了，再結合持續集成和持續交付的理念，把他們做成可視化。

4.DevOps的四觀

#p#

我自己對DevOps的一點認識：

文化觀：突破部門墻、深度合作的文化。

價值觀：持續優化、共享責任、杜絕浪費、關注用戶。

共享責任是合作的內在細化，談合作太虛無縹緲。

思維觀：精益、價值、跨界、敏捷

工具觀：自動化平臺集（實現價值的交付）+數據化平臺集（實現交付價值的衡量）。

為什么不是DevTest？為什么不是TestOps？為什么不是DTO？

我自己的理解是D和O代表面向用戶服務能力的兩端，兩端能力的對接是優化的極致。

運維人很多時候都和開發提運維友好，缺忽略我們自己要做的東西也要研發友好。所以很多時候不要站在“我”的需求立場上，而是“我們”。

14年DevOps調查報告，指出要“自動化、自動化還是自動化”。

運維自動化就是要解決運維團隊服務能力的吞吐率和延時問題，也即如何更多、更快的提供運維服務，其實是和線上的服務能力一樣的。

需要思考的問題是，制約我們服務能力的關鍵因素，是資源約束（服務器不夠）、還是架構約束（架構公共化能力不強）、還是運維服務約束（運維基礎平臺DNS/LVS服務能力）？

這個可以不斷的驅動我們思考DevOps的產品形態和狀態了。當然人的意識很重要哈，D/O分離應該走向DO合作。

5.善于借助研測的力量

運維自動化的工作少不了研發測試的支持，有時候運維復雜的系統封裝，結果在研發側做一些小小的改造就可以了，然后部門墻和彼此的強勢文化導致DO是分離，而不是合作。

我舉兩個例子，配置管理和名字服務。

define.conf是把其他底層配置在研發、測試和生產環境的差異消除掉，底層配置文件中采用變量配置方法，通過define.conf在三個環境中定義具體的值來簡化配置管理，持續部署系統就變得極度簡單，因為只需要管理一個define.conf配置即可。

因為我們業務規模很小，所以沒有提配置中心，配置中心在規模服務化運維下，必須要構造的一個基礎服務。需要研發深度支持配合！

名字服務中心是我的個人情節，終于在UC變成了現實。

我相信很多中小企業的服務調用都是通過DNS獲取服務地址來實現調用的，這個缺點就是故障的時候，需要運維深度參與故障處理（TTL、JDK緩存等等）。

我們為此特意建立一個名字服務中心，通過它來實現服務名到實例的具體映射，同時調用端統一實現服務的調度、容錯。

現在內部業務故障，基本上不需要運維參與切換和處理了，大大簡化運維故障處理系統的復雜度，還有服務擴容的時候，服務自動注冊不需要人為修改配置文件，更加的自動化。需要研發深度支持配合！

#p#

6.不一定強依賴CMDB

不要覺得CMDB是自動化的前提。cmdb和自動化平臺的關系有兩種：

1. 自動化平臺與CMDB的關聯發生在某些場景下的某些流程片段，比如說業務上線流程中的資源自動化申請，從CMDB獲取信息。

2. 自動化平臺把變更的信息回寫到CMDB，比如說應用部署系統／DNS系統／LVS系統等信息，目標是把CMDB作為元數據管理的平臺，它可以收斂之上服務之間的數據獲取接口。

當前我們是這么干的，但是發揮作用還不大。特別是業務規模不大，而業務變化不是非常頻繁時，CMDB的管理僅僅只需要記錄資源被誰，用在哪個業務上即可。在公有云IaaS平臺下，CMDB的形態就更簡單了。

7.以NO OPS為最終目標

運維自動化以挑戰每個運維職責部分的“no ops”為目標，比如說服務器交付／應用交付／組件服務交付等等。

最終這種”no ops”的運維平臺可以讓研發自己去完成（持續部署交給研發），也可以讓用戶來幫我們決策完成（容量驅動變更）。

把這些專業的服務能力可視化封裝起來，提供API，供其他關聯服務調用，體現自服務能力。每個人運維人應該帶著可視化管理的要求去面對自己的日常工作，這樣可以確保自動化的能力每個人都能獲取，并且執行結果是一致的。

8.Docker等不是干掉運維

個人認為對運維的影響不是這些技術，而是基于該技術之上的產品化能力。但是不同服務能力的結合，爆發出來的能量需要運維人注意：

比如說IaaS平臺和Docker技術結合，服務調度和名字服務中心結合，微服務對技術架構標準化影響。

因此DevOps不僅僅是對D有Ops能力的要求，對O來說，也要有Dev能力的要求。另外大家可以看看運維還有哪些工作，就知道這些技術對運維的影響了。

分享結束，謝謝大家。

歡迎大家關注本文作者老王的微信公眾號：

如何一起愉快地發展

“高效運維”公眾號（如下二維碼）值得您的關注，作為高效運維系列微信群（國內領先的運維垂直社區）的唯一官方公眾號，每周發表多篇干貨滿滿的原創好文：來自于系列群的討論精華、運維講壇精彩分享及群友原創等。“高效運維”也是互聯網專欄《高效運維最佳實踐》及運維2.0官方公眾號。

提示：目前高效運維兩個微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，進行申請；或申請加入我們技術交流群（技術討論為主，沒有主群那么多規矩，更熱鬧）。

重要提示：除非事先獲得授權，請在本公眾號發布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行及如下二維碼。