其實在過去一直想給“到底什么是運維”尋找一個答案?我極力避免的是我們狹義化定義運維(變更/問題處理/值班等等)。因此從我有限的理解和工作經歷中，我嘗試了從多個角度來闡述，初探精益運維體系。在精益運維的體系中，我把運維分成幾個標準的部分，有工具、有標準化、有架構、有服務化等等。自我覺得，這樣的認知一定程度上突破了對運維本身的認識，做了一點跨界的思考。

到今天，當我們都在不斷的講DevOps的時候，如果我們還在用運維的視角去認識當下的運維是否也是狹義化的表現呢?是不是要回歸到更大局的IT全價值鏈上看運維?我對此作出的***個改變是把運維的詞語給換了——文字背后的力量。應用運維就變成了應用管理，從運維到管理。

運維是一個階段性的定義，特別是在職能化的組織架構中，限制了你的職責范圍和行為方式。而管理不是，管理是從全生命周期的角度去看的。當我們從生命周期的角度去看，我們要知道每一個階段應該需要什么樣的平臺支持，需要什么樣的組織匹配，需要什么樣的文化支撐等等。

前天還和喬梁老師說，在我每一次的運維分享中，我都會和運維人說，你翻譯的《持續交付》被我給列為運維人必看書。的確，我深受這本書的全局視野的影響，同時也感嘆于作者在每一個事情上具體細節把握，是一本難得的好書。我之前也把這條IT交付的價值鏈和業務鏈匹配起來，從而讓自己有些全局視角，我再也不局限于我們自己范圍內的優化。另外一點這條能力鏈恰好覆蓋了應用管理的各個階段，很自然的完成了生命周期的管理。

有人會問，運維真的要且可以構建應用的全生命周期能力?當然。我認為最終的部署和運營行為都是依賴生產環境而進行的，運維有最準確的環境、部署、架構等管理理解。該能力很容易延伸到開發和測試環境(不考慮組織因素)。按照這個思路，持續部署流水線便形成了。那交付流水線又該如何對接呢?我的理解平臺本身能力一定要完成插件化的設計，這樣便可以對接各類的能力。在DevOps的工具、文化和組織合力下，能力也要以平臺化集成的模式對外提供，而每部分的能力由每個職責角色貢獻，然后集成，這一點很符合當今IT平臺化架構特點。

那DevOps是如何驅動應用從運維到管理的轉變呢?我總結了幾點：

1、認識應用在生命周期每一個階段的能力，比如說敏捷管理、持續交付、IT運營管理(包含IT服務管理)。這一點可以結合DevOps整體框架來進行，但我把IT服務管理改成了IT運營管理，IT服務管理是ITOM的一部分。

2、把持續交付作為應用構建的核心IT能力來看待。持續交付的起點是應用的形成，終點是應用的運行管理或者終止等等。持續集成、持續審查、測試、持續部署到持續運營反饋，在持續交付這個維度上要形成閉環。

3、給出一個IT效能指標體系或者IT價值衡量體系來對接應用支撐的業務價值。前者從應用交付的效能來技術化衡量應用對業務的支撐能力：

后者衡量應用的業務價值：

其實去運維化認知，也就是我不斷說的運維跨界，就是不要被運維過去的要求所束縛，應該看到IT模式變化給運維帶來新的要求。

【本文是51CTO專欄作者“王津銀”的原創稿件，轉載請注明出處】

戳這里，看該作者更多好文