运维建设之岗位模型

导读

本文主要探讨经典IT运维工种的发展阶段、商业模式、职责模型、职责阶段性、职业局限等问题,下文将IT运维简称为运维。Devops及云原生之后,运维团队的职责发生了很大变化,不在本文讨论范围。

运维的发展阶段

互联网运维领域,先后经历了纯手工、标准化、平台化、数智化等发展阶段,如下,

page.png

如果考虑到Devops理念引入的组织和分工变化,又可以按如下方式划分,

page.png

这几个发展阶段,有如下特点,

  • 继承性: 运维是一门实践学科,其发展历史呈现了强烈的继承性
    • 新阶段往往继承、发扬老阶段的优秀经验,又会在理念、技术、组织上有所创新,呈现出螺旋式的上升发展
    • 文档化、规范化、流程化、脚本化、平台化、自动化、数据化、智能化,这些都是运维一路发展过来的优秀成果
  • 职责转移: DevOps是运维管理模式的分水岭。DevOps之后,运维
    • 一方面沿着专业化方向继续推进,包括更完善的平台化-ToM、自动化、数据化、智能化
    • 另一方面则强调运维职责分散到RD,代表作是平台化-ToC,在可预见的将来集中管理还会被逐步压缩
  • 边际效益: 平台化-ToM是运维ROI的最高峰,之后ROI都在递减,无论是专业方向、还是DevOps方向

特别是职责转移,运维领域从业者产生了严重的价值恐慌。运维职责是否能够、什么时候全部转移给普通研发,这一点不做讨论。运维人员更应该多花一点时间,提供易于沉淀的运维服务,设计好运维服务安全ToC的路径。

运维的商业模式

纵观互联网、电信、金融、工业制造等领域,运维的商业模式主要有四种,

  • 免运维。高度成熟的商业产品往往具备免运维的特点,当企业购买、安装部署以及联调后,基本不需要提供后续运行维护支持
  • 外包运维。在单体应用、私有云建设模式下,企业通常采用驻场服务、定期或按需到场、远程运维的方式,将运维工作外包给专业厂商;对于使用公有云服务的场景,则通常选择购买云服务来解决一站式运维保障。外包运维主要适用于中小型企业
  • 自建运维。常见于互联网企业、大中型传统企业或者安全等级较高的企事业单位;即使采购了第三方的运维工具,也要求组建企业自有的运维团队,并逐渐走向集约化
  • 自建+外包混合模式。通常情况下,服务提供商是系统集成商或软件原厂商;当项目完成交付时,他们与企业自建运维团队共同提供运维服务。自建运维团队的主要任务是运维管理,而运维服务提供商的主要任务是运维执行,两者共同目标是提供可持续的运维服务运维的持续优化

本文后续章节,主要针对互联网领域的自有运维团队。

运维的职责范围

从软件生命周期的角度看,开发阶段占20%~30%左右,运行维护阶段占据60%以上、最长尾。可以很清晰地划分出”开发阶段”和”运维阶段”,分界点从代码开发完成、测试验收通过、交付软件包给运维开始,自此之后都可以认为是运行维护阶段了,也就是运维阶段。广义上讲,除却业务的设计、开发、测试、交付,之后的工作都算运维;众多角色都在做运维的活儿,但人员不一定归属运维团队。

运维的职责模型(经典)

经典运维的职责: 通过一系列的流程、技术、方法,将工业制成品组装为服务,并维护其正常运转。工业制成品,包括硬件基础设施IaaS、软件基础设施PaaS、业务应用服务SaaS等。维护服务正常运转、持续运营CO是运维的主要工作,要求达成稳定、成本、安全、效率的多维目标(多快好省)。

page.png

从某种程度上讲,运维需要依附于业务、才能产生价值。在很多公司,是否理解业务是运维工作者的主要考核项之一。

运维的认知模型

