超级访谈：对话毕玄_13_07运维团队我能干只是我不想干而已
你好，我是叶谦。
上一讲呢，我们聊到一力多活。
玉璇说他能做，其实是因为自己正好转岗去做运维了。
但是从研发转岗到运维，这似乎也是一个不太寻常的职业选择。
那作为阿里整个运维团队的leader呢，我们问他对于普遍存在的研发运维岗位的认知鄙视链他是怎么处理的？他说说实话我也觉得解决不了。
那运维团队面对的究竟是什么样的难题呢？又是如何知死地而后生找到了自己的团队价值的呢？我们开始坚静的对待。
嗯，你做异地多活的时候，所以就已经在运维团队了。
那进去之后，你觉得外界对运维最大的误解是什么？嗯，我以前是研发线的，嗯，研发线呢会觉得运维没有什么技术含量解决不了的，还是要研发去解。
因为说白了大多数研发都认为啊，像运维测试我完全可以干啊。
之所以我不干，只因为我不想干而已，但研发这活不是你能干的。
所以如果有专业壁垒就不一样。
比如说研发对数据库就不会这么看。
因为他觉得你那活我确实干不了，嗯，所以他就自然会觉得我在鄙视链的这个上游，你运维在下游很正常。
嗯，但我去做了运维之后呢，就发现很多人说真的不是这样啊，运维是一个知识面非常广的一个岗位。
如果你做研发，说实话知识面是很窄的。
很可能啊你连你的代码在哪个机房啊，机型是什么，什么样的，网络条件，运行环境是什么样的都不知道。
那我以前是刚到运维团队的时候去开会啊，他们说的是啥我都不知道啊。
但是研发会不会觉得像这种他们也不用太关注呢？这全部是基础设施，但如果你不知道，那做系统设计的时候可能就会有很多的偏差了。
后来我是做了运维才了解，可能说研发你说的一句话啊，运维为了满足你这个条件花了很多的钱。
但是如果你在软件侧去简单的改一下啊，这个钱其实根本就不用花。
那研发人也不懂，运维的人也不懂，他不知道呢，原来你的软件稍微改一下，这个需求就没有了。
他觉得你可能是一个合理的需求，然后就去干了。
那这就悲剧了。
两个没法对话，是因为运维如果没有足够的理由去挑战，那么研发侧肯定认为我干嘛要改呀。
所以后来我们跟很多的研发说要整体看一下成本投入啊，那研发很多就懂了。
那除了这一点，你还有什么新的认知吗？嗯，还有就是对这个基础设施的了解。
其实阿里后来很多做的很多创新啊，都是因为我们对基础设施演进的了解啊，一益多活不用说啊，比如说后来我们做统一调度啊，对整个的基础设施啊有很多的改造。
因为对网络啊有了一定的概念，知道网络带宽在不断的演进。
原来是万兆啊，现在能到二十五g四十g一百g啊，以前认为有两台机器之间的网络带宽太小啊，在软件侧做了很多东西，其实现在是不需要的。
因为网络可以支持，那才有了现在的计算存储分离等等。
嗯嗯，如果软件件人不懂这些，他根本就想不到很多基础侧的创新。
那硬件也是一样啊，就虚拟化下沉到另外一块芯片上，是因为它对物理的机型有更多的了解，知道的可能性是具备的。
不光是从这个存量来看，也能够啊从这个运行环境各个方面来看，这都是因为这些人的这个知识面非常广。
啊，如果你了解很多整个创新啊，其实能做的非常好，就是说因为了解才有可能性。
对，我们之前也觉得做基础设施的啥也不懂啊，因为研发始终认为自己是最牛的那除了业务之外，就技术线的研发肯定是站在顶端的。
觉得啊觉得其他所有的人呢都是为我做配套的而已。
但是如果你不知道网络可以这么变，不可能敢提出在软件侧要做计算分离这种事儿。
因为它根本就不可能实现所是很多都这样啊，包括基础设施的大机房建设啊等等。
嗯，所以如果让你总结一下自己在运维的这段经历啊，你会觉得有什么收获吗？嗯，要总结的话呢，嗯一是这个让我做的这个异地多活啊，这还是挺重要的。
因为我以前没有做过这么大的，也不涉及呃业务，算是做了异地多活。
大家才会觉得哎你是能够做整个大系统架构的人都认为你是可以的。
嗯，那第二个就是这个知识面的宽了。
我终于知道了一个系系统真正的的全貌为系统统，事实上都及这个个基础设施，其实你也逃不掉的。
我们可能认为好像不用管基础设施。
但事实上如果不管软件设计，或多或少都会有点问题，就不是那么合理。
我看阿里当时在做完异地多活之后，就一些些运维的工具起来了。
这个是你在参与吗？我是这个一一五年的时候，下半年一五年下半年的时候开始带整个运维团队。
嗯，当时想让这个团队发生一些变化，因为我以前很苦啊，几乎所有涉及线上操作的这个工作，必须都是运维团队做一天发几百个系统根本没法法干。
虽虽然发的也是套系统，但是必须要人点线上还要盯着看。
如果有问题还要查问题啊，背后还有机器管理等等。
杂事非常多。
以前有一个比例啊，就是一个一线运维要对一百多个研发。
所以他每天光是回答问题，比如说啊机器在哪啊，怎用，各各种各种不用干别的就满了，非常苦。
但是大家又觉得，哎，你既然运维既然这么苦，为什么不做一些工具解放自己呢？是不是没有研发技能？我去的时候才知道，哎呀，多数做运维做工具的这个技能还是有的。
但事实上是他每天根本就是没有时间去做工具，因为研发是很需要连续性的状态的。
写代码人都知道，你不能说写个十分钟被IM谈一个消息啊，回复完，然后半个小时后又好不容易进入上下文，结果又被打乱，那代码就没法写了。
嗯，那后来我就跟很多人说，那是因为你没干运维这事儿，你去的时候你也发现你也没空。
以后中国的运维大会可以让一线的运维的人呢来个吐槽环节以后，能够把运维喷死。
嗯，啊所以就是运维团队一直在给支持，对，恶性循环。
因为理论上你讲，如果运维有很好的工具给研发，他是不会问你问题的。
但这是个悖论。
而且阿里当时也有专门的运维工具团队就是我带的。
但通常来讲，业务运维团队跟运维工具团队很容易产生矛盾。
产生矛盾是为什么运维会觉得你工具团队做的东西不满足运维的需求。
但是他们一天到晚又实在是太忙之具，如果不好用，他就觉得哎我还不如手工。
因为如果已经习惯了，其实手工的效率也不会太低。
但是工具又需要成熟呢，它又需要不断的去使用。
啊，所以这个局面啊让运维这一侧都我们就就都觉得运维团队的未来会越来越难，成长的空间很有限。
因为干杂活怎么可能有成长空间，但活活很很对于一家公司来讲，没有这样的人是不行的。
但但有了大家又觉得这批人好像技能不行。
那这样恶性循环下去之后呢，之后一定是谁也不想干了这么苦，而且还全是责任。
你想运维不出问题没什么啊，不出问题。
大家觉得这个部门不存在，但是一出问题第一眼看到的就是运动。
嗯，对，所以你当年就一五年代的时候做了什么呢？当时我们就要讨论这个呃团队未来到底是走向一个什么样的方向。
嗯，这是一个非常纠结的问题啊，这也是后来让我去带整个团队很大的原因。
我们想就是既然工具和运维很容易矛盾，那干脆就合成一个团队得了啊，探索一下，看看能不能解决啊。
那当时有方法吗？就是有解法吗？我带了之后，说实话我觉得解决不了。
因为我当时接手最早的一个想法，就是让每个人一天腾出百分之二十的时间来做一些工具的研发。
然后来发现这根本就不现实。
但很多人就觉得哎，你们团队自己不想，或者说没有能力解决救自己吗？肯定不是，就是既是因为有很多现实的问题，包括运维的人，你说他不想吗？他自己当然解决，谁都不愿意天天做一些很碎片化的工作，大家都想解决自己。
当时google的SRE大家都觉得是最好的团队，对不对？嗯，但是如果你仔细去看，关键啊是第一，他的人呢大多数的都是来自以前非常资深的研发，根本就不是运维岗。
那他跟研发沟通，包括这个研发技能肯定是没有问题。
嗯，第二就是至少是我们外部得到的消息啊，是他们的人每天可以腾出百分之三十的时间来做研发类型的工作，而不是运维类型的工作，那就不一样了。
呃，那他们的时间是怎么来的？比例问题就是如果有一定的运维研发比例，让运维有时间去学习一些开发的技能，为自己写工具啊，这肯定满足需求。
嗯，但是有多少公司能够接受运维跟研发的比例是成一定比例的呢？啊，现在蚂蚁也是接受的，所以蚂蚁跟阿里不一样。
嗯，那这个这个比例问题，它的本质是是分工，就是运维到底是做什么的。
这个认知。
比如说蚂蚁现在的安全生产团队，嗯，核心指标就是整个系统全年的系统稳定性资损的情况，其他是不承担的。
很多让研发自己做掉。
那这样有了专业的分工，运维团队呢相当于是跟研发团队没有太大的区别。
只是说业务研发团队做的是业务的需求。
你运维团队啊做的是运维业务的需求。
嗯，那之前呢分工上大大家就直直觉运运维是做什持的。
再加上啊传统运维确实做了很多偏执行的工作。
我不知道就是中国其他的公司的状况是什么，反正在阿里我们觉得这条路很难走。
嗯，当时你们觉得很难走，是为什么？是，比如说你们团队的价值，在整个集团是没有被看到的那当时你们做了一些什么样的尝试呢？我们本来呢希望是跟集团去嗯谈一个数，比如说运维就是一比多少研发啊，你不要老挑战我的人多。
因为大家都觉得运维团队人很多，我带的时候运维团队有个一两百人啊，但是研发十几个人就能做一个非常核心的系统。
所以研发团队说，哎呦，我看你你会觉得哎呦，你比他人还多，运维动辄就上百人还说不够。
问题是他没有想到我们是整个集团的运维，我们还觉得一两百人怎么够啊，得四五百人更多。
但这上面一看啊，你没有这么多人。
另外就是你说的啊，运维的这个价值其实很难被衡量，就是说它的价值到底是什么？因为运维啊它不像研发，研发是直接去面对业务的，做的东西的价值是可以被论证的。
只要这个业务好，那研发肯定是有贡献的。
嗯，但是运维到底做了什么？我说运维很核心的工作是去保护整个系统的稳定。
另外是成本控制所是，这些呢都没有业务那么那么耀眼，而且保护稳定这种事不出问题是没有人知道的，就跟保全团队一样啊，也是很痛苦的团队。
呃，因为你今天提到蚂蚁，所以蚂蚁是论证了他们的运维价值这个事儿。
嗯，为什么蚂蚁能够搞定？是因为后面蚂蚁出了一些故障，就是阿里也出了。
但是蚂蚁对故障的这个重视度啊，必须说要比阿里高的非常多。
因为因为这个呃蚂蚁是金融，所会它出出故障，首先可能会引发这个用户的信任问题。
第第而引引发监管的问题，监管就生命一些，那对他们来说就不是开玩笑的。
所以蚂蚁会觉得我得力保稳定。
现在俊逸带的这个安全生产团队啊，就是一个固定的比例，嗯，每年不用去申请这个运维名额的研发。
你涨我就涨，非常简单。
你想一个固定的比率，那么大家肯定不会一天到晚就是总是那么饱满，就可以在日常工作以外呢去腾出时间来做工具研发，把自己给解放出来。
那其实这样呢就会越来越好是一个良性的循环，但是它需要时间。
所以我说呃我们当时是想跟集团去说定一个比例，嗯，然后团队转型呢也是需要一段的时间需要接受。
这段时间里人是比别人多的那集团当时批了吗？没有我带了半年多，也试了一些其他的想法。
但是这个问题在阿里太难解决了，所有人都这么觉得。
实际上我们知道就是google大概是这么做的，但是呃都学不来。
而且那个时候就是蚂蚁也没有一个呃搞定运维和研发一比多少的一个问题。
他们也是后来出了几次大的故障之后，公司在觉得这个是生命线。
嗯，那当时我就觉得嗯我很难带领这个团队完成一次组织的这个转型。
我们是希望完成这个组织转型和升级的向google去靠拢，变成一个非常资深的一个团队。
能够更加的专注做好工具研发，或者说去维护整个系统的稳定。
因为SRE的定义准确讲是维护这个系统稳定，而不是什么发布啊，运维答疑啊这些杂活。
但是在中国的绝大多数的公司，我估计啊运维团队都是这个角色。
那当时集团也没有给PE,然后其他方法也是不了。
那组织转型不了的话，那么怎么办？到一六年的时候，这个问题太难解决了。
当时呢这正好刑天来担任这个集团CTO,那我们是商量了一下，怎么搞下去，反正也解决不了问题啊。
就提了一个方案，就是说把运维的工作直接交还给研发，解散掉。
这个统一的运维团队，把运维啊是还给所有的BU.比如说一部分人是支持淘宝的一部分，支持搜索等等。
那按照BU啊，把人全部还给研发，相对相当于是没有了这个这个统一的运维团队。
那等到这个分人的时候，所有人终于知道了哦，你们人确实太少了。
以前他们觉得哎呦，你怎么这么多人啊，但是现在大家摊在一张纸上来看哦，好了，反正就是这么个情况，支持你部门的，其实就一两个人啊。
那当时这种拆分是是怎么去落地的，就是直接决定组织拆分。
那搞了多久啊？嗯应该一个多月一个月就搞定了。
组织拆分。
那会比如说给这批人有选择吗？比如说业务侧的这种没有选择，你以前对哪个BU,现在你就当然怎么分。
嗯，不过因为拆的过程啊就是太粗暴啊，当时呢也是引发了一波离职，导致啊有段时间就是运维很混乱，加上分散了，人也不够。
另外工具确实也是比较缺失啊，各家BU又开始做自己做工具，因为各家也受不了啊。
那所以你们这一下够狠的，你们当时能够想到这个结局，呃，我们能想到但是还是可以接受啊。
因为我们认为啊只有这样才有可能说让研发去承担掉一部分很杂碎的这个运维工作嗯，形成这个习惯。
也希望让所有的研发都至少知道你的代码是跑在哪些机器上。
这机器在哪里，大概的环境是什么啊，其他的方式很难做到这一点。
你只要有个团队在这儿啊，研发就不可能去做。
你想啊一个BU发现自己只有一两个运维的时候，他们肯定也会觉得人少。
对，那就会让这个部分的研发去承担运维的工作，这就是我们想要的。
嗯，当然就是研发吐槽就很多了啊，反正我们觉得就是在大的思路上想象的最后的样子没有问题，但是怎么走到那个样子是一个很大的挑战。
所以你当时决定下，那个时候也是因为呃在一五年一六年去尝试的时候，就其他方案都没有跑通。
因为这个最早大家能够想到的方案肯定就是做一套很好的工具。
嗯，啊研发用这个工具完成一些碎片化的工作。
然后运维团队就可以像SRE一样去很专注的去看系统的稳定性。
嗯嗯，但是我们当时看这就偏理想化，因为这么走你第一肯定是要人员扩张啊，那这一步肯定就做不到，因为集团不给批，这第一步就很难的。
我我要的人是去翻倍的呀。
啊，所以后面拆到整个每一个BU之后，他们又开始做自己的很多工，对工具呢又乱七八糟的。
嗯，因为说实话工具重复做这个意义很小，很多工具很类似，所以以前希望去统一。
嗯，以前希望统一的目的是什么？就是运维团队的。
嗯，最早是应该是只有淘宝啊，因为就一家公司它肯定是一个。
嗯，但是后来大家觉得淘宝双十一的模式做的非常好，希望淘宝的经验可以去覆盖掉其他的。
但是在慢慢就把其他的各家的运维全部合掉了。
那统一的目的呢，一是相对来讲，人效肯定是最好的。
二是这个理论上来说啊，你可以去统一工作来解决很多的问题。
那运维就有几家这样的基础设施能够更好的去统一眼进。
嗯，那如果说分散了，没有规模啊，很多事情就很难搞。
比如这个a业务说啊我的业务要这样的机器啊，毕业，我说我要另外一台机器啊，因为业务方就是这样嘛，什么对我最好，那我就要这样。
但对后面的设施的采购维护啊都是一个极大的问题。
如果能够统一运维啊，还能节省成本。
这个机器可能在你的这个业务上是浪费了一点钱。
但是在全盘你看其实是省钱的。
但是这件事如果你没有一个统一的团队，那就太难做了。
嗯，呃那阿里后来很多工具起来了嘛，之后有把他们合在一起吗？后来我就不太管这个事儿了，因为我知道分散造成了很多问题，但现在好像嗯想统一了。
那鲁肃下面又成立了SRE团队啊，各个运维团队又开始归拢了。
嗯，所以阿里对我们当年拆掉这个运维有很多争议啊非常多。
因为大家觉得现在的乱象就是我们当年那么暴力造成的啊，这个我们也认了。
但我们就是觉得关键是没有解法。
嗯，而且现在去合并啊，跟我们当年不一样。
因为运维的团队的职责变了，研发已经接受了。
我们当年其实也是这样想的。
我先来拆一下，让大家习惯，然后后面我们可以再整合，但职责就变了，只做这个全局稳定性的维护啊，机器管理这些啊，所以从这个角度上来说，你们当年那么拆核心目标也算是达成。
哎，算了，至少现在SRE团队比当年的运维团队好很多。
他们很多人合进去了，觉得哎工作的挺开心啊，不像以前运维的人简直太苦了，他的情绪永远不是很好，压力又非常大。
因为如果出故障那不得了啊，运维肯定第一个被问责。
嗯，但有很多有可能是研发的代码的系统设计的问题啊，这个你又负不了责，那这就很尴尬。
所以研发总觉得呃运维没啥用，但事实上呢又离不开。
所以我们这么去看的话，最早研发跟运维的这个分工方式是不是呃开始的时候就不太行，嗯，是有点问题。
你想哈最早是一家创业的小公司的时候，是不会有这个分工的对，肯定是从头到尾啊到尾写代码，自己发布上线维护全部都自己干。
那我零七年进淘宝的时候啊，发所有的系统也是我跟运维一起没有说什么，交给他了就不管了，没有觉得不可能啊。
那后来阿里有人有一个形象的比喻啊，他对研发团队说啊啊你看你们现在就是简直活的跟大爷一样，就是写完代码之后，有一帮人服侍你什么PM研发效能测试运维。
他们就好像你们的保姆一样，你们写完什么都不管了，什么都不知道。
嗯，所以从原则上来讲，虽然我们觉得拆分运维团队这个动作是有点不大合理啊，但至少是逼着研发去提升了自己的技能。
很多研发是不爽，但是如果从他的职业生涯来看，我们觉得这不是坏事，你的技能变好了嘛，对不对？但是研发测应该普遍都不会太高兴吧。
呃，研发的抱怨其实差不多，就是我的活已经很多了，每天要接一堆很碎片的需求啊，你们现在不想干，把活都扔给我们啊。
包括测试团队，当时也是希望研发自测，然后做呃自己更多的去做工具嘛。
嗯，所以研发那会儿会觉得哎，我不仅要管这些，还要管上线发布后的整个情况。
哎呦，你们这些团队就是啥活都不想干什么，都扔给我们。
但是研发你未来作为一个系统的掌控者，这些本来就是应该知道的，也本来是要去掌握的。
你做系统设计不可能忽视下面的基础设施，完全当它是个黑盒呀，不可能就算现在是云，你也不可能把它当黑盒用，对你还得是个白盒。
嗯，所以阿里当时强拆一定程度上去解决了这个问题，但是不能轻易用，必须要有很高的支持。
因为这个动作非常大会影响，所有的团队内部肯定会有各种意见。
但是我们认为就是组织去演进的路线是什么？你不能说虽然组织的人整体都没有成长，但是这样对公司是最好的。
这样最大的问题是团队会很难活下去，长期一定是个问题。
一是不稳定，那离职率会很高。
你老换人，那研发现他每次找你也很痛苦，而且也很危险啊。
公司哪天想换掉你就很简单。
嗯，那每个团队可能都要去想一下，成长空间问题很重要的。
不可能。
因为不可能说公司的哪个团队是弃子。
所以如果我们看未来的话，你觉得运维可能会往哪个方向去发展。
嗯，我现在觉得大厂的模式还是不错的，研发应该干掉运维的一些工作。
但是这个前提就是确实是公司在运维侧的工具上要有一定的积累。
嗯，就如果你完全没有积累，按照我们当年那么粗暴，也会有问题，一定也会有这个一段时间。
很崩溃。
当然是过了那段时间，可能会工具百花齐放，但是之后基础设施怎么去统一呢？又是一个问题。
呃，但大厂的模式有个问题啊，就是对研发的技能要求太高了，就相当于是研发你要懂运维。
嗯，对，但是从现实的人才池子上来讲的话，这一点又很难实现。
嗯，现实中的技数研发其实他不懂运维，嗯，而且像小厂的话应该更是了。
对，这很正常。
就像我们招人的时候，也不可能有这个要求。
首先肯定是在乎的是你的研发技能。
嗯，哎运维差一点就算了，因为我们可以有运维团队，但是也会陷入这个状况。
但我们前期就会让运维更多的偏向工具。
一开始就是这个定位。
那同时呢也是慢慢的去告诉研发运维不是你的配套，只给你工具和文档，其他是不管的啊。
那对小厂就会他有必要去制作自己的工具嘛。
因为现在市面上也有很多嘛，但运维的工具很难完全通用，这个比较麻烦。
通用的很难满足运维的所有的需求。
因为运维不像研发比较单纯，它杂活简直多到不可想象。
嗯，所以就只能说慢慢的去转变这个思维，只能看各家是怎么看待运维，大部分公司其实就没有解法。
但新一代的公司可能会慢慢好一点，那现在研发在这个技能层面上的要求就更完整一点。
那运维团队呢是慢慢转向类google的SRE,那更多的是提供工具。
那研究整个系统怎么样做的更加的稳定，而不是去发布。
嗯，那运维的职业发展路径呢，你觉得会是什么？架构师？以前啊我跟运维团队去说，其实他们最大的出路是成为真正掌控整个系统的最大架构师。
因为说实话哈架构师呢其实是最好从运维出来的，研发是出不来的。
因为研发没有全貌，但是运维是一定有的，他要负责线上。
所以说他看到的一定是整个系统，知识面一定是超级款的。
只不过关键是就是运维你能不能成长为这样的角色。
因为架构师最大的问题是研发线认不认可。
你研发线会觉得你就一个运维，哎，又没写过代码，你提供的方案我觉得不靠谱。
嗯，啊所以这就是为什么google相对好很多。
因为他的SRE就是原来的资深研发研发线挑战不了的，研发呢是一个很难伺候的角色。
我后来去了研发效能，体会更深就更难了。
研发效能是给研发和运维做工具，这个难度简直是高到天了，就跟我说的，只要研发觉得自己能能干，事事都很难。
今天的对谈呢到这里就暂时结束了。
我们主要聊的是碧璇从研发转岗到运维的经历。
先说点正经的运维团队呢，碧璇认为核心工作是保护整个系统的稳定和成本控制。
而运维的人呢最好的出路是架构师。
但是在当时的阿里来看，面对运维团队价值模糊的这个困境呢，他试图寻找解法，但似乎呢也看不到希望，迫不得已选择了一条争于非常大的路线。
但是每个团队确实都要想一下自己的成长空间问题。
你的团队，你觉得现在的空间是什么呢？未来的成长空间可能是什么呢？能够满足你的个人发展需要。
而但是呢说点不正经的，今天想来一个特别的吐槽环节啊，我完全可以干。
之所以我不干，只是因为我不想干要吗？你的岗位存在这样的鄙视链吗？是什么呢？如果你是一线运维，欢迎吐槽当年和研发协作的那些事情。
当然了，不能厚此薄彼。
如果你是一线研发、测试安全或者其他团队，也欢迎写下你的肺腑之言。
并有一位哲人说过嘛，吐槽是迈向理解的第一步，期待能够在留言区看到你的精彩发言。
下一讲呢我们会接着今天对谈的尾巴继续聊。
毕竟毕寻说运维之后，他去了比运维更难做的研发效能团队会发生什么呢？我们下一讲再见，拜拜。