这是对一个问题的回应“中小(互联网)企业真的需要运维么?”
很有意思的现象，这样的一个问题的提问者有时候包含了运维人自己。我一直用这样的回答来回复提问者“你可以不需要运维人，但不能不需要运维，运维是一种能力，它能带来业务价值。”
很多人都是从需求》研发》测试》维护过程来看运维的，中小企业觉得自身的IT不复杂，可以不需要测试或者运维，因为根本不明白他们能带来什么价值?这样一个时间段你都是把测试和运维看成某类具体的角色了，你认为可以不招聘相应的人，但是你不能忽略测试和运维的作用。今天不把传统企业纳入范畴，只对互联网+型公司做讨论。
从业务的驱动力来说，互联网+型的业务速度慢慢的变快，版本每日多次迭代。在强调业务驱动力的时候，很多公司看到了业务功能的实现，而忽略基础能力的构建，从而本应工具解决的问题，最后引入了大量的人来解决，吊诡的是，在软件领域，人的增多，并不意味着生产力的提升。也本应在一定的阶段，引入工具对IT流程来优化，此时能带来更多的时间和人力成本的节省，但依然忽略了。我认为这是过分强调业务驱动导致的，还有一个技术层的原因。
说到技术层的原因，我们都知道，随义务越来越复杂，产品线会裂变慢慢的变多，此时的组织复杂度就出来了，各个团队的行为会逐渐变得自主。在团队规模小的阶段，组织内部的信息流依然还是有序的，因为是少量人控制，能够最终靠面对面沟通解决。但在很短的时间内，产品迅速增多，信息流变得无序了，出现无规范/无制度/无平台的状态。技术层的原因，离散组织缺少中心控制节点。
强调业务驱动没有错的，但过分强调业务驱动则有错，没考虑业务驱动背后的其他因素。其实测试和运维也在强调业务驱动，但和研发所focus的业务驱动有很大的差别。研发强调的是业务上的功能实现，而测试运维分别强调更好的功能实现，什么是更好?如功能可测试性，功能的完备性，可维护性，稳定性等等。从专业分工的角度来说，测试和运维长期了以来形成了大量的方法论用于支撑软件研发的过程，确保高质量交付，不应该忽视长期形成的经验。
强调测试/运维的早期参与，是一种测试/运维驱动研发的软件方法论。举个简单的例子，测试在早期不参与研发需求评审的话，测试只能成为研发的附属过程，研发交给你什么，你测试什么，此时它就是一个成本中心，而不是价值中心，对于运维来说也是如此。可测试性和可运维性可以对软件的设计提出很多合理的要求，从代码的可测试性到整体架构的可运维性等等。
回到技术层面上离散组织缺少中心控制节点。为什么运维能成为中心控制节点?成为中心控制节点的运维到底还能做什么?接下来就是其他的组织设置和流程设置的问题了。
为什么运维可以称为中心控制节点?从交付链条来说，所有的服务交付都最终到运维这边，运维离用户最近，能够第一时间获取服务的用户使用状态；其次生产环境的集中管理一定是运维来保证的，运维能够建立起统一的技术管理规范。针对第一点，运维及时的获取服务状态及后续的服务状态更新之后，可以去反向驱动研发进一步的服务优化，这个优化有业务上(体验及服务)，也有非业务上(性能及成本)等等，这是运维的驱动力。针对第二点，这是运维的核心控制力，建立起统一的技术标准规范，在公司内所有产品线统一推行，让大家方向一致，减少混乱带来的无谓消耗，这是运维的控制力。此时需要做一些变化，把运维的职能从研发里面剥离出来，建立一个统一的中心化运维组织。我把DO关系分成三个阶段：
第一个阶段：DO混合，大家的职能交织在一起，运维是研发的附属过程，运维的职责就是资源交付；
第二个阶段：DO分离，研发和运维走向分离，一些维护的压力逐渐浮现出来，专业的运维怎么样更好的做好运维，定规范，建平台，收数据等等；
第三个阶段：DO融合，注意不是混合。融合是指一种能力的流动，运维的能力已经是研发过程自然而然考虑的一部分的了，另外这种运维的能力随着平台/规范/流程的完善，此时研发都可以具备真正的运维能力。
成为中心节点的运维到底还能做什么?其实能做的事情就很多了，定规范/建平台/收数据等等。规范可以分多种，线上运维的规范，持续交付过程规范，涉及环境管理/流程规范等等，还有安全准则规范，事务驱动的规范(可用性驱动研发)等等，很多很多。平台里面涉及到自动化平台，覆盖各种运维场景，可以是工具化的运维场景，一些配置管理工具就能解决的；还有一些复杂的业务场景，这个需要专业化的运维管理平台来完成的等等；数据驱动运维，驱动DevOps，需要采集大量的技术运营数据，这一个地区有一个争议，运维是否要覆盖产品运营的数据分析场景?我倒不建议，聚焦在自己擅长的部分，当然可以不阻止这个想象力，注意监控平台能够理解成数据体系的一部分。最终通过平台来沉淀规范，能力通过平台来表达，以此来实现运维就是一种能力。基于能力的运维交付，才是真正的运维。
最后，我想说有一种能力叫运维，而不是有一类人叫运维，对于中小企业甚至是初创企业，你可以不要运维人，但你不能不要运维的能力，因为它可以让公司更好，业务发展更快，为啥不呢。不知道你怎么看呢?
关于老王(原名王津银，微信号：waynewang)：07年进入腾讯公司接触运维，经历服务器从百到万的运维历程，先后在YY和UC参与不同业务形态的运维，期间带过前端运维、数据存储运维、YY语音、游戏运维、运维研发等多种运维团队，对运维有着全面的理解。极力倡导互联网价值运维理念，即面向用户的价值是由自动化平台交付传递，同时由数据化来提炼和衡量。
在经过经济寒冬的考验后，更多的IT公司开始考虑怎么应对接下来更复杂的行业环境，在努力提升公司自身抗风险素质的同时，能够把握更多的合作机遇，使企业保持继续健康发展的态势成为了新的焦点，中国IDC圈与中国IT实验室始终致力于打造行业间友好共赢的交流平台，在2009年1月7日成功举办第三届中国IDC产业年度大典之后，应众多行业伙伴的要求，在3月1日正...
如何理解“互联网+”，对企业的战略又有何影响全国人大代表用友网络董事长兼CEO王文京提出“企业互联网这个名词更合适”。企业是网络的重要主体，企业互联网化是推动中国经济转型的引擎。企业互联网有各种不同的叫法，产业互联网，工业互联网，工业4.0，总理报告里面提到互联网+，包括工业化与信息化融合即两化融合。
互联网+的热度在持续发酵，不仅与通信、金融以及商业结合创造出惊喜，也给别的行业带来了深度改变。运维就是这样，互联网运维蓬勃成长，与云计算碰撞出火花。在由51CTO举办的WOT2015互联网运维与开发者大会上，UnitedStack公司创始人兼CEO程辉解读了《OpenStack与互联网运维》，解释互联网+时代该怎么样运维。
有人说，运维从传统部署到大规模自动化的转变，Coding能力要求慢慢的升高。也有人说，大部分IT企业都是重研发轻运维，在云计算下思想急需转变。更有人说，DevOps在运维领域中，一场以它为中心的深入敏捷变革运动也在悄然兴起。还有人说，新的运维模式应该是建立ETA(EnvironmentToolsAutomation）团队，突破原有思维模式。到底未来的运维模式是什么？如今运维...