运维岗的由来

运维这一细分岗位起源于计算机和信息技术发展的早期。大概20世纪50年代，计算机还处于大型机时代，体积庞大且成本高昂，运维主要集中在硬件维护和操作系统管理上，他们负责确保计算机的正常运行和高效利用，早期的运维工作大多是手工完成的，这时候已经出现了事实上的细分岗，例如系统操作员（换磁带、调度作业、管理输出设备等）、系统程序员（输入打孔片、输入验证工作）等。

到了70年代，迷你计算机的出现让更多中小企业也能够负担得起计算资源，这时的运维工作就涉及更多的计算资源分配和网络管理，而管理多台计算机和网络设备的需求也促使了网络管理工具的发展，这时细分岗例如 DBA、网络管理就出现了。

80年代，PC的普及使得计算机进入了办公室的桌面，运维工作开始涉及桌面支持和网络管理。局域网（LAN）的广泛应用也增加了网络管理和维护的复杂性，出现了专门的细分岗。到了90年代，互联网的快速发展使得IT基础设施变得更加复杂，运维人员需要管理大量服务器、路由器和交换机。企业级应用（如ERP、CRM等）的出现也使得运维工作更加复杂和关键。

进入21世纪，大型数据中心的建设使得运维工作集中在高密度计算环境的管理上，运维的职责也开始逐步变宽，大机房的运维岗还包括电力、散热和物理安全等；而虚拟化技术的广泛应用改变了传统的服务器管理方式，运维人员也需要掌握虚拟机管理和资源调度技术。

到了2010前后，云计算的普及使得IT基础设施可以作为服务来交付，运维工作更多地涉及云服务的管理和优化。随着DevOps的兴起，运维工作也越来越依赖于自动化工具和脚本，以提高效率和减少人为错误。运维的演变反映了信息技术发展的每一个重要阶段，从早期的手工操作到现在的高度自动化和智能化，运维也在不断适应和创新，以满足现代企业和组织的需求。

运维衰落了？No

很多人都在说，哎呀运维不行了，赶紧转行 blabla...

这些人唱衰运维的点，主要在于技术和文化的变革。

首先，自动化工具的普及大大减少了传统手动运维任务的需求。许多曾经需要人工干预的操作现在可以通过自动化脚本高效完成，使得运维人员的工作量显著减轻。而另一方面看，DevOps文化的兴起也进一步推动了这一变化，开发团队开始承担更多的运维职责，运维和开发的界限变得模糊。

云计算的广泛应用也对传统运维产生了重大影响，云服务提供商接管了许多基础设施管理任务，企业只需通过接口进行管理，无需深入了解底层配置。这使得传统运维人员的需求减少，许多企业选择将运维工作外包给云服务提供商。

同时，平台即服务（PaaS）提供了更高层次的抽象，使开发者可以专注于应用开发，这就进一步削弱了运维人员的角色。容器化和编排技术的普及也是一个点，工具如Docker和Kubernetes简化了应用部署和管理。现在还有所谓智能运维（AIOps），通过引入人工智能和机器学习，实现更智能的监控、分析和预测功能，使运维工作更加自动化和智能化。

反驳1：自动化工具的普及

虽然自动化工具的普及减少了许多手动操作，但这并不意味着运维人员的价值降低了。相反，运维人员的角色变得更加重要，因为他们至少需要设计、管理和维护这些自动化系统。自动化工具只是帮助提高效率和减少错误，但必须有人确保这些工具正确配置并且适应不断变化的需求。

反驳2：DevOps文化的兴起

DevOps文化强调的是开发与运维的协作，而不是取代运维。运维人员在DevOps团队中扮演着关键角色，提供专业的运维知识和经验，确保系统的可靠性和性能，假设干掉运维，那余下的基础设施只有一条路 - 熵增。

反驳3：云计算的广泛应用

