第1期央请井老板发表了很多有趣的观点，有人留言说是运维劝退指南，哈哈，这一期的嘉宾，观点会有不同，请大家抱着开放的心态，听百家之言，自己做职业、人生规划。所谓兼听则明，偏信则暗，如果只听自己顺耳的，大概率不会有深度思考碰撞，憾事也。
这里是接地气、有高度的《运维百家讲坛》第 2 期，开讲！
本期我们邀请的是作业帮的运维负责人聂安，聂安是资深行业老炮，先后履职于阿里、小米、滴滴、作业帮，有10多年的运维/研发/管理经验。
互联网运维，先后经历了纯手工、标准化、平台化、数智化等几个阶段，如下图。其中，DevOps是技术驱动的组织变革、非专业变革。
从运维的发展历史，我们可以看到几个特点：
学习某个领域的发展历史，能够让我们以史为鉴、顺势而为。
在传统的运维模式中，服务对象基本可以划分为三层。最底层是硬件基础设施IaaS，主要是计算、网络、存储构成；中间层是软件基础设施，包括了操作系统、虚拟化技术、代码框架、中间件等；最上层是业务层，主要是应用服务。
传统运维的职责是，通过一系列的流程、技术、方法，将工业制成品组装成服务、交付给用户，并维持服务运转；通常要求达成稳定、成本、安全、效率等多个维度的目标(运营性)。从某种程度上来讲，传统运维需要依附于业务才能产生价值；很多公司，会把是否理解业务、作为运维工作者的主要考核之一(依附性)。
随着云计算、云原生技术的普及，传统的运维模式遇到了很多挑战。比如，
上面讲到的，基础设施外包给公有云、云原生之后运维职责转移给业务研发、平台替代人工的专业性。面对这样的趋势、事实，运维从业者需要做出一些转型。
首先聊聊组织结构。长期看，云原生时代的公司组织形态，由如下几部分构成：
最上面的终端用户，是企业的甲方客户、也是潜在的营利人群。业务团队，为终端用户负责，角色包括了产品、商务、市场、营销等。业务研发，直接为业务团队服务，主要是提供SaaS化的应用/服务。平台研发，则是为业务研发服务，提供各种各样的PaaS化能力，对下封装了云厂商。还会有一些跨功能组织，如成本运营FinOps、效率运营EP、行政团队IT等等。
在新的组织结构中，大家最终的目标是各司其事、服务好终端用户。业务团队更关注业务价值，研发体系聚焦在服务质量。随着信息化技术的进步，当前由跨功能组织履行的职能、将逐步分解到平台研发团队，组织协作的主要方式从人人协同、升级为平台自助。运维有了新的岗位目标，即：运维的主旋律是管理平台、是资源&技术中台，不是横向协同，运维要做高技术杠杆、赋能业务、助力企业提升经营效率。
运维转型，目标是：通过自助化的平台，向上层团队、提供运维管理服务；本质是运维服务化OPaS(OP as Service)。按照内容差异，运维工作可以分为对象管理、场景管理两大类，如下图所示。
对象管理是纵向模式，围绕运维对象、建设生命周期的管理平台。运维对象的分类，可以按照IaaS资源(机器、网络、存储、云服务)、PaaS组件(数据库、缓存、MQ、网关)、SaaS应用(业务中台、业务应用)、服务框架(运行时、代码框架、名字服务)等维度，不同公司的分类粒度不尽相同。每类对象都有独立的管理平台(烟囱)，管理平台功能要覆盖运维对象的完整生命周期，关键阶段包括 建模(元数据)、交付/变更、监控/度量、下线等，跟公有云的管理功能类似。对象管理的目标是，产出纵向完备的云产品、建成内部云平台ICSP。
场景管理是横向模式，根据运维场景、纳管多种运维对象的生命周期阶段。运维场景的分类，包括交付/变更、监控/度量、多云、成本等等，非常贴近业务研发的工作习惯、覆盖少数高频场景，不同公司大同小异。每类运维场景，有独立的场景管理平台，如工单中心、数据中心、FinOps平台等。场景管理建立在对象管理之上，场景管理平台对运维对象的纳管方式包括 统一模型、汇聚数据、编排管控API等。场景管理的目标是，提供自助化的业务管理能力、建成内部开发者平台IDP。
运维对象的产生方式，常见的有 自研、开源搭建、外采(公有云)等。每种运维对象，又能再细分出不同的品类、集群、实例等，规模和复杂度空前巨大。只有维持运维对象管理特征的同构，才能大规模建设、低成本维持运维服务化，进而实现规模运维(技术杠杆效应)，因此运维对象的同构维持是整个运维架构的基本前提。
同构维持，针对的是运维对象的管理特征、不是所有特征。同构维持，方式是：控增量、修存量、防裂变。如下图，通过平台做需求交付、来控增量，通过度量驱动治理、来修存量，通过规范服务框架、来防止技术体系的大范围裂变；平台、度量严格遵循规范，规范也需要度量或平台的问题输入来完善，三者相辅相成。规范，分为服务规范(对应服务治理)、管理规范(对应运维管控)等类型。
同构维持，依赖主责明确的组织分工。比如，运维专注于管理，剥离业务Toils、将之返还给业务研发，如现状治理、报警响应、CD；业务研发专注于业务实现，剥离服务框架这部分非业务逻辑、将之交给基础架构实现，如服务发现、流量控制；基础架构专注于服务框架等中台能力，剥离管理职能、将之交给运维，如需求交付、变更管控等。文化影响也不能忽视，运维和架构会通过沟通引导的方式，输出理念、培养用户习惯，如对个性化需求不提供SLA承诺、对标准应用提供开箱即用的观测能力等。
以运维对象同构维持为基础，向上支撑运维服务化技术体系，这就形成了一套可持续的运维架构，如下图。在当前的技术水平下，以自助平台为主的运维服务能解决70%的需求、剩余30%仍需要人工，比如需求沟通、问题排查、结果验收、政策合规等。随着技术和理念的进步，相信运维服务化的占比将进一步上升。
备注：本文中的服务框架，既包括N年前的代码框架、代码库，也包括当前流行的微服务治理，过渡阶段、起名捉急。
业务运维，也有人叫应用运维，离云原生最近、被冲击的最大。除却传统的规范制定、流程建设、全局管理等跨团队职责外，业务运维要朝着服务化的方向转型，路径如下图：
运维服务化OPaS(OP as Service)，是我们转型中期、从业务运维角度提出的目标，指出了大方向、但缺少路径比较抽象；之后，OPaS逐渐被细化为 ICSP IDP 的运维架构，适用范围扩展到整个运维团队，才算有了清晰的路径和抓手。
除了服务化，业务运维还可以主导超服务视角(现已更名为场景)建设。云原生下的DevOps技术拼图并不完整，只搞好了应用 计算这一块、其它方向存在能力空白，特别是向上的业务视角、部门视角、公司视角等，姑且称为超服务视角。对于超服务视角，业务研发人员通常没有能力、没有动力主R(主责)；部门主管或架构师可以照顾到本部门，但受限于岗位职责、很难扩展到全局。反观，超服务视角是传统业务运维的老战场，具备无与伦比的体验、理解和认知优势。业务运维主导超服务视角建设，既能添补云原生领域的空白、又能发挥业务运维的专业优势、借势转型，会是一个双赢的选择，如下图。
超服务视角，包括但不限于：
云原生下的DevOps技术拼图，向下看也有能力空白，如针对CDN、对象存储、MQ、EMR等基础服务支持的并不完善，2022年还处在探索期；站在运维管理角度，只要被服务框架(鉴权、发现、通信、感知、流控)辐射到了，就算被云原生纳管了。
云服务、中间件、大数据等运维对象，技术栈收敛、专业聚焦。运维人员转型实施时，可以按照洋葱模型来。
洋葱模型，最早在数据库、大数据、中间件等岗位上被验证，后来被拿过来用到云服务上、同样成功了。比如，我司的云服务运维CloudOps团队，就是按照洋葱模型、来实施转型的，具体如下，
随着业务运维、组件运维、系统运维(资源网络云服务)等角色开始参与开发工作，留给运维开发DevOps团队的空间逐渐变少，转型过程中出现了分工不清晰的情况。参照组织结构、技术架构的升级预判，我们重新调整了OpDev的岗位定位：OpDev不应该是运维人员的开发外包或附庸、而应该有自己独立提供的服务。于是乎，原有的运维平台被拆分成了两部分，一部分偏重功能迭代无法复用、交给原使用方自己维护，比如IDP资源控制台、ICSP场景管理工具等；另一部分是公共功能、抽象为运维中台由OpDev负责，如统一账号IAM、工单编排引擎、监控指标采集器等，如下图。
运维中台是原运维平台的子集，不需要重新构建领域知识，需要重新做一下领域抽象建模、对代码质量要求也比较高(同基础组件)，这正是OpDev童鞋的长处所在。随着职责的聚化缩减，OpDev要同步瘦身、做到更高的杠杆。
简单分享下我司的一些转型教训，包括
以下是附加内容，不是本文核心。
无论是公有云，还是内部的K8S平台，都存在着大量的需求交付操作。这类ToM(ToManager)的交付平台，往往缺少必要约束、只能对资深人士开放。
为了优化分工、提升效率，可以通过「工单编排 审批」的方式、将运维管理面ToC(ToRD)；工作流/工单本身会大量融入运维管理的最佳实践，可以安全的开放给研发。这是运维能力服务化的一个重要方向。交付自助化的演化路径如下：
目前看，从需求到技术方案的沟通环节，是比较难自助化或者自动化的，需要将来更多的尝试。
规模运维的经济学本质是边际成本，是「运维管理边际成本递减vs同构维持边际成本递增」的相互作用。如下图，运维对象数量较少时，运维管理的成本占大头儿，比如建设平台、人工运营；运维对象数量变大后，同构维持构成主要成本；边际转折点，会受到技术、理念等环境因素的影响。
云原生技术，降低了同构维持难度(促进同构维持曲线右移)、提升了运维服务化能力(促进运维管理曲线下移)，使得运维人员能够以更低的成本、管理更多运维对象，因此显著提升了生产效率。
以上是作业帮聂安：运维如何转型，听听作业帮的OPaS思路的详细内容。更多信息请关注PHP中文网其他相关文章！
