上面讲到的，基础设施外包给公有云、云原生之后运维职责转移给业务研发、平台替代人工的专业性。面对这样的趋势、事实，运维从业者需要做出一些转型。组织结构首先聊聊组织结构。长期看，云原生时代的公司组织形态，由如下几部分构成：最上面的终端用户，是企业的甲方客户、也是潜在的营利人群。业务团队，为终端用户负责，角色包括了产品、商务、市场、营销等。业务研发，直接为业务团队服务，主要是提供SaaS化的应用/服务。平台研发，则是为业务研发服务，提供各种各样的PaaS化能力，对下封装了云厂商。还会有一些跨功能组织，如成本运营FinOps、效率运营EP、行政团队IT等等。在新的组织结构中，大家最终的目标是各司其事、服务好终端用户。业务团队更关注业务价值，研发体系聚焦在服务质量。随着信息化技术的进步，当前由跨功能组织履行的职能、将逐步分解到平台研发团队，组织协作的主要方式从人人协同、升级为平台自助。运维有了新的岗位目标，即：运维的主旋律是服务产品、是技术中台、不是横向协同，运维要做高技术杠杆、赋能业务、助力企业提升经营效率。技术架构运维转型，目标是：通过自助化的平台，向上层团队、提供运维管理服务；本质是运维服务化OPaS(OP as Service)。按照内容差异，运维工作可以分为对象管理、场景管理两大类，如下图所示。对象管理是纵向模式，围绕运维对象、建设生命周期的管理平台。运维对象的分类，可以按照IaaS资源(机器、网络、存储、云服务)、PaaS组件(数据库、缓存、MQ、网关)、SaaS应用(业务中台、业务应用)、服务框架(运行时、代码框架、名字服务)等维度，不同公司的分类粒度不尽相同。每类对象都有独立的管理平台(烟囱)，管理平台功能要覆盖运维对象的完整生命周期，关键阶段包括建模(元数据)、交付/变更、监控/度量、下线等，跟公有云的管理功能类似。对象管理的目标是，产出纵向完备的云产品、建成内部云平台ICSP。场景管理是横向模式，根据运维场景、纳管多种运维对象的生命周期阶段。运维场景的分类，包括交付/变更、监控/度量、多云、成本等等，非常贴近业务研发的工作习惯、覆盖少数高频场景，不同公司大同小异。每类运维场景，有独立的场景管理平台，如工单中心、数据中心、FinOps平台等。场景管理建立在对象管理之上，场景管理平台对运维对象的纳管方式包括统一模型、汇聚数据、编排管控API等。场景管理的目标是，提供自助化的业务管理能力、建成内部开发者平台IDP。运维对象的产生方式，常见的有自研、开源搭建、外采(公有云)等。每种运维对象，又能再细分出不同的品类、集群、实例等，规模和复杂度空前巨大。只有维持运维对象管理特征的同构，才能大规模建设、低成本维持运维服务化，进而实现规模运维(技术杠杆效应)，因此运维对象的同构维持是整个运维架构的基本前提。同构维持同构维持，针对的是运维对象的管理特征、不是所有特征。同构维持，方式是：控增量、修存量、防裂变。如下图，通过平台做需求交付、来控增量，通过度量驱动治理、来修存量，通过规范服务框架、来防止技术体系的大范围裂变；平台、度量严格遵循规范，规范也需要度量或平台的问题输入来完善，三者相辅相成。规范，分为服务规范(对应服务治理)、管理规范(对应运维管控)等类型。同构维持，依赖主责明确的组织分工。比如，运维专注于管理，剥离业务Toils、将之返还给业务研发，如现状治理、报警响应、CD；业务研发专注于业务实现，剥离服务框架这部分非业务逻辑、将之交给基础架构实现，如服务发现、流量控制；基础架构专注于服务框架等中台能力，剥离管理职能、将之交给运维，如需求交付、变更管控等。文化影响也不能忽视，运维和架构会通过沟通引导的方式，输出理念、培养用户习惯，如对个性化需求不提供SLA承诺、对标准应用提供开箱即用的观测能力等。领域模型运维转型，目标是探索出新的领域模型。以运维对象同构维持为基础，向上支撑对象、场景层的运维服务化体系(OPaS)，做到可持续的高技术杠杆，这就是新的运维领域模型。在当前的技术水平下，以自助平台为主的运维服务能解决70%的需求、剩余30%仍需要人工，比如需求沟通、问题排查、结果验收、政策合规等。随着技术和理念的进步，相信运维服务化的占比将进一步上升。备注：本文中的服务框架，既包括N年前的代码框架、代码库，也包括当前流行的微服务治理，过渡阶段、起名捉急。转型实践
微信扫一扫