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

作为15年校招入职阿里的运维，完整经历了部门解散，团队解散。做运维的两年，每天基本上都是在处理工单和报警，几乎没有任何成长，除了几千个工单外也没有任何成果，真的非常痛苦，现在回想起来就是职业生涯的噩梦，后来转研发后真的好了太多太多了。我建议不要做运维，但很推荐学习一些运维的课程，工作中确实很有帮助。

只有屁股挪到了运维侧，才会更好的理解运维侧的难。经历了这一切之后，我越来越觉得人本身都是有潜质的，是公司的体系设计，所以要改变，最最主要的重新设计公司的游戏规则，要拿出愚公移山的精神一步一步啃。同时，自己也要革自己的命，抱怨吐槽之后，还是得面对问题。这跟我们国家试图改变在产业链中的位置，要做产业升级一个道理。所幸的是在我们公司，基础架构研发和运维在一个副总下面，他也同意不能老让运维来解决最后一公里的问题。

🤔☕️🤔☕️🤔 【R】运维难，如果运维仅在效率层面有体现的时候，尤其难，如果运维还在安全层面有体现的时候，日子好过点，不过难度更大。 【.I.】我能干，只是懒得干，有段时间，它也在我的用语列表，现在已经被删除。我记得出现这句话的时候，就在自己刚学通嵌入式软件的整个技术栈，有种技术脉络全部打开的神通感。当然，见到啥方案啦、产品啦、测试啦，那时候还没有啥运维，不过有技术支持啦，都会冒出不想干而已啦。这种技术的自负，持续很久，至少有十来年。直到某本养娃的书里讲，孩子不是教出来的，孩子是模仿而来的，父母想让自己的孩子怎样，那就自己得先做到那个样子，至少得去追求那个样子，必须是真心诚意的认真追求。在这句话的启发下，为了让我们家孩子也具有好学的品质，我自己就重拾学习，从本来喜欢的科普、科幻故事开始，逐步接触到各类通识课程，直到一本叫《技术的本质》的书，最终点破，或者叫点碎我的这种自负感。现在的我，更喜欢在自己实践后，分享点自己实践的体会。典型如测试开发，我的体会是具备怎样的业务理解和怎样的技术实现原理，只是做好测试开发的基础，如果测试开发具备边际成本和沉没成本的意识，那么在用例设计和方案规划时，有更多方面的决策依据。这样的经验，无论如何不会来自不想干但会想。 【.I.】运维和研发，让我想到纠错本和作业本，做完作业就像研发完成，普通学生的水准，当作业错误，如何看待纠错本，就是优秀生和普通生的认知分水岭。同样道理，在优秀生的眼里，运维是否就是纠错本，研发就是作业本。只是完成作业本的研发的认知和视野，无论如何都达不到优秀生看待纠错本的认知和视野。如此说来，研发对运维的鄙视真的没啥，这只是一种低认知难以突破的自负而已，反过来运维对于研发的鄙视，真的就是降维式鄙视。当然，这有个前提条件，那就是运维必须是研发出生，也就是让研发的优秀生成为运维。运维的杰出人才，再往架构师成长。 【Q】有个问题想问老师，那就是如果真要学习谷歌，从哪个点、哪个方面入手，比较适合国内的现状？ （备注：我个人觉得，学习谷歌从态度入手，就是从尊重工程就是，大家一起把所有的细节都做好的态度开始，做好每个细节的工程师，都有拿得上台面的尊重，而且这个态度必须始发自公司顶层。） —— by 术子米德@2022.10.25

歧视链条很正常，运维虽难-可是研发也有其技术弊端，一个研发出身的运维其实很多时候会知道研发的痛点，攻还是点到为止皆有技。毕大师的一路转深有体会，但是不曾有那种高度而已；运维对于底层与突发意外的理解和问题的分析-研发还是有差距的。

大家打份工,不要相互为难 -- 鄙视链

听完的感受：成见既成，不破不立

研发很单纯，和研发沟通，在技术上能比研发更有深度，研发基本会听；就像文章说的，DBA说的话，研发就会乖乖听，因为DBA比大部分的业务研发甚至是技术研发更专业； 运维，尤其是大运维，本身有个优势，他的岗位是从底层的环境一直到上层应用运行的。在部署架构上，这个更具有优势；纯研发想要走这条线，其实也必须去做一段时间的线上运维，否则不了解自己应用的运行环境，想要做系统的优化、拆分、提升其实都很难。 虽然现在说云化、说容器化，屏蔽掉一些运行环境的底层。但实际上在一些特殊要求的应用上，还必须要了解底层，比如一些占有大量网络带宽的应用上，即使是容器化，也希望各个实例是在不同的服务器上，避免带宽的争用。 如果研发不了解这些，更多会局限在业务研发上，其实做不到真正的架构。或者他能做个业务架构，但在系统架构、技术架构、部署架构上，都会是缺失的。

每个岗位要做出自己的专业性和壁垒，否则鄙视链肯定存在。在大公司线上日常的运维角色回归研发，通用横向的运维工作交给专业运维，这样运维的工作才有人干。小公司人才比例没那么高，社会上还是能找到干杂活脏会的人