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

我用十多年的开发经验告诉你，如果你作为开发觉得运维工程师很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吗？

一般的运维工作，好一点的程序员都能搞定，甚至这些玩意压根就是程序员的必修课，像一般的弄个系统，装个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 方面有一半的知识是他口述教我的，有问题不需要先百度，直接先问他，他会告诉我解决思路，然后告诉我怎么处理，再告诉我要处理的这几个点的技术名词让我去百度学一下，最后再告诉我坑在哪里需要多注意，是的，当年我俩工位相邻，学了不少，在此谢过大哥了。

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