DevOpsdays以非常成功的姿态完成首秀，自己也是满满的收货和思考！

在这次的DevOpsdays大会上了，我的演讲主题是《DevOps，驱动应用从运维走向管理》，我为什么分享这样的主题？

从2015年的第一篇文章[  /s?__biz=MzA4NjAzMjEyOA==&mid=204756282&idx=1&sn=d2caccadaee25313c301161da28964eb&scene=21#wechat_redirect]【扯淡篇】DevOps，值得运维拥抱！[/url]开始，去年不断地和大家讲[  /s?__biz=MzA4NjAzMjEyOA==&mid=2654565333&idx=1&sn=80e1118d3393528ec5eeb648daac1f09&chksm=840339bab374b0ac88b2e2ccb721e9ef68ce68e17bf3d0398935215ae10d61b05a5a37cf5f58&scene=21#wechat_redirect]【DevOps运维】构建面向应用的运维管理新思维[/url] 。在昨天的演讲上，我把两个点完整的串接起来了，整合到了一起。

其实在过去一直想给“到底什么是运维”寻找一个答案？我极力避免的是我们狭义化定义运维（变更/问题处理/值班等等）。因此从我有限的理解和工作经历中，我尝试了从多个角度来阐述，[  /s?__biz=MzA4NjAzMjEyOA==&mid=400858947&idx=1&sn=bc8e03f8b7662e6f5d77065615faace0#wechat_redirect]初探精益运维体系｜多图[/url] 。在精益运维的体系中，我把运维分成几个标准的部分，有工具、有标准化、有架构、有服务化等等。自我觉得，这样的认知一定程度上突破了对运维本身的认识，做了一点跨界的思考。

到今天，当我们都在不断的讲DevOps的时候，如果我们还在用运维的视角去认识当下的运维是否也是狭义化的表现呢？是不是要回归到更大局的IT全价值链上看运维？我对此作出的第一个改变是把运维的词语给换了——文字背后的力量。应用运维就变成了应用管理，从运维到管理。

运维是一个阶段性的定义，特别是在职能化的组织架构中，限制了你的职责范围和行为方式。而管理不是，管理是从全生命周期的角度去看的。当我们从生命周期的角度去看，我们要知道每一个阶段应该需要什么样的平台支持，需要什么样的组织匹配，需要什么样的文化支撑等等。

前天还和乔梁老师说，在我每一次的运维分享中，我都会和运维人说，你翻译的《持续交付》被我给列为运维人必看书。的确，我深受这本书的全局视野的影响，同时也感叹于作者在每一个事情上具体细节把握，是一本难得的好书。我之前也把这条IT交付的价值链和业务链匹配起来，从而让自己有些全局视角，我再也不局限于我们自己范围内的优化。另外一点这条能力链恰好覆盖了应用管理的各个阶段，很自然的完成了生命周期的管理。

有人会问，运维真的要且可以构建应用的全生命周期能力？当然。我认为最终的部署和运营行为都是依赖生产环境而进行的，运维有最准确的环境、部署、架构等管理理解。该能力很容易延伸到开发和测试环境（不考虑组织因素）。按照这个思路，持续部署流水线便形成了。那交付流水线又该如何对接呢？我的理解平台本身能力一定要完成插件化的设计，这样便可以对接各类的能力。在DevOps的工具、文化和组织合力下，能力也要以平台化集成的模式对外提供，而每部分的能力由每个职责角色贡献，然后集成，这一点很符合当今IT平台化架构特点。

那DevOps是如何驱动应用从运维到管理的转变呢？我总结了几点：

1、认识应用在生命周期每一个阶段的能力，比如说敏捷管理、持续交付、IT运营管理（包含IT服务管理）。这一点可以结合DevOps整体框架来进行，但我把IT服务管理改成了IT运营管理，IT服务管理是ITOM的一部分。

2、把持续交付作为应用构建的核心IT能力来看待。持续交付的起点是应用的形成，终点是应用的运行管理或者终止等等。持续集成、持续审查、测试、持续部署到持续运营反馈，在持续交付这个维度上要形成闭环。

3、给出一个IT效能指标体系或者IT价值衡量体系来对接应用支撑的业务价值。前者从应用交付的效能来技术化衡量应用对业务的支撑能力：

后者衡量应用的业务价值：

其实去运维化认知，也就是我不断说的运维跨界，就是不要被运维过去的要求所束缚，应该看到IT模式变化给运维带来新的要求。

原创：老王

DevOpsdays以非常成功的姿态完成首秀，自己也是满满的收货和思考！

在这次的DevOpsdays大会上了，我的演讲主题是《DevOps，驱动应用从运维走向管理》，我为什么分享这样的主题？

从2015年的第一篇文章[  /s?__biz=MzA4NjAzMjEyOA==&mid=204756282&idx=1&sn=d2caccadaee25313c301161da28964eb&scene=21#wechat_redirect]【扯淡篇】DevOps，值得运维拥抱！[/url]开始，去年不断地和大家讲[  /s?__biz=MzA4NjAzMjEyOA==&mid=2654565333&idx=1&sn=80e1118d3393528ec5eeb648daac1f09&chksm=840339bab374b0ac88b2e2ccb721e9ef68ce68e17bf3d0398935215ae10d61b05a5a37cf5f58&scene=21#wechat_redirect]【DevOps运维】构建面向应用的运维管理新思维[/url] 。在昨天的演讲上，我把两个点完整的串接起来了，整合到了一起。

其实在过去一直想给“到底什么是运维”寻找一个答案？我极力避免的是我们狭义化定义运维（变更/问题处理/值班等等）。因此从我有限的理解和工作经历中，我尝试了从多个角度来阐述，[  /s?__biz=MzA4NjAzMjEyOA==&mid=400858947&idx=1&sn=bc8e03f8b7662e6f5d77065615faace0#wechat_redirect]初探精益运维体系｜多图[/url] 。在精益运维的体系中，我把运维分成几个标准的部分，有工具、有标准化、有架构、有服务化等等。自我觉得，这样的认知一定程度上突破了对运维本身的认识，做了一点跨界的思考。

到今天，当我们都在不断的讲DevOps的时候，如果我们还在用运维的视角去认识当下的运维是否也是狭义化的表现呢？是不是要回归到更大局的IT全价值链上看运维？我对此作出的第一个改变是把运维的词语给换了——文字背后的力量。应用运维就变成了应用管理，从运维到管理。

运维是一个阶段性的定义，特别是在职能化的组织架构中，限制了你的职责范围和行为方式。而管理不是，管理是从全生命周期的角度去看的。当我们从生命周期的角度去看，我们要知道每一个阶段应该需要什么样的平台支持，需要什么样的组织匹配，需要什么样的文化支撑等等。

前天还和乔梁老师说，在我每一次的运维分享中，我都会和运维人说，你翻译的《持续交付》被我给列为运维人必看书。的确，我深受这本书的全局视野的影响，同时也感叹于作者在每一个事情上具体细节把握，是一本难得的好书。我之前也把这条IT交付的价值链和业务链匹配起来，从而让自己有些全局视角，我再也不局限于我们自己范围内的优化。另外一点这条能力链恰好覆盖了应用管理的各个阶段，很自然的完成了生命周期的管理。

有人会问，运维真的要且可以构建应用的全生命周期能力？当然。我认为最终的部署和运营行为都是依赖生产环境而进行的，运维有最准确的环境、部署、架构等管理理解。该能力很容易延伸到开发和测试环境（不考虑组织因素）。按照这个思路，持续部署流水线便形成了。那交付流水线又该如何对接呢？我的理解平台本身能力一定要完成插件化的设计，这样便可以对接各类的能力。在DevOps的工具、文化和组织合力下，能力也要以平台化集成的模式对外提供，而每部分的能力由每个职责角色贡献，然后集成，这一点很符合当今IT平台化架构特点。

那DevOps是如何驱动应用从运维到管理的转变呢？我总结了几点：

1、认识应用在生命周期每一个阶段的能力，比如说敏捷管理、持续交付、IT运营管理（包含IT服务管理）。这一点可以结合DevOps整体框架来进行，但我把IT服务管理改成了IT运营管理，IT服务管理是ITOM的一部分。

2、把持续交付作为应用构建的核心IT能力来看待。持续交付的起点是应用的形成，终点是应用的运行管理或者终止等等。持续集成、持续审查、测试、持续部署到持续运营反馈，在持续交付这个维度上要形成闭环。

3、给出一个IT效能指标体系或者IT价值衡量体系来对接应用支撑的业务价值。前者从应用交付的效能来技术化衡量应用对业务的支撑能力：

后者衡量应用的业务价值：

其实去运维化认知，也就是我不断说的运维跨界，就是不要被运维过去的要求所束缚，应该看到IT模式变化给运维带来新的要求。

原创：老王