一般的运维工作，好一点的程序员都能搞定，甚至这些玩意压根就是程序员的必修课，像一般的弄个系统，装个 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 方面有一半的知识是他口述教我的，有问题不需要先百度，直接先问他，他会告诉我解决思路，然后告诉我怎么处理，再告诉我要处理的这几个点的技术名词让我去百度学一下，最后再告诉我坑在哪里需要多注意，是的，当年我俩工位相邻，学了不少，在此谢过大哥了。
评论更精彩：
来自知友死宅的评论：
老哥说的有道理，其实运维真正的价值是踩坑。
来自知友邓乔青的评论：
运维的价值在业务连续性，开发只是系统生命周期的一小部分，而运维是伴随系统的整个生命周期。
一个只管生，不管养。一个生下来就小心呵护，哪个重要？？？
来自知友杰哥的评论：
我是做系统运维的，但这些东西怎么说呢，只是日常工作的一小部分，因为网上都有现成的知识，有的现学现用就能做。
真正难的是理解业务，不光是本系统的，还得是整个体系的，到什么程度呢？该系统的所有数据来源是哪里，对应的业务部门是哪个，负责人是谁，下游是哪里，某个字段会对其他系统造成什么影响，当A系统出现了问题，直接原因是什么，间接原因是什么，该由谁负责，解决方法有哪些，是否合规，怎么协调合各部门处理，如何分工。如何定制度，如何考核，这才是最难搞的。
来自知友下一个世界的评论：
开发和运维差别在意识，不在技术，一般的技术下功夫学学大家都能会。
开发是我怎么方便怎么来，运维是怎么风险最小怎么来。所以开发骂运维拖后腿，运维骂开发没有安全管理意识。[doge]
来源：https://www.zhihu.com/question/37627701/answer/2920293720
以下是来自知友技术王的回答：
我用十多年的开发经验告诉你，如果你作为开发觉得运维工程师很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吗？
链接：https://www.zhihu.com/question/37627701/answer/3005025102
来自知乎作者匿名用户的回答：
用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权限与研发无缘了
……
来源：https://www.zhihu.com/question/37627701/answer/3003706667
备注：相关内容转载自知乎网友评论，不代表本号观点
近期好文：
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。
发表评论