运维是一门实践学科,遵循问题驱动、持续演进的原则。在CO的过程中,运维工作者通常遵循了解现状、发现问题、提升认知、制定规范、设立流程、抽象产品/建设平台、技术运营的行为范式(有人也称为技术运营)。

page.png

运维的职业局限

效率提升是技术发展的最终驱动力。从技术发展史来看,每次能源使用效率的飞跃,都带来了革命性的结果、推动技术踏上一个新台阶。反观稳定、成本、安全,三者都是在特定效率阶段、追求达成最佳运营效果的努力。

运维工作者无力承担效率革命的使命。偏重横向运营的职责属性,往往会造成运维工作者”热心改良、抗拒革命”的性格特点,其在效率方面只能小修小补、不太可能有革命性突破,这也是为什么运维的效率主题这么难做。从运维领域的历次大变革来看,推动力主要来自领域外的推动、而非运维工作者自身的运营优化,何其悲哀!

运维的团队设计

运维团队的顶层设计,围绕组织、文化、技术原则展开。

  • 组织原则:从价值呈现的角度,围绕服务提供方、横向串联两个角色,设计运维的组织结构
  • 文化原则:工程思维,服务意识,Owner意识,自上而下的变革
  • 技术原则:以应用为中心、以生命周期为抓手,做到技术架构标准化、资源组件服务化、应用管理自助化

运维的组织结构。运维对外呈现两方面的价值。一方面是业务运维,照顾好业务应用的生命周期、发挥业务价值,这是运维最直接的使用。另一方面是平台服务,运维以场景之便逐渐纳管了类似资源、组件、数据等服务,通常以自助化平台的方式提供出来。这两种价值一横、一纵,关注点分离,中间的Gap又运维架构师填平。这两种价值所依赖的平台也有众多相似之处,抽象为统一的运维中台、避免重复造轮子。

运维的价值呈现,依赖配套的组织结构,参考如下:

  • 基础运维,纵向的服务提供方,提供资源、组件、数据服务及配套的自助化平台
  • 业务运维,面向业务研发、提供应用管理,实施技术运营
  • 运维架构,横向串联各服务能力,提供平台、规范、流程的全局解决方案,主导技术运营
  • 运维中台,负责运维平台体系的通用能力建设,非通用能力交给各运维团队负责,主要是开发人员
  • 新兴方向,如FinOps等,在领域影响力形成前一般会由已存在的团队兼任



接下来的文章内容,是对上文章节的细节拆解、分析。

运维职责的阶段性

在公司的不同成长阶段,运维的职责重心会有所不同。业务快速增长期,效率是关键,做好资源管理、快速协调资源、快速迭代发布是运维要解决的主要问题。业务成长到一定规模并持续增长时,稳定变为首要问题,做好变更管理、完善观察能力、做好容量管理、推动架构升级,保障不因非业务问题制约增长速度。业务成长至稳定期后,成本变的极为重要,资源管理、容量管理成为运维的关键主题。

站在运营的角度,在绝大部分时间里,运维都可以把稳定性当做核心价值。核心价值是筛选器,可以作为资源投入的取舍依据,也可以管理团队边界、避免失焦。每个领域都有扩展边界的冲动,目前能看到运维也在向大数据决策、ToB化输出、基础架构(K8S)、效能管理等方向扩展 —— 领域的交叉,如果不能融合、创造出新领域,最后都是无谓的争端。

运维的核心价值

运维可以把稳定性作为核心价值。原因如下,

  • 效率:搞不出革命突破。运维角度的效率通常更偏重运维内部、不太会着眼全局,运营的岗位属性也决定了运维不适合搞效率革命(搞了就相当于换行)
  • 成本:受限于公司体量。大公司有FinOps团队专门负责成本,中小公司做成本通常是间歇性投入、甚至自己挖坑自己填
  • 安全:重要性持续提升。受到国家层面的政策支撑,足够重要,通常有安全部门主R
  • 稳定:具备全局重要性,又有持续投入的必要性,绝对契合运维的职业定位

