“中小（互联网）企业真的需要运维吗？“
很有意思的现象，这个问题的提问者有时候包含了运维人自己。”可以不需要运维人，但不能不需要运维，运维是一种能力，它可以带来业务价值。“
很多人都是从「需求」「研发」「测试」维护过程来看运维的，中小企业认为自己的IT不复杂，可以不需要测试或者运维，因为根本不知道他们能带来什么价值？这个时候都是把测试和运维看成某类具体的角色了，认为可以不招聘相应的人员，但是不能忽略测试和运维的作用。
从业务的驱动力来说，互联网+型的业务速度越来越快，版本每日多次迭代。在强调业务驱动力的时候，很多公司看到了业务功能的实现，而忽略基础能力的构建，从而本应工具解决的问题，最后引入了大量的人来解决。在软件领域，人力增多，并不代表生产力的提升。也本应在一定的阶段，引入工具对IT流程进行优化，此时可以带来更多的时间和人力成本的节省，但依然忽略了。我认为这是过分强调业务驱动导致的，还有一个技术层的原因。
说到技术层的原因，随着业务越来越复杂，产品线裂变越来越多，此时的组织复杂度就出来了，各个团队的行为逐渐变得自主。在团队规模小的阶段，组织内部的信息流依然还是有序的，因为是少量人控制，可以通过面对沟通解决的。但在很短的时间内，产品迅速增多，信息流变得无序了，出现无规范，无制度，无平台的状态。技术层的原因，离散组织缺少中心控制节点。
那针对以上问题，测试、运维 到底能起到什么样的作用呢？
强调业务驱动没有错的，但过分强调业务驱动则有错，没考虑业务驱动背后的其他因素。其实测试和运维也在强调业务驱动，但和研发所聚焦的业务驱动有很大的差别。研发强调的是业务上的功能实现，而测试运维分别强调更好的功能实现，什么是更好？如功能可测试性，功能的完备性，可维护性，稳定性等等。从专业分工的角度来说，测试和运维长期以来形成了大量的方法论用于支撑软件研发的过程，确保高质量交付，不应该忽视长期形成的经验。
强调测试、运维的早起参与，是一种测试、运维驱动研发的软件方法论。举个简单的例子，测试在早起不参与研发需求的评审的haul，测试只能成为研发的附带流程，研发交给什么，就测试什么，测试它就是一个成本中心，而不是价值中心，对于运维来说也是如此。可测试性和可运维性可以对软件的设计提出很多合理的要求，从代码的可测试性到整体架构的可运维性等等。
回到技术层面上——离散组织缺少中心控制节点。为什么运维可以成为中心控制节点？成为中心控制节点的运维到底还能做什么？
从交付链条来说，所有的服务交付都最终到运维这边，运维理用户最近，能够第一时间获取服务的用户使用状态；其次生产环境的集中管理一定是运维来保证的，运维能够建立起统一的技术管理规范。针对第一点，运维及时的获取服务状态及后续的服务状态更新之后，可以去反向驱动研发进一步的服务优化，这个优化有业务上（体验及服务），也有非业务上等等，这就是运维的驱动力。针对第二点，这是运维的核心控制力，建立起统一的技术标准规范，在公司内所有产品线统一推行，让大家方向一致，减少混乱带来的无畏消耗，这是运维的控制力。此时需要做一些变化，把运维的职能从研发里剥离出来，建立一个统一的中心化运维组织。
成为中心节点的运维到底还能做什么？
其实能做的事情就很多了，定规范、建平台、查数据等。规范可以分多种，线上运维的规范，持续交付过程规范，涉及环境管理、流程规范等等，还有安全规范，事物驱动的规范等。平台里面涉及到自动化平台，覆盖各种运维场景，可以是工具化的运维场景，一些配置管理工具就能解决的；还有一些复杂的业务场景，这个需要专业化的运维管理平台来完成的等；数据驱动运维，驱动devops，需要菜鸡大量的技术运营数据。最终通过平台来沉淀规范，能力通过平台来表达从而实现运维就是一种能力。基于能力的运维交付，才是真正的运维。
最后说点
第三方企业运维服务商——嘀嗒运维。实现运维的能力，不是需要拥有一类人才叫运维，对于中小企业甚至是初创企业，可以不用运维工程师，但不能没有运维的能力，因为它可以让公司更好，业务发展更快。
end
