运维人如何转型？

程序员-老K

于 2024-10-08 13:46:08 发布

阅读量1k

点赞数 16

文章标签：运维 java 开发语言 web安全前端 linux 网络安全

本文链接：https://blog.csdn.net/weixin_57514792/article/details/142757636

版权

要点简述

传统运维，职责是将工业制成品组装成服务、交付给用户，并维持服务运转；特点是强依附于业务
领域危机，云原生时代公有云大量使用、微服务架构和DevOps真实达成、工具体系持续繁荣，传统运维的职责不断被外包、转移、替代，出现了领域危机
组织结构，协作方式从人人协同、逐渐升级为平台自助，运维的主旋律从横向协同、转变为服务产品和技术中台
运维转型，技术上通过自助化的平台、对外提供运维服务能力OPaS(OP as Service)，分成对象、场景两层；底层对象做到同构维持，就构成了一套可持续的运维架构
业务运维，服务化转型的核心是角色认知，运维人要把自己从依附于业务的运营角色、调整为独立的运维服务提供方；在超服务视角上，业务运维大有可为
组件运维，掌控组件本身、比纯运维管理更进一步，遵循洋葱模型，即立足于资源交付、建设管理平台、再深入到组件自身的专业领域
运维开发，剥离掉重复的平台迭代工作，聚焦到公共的运维中台，做专技术、做高杠杆

运维阶段

互联网运维，先后经历了纯手工、标准化、平台化、数智化等几个阶段，如下图。其中，DevOps是技术驱动的组织变革、非专业变革。

从运维的发展历史，我们可以看到几个特点：

继承性。新阶段往往继承、发扬老阶段的优秀经验，又会在理念、技术、组织上有所创新
比如，平台化继承、强化了标准化阶段的成果，数智化继承了平台化的成果、同时引入大数据技术
职责转移。DevOps是运维管理模式的分水岭，DevOps之后的运维
一方面，沿着运维专业化的方向继续推进，对更高量级的运维对象、保持同构管理的能力
另一方面，则强调运维研发融合，运维职责逐步转移到业务研发

学习某个领域的发展历史，能够让我们以史为鉴、顺势而为。

传统运维

在传统的运维模式中，服务对象基本可以划分为三层。最底层是硬件基础设施IaaS，主要是计算、网络、存储构成；中间层是软件基础设施，包括了操作系统、虚拟化技术、代码框架、中间件等；最上层是业务层，主要是应用服务。

传统运维的职责是，通过一系列的流程、技术、方法，将工业制成品组装成服务、交付给用户，并维持服务运转；通常要求达成稳定、成本、安全、效率等多个维度的目标(运营性)。从某种程度上来讲，传统运维需要依附于业务才能产生价值；很多公司，会把是否理解业务、作为运维工作者的主要考核之一(依附性)。

随着云计算、云原生技术的普及，传统的运维模式遇到了很多挑战。比如，

企业使用公有云后，IaaS/PaaS甚至SaaS基本都服务化了，通过API即可获取；大量的运维建设工作、由云厂商帮忙完成了，比如硬件、系统、网络、数据库、大数据等，原厂只需要保留少量的专业选型和集成能力(外包)
云原生技术普及后，微服务架构和DevOps大范围达成，之前由专业运维人员完成的操作、逐步交给业务研发自助完成，比如交付、变更、监控、容量等，运维职责被大量转移到业务研发(转移)
公有云的专业聚集效应、以及云原生的开源体系，提供了持续向好的工具化前景。工具化提升效率后，同一岗位需要的人工变少；工具化沉淀了专业能力，对操作人员的技术门槛越来越低；工具进化到自动化、智能化后，机器就可以替代人工。平台对人工的替代，还在逐步深化(替代)

上面讲到的，基础设施外包给公有云、云原生之后运维职责转移给业务研发、平台替代人工的专业性。面对这样的趋势、事实，运维从业者需要做出一些转型。

组织结构

首先聊聊组织结构。长期看，云原生时代的公司组织形态，由如下几部分构成：

