运维建设之云原生转型

云原生时代到来后,运维势必面临着转型的机遇和挑战。以下,是CH运维团队的转型思考和实践。

要点简述

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

运维阶段

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

page.png

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

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

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

传统运维

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

page.png

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

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

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

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

组织结构

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

pict

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

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

技术架构

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

pict

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

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

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

同构维持

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

pict

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

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

pict

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

转型实践

运维服务化OPaS

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

pict

  • 第一,角色认知要转变。把自己从依附于业务才能产生价值的运营角色,调整为具有独立价值的运维服务提供方。角色转变是关键
    • 组织上,重新划分主责。业务研发是应用主责方,运维不是应用主责方、也不是外挂式保姆,而是应用的管理能力提供方,业务研发使用运维服务、自助完成运营工作
    • 机制上,重构评价体系。业务运维岗位的绩效,不再强绑定业务团队和业务研发、而是更突出运维服务化,做轻主观评价、做重技术评价
  • 第二,运维转型四步走。明确对象 –> 抽象共性 –> 建设平台 –> 实现规模运维
    • 业务运维的对象,首先是应用(也称为服务),然后是应用的扩展场景(如业务视角、公司全局视角)
    • 抽象共性是难点,也是关键点。应用的数量大、技术栈复杂、个性化特征非常多,要抽象出应用的管理共性、避免陷入个性化case。严格来说,应用的共性特征才是运维管理的对象
    • 建设平台指的是应用管理平台,规模运维是一个可持续的终态
  • 第三,应用对象维持同构。除去服务化能力建设外,运维人员的主要精力应该投在同构维持上

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

超服务视角(业务运维)

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

pict

超服务视角,包括但不限于:

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

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

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

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

pict

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

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

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

运维中台(运维开发)

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

pict

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

一些教训

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

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

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

需求交付的演进

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

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

pict

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

规模运维的边际点

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

pict

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



Prev     Next