互联网企业需要一种能力叫运维

运维 系统运维 系统
本文是对一个问题的回应——“中小(互联网)企业真的需要运维么?”很有意思的现象,这个问题的提问者有时候包含了运维人自己。我一直用这样的回答来回复提问者“你可以不需要运维人,但不能不需要运维,运维是一种能力,它可以带来业务价值。”

  [[150063]]

这是对一个问题的回应——“中小(互联网)企业真的需要运维么?”

  很有意思的现象,这个问题的提问者有时候包含了运维人自己。我一直用这样的回答来回复提问者“你可以不需要运维人,但不能不需要运维,运维是一种能力,它可以带来业务价值。

  很多人都是从需求——》研发——》测试——》维护过程来看运维的,中小企业认为自己的IT不复杂,可以不需要测试或者运维,因为根本不知道他们能带来什么价值?这个时候你都是把测试和运维看成某类具体的角色了,你认为可以不招聘相应的人,但是你不能忽略测试和运维的作用。今天不把传统企业纳入范畴,只对互联网+型公司进行讨论。

  从业务的驱动力来说,互联网+型的业务速度越来越快,版本每日多次迭代。在强调业务驱动力的时候,很多公司看到了业务功能的实现,而忽略基础能力的构建,从而本应工具解决的问题,最后引入了大量的人来解决,吊诡的是,在软件领域,人的增多,并不代表生产力的提升。也本应在一定的阶段,引入工具对IT流程进行优化,此时可以带来更多的时间和人力成本的节省,但依然忽略了。我认为这是过分强调业务驱动导致的,还有一个技术层的原因。

  说到技术层的原因,我们都知道,随着业务越来越复杂,产品线会裂变越来越多,此时的组织复杂度就出来了,各个团队的行为会逐渐变得自主。在团队规模小的阶段,组织内部的信息流依然还是有序的,因为是少量人控制,可以通过面对面沟通解决。但在很短的时间内,产品迅速增多,信息流变得无序了,出现无规范/无制度/无平台的状态。技术层的原因,离散组织缺少中心控制节点。

  那针对以上问题,测试/运维到底能起到什么样的作用呢?

  强调业务驱动没有错的,但过分强调业务驱动则有错,没考虑业务驱动背后的其他因素。其实测试和运维也在强调业务驱动,但和研发所focus的业务驱动有很大的差别。研发强调的是业务上的功能实现,而测试运维分别强调更好的功能实现,什么是更好?如功能可测试性,功能的完备性,可维护性,稳定性等等。从专业分工的角度来说,测试和运维长期了以来形成了大量的方法论用于支撑软件研发的过程,确保高质量交付,不应该忽视长期形成的经验。

  强调测试/运维的早期参与,是一种测试/运维驱动研发的软件方法论。举个简单的例子,测试在早期不参与研发需求评审的话,测试只能成为研发的附属过程,研发交给你什么,你测试什么,此时它就是一个成本中心,而不是价值中心,对于运维来说也是如此。可测试性和可运维性可以对软件的设计提出很多合理的要求,从代码的可测试性到整体架构的可运维性等等。

  回到技术层面上——离散组织缺少中心控制节点。为什么运维可以成为中心控制节点?成为中心控制节点的运维到底还能做什么?接下来就是其他的组织设置和流程设置的问题了。

  为什么运维可以称为中心控制节点?从交付链条来说,所有的服务交付都最终到运维这边,运维离用户最近,能够第一时间获取服务的用户使用状态;其次生产环境的集中管理一定是运维来保证的,运维能够建立起统一的技术管理规范。针对第一点,运维及时的获取服务状态及后续的服务状态更新之后,可以去反向驱动研发进一步的服务优化,这个优化有业务上(体验及服务),也有非业务上(性能及成本)等等,这是运维的驱动力。针对第二点,这是运维的核心控制力,建立起统一的技术标准规范,在公司内所有产品线统一推行,让大家方向一致,减少混乱带来的无谓消耗,这是运维的控制力。此时需要做一些变化,把运维的职能从研发里面剥离出来,建立一个统一的中心化运维组织。我把DO关系分成三个阶段:

  第一个阶段:DO混合,大家的职能交织在一起,运维是研发的附属过程,运维的职责就是资源交付;

  第二个阶段:DO分离,研发和运维走向分离,一些维护的压力逐渐浮现出来,专业的运维如何更好的做好运维,定规范,建平台,收数据等等;

  第三个阶段:DO融合,注意不是混合。融合是指一种能力的流动,运维的能力已经是研发过程自然而然考虑的一部分的了,另外这种运维的能力随着平台/规范/流程的完善,此时研发都可以具备真正的运维能力。

  成为中心节点的运维到底还能做什么?其实能做的事情就很多了,定规范/建平台/收数据等等。规范可以分多种,线上运维的规范,持续交付过程规范,涉及环境管理/流程规范等等,还有安全规范,事务驱动的规范(可用性驱动研发)等等,很多很多。平台里面涉及到自动化平台,覆盖各种运维场景,可以是工具化的运维场景,一些配置管理工具就能解决的;还有一些复杂的业务场景,这个需要专业化的运维管理平台来完成的等等;数据驱动运维,驱动DevOps,需要采集大量的技术运营数据,这个地方有一个争议,运维是否要覆盖产品运营的数据分析场景?我倒不建议,聚焦在自己擅长的部分,当然可以不阻止这个想象力,注意监控平台可以理解成数据体系的一部分。最终通过平台来沉淀规范,能力通过平台来表达,从而实现运维就是一种能力。基于能力的运维交付,才是真正的运维。  

  最后,我想说有一种能力叫运维,而不是有一类人叫运维,对于中小企业甚至是初创企业,你可以不要运维人,但你不能不要运维的能力,因为它可以让公司更好,业务发展更快,为什么不呢。不知道你怎么看呢?

  关于老王(原名王津银,微信号:waynewang):07年进入腾讯公司接触运维,经历服务器从百到万的运维历程,先后在YY和UC参与不同业务形态的运维,期间带过前端运维、数据存储运维、YY语音、游戏运维、运维研发等多种运维团队,对运维有着全面的理解。极力倡导互联网价值运维理念,即面向用户的价值是由自动化平台交付传递,同时由数据化来提炼和衡量。

责任编辑:火凤凰 来源: 互联网运维杂谈
相关推荐

2019-11-13 10:45:43

互联网安全运维

2015-08-10 10:56:59

运维互联网

2014-05-16 15:24:36

IT运维管理移动互联网

2015-03-02 09:21:03

运维监控系统小米

2017-04-26 09:40:00

2015-10-14 09:41:23

四力模型互联网运维

2015-06-10 13:46:28

IT运维互联网+”

2016-05-05 14:20:50

运维互联网运维IOE

2014-09-24 15:44:46

用友

2015-03-25 18:31:20

互联网+

2015-04-10 12:43:10

开源WOT2015平台持续交付运维自动化

2009-03-06 17:41:43

互联网

2015-05-06 09:49:14

UnitedStackOpenStack

2019-07-15 07:57:51

工业互联网IIOT物联网

2017-01-22 16:35:02

iOSBlockCallback

2015-07-21 17:19:55

用友iUAP

2015-12-24 16:43:06

互联网错误代码451

2015-04-10 11:18:34

WOT运维大会

2016-05-12 17:23:43

用友iUAP

2014-06-27 14:04:27

运维自动化
点赞
收藏

51CTO技术栈公众号