第1期央请井老板发表了很多有趣的观点，有人留言说是运维劝退指南，哈哈，这一期的嘉宾，观点会有不同，请大家抱着开放的心态，听百家之言，自己做职业、人生规划。所谓兼听则明，偏信则暗，如果只听自己顺耳的，大概率不会有深度思考碰撞，憾事也。

这里是接地气、有高度的《运维百家讲坛》第 2 期，开讲！

嘉宾介绍

本期我们邀请的是作业帮的运维负责人聂安，聂安是资深行业老炮，先后履职于阿里、小米、滴滴、作业帮，有10多年的运维/研发/管理经验。

要点简述

• 传统运维，职责是将工业制成品组装成服务、交付给用户，并维持服务运转；特点是强依附于业务
• 领域危机，云原生时代公有云大量使用、微服务架构和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%仍需要人工，比如需求沟通、问题排查、结果验收、政策合规等。随着技术和理念的进步，相信运维服务化的占比将进一步上升。

备注：本文中的服务框架，既包括N年前的代码框架、代码库，也包括当前流行的微服务治理，过渡阶段、起名捉急。

转型实践

运维服务化OPaS

业务运维，也有人叫应用运维，离云原生最近、被冲击的最大。除却传统的规范制定、流程建设、全局管理等跨团队职责外，业务运维要朝着服务化的方向转型，路径如下图：

• 第一，角色认知要转变。把自己从依附于业务才能产生价值的运营角色，调整为具有独立价值的运维服务提供方。角色转变是关键

• 组织上，重新划分主责。业务研发是应用主责方，运维不是应用主责方、也不是外挂式保姆，而是应用的管理能力提供方，业务研发使用运维服务、自助完成运营工作
• 机制上，重构评价体系。业务运维岗位的绩效，不再强绑定业务团队和业务研发、而是更突出运维服务化，做轻主观评价、做重技术评价

• 第二，运维转型四步走。明确对象 --> 抽象共性 --> 建设平台 --> 实现规模运维
• 业务运维的对象，首先是应用(也称为服务)，然后是应用的扩展场景(如业务视角、公司全局视角)
• 抽象共性是难点，也是关键点。应用的数量大、技术栈复杂、个性化特征非常多，要抽象出应用的管理共性、避免陷入个性化case。严格来说，应用的共性特征才是运维管理的对象
• 建设平台指的是应用管理平台，规模运维是一个可持续的终态
• 第三，应用对象维持同构。除去服务化能力建设外，运维人员的主要精力应该投在同构维持上

运维服务化OPaS(OP as Service)，是我们转型中期、从业务运维角度提出的目标，指出了大方向、但缺少路径比较抽象；之后，OPaS逐渐被细化为 ICSP+IDP 的运维架构，适用范围扩展到整个运维团队，才算有了清晰的路径和抓手。

超服务视角(业务运维)

除了服务化，业务运维还可以主导超服务视角(现已更名为场景)建设。云原生下的DevOps技术拼图并不完整，只搞好了应用+计算这一块、其它方向存在能力空白，特别是向上的业务视角、部门视角、公司视角等，姑且称为超服务视角。对于超服务视角，业务研发人员通常没有能力、没有动力主R(主责)；部门主管或架构师可以照顾到本部门，但受限于岗位职责、很难扩展到全局。反观，超服务视角是传统业务运维的老战场，具备无与伦比的体验、理解和认知优势。业务运维主导超服务视角建设，既能添补云原生领域的空白、又能发挥业务运维的专业优势、借势转型，会是一个双赢的选择，如下图。

超服务视角，包括但不限于：

• 需求交付：工单中心，编排引擎、执行引擎
• 变更管控：五条军规、集中管控，编排审批、执行审批、服务检查、变更度量
• 观察度量：聚合展示业务视角的观测、度量数据，支持下钻到应用粒度
• 多云架构：贯穿整个技术体系的度量、治理、预案、演练
• 成本管控：公司全部IT资源的计费、分摊、管控、优化，独立为FinOps方向
• 规范制定：公司全局角度的运维规范制定、流程落地监督，避免小团队烟囱式重复建设
• 等等

云原生下的DevOps技术拼图，向下看也有能力空白，如针对CDN、对象存储、MQ、EMR等基础服务支持的并不完善，2022年还处在探索期；站在运维管理角度，只要被服务框架(鉴权、发现、通信、感知、流控)辐射到了，就算被云原生纳管了。

洋葱模型(云服务、中间件、大数据运维)

云服务、中间件、大数据等运维对象，技术栈收敛、专业聚焦。运维人员转型实施时，可以按照洋葱模型来。

