当前位置: 欣欣网 > 码农

开发都认为运维工程师很Low?我反手一个嘴巴子……

2024-05-26码农

最近,小编在知乎上看到这样一个问题:

开发都认为运维工程师很Low?

「你以为运维就是管理一下机器,管理一下数据库?你丢个包上去运维帮你执行下?你的日志爆满了运维给你清理一下?运维帮你安装下中 间件?你以为的运维只是做这些事?」

运维工程师的工作究竟是怎样的?秉 持着和平交流的学习态度,小编精选了几位高赞知乎网友的精彩回答,分享给大家学习交流(勿上升、勿引战)



1号知乎网友 :芬达味橘猫




我是自动化运维,我写了很多自动化脚本,我走了之后脚本没人维护了,开发不会整,测试不会整,其他运维也不会整,最后原先自动化的业务也都变成手动人员来干了,又增加人员成本了,公司开技术倒车了。

做运维挺不容易,总被别人说low。机房你得懂吧,网络安全你得懂吧,docker/K8s你得懂吧,公司OA/CRM系统你得懂吧,Linux/Debian/Fedora/Centos/Ubuntu和windows Server你得懂吧,数据库MySQL/Oracle/SQLServer你得懂吧,Kvm/Openstack/阿里云/华为云你得懂吧,Python也要求会也得懂吧,Java/Vue你也得懂吧,要不遇到个二把刀的开发又被坑得加班了吧,还得懂计算机服务器硬件Raid之类得,要不坏了东西都没法修理,所以运维真的不简单,终于有人提出这个问题了,回答一下也算抒发下不被人重视的感想吧。



2号知乎网友: 技术王




我用十多年的开发经验告诉你,如果你作为开发觉得运维工程师很Low,你是会吃苦头的,有些运维水平高的,那可真不是你能评论的。

你以为运维就是管理一下机器,管理一下数据库?你丢个包上去运维帮你执行下?你的日志爆满了运维给你清理一下?运维帮你安装下中间件?你以为的运维只是做这些事?

