运维技术能力_开发笑运维Low？醒醒吧，我反手就是一巴掌

最近小编在某乎上看到这样一个问题：

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

我从事自动化运维工作，编写了大量自动化程序，我离职后这些程序无人负责，开发人员无法处理，测试人员也不懂，其他运维人员同样无法应对，最终原本自动化的业务都改由人工操作，导致人员开支增加，公司整体技术发展停滞不前。

从事运维工作相当艰辛，经常被人认为价值不高。服务器机房需要了解，网络安全知识必须掌握，容器编排技术要熟悉，企业办公及客户关系管理系统也要精通。

Linux知识你掌握了吗，数据库MySQL你了解吗，Kvm技术你熟悉吗，阿里云和华为云平台你懂得运用吗，还要求你会操作，Java和Vue你也能运用自如吗，否则遇到能力不足的开发者可能就会被迫加班，还得懂计算机服务器硬件以及Raid配置，否则设备故障时都无法处理，由此可见运维工作确实不轻松，终于有人关注到这个问题了，回答一下也算表达一下不被重视的心声。

2号知乎网友：技术王

凭借十余年技术领域积累的见识来说，假如一个程序员认为系统管理方面的人才很微不足道，将来必定会遭遇麻烦，部分技术精湛的系统管理专家，其实远非他能随意评价的层次。

你误以为运维仅是照看设备，维护数据库？你上传文件后指望运维去操作？你的记录信息积压了由运维来处理？运维负责部署软件环境？你想象的运维工作仅限于此？

作为一名程序员，我见识过许多运维任务远超我的预料，这些工作的复杂程度完全不亚于开发，所需的技术能力同样十分精湛，现在我就来谈谈运维技术究竟能达到何种境界，他们又完成了哪些艰巨的任务。

1、监控能力

我在这个领域最有话语权，稳定性、SRE一直是我当前负责的工作，但全面的SRE并非仅靠开发就能实现，许多方面仍需依赖运维配合，期间我也发掘出不少新的可能性，原来还可以采取这种方式。

首先需要监视Linux系统，这要求对整个系统进行全面观察，包括网络状态、磁盘使用情况、CPU负荷和内存容量等，这才是真正的监控，不过对于我来说，直接获取这些初始数据确实很不容易，只有掌握了这些系统运行数据，才能进行性能评估和问题排查，进而实施异常识别等操作。

不过，运维人员给了我许多数据，数量庞大难以全部挑选，涉及网络监控啊，路由啊，还有其他技术等等，接着他们把这些指令或工具编排成脚本，顺利地提交到我们侧的云端平台，从而让我们能够全面且系统化地监视整个网络。

为何要监视磁盘？他们编写了诸多脚本，其中融合了多种技术要素，诸如lsof之类的各类工具，可以说将磁盘的各类信息都汇集上报了过来，我们时常觉得这些数据过于繁杂，但他们已全部部署妥当，他们的意图是促使我们构建监控机制，以便他们也能运用这些机制。

他们当然对处理器和内存的监控更为精通，能够将内存中的数据全部提取出来，然后评估内存的表现，并且应用程序的调用堆栈详情也能借助脚本上传至云端，这样用户的缓慢服务就无需人工察觉，运维工具便能自动识别，同时会指出具体是哪个线程，哪段代码的处理器占用过高，以及执行所需时间有多长等等。偶会琢磨，这些人并非技术人员，却怎么能准确找到那个位置呢？另外，他们使用perf这个软件的能力，一点也不比程序员差！

2、对Linux的熟悉程度

要说最擅长Linux的，那还得是系统管理员，他们了解得有多深入呢？举个例子，他们能让Linux的启动过程逐项进行，这跟程序员调试程序没什么两样。

比如某个时刻，技术人员调整了系统参数，就是修改了相关配置文件，随后检查了多次，却发觉完全无效，这就变得十分反常了，通常情况下都能正常进行，为何那台设备会特殊呢？考虑到我们采用的是特定架构，因此维护工作就由操作团队负责了。系统重装并不可行，毕竟已有大量关键应用部署，必须由专业人员来处理。

