其实以前一直想找到“什么是运维？”的答案。我尽量避免的是我们狭隘地定义运维（变更/问题处理/值班等）。因此，我结合自己有限的理解和工作经验，尝试从多个角度进行阐述，对精益运维体系进行了初步探索。在精益运维体系中，我把运维分为几个标准的部分，包括工具、标准化、架构、服务等等。感觉这种认知在一定程度上突破了对运维本身的认识，做了一点跨界的思考。在我们不断谈论DevOps的今天，如果还用运维的角度去理解现在的运维，是不是也是一种狭义的表达方式？我们要回到更大的IT价值链吗？看运维？我对这个做的第一个改动就是改了运维这个词——词背后的力量。应用运维变成应用管理，从运维到管理。运维是一个阶段性的定义，尤其是在功能性的组织结构中，它限制了你的责任范围和行为。而管理则不然，管理是从全生命周期的角度来看的。我们从生命周期的角度来看，需要知道每个阶段需要什么样的平台支持，需要什么样的组织匹配，需要什么样的文化支持等等。前天跟乔梁老师说，每次运维分享我都会告诉运维人员，你翻译的《持续交付》被列为运维人员必读的书。确实，我深受本书整体视野的影响，同时也感叹作者对每一件事的具体细节都把握的很好，是一本不可多得的好书。我也把这个IT交付价值链和之前的业务链进行了匹配，这样我就可以有全局的视野，不再局限于自己范围内的优化。还有一点，这个能力链恰好涵盖了应用管理的各个阶段，自然而然就完成了生命周期的管理。可能有人会问，运维真的需要并且能够构建应用的全生命周期能力吗？当然。我认为最终的部署和运维行为都依赖于生产环境，运维对环境、部署、架构的管理理解是最准确的。此功能很容易扩展到开发和测试环境（不考虑组织方面的考虑）。按照这个思路，持续部署流水线就形成了。输送管道应该如何连接？我的理解是，平台本身的能力一定要设计成插件的形式，让各种能力打通。在DevOps工具、文化和组织的共同努力下，能力也应该以平台化的集成模式对外提供，每一部分能力由每个角色贡献然后集成，这符合DevOps的特点今天的IT平台架构。那么DevOps是如何驱动应用从运维到管理的转变呢？我总结了几点：1、了解应用在生命周期各个阶段的能力，比如敏捷管理、持续交付、IT运维管理（包括IT服务管理）。这个可以结合DevOps的整体框架来做，但是我把IT服务管理改成了IT运维管理，IT服务管理是ITOM的一部分。2、将持续交付作为应用建设的核心IT能力。持续交付的起点是应用的形成，终点是应用的运行管理或终止。持续集成、持续评审、测试、持续部署、持续运营反馈，在持续交付的维度上形成一个闭环。3、提供IT性能指标体系或IT价值衡量体系，与应用所支撑的商业价值相联系。前者从应用交付的性能上从技术上衡量应用对业务的支撑能力；后者衡量的是应用的商业价值：其实运维的认知，也就是我口口声声说的运维跨界，不是运维要过关的，应该看到IT模型的变化对运维提出了新的要求。【本文为专栏作家“王金银”原创稿件，转载请注明出处】点此阅读更多该作者好文