为了达成稳定性这一核心价值,需要在多个管理环节实施管控:

  • 定方向:以稳定性工作为中心,建设、运营并举
  • 搭班子:招聘要求性格稳健、责任心强,五条军规护航
  • 做事情:以业务连接为底座,贯穿稳定性方法集合,在平台、架构、专业性等方面有所作为
    • 平台:工具比人更靠谱,使用受约束的弱智能(如经验智能)
    • 架构:相信架构决定运维的能力上限
    • 专业性:纵向足够深,横向能迁移

运维的职责演进

云原生架构逐渐成为行业趋势,运维职责被逐渐转移、替代,边界进一步收缩(未被彻底干掉)。主要表现为:

  • 系统运维:硬件基础设施的运维工作转移到了公有云厂商,IaaS真实达成;留给系统运维的工作主要是面向云API的”云资产生命周期管理”,如多云管理、元数据运营等
    • 公有云资产是逻辑资产,其运维特质跟中间件类似,要求深度和精度、要求场景闭环,是不折不扣的专家岗
    • 目前有不少创业公司在做云资产管理,主要集中在编排、运营等方向,尚未形成通用能力
  • 应用运维:软件基础设施的运维职责被云原生体系替代。以K8S为代表的PaaS体系已然成熟,公有云厂商已将其定义成新的交互界面;软基础设施工程师角色应运而生,承担了”打通PaaS和我方应用”的建设任务。应用运维工作继续向应用层收缩,更加专注于应用生命周期的运营
    • 应用服务通常数量庞大、在运维视角有广泛的复用性,因此,应用运维更容易在运维子领域建立专业性、然后横向输出解决方案,成为运维架构岗
  • 平台体系:公有云场景下的系统运维、云原生架构下的应用运维,因其所负责运维服务的属性(如复用性)、数量等差异,导致了专家岗、架构岗的明显分化。对应的,在运维平台建设方向,也同时存在了场景闭环、横向建设两种思路,这也是由所服务对象的属性差异所致

这里,引用腾讯刘天斯的一个例子,来形象的描述运维职责的变化:

云计算时代的运维就好比组装汽车,客户根据自己的需要,通过PaaS能力,选择匹配的引擎、车轮、离合器等进行拼装,  
客户不用再关心汽车元部件的实现原理。
但,光有汽车是玩不转的,还需要有修路、建加油站、控制交通,运维就是要承担这个角色。

运维架构

运维架构,是运维领域的一个细分方向,强调用架构的思路做运维,追求运维的体系化。具体的,

  • 岗位职责:全局视角,横向串联
    • 全局视角:技术全局观,先谋全局、再谋一域,跳出运维的领域局限,站在整个技术组织、技术架构的角度思考运维
    • 横向串联:从业务全局视角出发,将各纵向专业能力串联整合起来;资源、组件、架构、应用等团队聚焦于提供纵向专业能力
  • 指导思想:技术架构标准化,资源组件服务化,应用管理自助化。还有一些最佳实践,也可以参考,如
    • 自上而下(vs自下而上)
    • 规划驱动(vs问题驱动),事前标准(vs事后治理)
    • 软件工程(vs技术运营)
  • 实施路径:借助生命周期分析找准问题域,通过对象建模设定技术标准
    • 以「生命周期」为入手,确定运维的问题域。包括划分阶段,识别对象、提炼属性、理清关系、固化信息(CMDB)、梳理场景,
    • 以对象建模为突破口,建立统一的技术标准。自底而上、建立技术对象的统一模型,不同技术团队遵循此模型、协同建设上层平台
  • 岗位局限
    • 容量有限:千人规模的技术团队,只需要1-2名运维架构师
    • 要求很高:要兼具运维和架构两种技术能力、对业务足够了解,同时还要能够穿梭于一线和N线
    • 迁移性差:因为深度介入业务,公司间迁移也会比较困难,难以形成事实的团队,一般会兼任


Prev     Next