后来是如何解决的？技术人员发现这个操作在系统底层没有正确绑定相应的连接点，因此执行指令时无法识别路径参数，那么为何未能绑定到对应连接点呢？经过长时间调查，工作人员采用逐指令执行的方式分析Linux系统，最终运用了该操作系统的调试功能。后续查明缘由在于部分软件无意间更改了内存中的钩子设置，倘若从事开发工作，此类隐蔽的故障确实非常难以察觉。

我那时感到十分困惑，运维人员通常不负责调试代码，实际上Linux内核代码除了运维人员，几乎无人会去修改，应用开发人员也用不着，运维人员只是勉强为之。

3、救火能力

有时候，程序员会创建一个软件，然后放到服务器上运行，很快发现系统连接数用光了，或者硬盘读写速度变慢了，又或者处理器使用率达到了峰值，但这些只是表面现象，人们仅知道Linux服务器的资源已经满了，运维人员必须先确定资源消耗的具体位置，然后才能深入探究问题根源，只有确认确实是软件本身的问题，才能要求开发人员修改代码。

接下来，运维工作不能就此停步，必须深入探究是否存在资源调配不当的情况。不可以直接判定java进程占用了多少比例就立刻联系开发人员，否则显得不够专业，资深的运维人员会探究为何java的占用率会异常增高，是否会受到其他因素干扰，核实清楚确实是java程序导致的问题后，才会告知程序员进行优化，生产环境中的问题变化极快，他们又不了解具体业务，在这样的复杂状况下要做出准确判断，我认为这并非易事。

4、网络安全能力

运维的核心职责在于设备维护，以及网络系统的构建，究竟何种设备配置能促进整体系统效能，怎样监管手段才能确保安全可靠，这些都是运维人员必须面对的课题，管理流程过于繁琐，开发人员会心生抵触，而管理措施过于粗略，又容易引发安全风险。

此外，怎样判定是否安全？一旦发现不安全状况，有哪些应对措施？通常存在哪些安全风险？诸如恶意攻击、权限提升、异常流量来源等问题，都需要仔细研究，倘若设备中了木马，或遭受了猛烈攻击，主要责任就落在管理人员身上，可以想象他们承受的压力多么巨大，这正是高压之下催生出顶尖技术的情形。

这些就是运维人员所具备的技能，也是我关注但尚有不足之处的能力，许多故障排查方法也是向运维人员学习的，运维的范畴其实远不止这些，可以这样说，除了编程能力不需要具备，其他方面他们几乎都要精通，因此，你还会认为运维工作地位不高吗？

3号知乎网友：匿名用户

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

乱改密码以为可以调戏运维，是吧？

单用户模式直接回收root，就没脾气了。

权限控制就这么任性。

离职清代码显得自己牛逼是吧。

删除时程序会自动同步备份，十分钟后可还原至未知的备用场地，你正在使用的为高级账户，难道我设置了双重节点吗？

不好意思，删除指令我们alias了，当然你也没权限看。

n+1 没了开心不?

自动化监控上线后，一举一动都会被运维盯着。

一旦登录完成，他们的任务仅限于递交程序，其他的步骤全都通过权限划分成若干部分。

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

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

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

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

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

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

由此衍生出的应对措施：

经历那些难题后，你就能从基础运维成长为高手了，这一切都是压力促成的。

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

运维的作用在于以非常谨慎的态度，通过系统层面的手段来限制可能出现的风险，同时努力地全方位观察，预判未来可能会发生的问题，并制定相应的应对计划。

运维就是限制开发权限过度到破坏业务的防火墙。

这个职位的设立，是为了确保业务系统安稳运行，运用各种技术方法处理各类缺陷和错误，并且能在最短时间内消除影响恢复业务。

最突出的网络事故之一是数据删除后逃离现场。这种情形造成的恶劣影响，有能力的系统维护新手，往往能在十分钟之内纠正过来。