作为一个开发,我都看到过不少运维的工作超乎了我的想象,这些工作的难度感觉是一点也不比开发简单,需要的技术水平还是非常高的,现在我就来跟你说说运维的技术能有多高,他们做了哪些高难度的挑战。

  • 监控能力

  • 这方面我是最有发言权了,稳定性、SRE一直是我现在做的事情,但是全面性的SRE不是只有开发就能完成的,很多东西还是需要依赖于运维来做,这期间我也发现了很多天窗,原来还可以这么干?

    首先 监控Linux服务 嘛,那肯定是要全方位系统的监控,网络、磁盘、CPU、内存等等,这才叫监控,但是对于第一手信息的获取,对于我来说确实犯难了,我只有获取到了这些系统的运行指标,才能做一些性能分析诊断,然后作出一些异常检测等动作。

    然而,运维为我准备了一大堆的数据,我挑选都挑选不过来,监控网络吗?route、iptables、tcptop、tcplife、tcpconnect、tcpretrancs等等技术,然后他们把这些命令或者工具整理成脚本,成功的上报到我们这边的云端系统,让我们可以全方位系统的监控整个网络了。

    我们要 监控磁盘 呢?他们写了一大堆脚本,里面涉及到各种技术点,什么biotop、biosnoop、biplatency、mdflush、lsof、pcstat等等工具,可以说是把磁盘的各个方面的数据都搜集上报过来了,我们有时候都嫌多了这些数据,但是他们都统统建设好了,他们的意思是反向推动我们去做一些监控能力,让他们也能用得上这些能力。

    当然, cpu和内存方面的监控 他们就更熟悉了,他们能够把内存的数据都给你导出一份,然后分析内存的性能,以及应用程序的堆栈信息他们也可以通过脚本上报到云端,以至于用户的慢服务都不用自己去发现了,运维的工具就能发现,而且还告诉你,哪个线程,哪行代码的cpu消耗太多,执行的耗时多长等等。有时候我在想,他们都不是开发,怎么能定位到这么精准的地方了?还有,他们对perf这个工具运用一点都不逊色于程序员!

  • 对Linux的熟悉程度

  • 如果要说谁最精通Linux,那非运维莫属了,熟悉到什么程度呢?举个栗子吧,他们可以让Linux开机的流程单步执行,什么意思,相当于程序员在debug自己的程序一样。

    比如有一次,程序员配置了环境变量,就是改了/etc/profile文件,然后source了一下,发现根本没效果,这就是一件非常诡异的事情了,正常Centos 都是可以这样操作的,为什么那台机器就偏偏不行呢?由于我们使用的是openstack,所以管理的压力也就到了运维这里了。重装系统,不可能的,这么多重要的东西安装上去了,肯定是要运维去解决的。

    后来怎么解决的?运维发现source这个动作在内核中并没有挂载到对应的钩子上面,导致了执行命令也不会识别到path,那为什么没有挂载到对应钩子上面呢?排查了好久,运维直接单步运行了那个Linux系统,居然用到了Linux kernel的调试debug技术。后来查找到原因是因为有的应用程序不小心把内存的钩子给替换掉了,如果是开发,真的很难发现这样隐晦的问题。

    我当时是很纳闷的,一个运维,怎么会调试代码? 实际上Linux内核代码除了运维,又有谁 去调试呢,其他的应用开发人员并不需要啊,运维人员也是被逼的。

  • 救火能力

  • 有时候,开发写了个程序,部署到机器上,不一会就导致连接数耗尽了,磁盘IO出现瓶颈了、或者CPU飙高到100%了,但是这个时候,只是表象,只知道Linux机器的资源耗尽了,运维得先找到资源消耗在哪了,才能进一步分析原因,只有找到确实是应用的问题,才能责令程序员整改。

    然后,运维做到这一步还不够,他们还得需要进一步定位是不是资源分配不合理了?不能说java进程占用cpu100%了就直接找到开发人员吧,否则就很不够专业了,高级的运维会分析为什么是java的占用率太高了,会不会是其他影响了,确认了确实是java程序的影响,才通知到程序员去优化,生产问题,瞬息万变,他们又不熟悉业务,要在这样的复杂情况下作出正确的决策,这一点我想难度不小吧。

  • 网络安全能力

  • 运维的工作,最重要的是机器的管理,网络架构的建设,什么样的机器部署对整个系统有帮助?用什么样的方式管理是安全的?这些运维都是需要去做的,管理太复杂了,开发会很反感,管理太简单了,又担心安全问题。

    而且,怎么判断安全不安全?出现不安全的问题的时候有什么手段处理?常见的安全隐患有哪些?恶意流量、提权、不明流量来源,这些东西都得深入分析,如果机器上被植入了木马,或者被暴力请求了,主要责任还是在运维的,可想而知运维的压力有多大,这就是重压之下逼出最强技术。

    好了,这些大概就是我所见到的运维的能力,也是我比较关心但是欠缺的能力,很多排查方式我也是跟着运维学习的,运维的东西其实远远不止这一些,这样说吧,除了不用写代码,其他的事情他们几乎都要会做,所以,你还会觉得运维Low吗?



    3号知乎网友 匿名用户




    用vmsudo把账户降级的时候,他连个l都打不出来。还low……

    乱改密码以为可以调戏运维,是吧? 单用户模式直接回收root,就没脾气了。 权限控制就这么任性。

    离职清代码显得自己牛逼是吧。 删除时脚本自动同步备份,十分钟内恢复到你不知道的备用环境,你操作的是vip。 不知道我做了双节点吧?

    不好意思,删除指令我们alias了,当然你也没权限看profile。 n+1 没了开心不?

    自动化监控上线后,一举一动都会被运维盯着。 等devops上了以后,他们的工作就只有提交代码了。 剩下的操作全部被权限分离成碎片。

    要报错日志自己看ftp。实时同步给你和领导了。

    以上操作都不是我故意做的,都是给坑出来的。

  • 代码和研发一起离职了,然后程序定时器干掉了用户数据。

  • 密码和IP一起选择性忘记了, 然后自己做小动作。

  • 提交了bug然后皮球踢过来,然后关机走人。

  • 清数没写where变删表,然后甩锅摆烂。

  • 由此衍生出的应对措施:

  • vmsudo权限控制降权和密码有效期控制

  • 自动化运维监控,日志监控,elasticsearch集群存储

  • devops开发运维一体化

  • sql强审计监控DDL和DML

  • mac与IP端口绑定,VPN与工号绑定

  • ……

  • 当以上坑一个个踩过来了,你就从桌面运维逐渐变成大牛了, 是给逼的。

    如果开发的存在,是以极度开放的思维尽可能实现软件功能。

    那么运维的存在,就是以极度保守的目的,从系统层约束控制风险,并尽可能的全面监控预测未来可能导致的风险的存在,并指定应急方案。

    运维就是限制开发权限过度到破坏业务的防火墙。 这个岗位存在的意义,就是保证业务系统的稳定,以一切技术手段应对各方各面的漏洞和bug, 以及最快时间内灭火恢复业务的能力。

    其中最典型的火灾就是删库跑路。这个梗导致的严重后果,合格的系统运维菜鸟,可以在十分钟内修复。

    运维必须从架构,系统,网络,数据库,甚至软件功能,业务使用等多个层面了解分析产品的性能并保障其稳定的运行,和客户体验。

    必要之时控制或禁止研发的各种极端操作:

    1x年一个研发大佬奇葩操作

    定期清理数据库需求

    后台服务自动用drop

    然后重新creat database

    至于其他配置和历史数据……

    那不是运维的活吗?我担心干嘛呢?

    你不会备份导入吗?

    从那以后dml权限与研发无缘了

    为什么开发看运维不爽?

    因为研发人员从严谨的组织结构上,是被运维人员控制、约束和管理的。没有运维的许可,一行代码都无法部署更新到业务环境。 处处被限制,当然不爽。

  • 他们也不想理解为什么自己的软件,运维要浪费服务器资源部署两份。

  • 为什么天天要求自己修什么漏洞不就是个log4j、fastjson吗

  • 为什么不让自己用容易记的123456配公网admin账户而是天天强调复杂度和过期时间

  • 为什么不准自己用select *

  • 为什么为什么天天这个不准那个不准

  • 你很low啊不就是cpu内存开销大吗?不会花钱买设备吗

  • 最后为什么觉得运维low

  • 那是因为正经运维不会告诉研发,自己做了多少预备应急操作。

    你,没有那个权限。

    这是常识,你如果不懂,也没必要告诉你。

    火灾发生以前,消防队就是一群大男孩。灭火器就是浪费钱的摆设,消防检查就是浪费时间的事, 他们也没必要告诉你自己高压水枪能喷多远,云梯有多高,灭火弹能扔多远。 自己的设备有多少公斤重,为什么天天要练爬墙……

    抽烟的人觉得他们就是玩水枪打水仗闹着玩,吓唬人的,很low。

    有些回复,说运维优越感爆棚。 这叫优越感么? 这居然叫优越感? 这是最基本的维护常识。 这叫基本职业态度。

    如果运维同行没有这种职业态度,你是不合格的,你肯定会闯祸。

    在一个公司写了屎山代码的研发,可以拍拍屁股走人,然后继续去下一个企业赚个十万八万再写个屎山。反正不会追着代码跨省找你。

    而一个搞崩了系统的运维,这个闯祸经历将成为他的黑历史,并影响到他未来的就业

    因为需要专业运维的好企业,基本都是几百台服务器起步的大项目,难免不会查背景,这就导致运维如果想干得好,圈子会越来越小,请记住是干得好,不是混得好,混是会出事的。

    运维的屎山,就是P1级事故。

    倒霉点是跟着自己一辈子的黑历史。去哪都受影响,只能转行。

    2018年执行反内外网脚本,搞崩了云服务商网络导致全球业务故障30分钟的运维,,他第一时间和他的岗位一起消失了

    同年自作聪明清理垃圾数据干掉了某地邮政系统数据库的运维,相关行业的HR已经不搜他的简历了。此人据说曾是研发,脚本程序写的出神入化,就是分不清日志和数据。

    更早2013年清理垃圾干崩了某地建设银行db2数据库的运维,他被领导抓着去一个个低头鞠躬分行道歉。然后第一时间退出了计算机行业。

    为什么举这个例子,因为只要是正规大企业的运维,以上都是反面案例天天讲,告诫诸位运维要对自己执行的每一条指令负责。

    敏感操作double check 高危操作 triple check

    作为最后的系统防火墙,运维同时也是系统最大的破坏者。

    由此导致的就是极端保守的工作态度和极端苛刻的容灾机制。

    所以研发觉得这是优越感?这是现实责任压力下的常规操作。

    很多研发的心理是:三十岁前赚够钱回家买房, 又或者是: 以后去当领导再也不搞技术。

    见多了这种家伙,只要给钱谁都卖, 毕竟他们的职业规划都是技术只干30多岁

    都不用企业淘汰他。

    这种心态,是干不了运维,更替代不了运维的,更没资格说他们low的。 如果你们继续以运维会的研发也会的心态看待运维的工作, 看好你们成为下一个反面案例让全国技术圈都认识你。



    4号知乎网友: Gambler




    一般的运维工作,好一点的程序员都能搞定,甚至这些玩意压根就是程序员的必修课,像一般的弄个系统,装个k8s,弄一套cicd啥的,都在Java面试题里的东西,老生常谈了。

    再有就是纯硬件方面的工作,比如说整体网络机房啥的,这算不算在运维的范畴我不知道,但我们之前的运维反正是干过这些事,这些纯硬件方面的工作,可能不一定多难,但程序员一般也不会,其实也不是不会,就像你会开你的 帕萨特, 让你把一辆大型的公交车开起来也不是很难,但是让你去干几天公交司机的工作,你还真不一定干得了,就算干得了也是担惊受怕的,就这么个道理,但是因为学习成本不高,所以依然在鄙视链的底层。

    再高端一点的,比如说一些高端的硬件,思科的交换机,或者某些工业路由器,这种东西需要一定的知识和经验才能调试的了,程序员搞不定,如果只是付出了很少的学习成本也搞不定,在这一块上就能体现运维的技术含量的。打个括弧,这一块算运维的工作吗?我不太确定,括弧结束。

    举两个很简单的例子:一,一家公司几十或者几百台员工电脑,要求每台电脑的网络是被平均分配的,或者是动态平均分配的,你可不要以为这玩意简单,当你真的觉得设置这玩意就跟设置家里的小米路由器一样简单的时候那你基本上是解决不了这个问题的,因为你不会。二,设置让整个网络的硬件设备的 syslog 都推送到一个指定ip 的指定端口,然后给他们分类存储,你看,这你就更懵了吧,很多程序员是不是都没有听过 syslog 是啥玩意?

    再牛一点的,那就是对各种程序熟悉到比自己的家还要熟悉的那种,比如说mysql 在centos 上通过各种方式安装完之后,他自动创建的目录都有哪些,都是干嘛的,设置哪个文件能解决什么问题,给 MySQL 弄个集群或者 读者分离怎 么处理,别看程序员面试的时候这些问题背得贼6,真正碰到问题能处理的也没几个,因为绝大部分情况不会出现问题,哈哈哈哈哈哈,都是做个测试知道原理就成了,最终干这个活的还得是运维,从这点上来说,没有谁高谁低,一个偏理论,一个偏应用,而且理论的点和应用的点也不是同一个点,互补吧算是,MySQL 这都不算啥,还有一些更恶心的软件,光安装就给你安装吐,就不一一列举了。

    再另一种就是网络方面,弄个 vpn 啊,代理个域名啊啥的这都是基本操作,我之前开发微信公众号,后台接口调试需要放到服务器上测试,因为需要在设置的 ip 白名单下,做过这个的都懂我的意思,那时候是十年前,我还是个 小趴菜, 写代码还不是特别自信,也没有像现在的那种 ip 代理工具,都是写一点然后打满日志,然后编译到 tomcat ,是的,那时候用 eclipse 加 tomcat 开发,编译后从 webapps 下找到改动的那个类的 class 文件然后替换掉服务器上的这个文件,然后重启服务器上的 tomcat ,是的,那时候tomcat 貌似不会自动加载,或者我记得是加载之后会有各种缓存问题,最保险的就是重启,重启完了赶紧去另一个控制台看日志这种,那段时间快给我恶心吐了,后来我跟别人抱怨这种情况被运维大哥听到了,这大哥直接给我一顿神操作,然后那个ip 就拥有了一个 公网ip ,说明一个情况就是我们那个公司是没有拉专线的,公网ip 实际上是被服务器代理过来的,现在想想原理很简单,但是对于那时候的我来说那就是神一样的操作,当然了,就算让现 在的我去搞定这个我也不一定能搞定就是了,是的,我很菜。

    最后一种高端操作,这种是完全可以吊打绝大部分程序员的,linux 内核,是的,玩内核的,对linux 开源玩的炉火纯青,小到自己这个脚本,大到直接改动内核代码,他们都能搞定,我之前见过一大哥就专门干这个,我linux 方面有一半的知识是他口述教我的,有问题不需要先百度,直接先问他,他会告诉我解决思路,然后告诉我怎么处理,再告诉我要处理的这几个点的技术名词让我去百度学一下,最后再告诉我坑在哪里需要多注意,是的,当年我俩工位相邻,学了不少,在此谢过大哥了。

    好了,以上就是我对运维的理解了,有不足之处还望指正。

    " 开发都认为运维工程师很Low? " 欢迎在留言区交流,留下你的观点 ~


    整理丨dbaplus社群

    来源丨zhihu.com/question/37627701

    *仅为提供参考和学习交流,不代表dbaplus社群立场! dbaplus社群欢迎广大技术人员投稿,投稿邮箱:[email protected]

    直播推荐

    针对故障MTTR时长,监控系统进一步的机会点在哪里?可观测性系统如何用于快速辅助业务线定位问题根因?锁定5月29日周三晚7点, 去哪儿网 基础架构部技术TL肖双 老师带来的【去哪儿网可观测性实践】主题分享。