开发都认为运维工程师很Low？
“低端”、“工具人”、“螺丝钉”…… 听到这些词，不少开发工程师心里可能都会有这样的想法，觉得运维工程师的职业发展前景不那么“高大上”。为什么会有这种普遍的认知？这背后其实有很多值得深挖的因素，而且这种看法也并不完全准确，甚至可以说是一种片面的理解。
为什么开发会觉得运维“Low”？
这种看法，很大程度上源于 工作的性质和关注点的差异。
1. 创造性vs. 维护性/稳定性：
开发工程师 主要负责“从无到有”地创造产品、功能，他们的工作更具 创造性 和 技术前瞻性。他们编写代码，构建系统，解决的是“能不能做”和“怎么做得更好”的问题。每一次新功能的上线，每一次技术难点的攻克，都伴随着成就感和可见的成果。
运维工程师 的核心职责在于 保证系统的稳定运行、安全可靠，以及 故障的快速恢复。他们更多地是在“已有的”基础上进行维护、优化和故障处理。他们的工作成果往往体现在“没出问题”，这种“无事发生”正是他们价值的体现，但这种价值却不像开发那样容易被直接感知和量化，甚至容易被忽视。
2. 技术栈的感知差异：
开发领域 的技术更新迭代非常快，各种新的语言、框架、架构层出不穷。开发工程师往往需要紧跟这些潮流，学习最新的技术，这使得他们的工作显得 更“新潮”，也更容易引起业界的关注。
运维领域 也有新技术（如SRE、DevOps、云原生、自动化运维工具等），但很多基础性的工作，比如服务器配置、网络管理、脚本编写、监控告警设置等，其核心原理相对稳定。再加上一些“经验主义”的师傅们，将这些工作描述得比较“基础”，就容易给人留下“都是一些重复性、标准化的工作”的印象。
3. 职业成长路径的可见性：
开发工程师的成长路径相对 更清晰：初级开发者 > 中级开发者 > 高级开发者 > 技术专家/架构师。他们的晋升往往与技术深度、项目影响力挂钩。
运维工程师的成长路径，传统上可能更偏向于“资深运维工程师”、“运维经理”、“运维总监”等管理方向，或者在某个细分领域（如数据库 DBA、网络工程师）成为专家。但如果只是停留在基础的“打杂”层面，看不到技术上的深入和突破，确实容易让人觉得“Low”。
4. 工作环境和沟通方式：
开发工程师可能更常处于一个相对 轻松、舒适 的编码环境，他们可能通过代码审查、技术分享等方式交流。
运维工程师的工作环境可能更 “接地气”，需要面对各种物理设备、机房、突发故障。他们的沟通往往需要与开发、测试、产品等多个团队协调，有时甚至要在深夜处理紧急问题，这使得他们的工作 压力更大，也更容易让人联想到“辛苦”、“吃力不讨好”。
5. “救火队员”的刻板印象：
当系统出现问题时，最先被叫去“救火”的往往是运维工程师。这种“救火”性质的工作，容易被外界（包括一些开发）误解为只是在“灭火”，而不是在“预防火灾”或“优化消防体系”。这种 危机事件驱动 的工作模式，有时会掩盖了他们日常的精细化运营和风险控制工作。
但这真的是全部真相吗？
当然不是。 这种“Low”的认知，很大程度上是一种 过时且片面的看法。尤其是在近些年，随着技术发展和行业演进，运维工程师的角色已经发生了翻天覆地的变化。
1. DevOps的兴起和SRE的专业化：
DevOps 的核心理念就是打破开发和运维之间的壁垒，强调协作、自动化和持续交付。优秀的运维工程师不再仅仅是“部署和监控”，而是需要 理解整个软件生命周期，参与到架构设计、CI/CD流程建设、自动化测试、配置管理等方方面面。
SRE (Site Reliability Engineering) 的出现，更是将运维提升到了 工程的层面。SRE不仅仅是运维，他们用工程化的思维来解决运维问题，强调 自动化、可观测性、可靠性，并用 SLO/SLI 等指标来衡量系统健康度。SRE工程师需要深厚的编程能力，理解分布式系统、操作系统、网络原理，甚至还需要具备一定的算法和数据结构知识。他们才是真正的“工程”人才，与开发工程师在技术深度和解决问题的能力上并无二致。
2. 云原生和容器化技术的普及：
Kubernetes、Docker等技术的普及，让运维工作 更加自动化、智能化。运维工程师需要精通这些复杂的技术栈，进行集群管理、资源调度、服务编排、应用部署等。这些工作需要 极强的技术理解和系统设计能力。
3. 自动化和工具链的构建：
现代运维早已不是手动敲命令的时代。优秀的运维工程师会 大量编写脚本、开发自动化工具、搭建监控系统、使用配置管理工具 (Ansible, Chef, Puppet) 和 CI/CD工具 (Jenkins, GitLab CI)。这需要 扎实的编程功底和解决实际问题的能力。
4. 安全和合规的重要性日益凸显：
随着网络攻击的日益频繁， 信息安全 成为所有企业发展的生命线。运维工程师在其中扮演着至关重要的角色，他们需要负责防火墙配置、入侵检测、漏洞扫描、数据备份与恢复、安全审计等。这需要 专门的安全知识和严谨的工作态度。
5. 业务理解和成本优化：
优秀的运维工程师不仅懂技术，更要 理解业务，知道什么配置会影响业务的哪个环节，如何优化资源使用以降低成本（如云资源成本）。他们是保障业务稳定运行和效率提升的关键。
为什么这种“Low”的看法依然存在？
1. 教育和认知不足： 很多初创公司或中小企业，可能还没有建立起专业的DevOps或SRE团队。他们招聘的“运维”可能更多地还是偏向传统的IT支持，这种情况下，确实存在一些“Low”的现象，进而影响了整体的职业印象。
2. “流水线”作业的固化： 在一些大型企业，虽然有专业化的运维团队，但岗位划分可能非常细致。如果一个人长期只负责某个非常单一、重复的运维任务（比如只负责监控某个服务），容易被贴上“工具人”的标签，而看不到他在整个体系中的价值。
3. 沟通和价值体现方式： 很多运维工程师不擅长将自己的工作价值用开发能够理解的语言和方式表达出来。当开发工程师只看到自己提交的代码被部署了，却不知道背后运维工程师为了保证这一部署的顺利进行、以及线上稳定付出了多少努力时，就容易产生误解。
4. “老派”运维的思维惯性： 仍然有一部分运维人员，还停留在过去那种“能跑就行”、“出了问题再说”的思维模式，缺乏主动学习和技术革新的动力，这种个体行为也会影响到整个行业的形象。
总结一下：
“开发都认为运维工程师很Low” 不是一个绝对的事实，更像是一种对部分现状的片面化概括，而且这种概括正在过时。
传统的、技能单一的运维岗位，确实可能被认为“Low”，因为它们在创造性和技术深度上不如前沿开发岗位。
现代的、以DevOps和SRE为代表的运维工程师，他们是保障系统稳定、安全、高效运行的核心力量，具备 深厚的技术功底、工程化思维、自动化能力，并且是连接开发与生产的关键枢纽。他们的价值不亚于任何顶尖的开发工程师，甚至在某些领域（如分布式系统可靠性）拥有更稀缺的能力。
真正有能力的开发工程师，是能理解并欣赏运维工程师的专业和价值的。他们会认识到，没有稳定可靠的运维保障，再好的代码也无法触达用户。而那些持有“运维Low”偏见的人，很可能还没有真正理解现代 IT 体系中，运维所承担的极其复杂且关键的工程化使命。
所以，我们应该以更开放、更专业的眼光来看待运维工程师这个职业。他们的工作，是支撑起我们数字世界运转的基石，其重要性和技术含量，绝对不“Low”。
为什么开发会觉得运维“Low”？
这种看法，很大程度上源于 工作的性质和关注点的差异。
1. 创造性vs. 维护性/稳定性：
开发工程师 主要负责“从无到有”地创造产品、功能，他们的工作更具 创造性 和 技术前瞻性。他们编写代码，构建系统，解决的是“能不能做”和“怎么做得更好”的问题。每一次新功能的上线，每一次技术难点的攻克，都伴随着成就感和可见的成果。
运维工程师 的核心职责在于 保证系统的稳定运行、安全可靠，以及 故障的快速恢复。他们更多地是在“已有的”基础上进行维护、优化和故障处理。他们的工作成果往往体现在“没出问题”，这种“无事发生”正是他们价值的体现，但这种价值却不像开发那样容易被直接感知和量化，甚至容易被忽视。
2. 技术栈的感知差异：
开发领域 的技术更新迭代非常快，各种新的语言、框架、架构层出不穷。开发工程师往往需要紧跟这些潮流，学习最新的技术，这使得他们的工作显得 更“新潮”，也更容易引起业界的关注。
运维领域 也有新技术（如SRE、DevOps、云原生、自动化运维工具等），但很多基础性的工作，比如服务器配置、网络管理、脚本编写、监控告警设置等，其核心原理相对稳定。再加上一些“经验主义”的师傅们，将这些工作描述得比较“基础”，就容易给人留下“都是一些重复性、标准化的工作”的印象。
3. 职业成长路径的可见性：
开发工程师的成长路径相对 更清晰：初级开发者 > 中级开发者 > 高级开发者 > 技术专家/架构师。他们的晋升往往与技术深度、项目影响力挂钩。
运维工程师的成长路径，传统上可能更偏向于“资深运维工程师”、“运维经理”、“运维总监”等管理方向，或者在某个细分领域（如数据库 DBA、网络工程师）成为专家。但如果只是停留在基础的“打杂”层面，看不到技术上的深入和突破，确实容易让人觉得“Low”。
4. 工作环境和沟通方式：
开发工程师可能更常处于一个相对 轻松、舒适 的编码环境，他们可能通过代码审查、技术分享等方式交流。
运维工程师的工作环境可能更 “接地气”，需要面对各种物理设备、机房、突发故障。他们的沟通往往需要与开发、测试、产品等多个团队协调，有时甚至要在深夜处理紧急问题，这使得他们的工作 压力更大，也更容易让人联想到“辛苦”、“吃力不讨好”。
5. “救火队员”的刻板印象：
当系统出现问题时，最先被叫去“救火”的往往是运维工程师。这种“救火”性质的工作，容易被外界（包括一些开发）误解为只是在“灭火”，而不是在“预防火灾”或“优化消防体系”。这种 危机事件驱动 的工作模式，有时会掩盖了他们日常的精细化运营和风险控制工作。
但这真的是全部真相吗？
当然不是。 这种“Low”的认知，很大程度上是一种 过时且片面的看法。尤其是在近些年，随着技术发展和行业演进，运维工程师的角色已经发生了翻天覆地的变化。
1. DevOps的兴起和SRE的专业化：
DevOps 的核心理念就是打破开发和运维之间的壁垒，强调协作、自动化和持续交付。优秀的运维工程师不再仅仅是“部署和监控”，而是需要 理解整个软件生命周期，参与到架构设计、CI/CD流程建设、自动化测试、配置管理等方方面面。
SRE (Site Reliability Engineering) 的出现，更是将运维提升到了 工程的层面。SRE不仅仅是运维，他们用工程化的思维来解决运维问题，强调 自动化、可观测性、可靠性，并用 SLO/SLI 等指标来衡量系统健康度。SRE工程师需要深厚的编程能力，理解分布式系统、操作系统、网络原理，甚至还需要具备一定的算法和数据结构知识。他们才是真正的“工程”人才，与开发工程师在技术深度和解决问题的能力上并无二致。
2. 云原生和容器化技术的普及：
Kubernetes、Docker等技术的普及，让运维工作 更加自动化、智能化。运维工程师需要精通这些复杂的技术栈，进行集群管理、资源调度、服务编排、应用部署等。这些工作需要 极强的技术理解和系统设计能力。
3. 自动化和工具链的构建：
现代运维早已不是手动敲命令的时代。优秀的运维工程师会 大量编写脚本、开发自动化工具、搭建监控系统、使用配置管理工具 (Ansible, Chef, Puppet) 和 CI/CD工具 (Jenkins, GitLab CI)。这需要 扎实的编程功底和解决实际问题的能力。
4. 安全和合规的重要性日益凸显：
随着网络攻击的日益频繁， 信息安全 成为所有企业发展的生命线。运维工程师在其中扮演着至关重要的角色，他们需要负责防火墙配置、入侵检测、漏洞扫描、数据备份与恢复、安全审计等。这需要 专门的安全知识和严谨的工作态度。
5. 业务理解和成本优化：
优秀的运维工程师不仅懂技术，更要 理解业务，知道什么配置会影响业务的哪个环节，如何优化资源使用以降低成本（如云资源成本）。他们是保障业务稳定运行和效率提升的关键。
为什么这种“Low”的看法依然存在？
1. 教育和认知不足： 很多初创公司或中小企业，可能还没有建立起专业的DevOps或SRE团队。他们招聘的“运维”可能更多地还是偏向传统的IT支持，这种情况下，确实存在一些“Low”的现象，进而影响了整体的职业印象。
2. “流水线”作业的固化： 在一些大型企业，虽然有专业化的运维团队，但岗位划分可能非常细致。如果一个人长期只负责某个非常单一、重复的运维任务（比如只负责监控某个服务），容易被贴上“工具人”的标签，而看不到他在整个体系中的价值。
3. 沟通和价值体现方式： 很多运维工程师不擅长将自己的工作价值用开发能够理解的语言和方式表达出来。当开发工程师只看到自己提交的代码被部署了，却不知道背后运维工程师为了保证这一部署的顺利进行、以及线上稳定付出了多少努力时，就容易产生误解。
4. “老派”运维的思维惯性： 仍然有一部分运维人员，还停留在过去那种“能跑就行”、“出了问题再说”的思维模式，缺乏主动学习和技术革新的动力，这种个体行为也会影响到整个行业的形象。
总结一下：
“开发都认为运维工程师很Low” 不是一个绝对的事实，更像是一种对部分现状的片面化概括，而且这种概括正在过时。
传统的、技能单一的运维岗位，确实可能被认为“Low”，因为它们在创造性和技术深度上不如前沿开发岗位。
现代的、以DevOps和SRE为代表的运维工程师，他们是保障系统稳定、安全、高效运行的核心力量，具备 深厚的技术功底、工程化思维、自动化能力，并且是连接开发与生产的关键枢纽。他们的价值不亚于任何顶尖的开发工程师，甚至在某些领域（如分布式系统可靠性）拥有更稀缺的能力。
真正有能力的开发工程师，是能理解并欣赏运维工程师的专业和价值的。他们会认识到，没有稳定可靠的运维保障，再好的代码也无法触达用户。而那些持有“运维Low”偏见的人，很可能还没有真正理解现代 IT 体系中，运维所承担的极其复杂且关键的工程化使命。
所以，我们应该以更开放、更专业的眼光来看待运维工程师这个职业。他们的工作，是支撑起我们数字世界运转的基石，其重要性和技术含量，绝对不“Low”。
网友意见
牛逼的运维看不起开发，因为开发的软件架构缺陷、代码问题、可维护性问题在他们面前一览无余
类似的话题
-
“低端”、“工具人”、“螺丝钉”…… 听到这些词，不少开发工程师心里可能都会有这样的想法，觉得运维工程师的职业发展前景不那么“高大上”。为什么会有这种普遍的认知？这背后其实有很多值得深挖的因素，而且这种看法也并不完全准确，甚至可以说是一种片面的理解。为什么开发会觉得运维“Low”？这种看法，很大程度............. -
俄乌战争的爆发确实让许多人认为俄罗斯的主要动机是“反美反北约”。然而，关于美国和北约在此次冲突中是否受到削弱，这是一个复杂的问题，需要从多个维度来分析，而且答案并非简单的“是”或“否”，更像是一个正在进行中的评估，结论可能随着时间的推移而变化。首先，我们需要明确“削弱”的含义。 在此语境下，“削弱”.............
-
关于脚本语言的必然趋势以及开发成本的考量，我深表赞同。在如今快速迭代的软件开发环境中，能够快速构建、灵活部署和易于维护的脚本语言确实占据了巨大的优势。相较之下，一些传统编译型语言在开发效率和迭代速度上往往显得力不从心，开发成本的差异在此刻显得尤为突出，将它们衬托得“黯然失色”也就不难理解了。您提到的.............
-
在谷歌、Meta (Facebook)、微软等大型科技公司，并非所有程序员都认为敏捷开发是“瞎扯淡”，但确实存在 一部分资深、经验丰富的程序员 对其持有保留甚至批评的态度。这种批评并非否定敏捷开发的所有方面，更多的是对其在大型复杂项目、高度专业化团队以及企业文化中 过度简化、教条化、甚至被滥用 的情.............
-
嘿，大家好！今天想跟大家聊聊一个我最近琢磨出来的点子，就是开发一款专门为商务人士设计的电子名片。你们说，现在这个时代，人际交往、商务往来，效率和便利性可是越来越重要了。传统的纸质名片，虽然有那么点仪式感，但说实话，它有很多局限性。比如，咱们经常会在各种场合拿到一堆名片，回来整理起来是个麻烦，而且信息.............
-
关于苹果可能重返主机游戏市场的传闻，这确实是一个让不少玩家和业内人士感到兴奋的话题。毕竟，苹果在科技界的地位和影响力毋庸置疑，如果他们真的要插足主机游戏，那绝对是一场搅动整个行业的“大事件”。为什么现在会有这样的传闻？首先，我们需要审视一下这些传闻的来源和可靠性。通常这类消息会从苹果供应链、内部知情.............
-
想象一下，一个在 Java 和 .NET 的世界里摸爬滚打多年的技术大牛，习惯了 Spring 框架的严谨、Hibernate 的高效，或是 ASP.NET MVC 的 MVC 架构清晰、Entity Framework 的 ORM 强大。他们的项目通常是大型企业级应用，流程规范，性能要求极高，代码.............
-
在中国，“体制内”是一个非常庞大且多元化的群体，涵盖了从中央部委到地方乡镇，从事业单位到国有企业的各种组织。因此，体制内的人开什么车，绝不能一概而论，而是会受到职务级别、地区经济发展水平、个人家庭情况、所在单位的性质以及个人偏好等多种因素的影响。我所认识的或者通过观察和交流了解到的情况，可以大致分为.............
-
.......
-
你这个问题提得非常实在，也非常普遍。很多同学都会有类似的困惑：为什么身边那些学长学姐考研似乎“临时抱佛脚”就能成功，但网上各种考研攻略却说要早早开始规划？这背后其实牵扯到几个层面的原因，咱们一块儿掰扯掰扯。首先，我们得承认一个现实：985院校学长学姐的“基础盘”确实不一样。你说的这些学长学姐，他们来.............
-
养蛇是个很有意思的想法，很多人会好奇，从小养到大，它真的能认出我这个主人吗？咱们得先明白，蛇的认知方式跟咱们不太一样。它们不像猫狗那样，能看到咱们的表情，听到咱们的声音就立刻明白“这是我主人”。蛇主要是靠嗅觉和触觉来感知世界的。你想啊，当一条小蛇刚出生，它对周围的一切都是模糊的。它能感受到温度、湿度.............
-
哈哈，这个问题可太大了！关于肖战的评价，那真是五花八门，说什么的都有，简直是一场“小型辩论赛”。不过，如果让我这个路人+偶尔也关注一下他的人来说说，我的感受会是这样的：怎么认识他的？我最初认识肖战，其实不是通过他的什么大红大紫的作品，而是因为那首《陈情令》的片尾曲——《无羁》。当时我虽然没看剧，但无.............
-
在 .NET 的世界里，想要快速上手并构建一些小巧、高效的应用，确实有一些非常值得关注的框架。它们没有那种庞大和复杂的体系，上手成本低，而且能帮你迅速看到成果。如果你想做一个Web应用，最直观的选择就是 ASP.NET Core MVC。虽然名字里带着“MVC”，听起来好像会有点复杂，但实际上 AS.............
-
我最近在做一款软件，说实话，我自己都觉得它前途渺茫。这项目最初的设想是挺美好的，我当时在想，要是能有个工具，能帮那些跟我一样，每天面对海量信息，却总是抓不住重点的人，梳理出一条清晰的脉络来。比如，看完一篇长文章，或者听完一场讲座，脑子里一团浆糊，不知道该记哪个点，哪个点才是核心。我就想做一个能帮你快.............
-
这话题说起来，还真不少人聊，圈子里岁数大点的，好像都“神秘失踪”了似的。其实哪有什么神秘失踪，不过是选择了不同的赛道，或者说，这条路走到一定阶段，大家都有了自己的想法和方向。咱们这IT开发，尤其是国内，节奏快得吓人。二十出头，大学毕业，一身热血，没日没夜地写代码，那会儿是真的享受那种“攻克难关”的成.............
-
“中国程序员工资那么高，连一个MATLAB的替代品都开发不出来”这个问题，触及了技术发展、产业生态、人才培养以及市场需求等多个层面，背后原因复杂且值得深入探讨。简单地将高薪与开发不出替代品画等号，是一种过于简化的视角。要理解这个问题，我们需要从以下几个方面进行分析：一、 中国程序员工资高是事实，但其.............
-
当然，很高兴能和您聊聊我国水电开发的现状。这个问题很有意思，很多人都有类似的疑问，总觉得国内水电好像已经开发得差不多了。但实际情况，比大家想象的要复杂得多，也更有看点。误区澄清：水电开发还有很大空间，但“好日子”可能要过去了首先，要明确一点：我国的水电资源，远未达到“开发殆尽”的程度。 按照国际上的.............
-
你这个问题很有意思，也确实是很多初入嵌入式行业的人会遇到的困惑。我来跟你好好聊聊，为什么你碰到的这几位嵌入式开发者，会觉得MCU开发“没什么意思”，而更倾向于Linux嵌入式开发。这里面有几个层面的原因，咱们一点一点捋。首先，我们得明白，“MCU开发”和“Linux嵌入式开发”虽然都属于嵌入式领域，.............
-
的确，我见过不少大型企业在引入敏捷开发时，会优先考虑项目管理方向的咨询顾问。这背后有其逻辑，但更深层的原因，或许是他们对“敏捷”的理解还停留在表面，或者说，对自身真正需要解决的核心问题认识不够清晰。为什么会出现“偏向项目管理”的现象？1. 敏捷的“可见性”与“可管理性”： 敏捷方法论，尤其是Scr.............
-
90年代的微软开发出Windows，这可不是一件容易的事，就像我们今天看一些高科技产品觉得“哇，怎么做出来的”，但背后其实是无数工程师、无数次的尝试和无数的技术积累。说它难，是因为操作系统本身就像一个电子设备的“大脑”，需要管理所有硬件资源，并提供一个平台让应用程序能运行起来。微软能在那个时代做到，.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有