维护工作需要从整体布局，设备层面，线路配置，信息存储，功能实现，以及实际操作等多个角度审视产品的运作状况，确保其平稳运作，同时提升用户感受。

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

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

定期清理数据库需求

后台服务自动用drop

然后重新creat

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

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

你不会备份导入吗？

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

为什么开发看运维不爽？

研发团队在组织架构上受运维团队支配、制约和监管。没有运维的批准，任何代码都不能部署到生产环境。处处受到约束，自然会感到不快。

他们同样不愿明白，为何他们开发的程序，系统管理员却要占用大量机器能力，去安装两个相同的副本。

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

为何不选用简单易记的公共网络管理员账号，反而总是强调密码的复杂性和有效期限制呢。

为什么不准自己用 *。

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

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

最后为什么觉得运维low

那是因为专业维护人员不会告知开发人员，自己具体实施了哪些备用应对措施。你，不具备那样的知情权力。

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

火灾来临之前，消防组织不过是一帮愣头青。那些灭火器具被当作无用的装饰，防火审核被看作虚耗光阴的环节，他们没必要透露高压水龙头的射程有多长，云梯的高度有多高，灭火手雷的投掷距离有多远。自身装备的重量有多少，为何每日都要进行攀爬训练……

吸烟者认为他们只是在嬉水，像是在玩水枪，进行打水仗的游戏，目的是恐吓别人，显得很没水平。

部分回应，显现出操作维护方面极度自信。这算是自信吗？这竟然被称作自信？那是最基础的系统管理常识。这属于根本的职业操守。

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

一个公司的程序员，如果写出了糟糕的代码，能够轻易离开，然后去另一家公司，在那里获得丰厚的报酬，并继续制造质量低劣的代码。因为公司不会为了追查那些代码而跨省找你。

一旦系统维护工作出现重大失误，这次过失就会变成个人档案里的污点，进而波及到其今后的职业发展。

专业维护工作的高水平企业，通常从拥有数百台服务器的大型工程开始，这类项目往往会对相关人员的资历进行审查，因此，若想在运维领域取得优异成就，个人声誉会随着业绩提升而逐渐受限，务必明确，追求卓越而非敷衍了事，否则终将面临严重后果。

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

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

二零一八年实施了针对内外网的反制措施，引发了云服务提供商网络中断，致使全球业务停摆了三十分钟，他当机立断，与自身职责一同消失不见了

那一年他自作主张处理了无用信息，导致某个地区的邮件系统管理团队遭到破坏，结果从事相关领域的招聘人员不再关注他的履历了，据说他过去从事过技术开发工作，编写的自动化脚本非常出色，只是无法区分记录和资料。

二零一三年初期，有人负责清理废弃物时，导致某地建设银行的DB2数据库系统瘫痪，他因此被上级约谈，不得不逐一向分行负责人弯腰致歉，随后立即离开了信息技术领域。

举这个例子的缘由在于，只要是正规的大公司里的运维人员，以上这些情况都是反面教材，天天都在强调，提醒各位运维工作的人员，要对自己发出的每一条指令承担后果。

敏感操作 check 高危操作 check

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

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

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

许多人怀揣这样的想法：三十岁之前积累足够的财富购置房产，或者打算将来担任管理职位，不再从事技术工作。

见多了这种家伙，只要给钱谁都卖，

毕竟他们的职业规划都是技术只干30多岁。

都不用企业淘汰他。

这种想法，根本无法胜任系统维护工作，也无法取代专业人员，更没有资格去评价他们水平不高。

倘若你们依旧将运维事务视作研发部门的课题，那么我预见你们会变成又一个警示性的实例，使整个国内技术领域都注意到你们。

4号知乎网友：

基础的操作维护任务，寻常的软件开发者都可以胜任，这类职责实质上就是程序开发者的基本功，诸如部署普通系统，配置k8s环境，建立ci/cd流程等，都属于常规的技能范畴，在Java技术考核中屡见不鲜，早已是众所周知的内容。

