沒有比“可視化”更好的一個詞能概括運維的本質，而“可視化”又應該分成兩部分：可視化的服務交付和可視化的服務度量!
第一部分：可視化的服務交付
早期的運維是從ITIL開始的，那個時候大家都不知道運維是什么，怎么做，幸好找到了一個IT服務最佳實踐--ITIL。于是就開始了運維的摸索之路，從CMDB、服務臺、事件管理、變更管理、可用性管理、容量管理等等逐步去了解，逐步建設自己的系統。但我們很快發現，這一完備的流程框架遇到了大規模運維的時候，就無法應對，或者說過多的聚焦于流程以及規范，我們發現很難提升運維敏捷度和精細性，并且我們還是不知道一個完整的IT服務邊界在哪兒?如何實現它?
不過在ITIL的實踐過程中，其實提出了一個很好的概念---IT服務。對于運維來說，提供一種高效、一致性、透明化的服務是運維的成功所在，這樣就要求服務提供者屏蔽其提供的所有服務細節，因為對于服務消費者來說，很難對專業的運維服務內部細節掌握和了解。就拿服務器資源交付來說，從早期的研發要關心配置、OS初始化、自己安裝系統、配置網絡到最后交付到手里即插即用，服務的自動化程度和完整性越來越高。其實也是一種“架構及服務”的思想體現，把之前早期交付功能變成了交付服務的模式。
另外從運維事務或者活動的角度來說，如何對其進行一次或者多次的組合封裝，把它們變成一個完整的IT運維服務，是此時的運維自動化重點方向。畢竟繁雜的運維事務不進一步封裝，對個人或者團隊來說，都意味著很高的學習成本和事務執行成本。在傳統的IT運維組織中，我們能看到彼此事務之間的割裂非常明顯，比如說網絡、機房、服務器、應用部署等等，都是在不同的團隊完成，彼此工作獨立進行。在大一點的運維團隊中，可能會有一個專門的運維研發團隊來給這些日常活動進行自動化的封裝和實現。在大規模海量運維中，必須要求有一個集成的平臺來實現把這些事務流調度起來，否則無法提高事務執行的效率和質量。
對于如何封裝這些事務或者活動，從DevOps中可以找到一些答案。DevOps提倡自動化一切，其中一條核心的主線就是持續交付。我把持續交付分成兩類場景：一種是持續交付基礎設施，一個是持續交付軟件。當然持續集成更多的是偏重于后者。
持續交付基礎設施是目前IAAS平臺要解決的，利用軟件定義計算、存儲、網絡等技術來實現對上層應用所需資源的快速交付。其中虛擬化技術是IAAS層持續交付的一個核心技術，虛擬化能夠快速的創建資源，交付資源，回收資源等等，在早期也有人錯誤的認為虛擬化就是云計算。最新的輕量級虛擬化技術更是熱點，根本的原因是把應用的交付在鏡像級別交付了，從而進一步降低了應用交付的成本。
持續交付軟件從代碼產生的那一刻就開始進行管理，到編譯、到測試、到灰度環境驗收到正式環境部署，并且希望這條主線完全的自動化。具體的持續集成最佳實踐如下【具體請參見--持續集成：軟件質量改進和風險降低之道】：
面向程序包的持續集成非常簡單，現在有很多的開源解決方案來實現，jenkins、go平臺等等，但有一種情況需要非常注意，就是程序包的配置管理問題，這個也往往是影響發布的重要環節。所以我們很多時候使用開源平臺只是讓他產生程序包即可，后續的包的管理和配置管理以及后續的實例化發布，特別是大規模集群部署，都是由單獨的發布平臺來解決，而非持續集成工具(雖然它們也支持)。
基于軟件的交付解決之后，這個時候我們一定會想，如何實現全應用的交付，此時便有了PAAS平臺和基于應用架構的可視化部署服務兩種方案。這兩種實現思路有很大的不同，我們知道完整的PAAS平臺是提供了對底層服務的統一抽象，比如說數據庫服務、存儲服務、cache服務，但是對于許多開發者來說，好像又不愿意收到這么多的約束，這也是PAAS平臺一直沒有火起來的原因。 PAAS平臺最經典的實現應該是CloudFoudry了，國內很多PAAS平臺基本上都是參考CF來實現。Cloud Foudry概念模型如下：
參照CF的基本架構，我們也有一個類似的PAAS平臺實現(百度的PAAS平臺也是如此)，示意圖如下：
而在現實的情況中，很少有公司有能力把Mysql、MC、Fastdfs封裝一個服務供上層應用調用。在這種情況下，可視化的應用交付就會演變成可視化的全應用架構部署。像完成一個業務流程圖一樣，完成全應用的部署，在這個時候，我們也自然想到的是IDE編程環境。首先把我們架構中各個服務抽象一個對象(類似delphi環境中的控件)，這些對象有相應的屬性和狀態，并且可以在線可視化編輯。把這些可視化的對象按照應用架構視圖的模型構建出應用模板，點擊模板進行實例化，此時翻譯成各類的機器指令到相應的服務器上執行各類動作，這種實現便可以脫離某個服務的接口API約束。
綜上所述，運維的自動化最終要實現可視化，IAAS和PAAS是可視化的一個高度體現。可視化是自動化的更高階表現!
第二部分，可視化服務度量
在我的運維理念中，一直倡導數據驅動運維。有了數據，就有了事實判斷的標準，就有了運維服務優化的方向。“除了上帝，一切人都必須用數據說話”，這是在運維工作中必須恪守的信條。在早期寫過一篇完整的數據驅動運維文章【關于數據驅動運維的幾點認識】。在文章里面體系化的介紹數據化運維的目的、數據的來源以及如何構建數據體系等等。
最近也在進行一個數據實踐，就是建立端到端(立體化)數據分析體系，目標非常明確：*分鐘發現問題，*分鐘內定位問題。我們把數據建立一個標準化的分層體系，從基礎設施、上層組件、到應用服務、到接口、再到用戶側，基于應用的拓撲架構，收集各類指標，統一到一個分析平臺中展現。如圖：
基于這套分層化的數據體系標準，當前我們也有對應的系統實現，具體如下：
當我們形成標準之后，這套標準化的方案可以向其他業務不斷去復制，大家只需要遵循一套數據標準即可，最后數據的采集、分析、展現和告警都是標準化完成。
另外又針對單個用戶訪問情況，希望能實時的繪制它的業務訪問流，開源的產品實現有twitter的zippkin和google的dapper。這類開源方案不能直接使用，只能借鑒其思想。當前我們就結合自身的業務架構特點，實現了一個統一的服務調度框架和名字服務中心，在業務代碼無侵入的情況下，可以把業務調度鏈數據上報和整合，實現自己的業務訪問流拓撲繪制。
運維的數據化能力非常重要，一方面也體現出你對運維的理解是什么樣的，從數據上可以看到你很多運維經驗的提煉;其次利用數據可以發揮運維的驅動能力，從某種意義上來說，數據不會說謊。最后，數據共享和可視化之后，大家有了一致性的理解，它所釋放出來的能力非常大，無論是業務優化、服務改進都能從數據中找到方向。
因此我說可視化的能力代表了運維的能力，可視化的程度越高，運維的能力越高。那么你現在到底可視化了哪些運維服務，并能進行度量?
京公網安備 11010502049343號