07｜运维团队：我能干，只是我不想干而已

Sep 28, 2022



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

07｜运维团队：我能干，只是我不想干而已

2022-09-28 毕玄来自北京

《超级访谈：对话毕玄》

课程介绍



讲述：正霖，叶芊

时长25:58大小23.72M



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

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 11

提建议

06｜异地多活：技术圈子的人，见过猪跑很重要

08｜基础团队：研发效能部门，解决不了研发效能问题

 写留言

精选留言(8)

xindoo
2022-10-02 来自浙江
作为15年校招入职阿里的运维，完整经历了部门解散，团队解散。做运维的两年，每天基本上都是在处理工单和报警，几乎没有任何成长，除了几千个工单外也没有任何成果，真的非常痛苦，现在回想起来就是职业生涯的噩梦，后来转研发后真的好了太多太多了。我建议不要做运维，但很推荐学习一些运维的课程，工作中确实很有帮助。
作者回复: 运维这岗确实很不容易，不过比较好的是也看到国内现在有些公司的运维岗的职责在调整，更加专业化了，主要就是负责稳定性，成本等这些，这个是我觉得比较SRE化。
20
码小呆
2022-10-02 来自广东
大家打份工,不要相互为难 -- 鄙视链
11
MuBo
2022-09-30 来自江苏
听完的感受：成见既成，不破不立
5
JianXu
2022-10-09 来自浙江
只有屁股挪到了运维侧，才会更好的理解运维侧的难。经历了这一切之后，我越来越觉得人本身都是有潜质的，是公司的体系设计，所以要改变，最最主要的重新设计公司的游戏规则，要拿出愚公移山的精神一步一步啃。同时，自己也要革自己的命，抱怨吐槽之后，还是得面对问题。这跟我们国家试图改变在产业链中的位置，要做产业升级一个道理。所幸的是在我们公司，基础架构研发和运维在一个副总下面，他也同意不能老让运维来解决最后一公里的问题。
作者回复: 赞，能碰到这样理解和懂运维的leader，真的还挺幸运的。
3
alex
2022-12-02 来自福建
研发很单纯，和研发沟通，在技术上能比研发更有深度，研发基本会听；就像文章说的，DBA说的话，研发就会乖乖听，因为DBA比大部分的业务研发甚至是技术研发更专业；运维，尤其是大运维，本身有个优势，他的岗位是从底层的环境一直到上层应用运行的。在部署架构上，这个更具有优势；纯研发想要走这条线，其实也必须去做一段时间的线上运维，否则不了解自己应用的运行环境，想要做系统的优化、拆分、提升其实都很难。虽然现在说云化、说容器化，屏蔽掉一些运行环境的底层。但实际上在一些特殊要求的应用上，还必须要了解底层，比如一些占有大量网络带宽的应用上，即使是容器化，也希望各个实例是在不同的服务器上，避免带宽的争用。如果研发不了解这些，更多会局限在业务研发上，其实做不到真正的架构。或者他能做个业务架构，但在系统架构、技术架构、部署架构上，都会是缺失的。
展开
术子米德
2022-10-25 来自浙江
🤔☕️🤔☕️🤔 【R】运维难，如果运维仅在效率层面有体现的时候，尤其难，如果运维还在安全层面有体现的时候，日子好过点，不过难度更大。【.I.】我能干，只是懒得干，有段时间，它也在我的用语列表，现在已经被删除。我记得出现这句话的时候，就在自己刚学通嵌入式软件的整个技术栈，有种技术脉络全部打开的神通感。当然，见到啥方案啦、产品啦、测试啦，那时候还没有啥运维，不过有技术支持啦，都会冒出不想干而已啦。这种技术的自负，持续很久，至少有十来年。直到某本养娃的书里讲，孩子不是教出来的，孩子是模仿而来的，父母想让自己的孩子怎样，那就自己得先做到那个样子，至少得去追求那个样子，必须是真心诚意的认真追求。在这句话的启发下，为了让我们家孩子也具有好学的品质，我自己就重拾学习，从本来喜欢的科普、科幻故事开始，逐步接触到各类通识课程，直到一本叫《技术的本质》的书，最终点破，或者叫点碎我的这种自负感。现在的我，更喜欢在自己实践后，分享点自己实践的体会。典型如测试开发，我的体会是具备怎样的业务理解和怎样的技术实现原理，只是做好测试开发的基础，如果测试开发具备边际成本和沉没成本的意识，那么在用例设计和方案规划时，有更多方面的决策依据。这样的经验，无论如何不会来自不想干但会想。【.I.】运维和研发，让我想到纠错本和作业本，做完作业就像研发完成，普通学生的水准，当作业错误，如何看待纠错本，就是优秀生和普通生的认知分水岭。同样道理，在优秀生的眼里，运维是否就是纠错本，研发就是作业本。只是完成作业本的研发的认知和视野，无论如何都达不到优秀生看待纠错本的认知和视野。如此说来，研发对运维的鄙视真的没啥，这只是一种低认知难以突破的自负而已，反过来运维对于研发的鄙视，真的就是降维式鄙视。当然，这有个前提条件，那就是运维必须是研发出生，也就是让研发的优秀生成为运维。运维的杰出人才，再往架构师成长。【Q】有个问题想问老师，那就是如果真要学习谷歌，从哪个点、哪个方面入手，比较适合国内的现状？（备注：我个人觉得，学习谷歌从态度入手，就是从尊重工程就是，大家一起把所有的细节都做好的态度开始，做好每个细节的工程师，都有拿得上台面的尊重，而且这个态度必须始发自公司顶层。） —— by 术子米德@2022.10.25
展开
作者回复: 目前看到的现象来看，国内的一些头部公司，对运维的这个的岗位我觉得是比以前友好很多，定位也会是专业型，整个大环境的话我觉得还需要时间慢慢改变。
sesamegu
2022-10-07 来自浙江
每个岗位要做出自己的专业性和壁垒，否则鄙视链肯定存在。在大公司线上日常的运维角色回归研发，通用横向的运维工作交给专业运维，这样运维的工作才有人干。小公司人才比例没那么高，社会上还是能找到干杂活脏会的人
leslie
2022-10-03 来自浙江
歧视链条很正常，运维虽难-可是研发也有其技术弊端，一个研发出身的运维其实很多时候会知道研发的痛点，攻还是点到为止皆有技。毕大师的一路转深有体会，但是不曾有那种高度而已；运维对于底层与突发意外的理解和问题的分析-研发还是有差距的。
作者回复: 运维对广度的要求非常高，另外练手机会相对会比研发多很多，在综合问题的处理能力上是非常有机会锻炼的非常强的。

