导读
本文主要探讨经典IT运维工种的发展阶段、商业模式、职责模型、职责阶段性、职业局限等问题，下文将IT运维简称为运维。Devops及云原生之后，运维团队的职责发生了很大变化，不在本文讨论范围。
运维的发展阶段
互联网运维领域，先后经历了纯手工、标准化、平台化、数智化等发展阶段，如下，
如果考虑到Devops理念引入的组织和分工变化，又可以按如下方式划分，
这几个发展阶段，有如下特点，
- 继承性: 运维是一门实践学科，其发展历史呈现了强烈的继承性
- 新阶段往往继承、发扬老阶段的优秀经验，又会在理念、技术、组织上有所创新，呈现出螺旋式的上升发展
- 文档化、规范化、流程化、脚本化、平台化、自动化、数据化、智能化，这些都是运维一路发展过来的优秀成果
- 职责转移: DevOps是运维管理模式的分水岭。DevOps之后，运维
- 一方面沿着专业化方向继续推进，包括更完善的平台化-ToM、自动化、数据化、智能化
- 另一方面则强调运维职责分散到RD，代表作是平台化-ToC，在可预见的将来集中管理还会被逐步压缩
- 边际效益: 平台化-ToM是运维ROI的最高峰，之后ROI都在递减，无论是专业方向、还是DevOps方向
特别是职责转移，运维领域从业者产生了严重的价值恐慌。运维职责是否能够、什么时候全部转移给普通研发，这一点不做讨论。运维人员更应该多花一点时间，提供易于沉淀的运维服务，设计好运维服务安全ToC的路径。
运维的商业模式
纵观互联网、电信、金融、工业制造等领域，运维的商业模式主要有四种，
- 免运维。高度成熟的商业产品往往具备免运维的特点，当企业购买、安装部署以及联调后，基本不需要提供后续运行维护支持
- 外包运维。在单体应用、私有云建设模式下，企业通常采用驻场服务、定期或按需到场、远程运维的方式，将运维工作外包给专业厂商；对于使用公有云服务的场景，则通常选择购买云服务来解决一站式运维保障。外包运维主要适用于中小型企业
- 自建运维。常见于互联网企业、大中型传统企业或者安全等级较高的企事业单位；即使采购了第三方的运维工具，也要求组建企业自有的运维团队，并逐渐走向集约化
- 自建+外包混合模式。通常情况下，服务提供商是系统集成商或软件原厂商；当项目完成交付时，他们与企业自建运维团队共同提供运维服务。自建运维团队的主要任务是运维管理，而运维服务提供商的主要任务是运维执行，两者共同目标是提供可持续的运维服务运维的持续优化
本文后续章节，主要针对互联网领域的自有运维团队。
运维的职责范围
从软件生命周期的角度看，开发阶段占20%~30%左右，运行维护阶段占据60%以上、最长尾。可以很清晰地划分出”开发阶段”和”运维阶段”，分界点从代码开发完成、测试验收通过、交付软件包给运维开始，自此之后都可以认为是运行维护阶段了，也就是运维阶段。广义上讲，除却业务的设计、开发、测试、交付，之后的工作都算运维；众多角色都在做运维的活儿，但人员不一定归属运维团队。
运维的职责模型(经典)
经典运维的职责: 通过一系列的流程、技术、方法，将工业制成品组装为服务，并维护其正常运转。工业制成品，包括硬件基础设施IaaS、软件基础设施PaaS、业务应用服务SaaS等。维护服务正常运转、持续运营CO是运维的主要工作，要求达成稳定、成本、安全、效率的多维目标（多快好省）。
从某种程度上讲，运维需要依附于业务、才能产生价值。在很多公司，是否理解业务是运维工作者的主要考核项之一。
运维的认知模型
运维是一门实践学科，遵循问题驱动、持续演进的原则。在CO的过程中，运维工作者通常遵循了解现状、发现问题、提升认知、制定规范、设立流程、抽象产品/建设平台、技术运营的行为范式（有人也称为技术运营）。
运维的职业局限
效率提升是技术发展的最终驱动力。从技术发展史来看，每次能源使用效率的飞跃，都带来了革命性的结果、推动技术踏上一个新台阶。反观稳定、成本、安全，三者都是在特定效率阶段、追求达成最佳运营效果的努力。
运维工作者无力承担效率革命的使命。偏重横向运营的职责属性，往往会造成运维工作者”热心改良、抗拒革命”的性格特点，其在效率方面只能小修小补、不太可能有革命性突破，这也是为什么运维的效率主题这么难做。从运维领域的历次大变革来看，推动力主要来自领域外的推动、而非运维工作者自身的运营优化，何其悲哀!
运维的团队设计
运维团队的顶层设计，围绕组织、文化、技术原则展开。
- 组织原则：从价值呈现的角度，围绕服务提供方、横向串联两个角色，设计运维的组织结构
- 文化原则：工程思维，服务意识，Owner意识，自上而下的变革
- 技术原则：以应用为中心、以生命周期为抓手，做到技术架构标准化、资源组件服务化、应用管理自助化
运维的组织结构。运维对外呈现两方面的价值。一方面是业务运维，照顾好业务应用的生命周期、发挥业务价值，这是运维最直接的使用。另一方面是平台服务，运维以场景之便逐渐纳管了类似资源、组件、数据等服务，通常以自助化平台的方式提供出来。这两种价值一横、一纵，关注点分离，中间的Gap又运维架构师填平。这两种价值所依赖的平台也有众多相似之处，抽象为统一的运维中台、避免重复造轮子。
运维的价值呈现，依赖配套的组织结构，参考如下：
- 基础运维，纵向的服务提供方，提供资源、组件、数据服务及配套的自助化平台
- 业务运维，面向业务研发、提供应用管理，实施技术运营
- 运维架构，横向串联各服务能力，提供平台、规范、流程的全局解决方案，主导技术运营
- 运维中台，负责运维平台体系的通用能力建设，非通用能力交给各运维团队负责，主要是开发人员
- 新兴方向，如FinOps等，在领域影响力形成前一般会由已存在的团队兼任
接下来的文章内容，是对上文章节的细节拆解、分析。
运维职责的阶段性
在公司的不同成长阶段，运维的职责重心会有所不同。业务快速增长期，效率是关键，做好资源管理、快速协调资源、快速迭代发布是运维要解决的主要问题。业务成长到一定规模并持续增长时，稳定变为首要问题，做好变更管理、完善观察能力、做好容量管理、推动架构升级，保障不因非业务问题制约增长速度。业务成长至稳定期后，成本变的极为重要，资源管理、容量管理成为运维的关键主题。
站在运营的角度，在绝大部分时间里，运维都可以把稳定性当做核心价值。核心价值是筛选器，可以作为资源投入的取舍依据，也可以管理团队边界、避免失焦。每个领域都有扩展边界的冲动，目前能看到运维也在向大数据决策、ToB化输出、基础架构(K8S)、效能管理等方向扩展 —— 领域的交叉，如果不能融合、创造出新领域，最后都是无谓的争端。
运维的核心价值
运维可以把稳定性作为核心价值。原因如下，
- 效率：搞不出革命突破。运维角度的效率通常更偏重运维内部、不太会着眼全局，运营的岗位属性也决定了运维不适合搞效率革命(搞了就相当于换行)
- 成本：受限于公司体量。大公司有FinOps团队专门负责成本，中小公司做成本通常是间歇性投入、甚至自己挖坑自己填
- 安全：重要性持续提升。受到国家层面的政策支撑，足够重要，通常有安全部门主R
- 稳定：具备全局重要性，又有持续投入的必要性，绝对契合运维的职业定位
为了达成稳定性这一核心价值，需要在多个管理环节实施管控：
- 定方向：以稳定性工作为中心，建设、运营并举
- 搭班子：招聘要求性格稳健、责任心强，五条军规护航
- 做事情：以业务连接为底座，贯穿稳定性方法集合，在平台、架构、专业性等方面有所作为
- 平台：工具比人更靠谱，使用受约束的弱智能（如经验智能）
- 架构：相信架构决定运维的能力上限
- 专业性：纵向足够深，横向能迁移
运维的职责演进
云原生架构逐渐成为行业趋势，运维职责被逐渐转移、替代，边界进一步收缩（未被彻底干掉）。主要表现为：
- 系统运维：硬件基础设施的运维工作转移到了公有云厂商，IaaS真实达成；留给系统运维的工作主要是面向云API的”云资产生命周期管理”，如多云管理、元数据运营等
- 公有云资产是逻辑资产，其运维特质跟中间件类似，要求深度和精度、要求场景闭环，是不折不扣的专家岗
- 目前有不少创业公司在做云资产管理，主要集中在编排、运营等方向，尚未形成通用能力
- 应用运维：软件基础设施的运维职责被云原生体系替代。以K8S为代表的PaaS体系已然成熟，公有云厂商已将其定义成新的交互界面；软基础设施工程师角色应运而生，承担了”打通PaaS和我方应用”的建设任务。应用运维工作继续向应用层收缩，更加专注于应用生命周期的运营
- 应用服务通常数量庞大、在运维视角有广泛的复用性，因此，应用运维更容易在运维子领域建立专业性、然后横向输出解决方案，成为运维架构岗
- 平台体系：公有云场景下的系统运维、云原生架构下的应用运维，因其所负责运维服务的属性（如复用性）、数量等差异，导致了专家岗、架构岗的明显分化。对应的，在运维平台建设方向，也同时存在了场景闭环、横向建设两种思路，这也是由所服务对象的属性差异所致
这里，引用腾讯刘天斯的一个例子，来形象的描述运维职责的变化：
云计算时代的运维就好比组装汽车，客户根据自己的需要，通过PaaS能力，选择匹配的引擎、车轮、离合器等进行拼装，
客户不用再关心汽车元部件的实现原理。
但，光有汽车是玩不转的，还需要有修路、建加油站、控制交通，运维就是要承担这个角色。
运维架构
运维架构，是运维领域的一个细分方向，强调用架构的思路做运维，追求运维的体系化。具体的，
- 岗位职责：全局视角，横向串联
- 全局视角：技术全局观，先谋全局、再谋一域，跳出运维的领域局限，站在整个技术组织、技术架构的角度思考运维
- 横向串联：从业务全局视角出发，将各纵向专业能力串联整合起来；资源、组件、架构、应用等团队聚焦于提供纵向专业能力
- 指导思想：技术架构标准化，资源组件服务化，应用管理自助化。还有一些最佳实践，也可以参考，如
- 自上而下(vs自下而上)
- 规划驱动(vs问题驱动)，事前标准(vs事后治理)
- 软件工程(vs技术运营)
- 实施路径：借助生命周期分析找准问题域，通过对象建模设定技术标准
- 以「生命周期」为入手，确定运维的问题域。包括划分阶段，识别对象、提炼属性、理清关系、固化信息(CMDB)、梳理场景，
- 以对象建模为突破口，建立统一的技术标准。自底而上、建立技术对象的统一模型，不同技术团队遵循此模型、协同建设上层平台
- 岗位局限
- 容量有限：千人规模的技术团队，只需要1-2名运维架构师
- 要求很高：要兼具运维和架构两种技术能力、对业务足够了解，同时还要能够穿梭于一线和N线
- 迁移性差：因为深度介入业务，公司间迁移也会比较困难，难以形成事实的团队，一般会兼任