最上面的终端用户，是企业的甲方客户、也是潜在的营利人群。业务团队，为终端用户负责，角色包括了产品、商务、市场、营销等。业务研发，直接为业务团队服务，主要是提供SaaS化的应用/服务。平台研发，则是为业务研发服务，提供各种各样的PaaS化能力，对下封装了云厂商。还会有一些跨功能组织，如成本运营FinOps、效率运营EP、行政团队IT等等。

在新的组织结构中，大家最终的目标是各司其事、服务好终端用户。业务团队更关注业务价值，研发体系聚焦在服务质量。随着信息化技术的进步，当前由跨功能组织履行的职能、将逐步分解到平台研发团队，组织协作的主要方式从人人协同、升级为平台自助。运维有了新的岗位目标，即：运维的主旋律是管理平台、是资源&技术中台，不是横向协同，运维要做高技术杠杆、赋能业务、助力企业提升经营效率。

技术架构

运维转型，目标是：通过自助化的平台，向上层团队、提供运维管理服务；本质是运维服务化OPaS(OP as Service)。按照内容差异，运维工作可以分为对象管理、场景管理两大类，如下图所示。

对象管理是纵向模式，围绕运维对象、建设生命周期的管理平台。运维对象的分类，可以按照IaaS资源(机器、网络、存储、云服务)、PaaS组件(数据库、缓存、MQ、网关)、SaaS应用(业务中台、业务应用)、服务框架(运行时、代码框架、名字服务)等维度，不同公司的分类粒度不尽相同。每类对象都有独立的管理平台(烟囱)，管理平台功能要覆盖运维对象的完整生命周期，关键阶段包括建模(元数据)、交付/变更、监控/度量、下线等，跟公有云的管理功能类似。对象管理的目标是，产出纵向完备的云产品、建成内部云平台ICSP。

场景管理是横向模式，根据运维场景、纳管多种运维对象的生命周期阶段。运维场景的分类，包括交付/变更、监控/度量、多云、成本等等，非常贴近业务研发的工作习惯、覆盖少数高频场景，不同公司大同小异。每类运维场景，有独立的场景管理平台，如工单中心、数据中心、FinOps平台等。场景管理建立在对象管理之上，场景管理平台对运维对象的纳管方式包括统一模型、汇聚数据、编排管控API等。场景管理的目标是，提供自助化的业务管理能力、建成内部开发者平台IDP。

运维对象的产生方式，常见的有自研、开源搭建、外采(公有云)等。每种运维对象，又能再细分出不同的品类、集群、实例等，规模和复杂度空前巨大。只有维持运维对象管理特征的同构，才能大规模建设、低成本维持运维服务化，进而实现规模运维(技术杠杆效应)，因此运维对象的同构维持是整个运维架构的基本前提。

同构维持

同构维持，针对的是运维对象的管理特征、不是所有特征。同构维持，方式是：控增量、修存量、防裂变。如下图，通过平台做需求交付、来控增量，通过度量驱动治理、来修存量，通过规范服务框架、来防止技术体系的大范围裂变；平台、度量严格遵循规范，规范也需要度量或平台的问题输入来完善，三者相辅相成。规范，分为服务规范(对应服务治理)、管理规范(对应运维管控)等类型。

同构维持，依赖主责明确的组织分工。比如，运维专注于管理，剥离业务Toils、将之返还给业务研发，如现状治理、报警响应、CD；业务研发专注于业务实现，剥离服务框架这部分非业务逻辑、将之交给基础架构实现，如服务发现、流量控制；基础架构专注于服务框架等中台能力，剥离管理职能、将之交给运维，如需求交付、变更管控等。文化影响也不能忽视，运维和架构会通过沟通引导的方式，输出理念、培养用户习惯，如对个性化需求不提供SLA承诺、对标准应用提供开箱即用的观测能力等。

以运维对象同构维持为基础，向上支撑运维服务化技术体系，这就形成了一套可持续的运维架构，如下图。在当前的技术水平下，以自助平台为主的运维服务能解决70%的需求、剩余30%仍需要人工，比如需求沟通、问题排查、结果验收、政策合规等。随着技术和理念的进步，相信运维服务化的占比将进一步上升。