云计算虽然简化了一些基础设施管理任务，但它也带来了新的复杂性。运维人员需要具备云架构、成本管理和安全管理的专业知识。云服务的使用不仅需要部署和管理，还需要优化和监控，以确保系统的高效运行和安全性，可以这么说：运维人员的技能需求更加多样化和高级化，而不是被削弱。

反驳4：平台即服务（PaaS）

PaaS 虽然提供了更高层次的抽象，但他们依旧需要管理平台的底层基础设施，确保平台的可用性、扩展性和安全性。

反驳5：容器化和编排技术

容器化和编排技术（如Docker和Kubernetes）确实简化了应用部署和管理，但这也需要专业的运维技能来设计和维护容器架构，让开发写 yaml？可能是神话故事吧 ... 除此之外，运维还需要管理容器的生命周期、优化性能、确保安全性，并处理复杂的分布式系统问题。

反驳6：智能运维（AIOps）

AIOps通过引入人工智能和机器学习，提高了运维的自动化和智能化水平，但它并不能完全取代运维人员的工作（现阶段看起来更多像是一个概念，落地遥遥无期，它只能做一些工具安装配置、负载均衡、监控、告警之类，像运维体系建设等高层面任务 AIOps 很难做好）。运维人员还需要解释和分析智能工具提供的数据和建议，来做出最终决策。

或者再直白一点，目前的 AIOps 几乎就是专家系统做了智能告警集、指标、检测设备状态等等，集合大量数据之后做一些可观测性啊、预测啊、告警啊、分析之类，对于大厂来说锦上添花，对于小厂来说乏善可陈（因为没数据），我短期内不看好 AIOps 的落地效果。

当然以上只是我的看法，我虽然不是运维岗，但实际工作内容和运维团队打交道的频率极高。在我看来，运维并没有衰落，而是正在经历转型和进化，技术栈也变得更加复杂和多样化；运维人员的角色和技能要求在不断提升，他们在确保系统的稳定性和安全性方面永远不可或缺。唱衰运维的论调忽略了运维领域的实际需求和不断演变的挑战。远的不说，腾讯云、阿里云、滴滴大规模宕机也没多久吧，忽视运维只会让类似的事故越来越多。

如果硬要说衰落，那只能说是传统的运维岗逐渐式微，毕竟大部分公司不一定需要能调整 SpamAssassin、postfix、ClamAV，也不一定需要一批掌握服务器、交换机、存储硬件设备的人，但是他们一定需要那些具备云服务管理、容器化和编排、自动化工具应用等现代技术的运维人员。

现代运维的核心职责和竞争力

现代运维的核心职责包括管理和维护系统基础设施、自动化和配置管理、安全管理、云服务管理、容器化和编排、持续集成和持续部署（CI/CD）、监控和日志管理，以及技术支持和用户服务等，虽然技术可能发生进化，但面对的依旧是大而杂的工作。

技术角度全网已经讨论的足够多了，我们可以换个角度看，运维团队、测试团队、安全团队这些都属于跨职能团队型组织，这类组织通过整合不同领域的专业知识和技能，来增强企业整体的协同能力和问题解决能力。想要获得高竞争力，那跨职能团队型组织就需要在以下节点发力：

高效协作：整合来自不同领域的专业知识，实现更高效的协作，运维、测试、安全等团队成员可以实时交流和共享信息，快速响应和解决问题，减少沟通障碍和流程瓶颈。

敏捷开发：通过跨职能团队的紧密合作，企业需要实现更敏捷的开发和运维流程；持续集成和持续部署（CI/CD）流水线的实现，使得代码从开发到部署的周期大大缩短，提高了产品的发布速度和质量；针对流水线和 CICD做优化、发布版本时的流程优化都算在这一点内。

全面安全：与安全团队合作，在各个阶段提供安全实践和监控，确保系统和数据的安全性；通过提前介入和持续监控，能够更有效地识别和防范潜在的安全威胁。

全面测试：与测试团队合作，设计和执行全面的测试计划，通过自动化测试和持续测试，确保代码在不同环境下的稳定性和性能，减少生产环境中的故障和问题。

