云原生时代到来后，运维势必面临着转型的机遇和挑战。以下，是CH运维团队的转型思考和实践。
要点简述
- 传统运维，职责是将工业制成品组装成服务、交付给用户，并维持服务运转；特点是强依附于业务
- 领域危机，云原生时代公有云大量使用、微服务架构和DevOps真实达成、工具体系持续繁荣，传统运维的职责不断被外包、转移、替代，出现了领域危机
- 组织结构，由横转纵，协作方式从人人协同、逐渐升级为平台自助，运维的主旋律从横向协同、转变为服务产品和技术中台
- 领域模型，以运维对象同构维持为基础，向上支撑对象、场景层的运维服务化体系(OPaS)，做到可持续的高技术杠杆，这就转型后的运维领域模型
- 业务运维，服务化转型的核心是角色认知，运维人要把自己从依附于业务的运营角色、调整为独立的运维服务提供方；在超服务视角上，业务运维大有可为
- 组件运维，掌控组件本身、比纯运维管理更进一步，遵循洋葱模型，即立足于资源交付、建设管理平台、再深入到组件自身的专业领域
- 运维开发，剥离掉重复的平台迭代工作，聚焦到公共的运维中台，做专技术、做高杠杆
运维阶段
互联网运维，先后经历了纯手工、标准化、平台化、数智化等几个阶段，如下图。其中，DevOps是技术驱动的组织变革、非专业变革。
从运维的发展历史，我们可以看到几个特点：
- 继承性。新阶段往往继承、发扬老阶段的优秀经验，又会在理念、技术、组织上有所创新
- 比如，平台化继承、强化了标准化阶段的成果，数智化继承了平台化的成果、同时引入大数据技术
- 职责转移。DevOps是运维管理模式的分水岭，DevOps之后的运维
- 一方面，沿着运维专业化的方向继续推进，对更高量级的运维对象、保持同构管理的能力
- 另一方面，则强调运维研发融合，运维职责逐步转移到业务研发
学习某个领域的发展历史，能够让我们以史为鉴、顺势而为。
传统运维
在传统的运维模式中，服务对象基本可以划分为三层。最底层是硬件基础设施IaaS，主要是计算、网络、存储构成；中间层是软件基础设施，包括了操作系统、虚拟化技术、代码框架、中间件等；最上层是业务层，主要是应用服务。
传统运维的职责是，通过一系列的流程、技术、方法，将工业制成品组装成服务、交付给用户，并维持服务运转；通常要求达成稳定、成本、安全、效率等多个维度的目标(运营性)。从某种程度上来讲，传统运维需要依附于业务才能产生价值；很多公司，会把是否理解业务、作为运维工作者的主要考核之一(依附性)。
随着云计算、云原生技术的普及，传统的运维模式遇到了很多挑战。比如，
- 企业使用公有云后，IaaS/PaaS甚至SaaS基本都服务化了，通过API即可获取；大量的运维建设工作、由云厂商帮忙完成了，比如硬件、系统、网络、数据库、大数据等，原厂只需要保留少量的专业选型和集成能力(外包)
- 云原生技术普及后，微服务架构和DevOps大范围达成，之前由专业运维人员完成的操作、逐步交给业务研发自助完成，比如交付、变更、监控、容量等，运维职责被大量转移到业务研发(转移)
- 公有云的专业聚集效应、以及云原生的开源体系，提供了持续向好的工具化前景。工具化提升效率后，同一岗位需要的人工变少；工具化沉淀了专业能力，对操作人员的技术门槛越来越低；工具进化到自动化、智能化后，机器就可以替代人工。平台对人工的替代，还在逐步深化(替代)
上面讲到的，基础设施外包给公有云、云原生之后运维职责转移给业务研发、平台替代人工的专业性。面对这样的趋势、事实，运维从业者需要做出一些转型。
组织结构
首先聊聊组织结构。长期看，云原生时代的公司组织形态，由如下几部分构成：
最上面的终端用户，是企业的甲方客户、也是潜在的营利人群。业务团队，为终端用户负责，角色包括了产品、商务、市场、营销等。业务研发，直接为业务团队服务，主要是提供SaaS化的应用/服务。平台研发，则是为业务研发服务，提供各种各样的PaaS化能力，对下封装了云厂商。还会有一些跨功能组织，如稳定性运营GOC、效率运营EP、成本运营FinOps、行政团队IT等等。
在新的组织结构中，大家最终的目标是各司其事、服务好终端用户。业务团队更关注业务价值，研发体系聚焦在服务质量。随着信息化技术的进步，当前由跨功能组织(横向)履行的职能、将逐步分解到平台研发团队(纵向)，组织协作的主要方式从人人协同、升级为平台自助。运维有了新的岗位目标，即：运维的主旋律是管理平台、是资源&技术中台、不是横向协同，运维要做高技术杠杆、赋能业务、助力企业提升经营效率。BTW，效率才是推动行业发展的动力，质量、成本、安全不是。
技术架构
运维转型，目标是：通过自助化的平台，向上层团队、提供运维管理服务；本质是运维服务化OPaS(OP as Service)。按照内容差异，运维工作可以分为对象管理、场景管理两大类，如下图所示。
对象管理是纵向模式，围绕运维对象、建设生命周期的管理平台。运维对象的分类，可以按照IaaS资源(机器、网络、存储、云服务)、PaaS组件(数据库、缓存、MQ、网关)、SaaS应用(业务中台、业务应用)、服务框架(运行时、代码框架、名字服务)等维度，不同公司的分类粒度不尽相同。每类对象都有独立的管理平台(烟囱)，管理平台功能要覆盖运维对象的完整生命周期，关键阶段包括 建模(元数据)、交付/变更、监控/度量、下线等，跟公有云的管理功能类似。对象管理的目标是，产出纵向完备的云产品、建成内部云平台ICSP。
场景管理是横向模式，根据运维场景、纳管多种运维对象的生命周期阶段。运维场景的分类，包括交付/变更、监控/度量、多云、成本等等，非常贴近业务研发的工作习惯、覆盖少数高频场景，不同公司大同小异。每类运维场景，有独立的场景管理平台，如工单中心、数据中心、FinOps平台等。场景管理建立在对象管理之上，场景管理平台对运维对象的纳管方式包括 统一模型、汇聚数据、编排管控API等。场景管理的目标是，提供自助化的业务管理能力、建成内部开发者平台IDP。
运维对象的产生方式，常见的有 自研、开源搭建、外采(公有云)等。每种运维对象，又能再细分出不同的品类、集群、实例等，规模和复杂度空前巨大。只有维持运维对象管理特征的同构，才能大规模建设、低成本维持运维服务化，进而实现规模运维(技术杠杆效应)，因此运维对象的同构维持是整个运维架构的基本前提。
同构维持
同构维持，针对的是运维对象的管理特征、不是所有特征。同构维持，方式是：控增量、修存量、防裂变。如下图，通过平台做需求交付、来控增量，通过度量驱动治理、来修存量，通过规范服务框架、来防止技术体系的大范围裂变；平台、度量严格遵循规范，规范也需要度量或平台的问题输入来完善，三者相辅相成。规范，分为服务规范(对应服务治理)、管理规范(对应运维管控)等类型。
同构维持，依赖主责明确的组织分工。比如，运维专注于管理，剥离业务Toils、将之返还给业务研发，如现状治理、报警响应、CD；业务研发专注于业务实现，剥离服务框架这部分非业务逻辑、将之交给基础架构实现，如服务发现、流量控制；基础架构专注于服务框架等中台能力，剥离管理职能、将之交给运维，如需求交付、变更管控等。文化影响也不能忽视，运维和架构会通过沟通引导的方式，输出理念、培养用户习惯，如对个性化需求不提供SLA承诺、对标准应用提供开箱即用的观测能力等。
领域模型
运维转型，目标是探索出新的领域模型。以运维对象同构维持为基础，向上支撑对象、场景层的运维服务化体系(OPaS)，做到可持续的高技术杠杆，这就是新的运维领域模型。在当前的技术水平下，以自助平台为主的运维服务能解决70%的需求、剩余30%仍需要人工，比如需求沟通、问题排查、结果验收、政策合规等。随着技术和理念的进步，相信运维服务化的占比将进一步上升。
备注：本文中的服务框架，既包括N年前的代码框架、代码库，也包括当前流行的微服务治理，过渡阶段、起名捉急。
转型实践
运维服务化OPaS
业务运维，也有人叫应用运维，离云原生最近、被冲击的最大。除却传统的规范制定、流程建设、全局管理等跨团队职责外，业务运维要朝着服务化的方向转型，路径如下图：
- 第一，角色认知要转变。把自己从依附于业务才能产生价值的运营角色，调整为具有独立价值的运维服务提供方。角色转变是关键
- 组织上，重新划分主责。业务研发是应用主责方，运维不是应用主责方、也不是外挂式保姆，而是应用的管理能力提供方，业务研发使用运维服务、自助完成运营工作
- 机制上，重构评价体系。业务运维岗位的绩效，不再强绑定业务团队和业务研发、而是更突出运维服务化，做轻主观评价、做重技术评价
- 第二，运维转型四步走。明确对象 –> 抽象共性 –> 建设平台 –> 实现规模运维
- 业务运维的对象，首先是应用(也称为服务)，然后是应用的扩展场景(如业务视角、公司全局视角)
- 抽象共性是难点，也是关键点。应用的数量大、技术栈复杂、个性化特征非常多，要抽象出应用的管理共性、避免陷入个性化case。严格来说，应用的共性特征才是运维管理的对象
- 建设平台指的是应用管理平台，规模运维是一个可持续的终态
- 第三，应用对象维持同构。除去服务化能力建设外，运维人员的主要精力应该投在同构维持上
运维服务化OPaS(OP as Service)，是我们转型中期、从业务运维角度提出的目标，指出了大方向、但缺少路径比较抽象；之后，OPaS逐渐被细化为 ICSP+IDP 的运维架构，适用范围扩展到整个运维团队，才算有了清晰的路径和抓手。
超服务视角(业务运维)
除了服务化，业务运维还可以主导超服务视角(现已更名为场景)建设。云原生下的DevOps技术拼图并不完整，只搞好了应用+计算这一块、其它方向存在能力空白，特别是向上的业务视角、部门视角、公司视角等，姑且称为超服务视角。对于超服务视角，业务研发人员通常没有能力、没有动力主R(主责)；部门主管或架构师可以照顾到本部门，但受限于岗位职责、很难扩展到全局。反观，超服务视角是传统业务运维的老战场，具备无与伦比的体验、理解和认知优势。业务运维主导超服务视角建设，既能添补云原生领域的空白、又能发挥业务运维的专业优势、借势转型，会是一个双赢的选择，如下图。
超服务视角，包括但不限于：
- 需求交付：工单中心，编排引擎、执行引擎
- 变更管控：五条军规、集中管控，编排审批、执行审批、服务检查、变更度量
- 观察度量：聚合展示业务视角的观测、度量数据，支持下钻到应用粒度
- 多云架构：贯穿整个技术体系的度量、治理、预案、演练
- 成本管控：公司全部IT资源的计费、分摊、管控、优化，独立为FinOps方向
- 规范制定：公司全局角度的运维规范制定、流程落地监督，避免小团队烟囱式重复建设
- 等等
云原生下的DevOps技术拼图，向下看也有能力空白，如针对CDN、对象存储、MQ、EMR等基础服务支持的并不完善，2022年还处在探索期；站在运维管理角度，只要被服务框架(鉴权、发现、通信、感知、流控)辐射到了，就算被云原生纳管了。
洋葱模型(云服务、中间件、大数据运维)
云服务、中间件、大数据等运维对象，技术栈收敛、专业聚焦。运维人员转型实施时，可以按照洋葱模型来。
- 第一阶段，立足于资源交付，把原来的运维对象、转变为资源实体，向上游交付有保障的服务功能、建立岗位价值的底线
- 第二阶段，投入大精力、建设服务管理，主要是外在特征管理，如运维管理平台化、组件融入服务治理
- 第三阶段，深入到组件自身的专业领域，从功能、架构、性能、成本、代码等方方面面加深组件理解，成为领域技术专家、产品架构师
洋葱模型，最早在数据库、大数据、中间件等岗位上被验证，后来被拿过来用到云服务上、同样成功了。比如，我司的云服务运维CloudOps团队，就是按照洋葱模型、来实施转型的，具体如下，
- 这个团队的对象就是各种云服务，分布在腾讯、阿里、百度等几家云厂商
- 两年前，通过各种手工的方式，对外提供机器、存储等资源，支撑了业务的快速发展(资源交付)
- 之后，我们开始建设多云管理平台，管理机器、带宽、对象存储、CDN等云服务的生命周期。在这个过程中，CloudOps的管理平台成功转型为公司内部的二级云服务提供商ICSP(服务管理)
- 接下来，我们还会不断加强对公有云产品的学习、认知、选型、演化推动等等，争取在这个领域建立更多的专业性(组件自身)
值得注意的是，开源二开或全自研的组件模式、经常能造就技术专家(深度见长)，外采云服务的模式则更能成就产品架构师(广度见长)。
运维中台(运维开发)
随着业务运维、组件运维、系统运维(资源网络云服务)等角色开始参与开发工作，留给运维开发DevOps团队的空间逐渐变少，转型过程中出现了分工不清晰的情况。参照组织结构、技术架构的升级预判，我们重新调整了OpDev的岗位定位：OpDev不应该是运维人员的开发外包或附庸、而应该有自己独立提供的服务。于是乎，原有的运维平台被拆分成了两部分，一部分偏重功能迭代无法复用、交给原使用方自己维护，比如IDP资源控制台、ICSP场景管理工具等；另一部分是公共功能、抽象为运维中台由OpDev负责，如统一账号IAM、工单编排引擎、监控指标采集器等，如下图。
运维中台是原运维平台的子集，不需要重新构建领域知识，需要重新做一下领域抽象建模、对代码质量要求也比较高(同基础组件)，这正是OpDev童鞋的长处所在。随着职责的聚化缩减，OpDev要同步瘦身、做到更高的杠杆。
一些依赖
组织转型是系统工程，往往需要多方面的依赖。以下是一些显而易见的事项，
- 组织高层认可。高效而彻底的转型，通常依赖组织的力量、自上而下强权推进，在不违背公司文化的前提下，首先需要得到技术一号位的理解认可，其次需要来自技术中高层的有限配合
- 人员素质升级。协作方要配套的素质提升，比如业务RD，思维模式上要调整到整体意识，技术上除了会开发、还要具备生命周期的运营能力，有时不得不汰换
一些教训
简单分享下我司的一些转型教训，包括
- 转型和保守要折中。传统运维转型到服务提供方，既不会一蹴而就、也不会全员迁徙，总要有人留下来殿后(当前技术水平大概73开)。资源集中后，殿后人员会获得更多的价值回报
- 研发能力区分梯度。从运维转型到开发的童鞋能力参差不齐，要从业务需求迭代做起，要严控设计和验收来保质量、要有意识的补齐工程理论，要配备精良的运维中台能力、保证底层干净
- 平台不是唯一选择。平台是服务能力最有力的承接方式，但绝对不是唯一方式。组织、文化、规范、流程、平台，一样都不能少(但转移成本可能略高)
- 最佳实践不能靠人。运维管理的一个大坑，是平台管理面约束不足的情况下，直接ToRD、或To多个管理员，进而产生大量的不规范
- 明确运维管理对象。运维、特别是应用运维，管理对象不是应用本身、而是应用的共性特征；应用的共性特征越多，应用运维的价值才能越大(杠杆)
- 组织保障不容忽视。组织结构是第一生产力，CTO要有所作为、目标明确、清晰分工，如明确主责、设置独立验收机构、度量和治理循环等，这是运维转型的组织保障
- 警惕纯粹项目思维。运维还是要参与一些项目，短期内爆发价值、揽获成就感，但也很容易人走茶凉、价值归零；需要有意识的设计目标，在项目过程中的沉淀服务能力
- 预防比应急更有效。稳定性问题要在架构领域求解，预防比应急更有效。优先延长MTBF、其次才是缩短MTTR
以下是附加内容，不是本文核心。
跨功能组织分析
本文提到的跨功能组织，是以人人协同为主的运营组织，前期大而不专、后期价值不足。上文中断言，跨功能组织的职能、将逐步分解到平台团队，原因是信息化比人人协同效率更高。
和其它物理事物一样，IT系统遵循熵增定律，通过输入负熵、维持有序，缺少输入、则自发走向无序。从历史发展看，负熵来源先后有过纯人力(手工)、算力辅助人力(机械化)、纯算力(智能化)等几个阶段。信息化的过程，是知识从人转移到平台(固化智力)、负熵从人力转移到算力的过程；虽然前期固化智力的投入较大，但后期算力比人力更具性价比，观察周期越长、信息化的TCO越可观，因此信息化是比人更高效的生产力。
跨功能组织被专业平台团队替代的过程，是信息化战胜人工的过程，也是生产力发展的必然结果。当前的信息化发展水平，还不足以消灭所有跨功能组织，但会大大的削弱之。
DevOps组织分析
DevOps组织中，研发人员通常将开发、测试、运维等多项职责一肩挑，相比之前开发、测试、运维细分部门，DevOps模式是否违背了专业分工的原则呢？NO!
研发人员的主责是通过业务开发、拿到业务绩效，这一点在DevOps组织中并未发生变化。研发人员之所以能够承担测试、运维等之前专业分工的职责，是因为当前有了成熟的自助化平台。在开源、云服务盛行的今天，自助化平台往往是整个领域的知识沉淀、是更大Scope上的专业分工，其专业性远高于公司内部的某个小作坊。
从这个角度看，DevOps是更先进的生产关系，不但打破了部门墙、提升了组织效率，而且遵循和促进了专业分工、有利于技术进步。
需求交付的演进
无论是公有云，还是内部的K8S平台，都存在着大量的需求交付操作。这类ToM(ToManager)的交付平台，往往缺少必要约束、只能对资深人士开放。
为了优化分工、提升效率，可以通过「工单编排+审批」的方式、将运维管理面ToC(ToRD)；工作流/工单本身会大量融入运维管理的最佳实践，可以安全的开放给研发。这是运维能力服务化的一个重要方向。交付自助化的演化路径如下：
目前看，从需求到技术方案的沟通环节，是比较难自助化或者自动化的，需要将来更多的尝试。
规模运维的边际点
规模运维的经济学本质是边际成本，是「运维管理边际成本递减vs同构维持边际成本递增」的相互作用。如下图，运维对象数量较少时，运维管理的成本占大头儿，比如建设平台、人工运营；运维对象数量变大后，同构维持构成主要成本；边际转折点，会受到技术、理念等环境因素的影响。
云原生技术，降低了同构维持难度(促进同构维持曲线右移)、提升了运维服务化能力(促进运维管理曲线下移)，使得运维人员能够以更低的成本、管理更多运维对象，因此显著提升了生产效率。