[[159288]]

一個好的運維產品分層體系，是運維平臺理解清晰與否的標志。

　　建設一個完整的運維平臺，絕非一日之功，也非一兩個平臺所能覆蓋，因此我非常喜歡用分層體系來歸納問題。無論是整體運維產品的規劃體系，還是自動化體系，還是數據化體系，甚至說CMDB平臺的資源體系，都可以用分層歸納總結。以下是我對運維產品整體分層體系的理解：　　

　　1.運營能力層

　　運營能力是體現IT運營價值，把IT的價值和業務場景緊密聯系在一起，這些場景和之前談的運營價值體系是一致的。在運維發展的不同階段，IT系統的運營價值體現有所不同，IT運營的核心方法是有迭代式的思維。

　　對于很多企業來說，自動化提升效率是運維***個價值突破點，再往后，業務的高可用保證和成本控制，則是下一個價值方向；在之后，精細化運營的業務支撐則是更高的訴求，類似質量要求(質量的概念非常寬泛)。越往后，越凸顯數據的價值，而非自動化工具的價值。因此我個人覺得在某一個階段，自動化平臺突破之后，自動化則不是主要瓶頸，而是數據化運營的能力。該能力在依賴平臺的同時，更依賴的是運維團隊的業務理解能力和經驗總結。

　　這一層的能力都表現為一個具體的產品形式+運營方法，從而確保能夠很好的閉環起來。

　　2.平臺能力層

　　在一個完整的運維平臺中，其能力是集成的，而非離散的--系統需要提供很好的集成能力，讓系統得到收斂，避免系統被割裂成一個一個的執行單元，用戶為此痛苦不堪；是場景化的，而非基于功能需求的--場景能夠串聯工具的能力；是基于角色的，而非基于單一用戶的--運維的角色能過清晰定義場景需求，用戶的需求往往是片面而不真實的需求；基于事務的，而非基于職能的--事務能過跨越職能組，讓運維組織的自動化和數據能力流動起來。

　　平臺能力是指基于底層平臺構建起來的運維自動化/數據化(監控+分析)/安全的能力平臺，這層能力實現了底層能力的組合與封裝，屏蔽底層各個專業子平臺的實現細節，是面向業務運維場景的，比如說應用交付/資源交付/業務交付/持續反饋等等。

　　3.通用能力層

　　通用能力層是基于基礎設施之上封裝的公共服務能力，這層架構的能力分成兩部分：一部分是面向業務技術架構的，另一部分是面向運維服務架構的。圖中列的服務只是其中的部分，這個也是我經常和交流者強調能力建設的核心，不能把這個問題留給下面資源能力層，也不能交給上層平臺能力層。

　　對于線上技術架構來說，里面涉及到名字服務/負載均衡服務/分布式緩存/消息隊列/分布式關系存儲等等，運維需要對其技術實現的同學要求API直接調用的服務能力。

　　對于運維服務來說，提供了資源服務/作業服務/部署服務/F5管理/GSLB等等。這層的平臺能力我一直理解成PAAS平臺的核心，有了它們其實就可以實現端到端的能力調度。

　　該層服務能力平臺可以很好的對上層平臺進行積木式的支撐，同時可以對底層設施層能力做服務化能力交付，脫離了資源交付的范疇。

4.基礎設施層

　　基礎設施層是資源交付層，對于一個運維系統來說，應該屏蔽底層基礎設施的交付能力，無論是IaaS，還是物理。特別對于一些IaaS云平臺來說，更應該屏蔽IaaS底層實現的細節差異，通過api網關向上提供能力。國外早年有同類的產品，如RightScale，很好的實現了多云管理的能力。

　　基于這個思路，可以對其他系統或平臺不斷的進行分層分解，最終讓平臺的落地可執行性變得很強，而不是人云亦云的系統工具建設。