综合优化：从整体上优化系统的性能和资源利用（当然老板更看重成本，例如你能把云上成本干掉30%也是竞争力之一）。运维、开发、产品、测试团队需要共同分析系统的运行情况，提出优化方案和改进措施，提升系统的效率和用户体验。

举个例子

前面说到运维团队要负责的工作是大而杂，举个例子吧：

云平台技术选型这里坑比较多，我们知道现在云服务竞争激烈，各家技术栈和产品都是一页装不下，各种API、SDK和配套工具令人眼花缭乱。因此，要么需要经验老道的运维专家，要么需要有专职人员来做出正确决策，选择一套满足需要的云服务，并且负责编写工具，整合所有采购来的云服务，供业务开发使用。这种角色就叫做平台工程师，大厂有专人，小厂一般就是运维专家来做这件事，他负责评估、采购、整合各种云服务，作为自身的基础设施，并在外部云服务基础上构建自己的平台，让开发工程师能够在其上自助服务，将自己的代码投入生产。

做这件事的时候需要将“外包”基础设施整合成一个统一的好用的平台，提供一致的接口或工具集；还需要在这个平台上自主搭建和管理运行环境；同时为了减轻自身工作量，减少开发对运维团队的依赖，这个平台还需要提供一部分自助服务工具；最重要的是，将成本和开发周期最小化，也就是说运维团队（平台工程师）需要通过采购整合的方式让企业快速获得高效的计算资源，而无需从头开始搭建和维护平台。

诸位看官，你们说，如果没有运维，就这么一件事要搞多久？

还记得在上家公司工作时，运维负责人排查了一次云服务成本，简单的根据他的经验做了些优化，把GCP、AWS、Azure三朵云 + confluence、jira、slack等等平台总成本优化掉了20%以上，做这件事的时候，没有运维的话谁来干呢?

题外话：DevOps vs SRE

在我看来，DevOps 文化更适合那些需要管理大量基础设施的公司，这些公司的DevOps团队需要自动化、测试和做很多运营工作，他们不止使用配置管理、虚拟化和容器技术，还会涉及到机房硬件、数据中心设计等等。但是在小公司基础设施不太多，云上工作为主时，DevOps 还有必要吗？我认为是没啥必要了...中小型公司把业务做好即可，运维全力保障稳定性是最优选择。

而 SRE（站点可靠性工程）呢？SRE 通常嵌入在研发团队或产品团队中，专注于可靠性，因此相对 DevOps 文化的运维团队来说，SRE 一般不太进行基础设施管理或自动化操作，他们的优势是监控、可观测性和跨职能协调有很多解决方案。SRE 主要负责事故响应和无责回顾，如果一家公司同时拥有 DevOps 团队和 SRE，我通常会看到 SRE 团队更多地参与一线工作，处理事故、监控等，而 DevOps 团队则更多地在后台处理基础设施工作。

再多说几句，在当前技术环境的快速演变中，DevOps 虽然依然具有重要性，但其角色和功能正在逐渐被新的模式和理念所取代，或者说现在正在进入后 DevOps 时代，云原生架构的普及、平台工程的兴起、DevOps 流程和工具傻瓜化、SRE 方法论的普及都在加速后 DevOps 时代的进程。许多原本属于 DevOps 职责范围的任务，如服务器配置、环境维护等，现在可以通过云服务提供商（外包）的平台自动管理，这减少了对传统 DevOps 角色的需求，使得 DevOps 需要适应更高层次的策略和自动化管理。

总结

尽管面临自动化工具、云计算、DevOps 文化等技术变革的冲击，运维并未且永远不会衰落，只是在转型和进化（运维兄弟们还是要终身学习哦）。运维团队在现代企业中仍然扮演着不可或缺的角色，通过管理和维护系统基础设施、自动化和配置管理、安全管理等工作，确保系统的稳定性和安全性。而跨职能团队的高效协作和综合优化能力，使得运维在确保系统可靠性和提高企业整体协同能力方面，依然具有重要竞争力。