DevOps-运维的救世主?
之前提到过运维团队的“背黑锅”命运,有些互联网出身的就开始吐槽了,说你看我们互联网里的运维团队就很NB,我们实现了DevOps,我们运维团队的工资同行业傲娇.... 这里,我想先探讨一下为什么在传统行业中会有这样一个在很多“互联网大神”们看起来不可思议反人类的组织架构,把这个问题分析清楚,我们才能不会变成跷跷板,压起这头确翘起了另一头。
首先声明,我们所说的传统行业,是要把一些“你我都明白的行业”去掉,这些行业的业务可有可无,毫无压力,不在我们讨论范围。
我们来谈一个“负责”的概念,我们通常会听到一句话:“这个出了问题,你负的起这个责吗?!”。在互联网行业中,我想不少人会说:我想我负的起!我们举两个例子,前两天某宝,把所有的用户的昵称后面都加了个“宝宝”,我脑补了一下我一个40多岁、胡子拉碴的直男被称为“宝宝”,直接口吐鲜血了。这个明显是一个“决策失误”,但是,我们从2方面来看:1. 公众怎么看这个事儿;2.这个问题出在哪个环节。
1. 唯一在能够看到的公众信息就是大家的朋友圈开始刷屏,貌似没有任何的损失,反而因为刷屏,某宝做了一次成功的”营销“。为什么会是这个样子?
2. 这个事情的决策,可能是两个产品经理头天晚上喝酒的时候定的,当晚就让码农们搞定上线了(实际情况不太清楚,随便黑一下)
实际上这种情况还出现在其他很多环节,例如前两天我某打车平台上的钱不对了,结果就是不对就不对,投诉之后,人家说我补给你就OK了,我后来拿着补偿乐开了花:)
等等
那么如果是传统企业出了这样的事情,会是一个什么结果?
大家回想一下之前的彩票事件,闹得渲染大波。
我们来总结一下不同:
1. 传统行业大多是”国“背景,除了要”赚钱“之外,还要承担”社会责任“,这个社会责任是一座大山,比如银行对于地区、国家的金融秩序稳定,彩票行业对福利、体育事业的支撑以及对国家信任的保护。这些在大多互联网企业,貌似大多只有”赚钱“。这么说可能不少互联网兄弟会不高兴,但是,我们认真想一想,你所供职的企业,承担了什么样的”社会责任“。
2. 由于”社会责任“的压力,所以要考虑到”风险“,这也是传统企业谈的最多的一个话题,“风险管控”!,在传统企业混,如果不知道如何控制风险,不管是控制个人的风险,还是团队的风险、企业的风险,都是很Low的。
所以,我们经常所诟病的传统企业的一些政策,也就容易理解了,传统企业中,我们经常说的一句话是:“会多”,什么事情都要上会,很多人会吐槽会议太多极大的影响了企业的效率和创新,但是,我们可以先思考一下“会议”的好处。
一个业务的投产,通常要经过很多轮会议,回想一下之前提到的流程中4个节点,规划、开发、测试、运维。我们可以看到,这4个环节的想法是不一样的,俗话说,屁股决定脑袋,会议,是一种手段,就是让一个问题在不同的部门内部决策、部门之间PK,从而产生一个平衡的最优解,你想,大家推崇的美国还经常大会小会不停的开呢。
那么,谈到会议,我觉得我们的企业中,并不是会多,而是会议的效率低,说道如何提高会议的效率,我推荐大家听一下《罗辑思维 开会是个技术活》,通过美国宪法的产生,思考一下我们现行的开会方式的缺陷。
再来说一下DevOps,DevOps说白了就是“全才”,开发、测试、运维都在一个团队中,我们先参照一下互联网团队的构成:
这个图,有些地方会成为“横向的服务团队+纵向的产品团队”。
设备运维团队就不讲了,基础平台服务团队,向上面的产品团队提供计算资源、平台资源、数据存储等等平台服务,并且制定运行规范,以提供几乎所有的“共性”产品/模块给到上面的业务团队。
上面的业务团队实际上就是一个一个的产品团队,每个产品团队中又包含产品经理(规划)、开发、测试和运维,很多时候,开发、测试、运维基本上就不怎么分家了,有时候一个人会同时承担多个角色,比如,一个开发人员、负责同伴的模块测试,同时还负责自己模块的运维。
实际上,基础平台服务我们也可以把它看成一个“产品”,所以,我们可以把这个架构简化为一个横向的大产品团队和若干个纵向的产品团队。在每一个产品团队内部,要承担自己产品架构设计、开发、测试和运维。
这个就是我所认识的DevOps,就是小循环内的DevOps!
这种架构对运维确实能够带来极大的好处:
1. One Team,One Dream! 大家都是兄弟,啥事儿都好说,所以,会议效率大大提高。
2. 专业的人干专业的事儿,说起基础平台,还是搞运维这帮人最熟悉,说起业务,当然是谁设计开发的,谁最熟悉了,这样,运维的专业性、故障处理效率也会大大提高。
3. 责任划分更加清晰, 纵向产品团队为自己的业务负责,基础平台团队为基础平台的稳定性、可靠性负责,大家通过简单地“服务”实现接口。
什么事情都要看正反2面,我们反过来看一下弊端:
* One Team,One Dream! 大家都是兄弟,很多事儿睁一只眼闭一只眼,草率决策,相互约束降低,出了问题互相掩盖。。。
实际上,传统企业中还有另一个大大的问题就是,这会设计到巨大的部门调整,这个问题基本上是个无解!
扯了这么多,该抛出一个讨论话题了,就是:
如何在企业实现DevOps从而实现敏捷的企业业务创新和发展的同时,通过什么样的手段来降低企业的风险。