通过最近多次的运维交流，还是可以看出一些运维误区。我个人总结如下： 误区一：运维是运维人员的运维 首先要改正，因为这关系到你的定位和团队未来的发展。当你把运维限制在运维人员的职责范围内时，你肯定是走不远的。这也限制了您可以提供的价值。看来价值低的球队是绝对不会被认可的。要正确理解，运维人员需要不断地将可操作性标准和意识推入产品/研发过程，让运维成为每个人的运维，成为产品功能实现的一部分。 错误二：运维是成本中心 有两个层次的理解。第一层是IT服务资源管理者。他负责控制资源的使用，避免浪费；第二层在上层，运维人员似乎无法直接产生收益。管理意识就是控制运维成本的投入，尤其是运维人力的投入。 对于第一层来说，资源成本控制确实是运维的职责之一，但这只是其价值维度的体现。高可运维性的系统带来的是服务质量的提升，需要运维hold住（至少国内很多研发团队是这么干的）；一个好的运维团队可以反向驱动组织IT性能的提升，性能的提升就是组织利润/市场份额的提升（2014年DevOps报告揭示的现实）。 第二层，其实在误区一中就有答案，根本原因还是大家还是把运维当维护。那个时候，运维功能化是一个过时的说法。今天，运维的价值开始被提倡。转到IT运营。 误区三：运维的职责就是保持稳定性 稳定性可以理解为可用性。我们不能实现可用性。运维过程确实可以增加业务的易用性，但是易用性的根本不是靠维护来实现的。可用性是产品线上所有职能角色的共同责任。维文让人觉得自己像个消防员。当故障发生时，运维冲到第一线。如果没有运维，就不能保证这个产品的稳定性？我还是觉得这还是一种有形的运维，还是要靠运维的实体。真正的运维是没有运维的。我习惯性的想到应用运维的三个阶段： 第一阶段：应用跟随业务。这时候运维人员仍然可以看到业务，运维过程与业务特性紧密相连。现阶段运维需要站在用户的角度审视自己维护的系统，看系统是否满足高可用的要求。 第二阶段：运维看不到业务。这时候业务的技术架构是高度服务化的，A业务和B业务没有区别，因为技术架构是统一的。在这一点上，感觉有点像IT运维。 第三阶段：运维实体不存在，尤其是上层的应用运维。可操作性已经是研发体系的一部分，已经是约定俗成。自己开发的业务自己上线、自己维护、自己接收告警、自己处理、自己变更。运维提供了一套标准，一个平台，一个机制等等。 运维和稳定是运维人员的枷锁。非常认同老肖的“高效运维”实践（IT高性能）。基于互联网+的业务，应该追求运维性能的极致。在“高效运维”的实践中，这时候就需要对运维过程进行彻底的可视化，可视化是可控的。可视化是自动化的一种高级形式。更需要将可视化流程传递到在线业务技术架构中，使架构可视化成为可操作性的重要标准。 误区四：运维人员要乐于留下 这是上次高效运维揭示的一个观点，这个观点很普遍。这点我不同意，皇后是拥护者的立场。改变运维的角色认知，需要把自己和用户放在一起。你代表用户来看我们的系统。系统的好坏需要通过建立运维规则来衡量。同时，它必须代表用户施加执行力。推动整个内部研发流程的改进。这就需要运维从后台走到前台！！！ 错误五：DevOps是运维人的救命稻草 DevOps不是运维人的救命稻草！我对DevOps更多的理解是对软件开发模式的一种改变。从早期的传统软件工程模型到敏捷模型，再到DevOps模型，就是让软件开发过程越来越集成，一次进入的角色越来越多。 在早期的瀑布式软件工程模式中，研发/测试/维护（不是运维）是独立孤立的。研发代码写好自测后才交给测试。测试完成后，维护部署上线。敏捷模式下，研发与测试深度融合，测试带动研发。随着基于互联网的业务敏捷性要求越来越高，维护的重要性也越来越凸显，以往的维护方法论已经不足以支撑。这时候就需要提前在软件开发过程中加入运维能力，比如软件的高可用设计（对软硬件的容错）/服务监控/自动化能力打包等。 错误六：DevOps就是自动化 自动化很重要，但不代表DevOps就等同于自动化。自动化是一项技术要求。当你没有完全自动化的时候，它带来的驱动力就更有限了。此外，DevOps从来都不是技术问题。所以我建议大家一定要以基于用户价值传递流程的自动化为目标。这个时候可以全局思考运维各个团队的自动化需求，研发、测试的自动化需求等等。 错误七：APM代表着运维的存在 很奇怪。在不同的交流场合，人们还在问我对APM的看法。我的观点很明确，APM很重要，但不能代表运维。APM解决的更多是研发端的代码性能问题，而不是运维端的问题。如果一个运维团队想通过APM找到存在感，我觉得运维团队已经无路可走。早期的ITIL中提到了能力管理，其中之一就是服务能力管理，你可以理解为服务性能管理。实现绩效管理的方法有很多种。APM提供了一种通用的方法，从这个角度来说意义重大。 误区八：互联网运维是最好的运维运维模式（组织/标准/平台等）。以BAT为例，他们的运维其实有很大的不同，尤其是在应用层运维方??面。 运维太实用了，照搬也未必有用。更重要的是看运维体系的建立背后考虑和依赖了哪些因素，尤其是业务形态相关的因素。这些实用的东西对大家比较有用。有用。传统行业更需谨慎。一定要记住，先介绍互联网运维的最佳实践，再进入产品。 其实还有很多错误的观点，比如：“业务运维做不了运维系统的研发”。简单，难点在于对??运维场景的理解，对运维模型的理解，对运维核心需求的识别等；“运维不能参与研发架构设计”，运维要尽早参与研发架构设计，推动运维需求实现；“运维对初创企业来说不重要”，我想这是因为大家不了解运维是什么，其实运维能力的建设越晚，成本越高。其他观点就不一一列举啦~ 关于老王（原名王金银） 2007年加入腾讯接触运维，经历了服务器从一百到十台的运维过程千，先后参与YY、UC不同业务形态，期间带领前端运维、数据存储运维、YY语音、游戏运维、运维等多个运维团队研发等，对运维有全面的了解。大力倡导互联网价值运维理念，即以用户为中心的价值由自动化平台交付，同时由数据细化和衡量。
