这是对一个问题的回应——“中小型（互联网）公司真的需要运维吗？” 是一个很有趣的现象。包括运维人员自己。我一直用这个答案来回复提问者“你可以不需要运维人员，但是你离不开运维，运维是一种能力，可以带来商业价值。” 很多人从需求出发——“研发——”测试—“运维角度的维护过程，中小企业认为自己的IT不复杂，不需要测试或者运维，因为他们不知道自己能带来什么价值？这个时候，你们都把测试和运维当做某类特定的角色，你认为你招不到相应的人，其实你招不到忽略测试和运维的作用，今天传统企业不在范围内，只讨论互联网+企业。 从业务驱动力来看，互联网+业务的速度越来越快，速度更快，版本一天迭代多次，很多公司在强调业务驱动力的时候，只看到了业务功能的实现，而忽略了基础能力的建设，以至于出现的问题工具能解决的，最后还是请了一大批人来解决。矛盾的是，在软件领域，人们生产力的提高并不意味着生产力的提高。也应该在某个阶段引入工具来优化IT流程，这可以带来更多的时间和人力成本的节约，但还是被忽视了。我认为这是过于强调业务驱动造成的，也有技术方面的原因。 说到技术原因，大家都知道随着业务越来越复杂，产品线也会越来越裂变。这时候组织的复杂性就出来了，各个团队的行为也会逐渐自主化。.当团队规模较小时，组织内部的信息流仍然是有序的，因为它由少数人控制，可以通过面对面的沟通来解决。但在短时间内，产品数量迅速增加，信息流动变得混乱，出现无标准/无系统/无平台的状态。由于技术原因，离散组织缺乏中央控制节点。 针对以上问题，测试/运维能起到什么作用？ 强调业务驱动没有错，但是过分强调业务驱动而不考虑业务驱动背后的其他因素是错误的。其实测试和运维也是在强调业务驱动，但是和研发院所关注的业务驱动有很大区别。研发侧重于业务功能的实现，测试运维侧重于更好的功能实现。什么是更好的？如功能可测试性、功能完备性、可维护性、稳定性等。从专业分工的角度来看，测试和运维长期形成了大量的方法论来支撑软件开发过程，保证高质量交付。长期经验不容忽视。 强调测试/运维的早期参与，是由测试/运维驱动的软件方法论。举个简单的例子，如果前期测试不参与研发需求评审，那么测试只能成为研发的一个附属过程。研发交给你什么，你测试什么，这时候就是成本中心，而不是价值中心。魏亦然。可测试性和可操作性可以对软件设计提出很多合理的要求，从代码的可测试性到整体架构的可操作性等等。 回到技术层面——离散的组织缺乏一个中央控制节点。为什么运维可以成为中控节点？成为中控节点的运维还能做什么？其次是其他组织设置和流程设置的问题。 运维为什么可以称为中控节点？从交付链的角度来看，所有的服务交付都终止于运维端，离用户最近，可以第一时间获取用户对服务的使用情况；其次，生产环境的集中管理必须有运维保障，可以建立统一的技术管理标准。对于第一点，运维及时获取服务状态后，后续的服务状态更新，可以反向带动进一步服务优化的研发。这个优化包括业务（体验和服务）和非业务（性能和成本））等等，这就是运维的驱动力。对于第二点，这是运维的核心控制力。建立统一的技术标准和规范，并在公司所有产品线中统一执行，使大家同心协力，减少混乱带来的不必要的消耗。这就是运维的控制。力量。这时候就需要做出一些改变，将运维职能从研发中分离出来，建立统一的集中式运维组织。我把DO关系分为三个阶段： 第一阶段：DO混合，大家的职能相互交织，运维是研发的附属过程，运维的职责是资源交付； 第二阶段：DO分离，研发和运维走向分离，一些运维压力逐渐显现，专业运维如何做好运维、制定规范、搭建平台、收集数据，ETC。; 第三阶段：DOFusion，注意不是混音。融合是指能力的流动。运维能力已经是研发过程中自然而然的一部分。另外，随着平台/标准/流程的完善，研发现在可以拥有真正的运维能力。维度能力。 中心节点的运维还能做什么？其实可以做的事情有很多，比如设置规范/搭建平台/接收数据等等。规范可以分为很多种，线上运维规范、持续交付流程规范、环境管理/流程规范等，还有安全规范、事务驱动规范（可用性驱动研发）等，还有很多更多的。平台涉及自动化平台，涵盖各种运维场景。可以是工具化的运维场景，可以通过一些配置管理工具来解决；还有一些复杂的业务场景，需要专业的运维管理平台。完成等；数据驱动运维，驱动DevOps，需要采集大量的技术运维数据，这里有个争论，运维是否应该涵盖产品运行的数据分析场景？不推荐，专注于自己擅长的部分，当然也不能停止这种想象，注意监控平台可以理解为数据系统的一部分。最终通过平台沉淀规范，通过平台表达能力，运维的实现就是一种能力。基于能力的运维交付才是真正的运维。 最后想说，有一种能力叫运维，而不是有一种人叫运维。对于中小企业甚至初创企业来说，可以没有运维人员，但是不能没有运维能力，因为它可以让公司更好，业务增长更快，何乐而不为.不知道你怎么看？ 关于老王（原名王金银，微信号：waynewang）：2007年加入腾讯，接触运维。他经历了从一百台到万台服务器的运维过程。在业务形态运维方面，期间带领过前端运维、数据存储运维、YY语音、游戏运维、运维研发等各类运维团队.，并对运维有全面的了解。大力倡导互联网价值运维理念，即以用户为中心的价值由自动化平台交付，同时由数据细化和衡量。
