运维建设之云原生转型

要点简述

  • 传统运维,职责是将工业制成品组装成服务、交付给用户,并维持服务运转;特点是强依附于业务
  • 领域危机,云原生时代公有云大量使用、微服务架构和DevOps真实达成、工具体系持续繁荣,传统运维的职责不断被外包、转移、替代,出现了领域危机
  • 转型核心,是改变角色认知。运维人,要把自己从依附于业务的运营角色,调整为独立的运维服务提供方
  • 转型目标,是达成运维即服务OPaS。传统运维转型为服务提供方、建设运维即服务OPaS,业务研发借助OPaS、自助完成运营
  • 转型实践,洋葱模型、超服务视角、管理面自助化、同构维持这几条路,已经被我们证明可行
  • 规模运维 = 运维服务化OPaS + 同构维持

运维阶段

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

page.png

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

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

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

传统运维

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

page.png

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

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

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

pict

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

转型思路

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

pict

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

在这个组织结构中,大家最终的目标是集中力量、服务好终端用户。业务团队只需要关注业务价值,研发体系的底层聚焦在服务好更上层的团队。随着技术的进步,跨功能组织也将逐渐细化为平台研发团队,以服务化的方式呈现价值。

传统运维的转型,也是这种情况。除却规范制定、流程建设、全局管理等跨团队职责外,运维需要向着服务化的方向转型:

  • 第一层,要改变角色认知。把自己从依附于业务才能产生价值的运营角色,调整为具有独立价值的 运维服务提供方 。这是转型的关键部分
    • 业务研发使用「运维服务」,自助完成运营维护工作
  • 第二层,转型实施遵循四步走。明确价值 –> 抽象服务 –> 建设平台 –> 达成OPaS
    • 抽象运维服务是难点、也是关键点。对于运维对象比较明确的运维角色,抽象服务相对简单,如,CloudOps就是云服务、DBA是数据库、MiddlewareOps是中间件、BigdataOps是大数据。对于业务运维、安全运维等角色,抽象服务则比较困难,因为他们没有主责的服务
    • 运维服务化OPaS (OP as Service)是转型目标。运维转型为服务提供方,专注于打造运维即服务OPaS的能力、持续深化专业性;业务研发则借助OPaS,自助完成日常的运营工作
  • 第三层,运维对象维持同构。同构是规模运维能够发生的前提,更是OPaS的技术底座
    • 除去OPaS专业能力建设外,运维的主要精力应该投在同构维持上

pict

运维转型的三明治模型,符合我们对云原生组织形态的判断。这里也有一个额外的好处,运营Toils交给业务研发自助,解放了运维、提效了研发!

转型实践

洋葱模型

对于云服务、中间件、数据库、大数据等运维角色来说,抽象运维服务比较简单。他们在转型实施时,可以按照洋葱模型来。

pict

  • 第一阶段,立足于价值交付,把原来的运维对象、转变为服务实体,向上游交付有保障的功能、建立价值底线
  • 第二阶段,抽出大部分的精力、来建设管理平台,把服务实体的生命周期管理好、解放自己,平台要能ToC化、解放用户
  • 第三阶段,深入到组件自身的专业领域中去,从架构、代码、性能、运维等方方面面提升专业性。做到这一步时,运维已经转型为领域专家

洋葱模型,之前是数据库、大数据、中间件等角色遵循的成长模型,现在可以直接拿过来、用于云服务管理员等角色的转型。比如,我司的云服务运维CloudOps团队,就是按照洋葱模型、来实施转型的,具体如下,

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

同构维持

只有维持运维对象的同构,才能低成本的建设运维服务能力、进而实现规模运维,因此同构维持是运维转型的技术底座。

同构维持,需要同时做好控增量、修存量、防裂变。其中,运维通过平台做需求交付、来控增量,通过度量驱动服务治理、来修存量,通过规范服务框架、来防技术体系裂变;当然,平台和度量也要严格遵循规范(规范分为服务、管理等类型)。运维对象同构维持的好,再加上运维服务化OPaS,规模运维才有可能持续,如下图。运维偶尔也会威逼利诱灌输理念,如对个性化需求不提供运维服务承诺、对同构应用提供开箱即用的运维服务等。

pict

该模型依赖明确的组织分工。运维专注于运维服务,剥离业务Toils、将之返还给业务研发主R,如服务治理、报警响应、CD;业务研发专注于业务价值,剥离服务框架的非业务逻辑、将之交给基础架构实现,如服务发现、流量控制;架构专注于服务框架等中台能力,剥离运维管理职能、将之交给运维来做,如需求交付等。

进一步分析,规模运维的经济学本质是边际成本,是「运维服务边际成本递减vs同构维持边际成本递增」的相互作用。如下图,运维对象数量较少时,运维服务(运维管理)的成本占大头儿,比如建平台、做运营;运维对象数量变大后,同构维持构成主要成本。云原生体系促进了同构维持边际曲线的右移和下移,也促进了运维服务边际曲线的左移和下移,显著提升了规模运维的经济效益。

pict

交付自助化

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

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

pict

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

超服务视角

话题转回到业务运维领域。当前,在云原生体系的加持下,DevOps持续扩展边界。围绕着「应用/服务」视角,资源交付的细节被彻底屏蔽,资源调度、应用变更基本实现了自助化,服务注册发现、服务通信、服务观察、流量控制等服务治理手段也取得了很大的发展,很多运维职责逐步转移给了业务研发。

但我们也能看到,云原生下的DevOps领域拼图并不完整,在「应用/服务」视角之外存在能力空白,特别是向上的业务视角、部门视角、公司视角等,姑且称为超服务视角。对于超服务视角,业务研发人员通常没有能力、没有动力主R;部门主管或架构师可以照顾到本部门,但受限于岗位职责、很难扩展到全局。反观,超服务视角是传统运维的老战场,具备无与伦比的体验、理解和认知优势。

这样,业务运维主导超服务视角建设、提供运维即服务OPaS 的能力,既能添补云原生工具领域的空白,又能发挥传统运维的专业优势、借势转型,会是一个双赢的选择。如下图,

pict

超服务视角,是业务运维抽象出的服务领域,本身具备极强的专业性,也适用于洋葱模型。

超服务视角的需求场景,包括但不限于:

  • 需求交付,编排「应用/服务」视角的交付能力、提供场景闭环的交付方案
  • 质量管理,聚焦超服务视角的感知、定位、预案、容量、标准化度量能力建设,架起超服务视角、立马鸟枪换炮
  • 成本管控,公司全局角度的计费分摊、预算管理、成本控制等,这个方向已独立为FinOps
  • 规范制定,公司全局角度的运维规范制定、流程落地监督,避免小团队烟囱式重复建设
  • 等等

超服务视角-业务监控

何为业务?从技术视角看,业务是商业逻辑、组织结构在技术上的抽象和实现。

一些教训

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

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


Prev     Next