错误1：运维是运维人的运维

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

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

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

• 对于第一层，资源的成本控制的确是运维的职责之一，但仅仅是他一个价值维度的体现。一个可运维性高的系统，带来的是服务质量的提升，这个是需要运维来hold（至少国内很多研发团队如此）；一个好的运维团队，能够反向驱动组织IT性能的提升，性能的提升，就是组织利润／市场占有率的提升（2014年DevOps Report揭示的现实）。
• 对于第二层，其实在错误认识1里面已经有了答案，根源是在于大家还是把运维当成维护来看待，那时运维职能化是过去的表述，今天已经开始提倡运维价值，走向IT运营。
  

错误3：运维的职责就是维稳

稳定性可以理解成可用性，可用性一定不是我们维护出来的。运维过程的确能增加业务的可用性，但可用性的根源不是维护出来的，可用性是产品线上各个职能角色的共同职责。

维稳让人感觉就是救火队员，故障发生时运维冲在第一线，如果没有运维，这个产品的稳定性就没法保证？我依然觉得这还是一种有形的运维存在，还是要依赖运维这个实体，真正的运维是没有运维的。我习惯性把应用运维有三种阶段：

• 第一阶段：应用是按照业务走的，此时运维人还能看到业务，把运维过程和业务特性紧密联系在一起了。当前阶段，运维需要站在用户的角度来审视自己维护的系统，看看系统是否达到高可用的要求。
• 第二阶段：运维是看不到业务的，这个时候业务的技术架构高度服务化，A和B业务是没有差别的，因为技术架构是统一的。此时有点IT运营的感觉了。
• 第三阶段：运维实体是不存在的，特别是上层的应用运维。可运维性已经是研发体系的一部分，已经是约定俗成，自己开发的业务，自己上线，自己维护，自己接收告警，自己处理，自己变更。运维提供的是一套标准，一种平台，一类机制等等。
  

维稳，是运维人的枷锁，非常赞同老萧的“高效运维”实践（IT高性能），基于互联网＋的业务更应该去追求运维的极致性能。在“高效运维”的实践过程中，此时需要运维过程的彻底可视化，可视化才能可控，可视化是更是自动化的一种高级形态。更要把可视化的过程传导到线上业务技术架构中，让架构可视化是可运维性的一个重要标准。

错误4、运维人要甘居人后

这个是上次高效运维中透漏出来的一个观点，并且这种观点普遍存在。我对此并不认同，人后是一种支持者的定位。

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

错误5、DevOps是运维人的救命稻草

DevOps不是运维人的救命稻草！我把DevOps更多理解成软件研发模式的一种变化，从早期的传统软件工程模式到敏捷模式再到DevOps模式，是让软件研发过程越来越柔和更多的角色一次性进入。

在早期的瀑布式软件工程模式下，研发／测试／维护（还不是运维）是独立和隔离的，研发写好代码并自测后交给测试，测试完成后，维护部署上线。再到敏捷模式下，研发和测试深度融合，测试驱动研发。

当随着基于互联网下的业务敏捷性要求越来越高，维护的重要性日益凸显，单纯过去的维护方法论不足以支撑，此时就需要运维的能力提前加入到软件研发过程中，比如说软件的高可用设计（对软硬件的容错性）／服务监控／自动化能力封装等等。

错误6、DevOps就是自动化

自动化很重要，但不代表DevOps就等同自动化。自动化是一种技术要求，当你不是全局自动化的时候，它带来的驱动力更是有限的，况且DevOps从来就不是一个技术问题。

因此我建议一定大家把基于用户价值交付流的自动化作为目标，此时能全局思考对运维内部各团队的自动化要求，对研发、对测试的自动化要求等等。

错误7、APM代表运维的存在感

很奇怪，在不同的交流场合，大家依然在问我怎么看APM。我的观点很明确，APM很重要，但不能代表运维。APM解决的更多是研发的代码性能问题，而不是运维侧的问题。如果一个运维团队要通过APM找存在感的话，我觉得运维是黔驴技穷了。

在早期的ITIL里面就提到过能力管理，其中一个就是服务能力管理，你可以理解成服务性能管理。达到性能管理，实现手段有很多种，APM提供了一种通用方法，从这个角度来说，意义很大。

错误8、互联网运维就是最好的运维

某些方面是，某些方面不是，这个需要细看，只能说互联网找到了该业务形态及业务体量下最合适的运维模式（组织／规范／平台等等）。就拿BAT三家来说，他们的运维差别其实很大，特别是到应用层运维。

运维的实践性太强，照搬不一定有用，更要看到一个运维体系的建立背后考虑和依赖的因素是哪些，特别是和业务形态有关系，这些实践性东西对大家更有用。传统行业更需要慎重，一定要记得互联网运维最佳实践先行导入，然后产品进入。

其他

其实还有很多错误的观点，如：“业务运维可以不做运维系统研发工作”，这个说法叫愚蠢；“运维系统研发很简单”，可以说运维系统研发一点都不简单，难在对运维场景的理解上，对运维模式的理解上，对运维核心需求的识别上等等；“运维没法参与研发架构设计”，运维更应该早期参与到研发的架构设计中，把运维的要求推进去，并要求实现；“运维对初创企业不重要”，我觉得这是因为大家还不知道运维是什么，其实越到后面构建运维能力，成本越高。

