错误1??it运维是运维人的运??

这个是必须首先要纠正的，因为它关系到你的定位和团队未来的发展。当你把运维限制在运维人的职责范围之内的时候，必定是没法走远的。这也限制你能提供的价值，貌似一个价值不高的团队，必然就没法认可。正确的认识，运维人需要把可运维性标准和意识不断Push到产品／研发过程中，让运维成为所有人的运维，成为产品功能实现的一部分??

错误2：运维是一个成本中??

这里面有两层理解，第一层是IT服务资源的管理者，他有责任对资源的使用状况做好控制，避免浪费；第二层，运维人好像没法直接产生收益，管理意识里就是要控制运维成本的投入，特别是运维人力投入??

    对于第一层，资源的成本控制的确是运维的职责之一，但仅仅是他一个价值维度的体现。一个可运维性高的系统，带来的是服务质量的提升，这个是需要运维来hold（至少国内很多研发团队如此）；一个好的运维团队，能够反向驱动组织IT性能的提升，性能的提升，就是组织利润／市场占有率的提升（2014年DevOps Report揭示的现实）??

    对于第二层，其实在错误认??1里面已经有了答案，根源是在于大家还是把运维当成维护来看待，那时运维职能化是过去的表述，今天已经开始提倡运维价值，走向IT运营??

错误3：运维的职责就是维稳
稳定性可以理解成可用性，可用性一定不是我们维护出来的。运维过程的确能增加业务的可用性，但可用性的根源不是维护出来的，可用性是产品线上各个职能角色的共同职责??
维稳让人感觉就是救火队员，故障发生时运维冲在第一线，如果没有运维，这个产品的稳定性就没法保证？这还是一种有形的运维存在，还是要依赖运维这个实体，真正的运维是没有运维的??

错误4、运维人要甘居人??
运维要改变角色认知，需要把自己放到用户一起，你代表着用户来看我们的系统，系统的好与坏是需要运维建立规则来衡量，同时必须要代表用户强加一种执行力去驱动整个内部研发过程改善的。这需要运维从幕后走向前台！！??

错误5、DevOps就是自动??
自动化很重要，但不代表DevOps就等同自动化。自动化是一种技术要求，当你不是全局自动化的时候，它带来的驱动力更是有限的，况且DevOps从来就不是一个技术问题??
建议一定大家把基于用户价值交付流的自动化作为目标，此时能全局思考对运维内部各团队的自动化要求，对研发、对测试的自动化要求等等??

错误6、APM代表运维的存在感
APM很重要，但不能代表运维。APM解决的更多是研发的代码性能问题，而不??it运维侧的问题。如果一个运维团队要通过APM找存在感的话，就是黔驴技穷了??
在早期的ITIL里面就提到过能力管理，其中一个就是服务能力管理，你可以理解成服务性能管理。达到性能管理，实现手段有很多种，APM提供了一种通用方法，从这个角度来说，意义很大??