沒有比“可視化”更好的一個詞能概括運維的本質，而“可視化”又應該分成兩部分：可視化的服務交付和可視化的服務度量！
第一部分：可視化的服務交付
早期的運維是從 ITIL 開始的，那個時候大家都不知道運維是什麼，幸好找到了一個IT服務最佳實踐——ITIL。開始了互聯網運維的摸索之路，從CMDB、服務檯、事件管理、變更管理、可用性管理、容量管理等逐步去了解，並同步建設對應的管理平臺。但我們很快發現，這一完備的流程框架如果遇到了大規模運維的情況，就無法應對，原因在於過多的聚焦於流程以及規範，我們發現很難提升運維敏捷度和精細性，並且我們還是不知道一個完整的IT服務邊界在哪兒？如何實現它？不過在ITIL的實踐過程中，其實提出了一個很好的概念——IT服務。對於運維來說，提供一種高效、一致性、透明化、面向用戶的服務是運維的價值所在，這樣就要求運維屏蔽其提供的服務背後的所有實現細節。從運維具體事務或者活動的角度來說，如何對其進行一次或者多次的組合封裝，把它們變成一個完整的IT運維服務，是此時的運維自動化重點方向。畢竟繁雜的運維事務不進一步封裝，對個人或者團隊來說，都意味著很高的學習成本和事務執行成本。在傳統的 IT 運維組織中，我們能看到彼此事務之間的割裂非常明顯，比如說網絡、機房、服務器、應用部署等，都是在不同的團隊完成，彼此工作獨立進行。在敏捷和精益運維驅動之下，必須要求有一個集成平臺來把這些事務流調度起來，否則無法提高事務執行的效率和質量，真正地把運維交付功能變成了交付服務的模式。對於如何封裝這些事務或者活動，從 DevOps 提倡的“自動化一切” （Auto everything）可以找到些答案，其核心的自動化主線就是面向用戶的敏捷持續交付。我把持續交付又分成兩類場景： 一種是持續交付基礎設施，一個是持續應用交付（持續構建、持續測試、持續部署、持續反饋)，他們有點近似IAAS和PAAS的關係。持續交付基礎設施在公有云 IAAS 平臺中得到很好的解決，利用軟件定義計算、存儲、網絡等技術來實現對上層應用所需資源的快速交付。在私有IT環境中，當前有大量客戶採用虛擬機方案或者私有云方案來解決交付難和慢的問題。最新的輕量級虛擬化技術Docker更是熱點，根本的原因是把應用的交付在鏡像級別完成，從而讓應用交付更加快速。持續交付軟件從代碼產生的那一刻就開始進行管理，到編譯、到測試、到灰度環境驗收再到正式環境部署，並且希望這條主線完全自動化。面向程序包的持續集成非常簡單，現在有很多的開源解決方案來實現，如Jenkins、Go等，但有一種情況需要特別注意，就是程序包的配置管理問題，這個也往往是影響部署的重要因素。所以我們很多時候使用開源平臺只是為了構建程序包，後續包及其其中的配置管理以及實例化部署，特別是大規模集群部署，都是由單獨的持續部署平臺來解決，而非之前的持續集成工具（雖然它們也支持發佈），但持續部署平臺需要有和持續集成平臺無縫對接的能力。 基於軟件包的交付解決之後，我們希望交付的粒度更大，如何實現全應用（從應用的前端接入到後端存儲)的交付，此時便有了PAAS平臺和基於應用架構的可視化部署服務兩種方案。這兩種實現思路有很大的不同，我們知道完整的PAAS平臺提供了對底層公共服務的向上API統一抽象，比如說數據庫服務、存儲服務、Cache服務。PAAS平臺最經典的實現應該是Cloud Foudry了，國內很多PAAS平臺基本上都是參考CF來實現的。阿里UC也有一個類似的PAAS平臺，示意圖如下。
而在現實的情況中，很少公司有能力把Mysql、MC、Fastdfs封裝公共服務供上層應用直接調用，意味著對研發程序有著一定的要求，是否還有一種更輕量的無約束自動化方式呢？我們可以把運維的全應用部署轉變下思路，此時把應用架構中的各個部分拆解成對象組件（包含屬性和狀態)，比如說機房、OS、應用包等，全應用部署就是這些對象的編排，類似可視化IDE編程環境。綜上所述，
運維的自動化最終要實現可視化，複雜的運維工作流必須通過可視化來表達，可視化後的自動化才能讓所有人理解一致、執行一致、結果一致。第二部分，可視化服務度量
“除了上帝，一切人都必須用數據說話”，這是運維人員必須恪守的信條。我寫過一篇完整的數據驅動運維的文章“關於數據驅動運維的幾點認識”，裡面系統地介紹了數據化運維的目的、數據的來源以及如何構建數據體系，等等。
最近也在進行一個數據實踐，就是建立面嚮應用的端到端數據分析體系，該體系對數據有個標準化的分層歸類，從基礎設施、上層組件、到應用服務、到接口、再到用戶側，基於應用的拓撲架構，收集各類指標，統一到一個分析平臺中展現，如下圖所示。
基於這套分層化的數據體系標準，我們也有對應的系統實現，如下圖所示。
當形成標準的數據採集、分析和展現體系之後，可以向其他應用不斷去複製這套方案，大家只需要遵循一套數據標準即可，最後數據的採集、分析、展現和告警都是標準化完成。這套數據體系建設完成之後，可以在運維的故障定位、服務優化、架構改進、運維規劃等各方面找到應用場景。
此時有人會有疑問如何面向應用把這些數據整合關聯起來？我們當前是基於配置文件的靜態視圖和基於接口調用而生成的動態視圖來集成。動態調用視圖生成會複雜一點，可以讓線上的接口調用統一由名字服務中心來接管調度，抽樣對接口調用進行染色，從而生成動態的訪問關係。
以上視圖能快速發現和定位規模故障，但對於單個用戶的故障指標上則應對乏力。此時分佈式Trace服務的作用就顯現出來了，可以借鑑Twitter的Zippkin和Google的Dapper的實現思路。當前我們就結合自身的業務架構特點，實現了一個統一的服務調度框架和名字服務中心，在業務代碼無侵入的情況下，可以把業務調度鏈的染色數據上報和關聯，實現對於單個問題的快速定位。
數據的可視化能力非常重要，需要在面向整體和麵向某個業務流上都有實現。它首先體現出你對運維的理解是什麼樣的，從可視化Dashboard上可以看到最直接的運維經驗；其次基於可視化之上的數據共享，讓大家對數據的理解達成一致；最後利用一致化的可視化數據發揮運維的驅動能力，驅動 DevOps，數據的核心價值就在於此。
因此可視化的能力就代表了運維的能力，可視化的程度越高，運維的能力越高。那麼你現在到底可視化了哪些運維服務，並能進行度量呢？
與“老王”探討 DevOps 實踐就在 GOPS 2019 · 深圳站
閱讀更多 高效運維 的文章
