乙個好的運維產品分層體系，是運維平台理解清晰與否的標誌。
1.運營能力層
運營能力是體現it運營價值，把it的價值和業務場景緊密聯絡在一起，這些場景和之前談的運營價值體系是一致的。在運維發展的不同階段，it系統的運營價值體現有所不同，it運營的核心方法是有迭代式的思維。
對於很多企業來說，自動化提公升效率是運維第乙個價值突破點，再往後，業務的高可用保證和成本控制，則是下乙個價值方向；在之後，精細化運營的業務支撐則是更高的訴求，類似質量要求(質量的概念非常寬泛)。越往後，越凸顯資料的價值，而非自動化工具的價值。因此我個人覺得在某乙個階段，自動化平台突破之後，自動化則不是主要瓶頸，而是資料化運營的能力。該能力在依賴平台的同時，更依賴的是運維團隊的業務理解能力和經驗總結。
這一層的能力都表現為乙個具體的產品形式+運營方法，從而確保能夠很好的閉環起來。
2.平台能力層
在乙個完整的運維平台中，其能力是整合的，而非離散的--系統需要提供很好的整合能力，讓系統得到收斂，避免系統被割裂成乙個乙個的執行單元，使用者為此痛苦不堪；是場景化的，而非基於功能需求的--場景能夠串聯工具的能力；是基於角色的，而非基於單一使用者的--運維的角色能過清晰定義場景需求，使用者的需求往往是片面而不真實的需求；基於事務的，而非基於職能的--事務能過跨越職能組，讓運維組織的自動化和資料能力流動起來。
平台能力是指基於底層平台構建起來的運維自動化/資料化(監控+分析)/安全的能力平台，這層能力實現了底層能力的組合與封裝，遮蔽底層各個專業子平台的實現細節，是面向業務運維場景的，比如說應用交付/資源交付/業務交付/持續反饋等等。
3.通用能力層
通用能力層是基於基礎設施之上封裝的公共服務能力，這層架構的能力分成兩部分：一部分是面向業務技術架構的，另一部分是面向運維服務架構的。圖中列的服務只是其中的部分，這個也是我經常和交流者強調能力建設的核心，不能把這個問題留給下面資源能力層，也不能交給上層平台能力層。
對於線上技術架構來說，裡面涉及到名字服務/負載均衡服務/分布式快取/訊息佇列/分布式關係儲存等等，運維需要對其技術實現的同學要求api直接呼叫的服務能力。
對於運維服務來說，提供了資源服務/作業服務/部署服務/f5管理/gslb等等。這層的平台能力我一直理解成paas平台的核心，有了它們其實就可以實現端到端的能力排程。
該層服務能力平台可以很好的對上層平台進行積木式的支撐，同時可以對底層設施層能力做服務化能力交付，脫離了資源交付的範疇。
4.基礎設施層
基礎設施層是資源交付層，對於乙個運維系統來說，應該遮蔽底層基礎設施的交付能力，無論是iaas，還是物理。特別對於一些iaas雲平台來說，更應該遮蔽iaas底層實現的細節差異，通過api閘道器向上提供能力。國外早年有同類的產品，如rightscale，很好的實現了多雲管理的能力。
基於這個思路，可以對其他系統或平台不斷的進行分層分解，最終讓平台的落地可執行性變得很強，而不是人云亦云的系統工具建設。
細說運維經理的七大能力
首先我們談第乙個問題，如何成為運維經理。一般來說，運維經理大概有兩種出身，一種是從底層最基礎的維護做起，通過出色的維護工作，讓公司領導對這個人非常認可，同時對it工作也比較重視，逐步走向it manager的崗位。第二種是業務管理出身或者有it技術背景，具備了一定經驗直接進入it管理層的人員。因此，...
運維服務能力管理體系應建立的幾種能力
運維服務能力管理體系應建立的幾種能力包括 1.運維業務戰略設計與規劃能力 企業應具備有對運維業務的定位 發展戰略 新型運維業務發展進行規劃分析的能力，能夠規劃出與戰略相匹配的運維業務方向 業務的管理策略 需要的配備資源等方面的能力。2.運維業務管控能力 企業應能規劃和設計運維業務的整體化 標準化的解...
資料中心運維人的半衰期危機
資料中心運維是乙份工作壓力極大的工作，需要經常熬夜 加班，還要經常做一些重複性的工作，不少人幹上三五年若沒有提公升的話，都很難堅持下去。所以我們發現資料中心運維人的群體基本都是一群年輕的，充滿幹勁的小夥子，個別一些資深的運維工程師可能三十幾歲，超過四十歲的若還不是主管或者總監，還做基礎運維的工作人員...