運維自動化的最佳實踐探索
嘉賓介紹
老王：“互聯網運維雜談”公眾號作者，兩年電信boss系統研發、五年騰訊運維經歷，而后在YY和UC帶過業務運維和運維研發。
主題介紹
大家好，這些年來，我經歷了不同形態的業務和不同規模的運維，今天我主要和大家分享我這些年來關于運維自動化的一些認識和實踐，包括如下八點：
-
自動化需要整體規劃
-
自動化的基礎是標準化
-
首先從持續交付開始
-
DevOps的四觀
-
善于借助研測的力量
-
不一定強依賴CMDB
-
以NO OPS為最終目標
-
Docker等不是干掉運維
以下為詳細內容，敬請欣賞。
1.自動化需要整體規劃
沒有整體的規劃始終覺得運維是在建一個個的工具，沒法形成遞進式的實現策略。
邊界的識別是通過分層體系來構建DevOps自動化工具棧，而不是用一個工具解決所有問題，和智錦的觀點類似：
千萬不要以為puppet/salt/ansible所管理的配置工具能夠解決所有運維自動化的問題（不過小企業運維另論哈）。
運維場景是尋找自動化平臺實現的驅動力，可以衡量成本和收益比， 不要為了自動化而自動化。
我把其中的每一塊都抽象成服務，比如說基礎設施及服務（IAAS部分）、配置及服務、流程及服務（ITIL部分）、架構及服務（PAAS部分）、數據及服務、監控及服務等等。
持續集成平臺，我把他單獨提出來，它很特別：是一個應用交付的主線，他涉及的點很多，自動化編譯、自動化測試、自動化部署等等，另外橫跨了多個團隊，帶來的收益很高。
監控及服務也很特別，對于我來說，一切數據都應該有監控的能力，所以我更多覺得監控是一種數據化的應用，和數據分析一樣，個人監控觀點是“ 先數據、后監控 ”。
我習慣把它們映射到對應的層次上，對每一層的自動化手段都不一樣，其實我覺得底層的資源及服務和系統服務層應該越簡單越好，最好不要在系統層面上有依賴，比如說特殊的網絡設置，特殊的DNS設置。
嚴格 禁止系統內部調用通過運維系統路徑 ，比如說DNS、LVS，目的就是為了 簡化服務間的依賴 ，對于運維來說部署一個完整的服務，就要做到部署一個包這么簡單。
另外一個維度就是運維場景的識別，業務形態不一樣，場景就不一樣，逐步挑選對運維收益最大的部分自動化實現它。