云原生时代的运维转型

要点简述

  • 传统运维,职责是将工业制成品组装成服务、交付给用户,并维持服务运转;特点是强依附于业务
  • 云原生时代,公有云大量使用、微服务架构和DevOps真实达成、工具体系持续繁荣,传统运维的职责不断被外包、转移、替代,出现了领域危机
  • 运维转型,核心是改变角色认知。运维人,要把自己从依附于业务的运营角色,调整为独立的运维服务提供方
  • 运维转型,目标是运维即服务OPaS。运维转型为服务提供方,专注于打造OPaS能力,持续深化专业性;业务研发借助OPaS,自助完成日常的运营工作
  • 转型实践,洋葱模型、超服务视角、管理面自助化这三条路,已经被我们证明可行
  • 平台是服务能力最有力的承接方式,但不是唯一方式。组织、文化、规范、流程、架构、平台,一样都不能少(除平台外,自助化的成本可能略高)

运维阶段

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

page.png

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

  • 继承性。新阶段往往继承、发扬老阶段的优秀经验,又会在理念、技术、组织上有所创新
    • 比如,平台化继承、强化了标准化阶段的成果,数据化继承了平台化的成果、同时引入大数据技术,DevOps也是一个左右能够衔接起来的组织变革
  • 职责转移。DevOps是运维管理模式的分水岭,DevOps之后的运维
    • 一方面,沿着专业化的方向继续推进,不断强化工具体系的重要性,包括更完善的平台化、自动化、数据化、智能化
    • 另一方面,则强调运维研发融合,运维职责逐步转移到业务研发

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

传统运维

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

page.png

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

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

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

pict

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

转型思路

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

pict

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

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

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

  • 第一层,要改变角色认知。把自己从依附于业务才能产生价值的运营角色,调整为具有独立价值的运维服务提供方。这是转型的关键部分
    • 业务研发使用「运维服务」,自助完成运营维护工作
  • 第二层,转型实施遵循四步走。提炼服务 –> 提供服务能力 –> 建设平台 –> 持续深入
    • 其中,理解运维价值、提炼出运维服务,是难点、也是方向性的关键点
    • 对于服务实体比较明确的运维角色,提炼服务相对简单。如,CloudOps就是云服务、DBA是数据库、MiddlewareOps是中间件、BigdataOps是大数据
    • 业务运维、安全运维等角色,服务实体抽象比较困难
  • 第三层,达成运维即服务OPaS。运维转型为服务提供方,专注于打造运维即服务OPaS的能力、持续深化专业性;业务研发则借助OPaS,自助完成日常的运营工作。这是转型的目标

pict

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

转型实践

洋葱模型

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

pict

  • 第一阶段,立足于运营优势,把原来运维的对象,转变为服务实体、对外提供出去,初步建立一个价值底线
  • 第二阶段,抽出大部分的精力、来建设管理平台,把服务实体的整个生命周期管理好,平台要能ToC化、以降低人力负担
  • 第三阶段,深入到组件自身的专业领域中去,从代码、架构、运维、性能等方方面面提升专业性,建立专业壁垒。做到这一步时,运维已经转型为领域专家

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

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

超服务视角

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

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

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

pict

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

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

  • 稳定性管控,运维人员重新审视原有的运维场景,主动弱化「应用/服务」视角,聚焦到业务、部门、公司等超服务视角,例如感知、定位、预案、容量、标准化度量等等。架起超服务视角、立马鸟枪换炮
  • 成本管控,公司全局角度的计费分摊、预算管理、成本控制(这个方向可能会独立为FinOps)
  • 规范制定,公司全局角度的运维规范制定、流程落地监督,避免小团队烟囱式建设
  • 持续更新…

管理面自助化

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

为了优化分工、提升组织效率,可以通过工作流/工单的方式,将运维管理面安全ToC。工作流/工单本身的设计,大量融入了运维变更管理的最佳实践,目前也是运维能力服务化的一个子方向。以交付场景为例,能力演化路径如下:

pict

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

一些教训

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

  • 转型和保守要折中。传统运维转型到服务提供方,既不会一蹴而就、也不会全员迁徙,总要有人留下来殿后。因为资源更集中,殿后人员会获得更多的价值回报
  • 研发能力区分梯度。从运维转型到开发的童鞋,开发能力参差不齐,要从简单的业务需求做起;要配备足够精致的运维中台开发能力,保障底层架构的干净
  • 平台不是唯一选择。平台是服务能力最有力的承接方式,但绝对不是唯一方式。组织、文化、规范、流程、平台,一样都不能少(但转移成本可能略高)
  • 警惕纯粹项目思维。运维还是要参与一些项目,短期内爆发价值、揽获成就感,但也很容易人走茶凉、价值归零;需要有意识的设计目标,在项目过程中的沉淀服务能力


Prev     Next