• 第一阶段，立足于资源交付，把原来的运维对象、转变为资源实体，向上游交付有保障的服务功能、建立岗位价值的底线
• 第二阶段，投入大精力、建设管理平台，把资源实体的生命周期管理好、解放自己，平台要能ToC自助化、实现解耦
• 第三阶段，深入到组件自身的专业领域，从架构、代码、性能、运维等方方面面提升专业性。做到这一步时，运维已经成为该领域的服务专家、而不仅仅是管理员

洋葱模型，最早在数据库、大数据、中间件等岗位上被验证，后来被拿过来用到云服务上、同样成功了。比如，我司的云服务运维CloudOps团队，就是按照洋葱模型、来实施转型的，具体如下，

• 这个团队的对象就是各种云服务，分布在腾讯、阿里、百度等几家云厂商
• 两年前，通过各种手工的方式，对外提供机器、存储等资源，支撑了业务的快速发展(资源交付)
• 之后，我们开始建设多云管理平台，管理机器、带宽、对象存储、CDN等云服务的生命周期。在这个过程中，CloudOps的管理平台成功转型为公司内部的二级云服务提供商ICSP(平台能力)
• 接下来，我们还会不断加强对公有云产品的学习、认知、选型、演化推动等等，争取在这个领域建立更多的专业性(组件自身)

运维中台(运维开发)

随着业务运维、组件运维、系统运维(资源网络云服务)等角色开始参与开发工作，留给运维开发DevOps团队的空间逐渐变少，转型过程中出现了分工不清晰的情况。参照组织结构、技术架构的升级预判，我们重新调整了OpDev的岗位定位：OpDev不应该是运维人员的开发外包或附庸、而应该有自己独立提供的服务。于是乎，原有的运维平台被拆分成了两部分，一部分偏重功能迭代无法复用、交给原使用方自己维护，比如IDP资源控制台、ICSP场景管理工具等；另一部分是公共功能、抽象为运维中台由OpDev负责，如统一账号IAM、工单编排引擎、监控指标采集器等，如下图。

运维中台是原运维平台的子集，不需要重新构建领域知识，需要重新做一下领域抽象建模、对代码质量要求也比较高(同基础组件)，这正是OpDev童鞋的长处所在。随着职责的聚化缩减，OpDev要同步瘦身、做到更高的杠杆。

一些教训

简单分享下我司的一些转型教训，包括

• 转型和保守要折中。传统运维转型到服务提供方，既不会一蹴而就、也不会全员迁徙，总要有人留下来殿后(当前技术水平大概73开)。资源集中后，殿后人员会获得更多的价值回报
• 研发能力区分梯度。从运维转型到开发的童鞋能力参差不齐，要从业务需求迭代做起，要严控设计和验收来保质量、要有意识的补齐工程理论，要配备精良的运维中台能力、保证底层干净
• 平台不是唯一选择。平台是服务能力最有力的承接方式，但绝对不是唯一方式。组织、文化、规范、流程、平台，一样都不能少(但转移成本可能略高)
• 明确运维管理对象。运维、特别是应用运维，管理对象不是应用本身、而是应用的共性特征；应用的共性特征越多，应用运维的价值才能越大(杠杆)
• 组织保障不容忽视。组织结构是第一生产力，CTO要有所作为、目标明确、清晰分工，如明确主责、设置独立验收机构、度量和治理循环等，这是运维转型的组织保障
• 警惕纯粹项目思维。运维还是要参与一些项目，短期内爆发价值、揽获成就感，但也很容易人走茶凉、价值归零；需要有意识的设计目标，在项目过程中的沉淀服务能力
• 预防比应急更有效。稳定性问题要在架构领域求解，预防比应急更有效。优先延长MTBF、其次才是缩短MTTR

以下是附加内容，不是本文核心。

需求交付的演进

无论是公有云，还是内部的K8S平台，都存在着大量的需求交付操作。这类ToM(ToManager)的交付平台，往往缺少必要约束、只能对资深人士开放。

为了优化分工、提升效率，可以通过「工单编排+审批」的方式、将运维管理面ToC(ToRD)；工作流/工单本身会大量融入运维管理的最佳实践，可以安全的开放给研发。这是运维能力服务化的一个重要方向。交付自助化的演化路径如下：

目前看，从需求到技术方案的沟通环节，是比较难自助化或者自动化的，需要将来更多的尝试。

规模运维的边际点

规模运维的经济学本质是边际成本，是「运维管理边际成本递减vs同构维持边际成本递增」的相互作用。如下图，运维对象数量较少时，运维管理的成本占大头儿，比如建设平台、人工运营；运维对象数量变大后，同构维持构成主要成本；边际转折点，会受到技术、理念等环境因素的影响。

云原生技术，降低了同构维持难度(促进同构维持曲线右移)、提升了运维服务化能力(促进运维管理曲线下移)，使得运维人员能够以更低的成本、管理更多运维对象，因此显著提升了生产效率。