硬件层面的任务，例如网络设施维护，是否属于运维工作范畴尚不明确，不过我们以往的运维人员确实承担过这些职责，硬件相关工作或许技术难度不大，但程序员通常不擅长，并非真不会，就好比你会驾驶帕萨特，但要操控大型公交车，操作上并非难事，但让你持续驾驶几天公交车，你未必能胜任，即便胜任也必定心神不宁，道理相同，但由于掌握起来并不费劲，这类工作依然处于职业评价的较低层次。

更高级的设备，比如一些专业的硬件，像思科的网络交换机，或者特定的工业用路由器，这种设备需要相当的专业知识和实践经验才能进行设置，编程人员通常无法处理，如果只是略微学习了相关内容也无法解决，这方面可以明显看出运维人员的技术水平，需要加个括号，运维工作包含这些内容吗，我对此感到不确定，括号结束。

列举两个较为基础的案例：其一，某企业拥有数十台乃至数百台员工用电脑，需要确保每台电脑的网络流量能够得到均等分配，或者是实现动态均衡分配，切莫认为这项任务简单，一旦你自认为配置这类系统与在家中设置小米路由器同等容易，那么你几乎无法妥善处理该问题，因为你缺乏相应的能力。二，让全部网络硬件设备都传送至特定IP的特定端口，随后进行分类保存，你瞧，这你就更加困惑了，众多程序员是否都没听过这东西？

真正厉害的人，对各种软件的使用程度要远超对自己住所的了解，比如在服务器上安装 MySQL 后，自动生成的各个目录的功能和用途，以及哪些文件能够解决特定问题，如何构建 MySQL 集群或实现读写分离，面试时程序员或许能背诵这些知识，但实际遇到问题时，能妥善处理的人却不多，毕竟大多数情况都不会发生故障，哈哈哈，通常做测试时明白原理就足够了，最终负责这些工作的还是运维人员，从这个角度讲，两者没有优劣之分，一个侧重理论，一个侧重实践，而且两者的关注点也完全不同，可以说是相辅相成，MySQL 还算不上最复杂的，还有一些软件安装起来极其繁琐，就不一一列举了。

网络方面还有另一种做法，比如设置虚拟专用网络，或者代理域名之类的，这些都属于常规手段，我之前开发微信公众号时，后台接口调试需要部署到服务器上测试，因为必须在设置的ip白名单内，做过这个的都明白我的意思，那时候是十年前，我还是个新手，写代码还不够自信，也没有现在这些ip代理工具，都是写一点然后查看详细日志，接着编译到指定目录，是的，那时候用开发，编译后从工作区找到修改过的那个类的class文件，然后替换掉服务器上的这个文件，接着重启服务器，是的，那时候似乎不会自动加载，或者我记得加载之后会有各种缓存问题，最稳妥的办法就是重启，重启后赶紧去另一个控制台看日志，那段时间差点把我逼疯，后来我跟别人抱怨这种状况被运维前辈听到了，这位前辈直接给我来了一套高招，结果那个ip就获得了一个公网ip，这说明一个情况就是我们公司没有架设专用线路，公网ip实际上是由服务器代理的，现在回想原理很简单，但对我来说当时就是神奇的操作，当然了，就算让现在的我去处理这个我也不一定成功，是的，我确实比较欠缺。

最后一种高级技能，这种能力足以超越大多数程序员，涉及Linux内核，确实，精通内核开发的人，对Linux开源生态运用自如，小到编写脚本，大到直接修改内核代码，他们都能轻松应对，我之前认识一位高手专门从事这项工作，我在Linux方面的知识有一半是他传授给我的，遇到问题不用先上网搜索，直接向他请教，他会讲解解决思路，然后指导具体操作步骤，接着告诉我需要掌握的技术术语让我自行查阅，最后再提醒我关键注意事项，没错，当年我们工位挨着，从他那里学到了很多，在此表示感谢。