错误1：运维是运维人的运维

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

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

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

• 对于第一层，资源的成本控制的确是运维的职责之一，但仅仅是他一个价值维度的体现。一个可运维性高的系统，带来的是服务质量的提升，这个是需要运维来hold（至少国内很多研发团队如此）；一个好的运维团队，能够反向驱动组织IT性能的提升，性能的提升，就是组织利润／市场占有率的提升（2014年DevOps Report揭示的现实）。
• 对于第二层，其实在错误认识1里面已经有了答案，根源是在于大家还是把运维当成维护来看待，那时运维职能化是过去的表述，今天已经开始提倡运维价值，走向IT运营。
  

错误3：运维的职责就是维稳

稳定性可以理解成可用性，可用性一定不是我们维护出来的。运维过程的确能增加业务的可用性，但可用性的根源不是维护出来的，可用性是产品线上各个职能角色的共同职责。

维稳让人感觉就是救火队员，故障发生时运维冲在第一线，如果没有运维，这个产品的稳定性就没法保证？我依然觉得这还是一种有形的运维存在，还是要依赖运维这个实体，真正的运维是没有运维的。我习惯性把应用运维有三种阶段：

• 第一阶段：应用是按照业务走的，此时运维人还能看到业务，把运维过程和业务特性紧密联系在一起了。当前阶段，运维需要站在用户的角度来审视自己维护的系统，看看系统是否达到高可用的要求。
• 第二阶段：运维是看不到业务的，这个时候业务的技术架构高度服务化，A和B业务是没有差别的，因为技术架构是统一的。此时有点IT运营的感觉了。
• 第三阶段：运维实体是不存在的，特别是上层的应用运维。可运维性已经是研发体系的一部分，已经是约定俗成，自己开发的业务，自己上线，自己维护，自己接收告警，自己处理，自己变更。运维提供的是一套标准，一种平台，一类机制等等。
  

维稳，是运维人的枷锁，非常赞同老萧的“高效运维”实践（IT高性能），基于互联网＋的业务更应该去追求运维的极致性能。在“高效运维”的实践过程中，此时需要运维过程的彻底可视化，可视化才能可控，可视化是更是自动化的一种高级形态。更要把可视化的过程传导到线上业务技术架构中，让架构可视化是可运维性的一个重要标准。

错误4、运维人要甘居人后

这个是上次高效运维中透漏出来的一个观点，并且这种观点普遍存在。我对此并不认同，人后是一种支持者的定位。

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

错误5、DevOps是运维人的救命稻草

DevOps不是运维人的救命稻草！我把DevOps更多理解成软件研发模式的一种变化，从早期的传统软件工程模式到敏捷模式再到DevOps模式，是让软件研发过程越来越柔和更多的角色一次性进入。

在早期的瀑布式软件工程模式下，研发／测试／维护（还不是运维）是独立和隔离的，研发写好代码并自测后交给测试，测试完成后，维护部署上线。再到敏捷模式下，研发和测试深度融合，测试驱动研发。

当随着基于互联网下的业务敏捷性要求越来越高，维护的重要性日益凸显，单纯过去的维护方法论不足以支撑，此时就需要运维的能力提前加入到软件研发过程中，比如说软件的高可用设计（对软硬件的容错性）／服务监控／自动化能力封装等等。

错误6、DevOps就是自动化

自动化很重要，但不代表DevOps就等同自动化。自动化是一种技术要求，当你不是全局自动化的时候，它带来的驱动力更是有限的，况且DevOps从来就不是一个技术问题。

因此我建议一定大家把基于用户价值交付流的自动化作为目标，此时能全局思考对运维内部各团队的自动化要求，对研发、对测试的自动化要求等等。

错误7、APM代表运维的存在感

很奇怪，在不同的交流场合，大家依然在问我怎么看APM。我的观点很明确，APM很重要，但不能代表运维。APM解决的更多是研发的代码性能问题，而不是运维侧的问题。如果一个运维团队要通过APM找存在感的话，我觉得运维是黔驴技穷了。

在早期的ITIL里面就提到过能力管理，其中一个就是服务能力管理，你可以理解成服务性能管理。达到性能管理，实现手段有很多种，APM提供了一种通用方法，从这个角度来说，意义很大。

错误8、互联网运维就是最好的运维

某些方面是，某些方面不是，这个需要细看，只能说互联网找到了该业务形态及业务体量下最合适的运维模式（组织／规范／平台等等）。就拿BAT三家来说，他们的运维差别其实很大，特别是到应用层运维。

运维的实践性太强，照搬不一定有用，更要看到一个运维体系的建立背后考虑和依赖的因素是哪些，特别是和业务形态有关系，这些实践性东西对大家更有用。传统行业更需要慎重，一定要记得互联网运维最佳实践先行导入，然后产品进入。

其他

其实还有很多错误的观点，如：“业务运维可以不做运维系统研发工作”，这个说法叫愚蠢；“运维系统研发很简单”，可以说运维系统研发一点都不简单，难在对运维场景的理解上，对运维模式的理解上，对运维核心需求的识别上等等；“运维没法参与研发架构设计”，运维更应该早期参与到研发的架构设计中，把运维的要求推进去，并要求实现；“运维对初创企业不重要”，我觉得这是因为大家还不知道运维是什么，其实越到后面构建运维能力，成本越高。