Chapter 6
第6章
岗位与能力

在新制度下，如果一个工人没有干好，总是假定首先是管理人员的过错，可能是管理人员没有正确地教会这个人，没有给他做出榜样，没有花费足够的时间教会他怎样干他的工作。

——科学管理之父弗雷德里克·泰勒

人是运维组织最核心的要素。运维组织将人力资源投入到组织最关键、最核心的底线工作的同时，还需要设立面向持续优化主题的横向优化型岗位，以形成“职能型+优化型”组合的运维岗位。而要充分赋能运维员工，运维组织要善于运用组织架构设计、协同机制、运维平台工具，提升运维人员被动与主动的适应性能力，基于实际工作场景，为员工构建在线、自动化、数据驱动的工作空间。

6.1 职能型运维团队岗位

运维组织在面对复杂的工作任务时，往往把任务分解到多个团队去完成，形成以IDC机房运维、网络运维、服务器与存储运维、平台系统运维、应用运维、安全运维等为职能的组织架构。职能型运维团队岗位具有工作范围确定、人员职责分明、内部工作效率高、有助于精细化分工的特点，是当前运维组织最常见的组织形式。

1.职能型运维团队岗位概述

IDC机房运维岗主要对IDC机房基础设施进行管理，负责机柜、空调、UPS等最基础的机房设施的运维管理，主要工作包括：机房机柜摆放和机柜管理，服务器和网络设备摆放规划和设备日常管理与人员出入机房管理，机房电力系统、消防监控系统、空调报警系统、温湿度报警系统、漏水报警系统、机房卡门禁系统、视频监控系统、UPS系统运维、机房巡检管理等。

网络运维岗管理数据中心所有的交换机、路由器、防火墙等设备，以及连接设备组成的所有网络，主要工作包括网络管理及平台化统筹规划、网络监控、故障应急、网络设备上下架、专线管理、互联网线路管理、局域网日常管理和维护、VPN办公远程接入、网络病毒查杀和网络安全保护等。

服务器与存储运维岗主要管理数据中心的小型机、服务器、存储设备、SAN交换机等设备，以及IaaS云平台，主要工作包括设备监控告警处理、监控策略完善、故障应急、IT资源规划、成本管理、云平台建设、服务器设备巡检、操作系统安装、硬件微码升级、系统及用户权限管理等。

平台系统运维岗主要是对操作系统、数据库、中间件、PaaS云平台等系统的运维，主要工作包括系统监控、故障应急、系统安装、用户与权限管理、补丁升级、系统配置、数据库信息备份与恢复、数据库信息同步、数据库日志和表空间定期整理、中间件配置、PaaS平台建设及管理等。

应用运维岗主要是对企业应用系统、桌面的运维，主要工作包括应用系统监控及应急、运维规范落地、应用配置管理、应用发布、资源扩容、事件及问题管理、应用系统调优、技术架构评审、应用系统SLA签订、服务台管理、业务咨询管理、数据维护、系统巡检、架构优化、应急演练、数据提取、参数维护等。

安全运维岗主要是对网络、办公、系统和业务等的安全管理，主要工作包括安全及合规规划、常规安全扫描、渗透测试、安全工具和系统研发、安全事件应急处理、安全制度建设、内部安全培训和考核、操作审计、监管风险管理，定期对物理网络、服务器、业务应用、用户数据等进行安全评估，设计安全防线，部署安全设备，及时更新补丁，防御病毒等。

2.职能型运维团队岗位底线工作

运维团队的任何操作都可能引入风险。运维团队要建立底线思维，强化对运维工作的敬畏心。下面结合金融行业特点，梳理职能型运维团队6种常见底线工作。

（1）主动巡检、告警快速响应、协同作战、应急预案

主动巡检 是值班第一项底线工作。IT风险的“事前管理”始终优先于“事后管理”。关键节点的主动巡检是故障防患于未然的关键。下面列举一些巡检建议，包括：由于巡检是例行工作，为了确保工作的有效落地，需要将例行工作任务线上化，将巡检任务落实到具体的人；确保巡检覆盖率，比如制定关键节点、关键业务的例行巡检项，重要系统变更后第一个工作日对变更功能的验证等；建立点面结合的巡检策略，“点”即有针对性地对重要的运行指标进行巡检评价，“面”即通过运行数据主动分析检查；建立完善的巡检机制，比如任务未按时完成时通过机器人催办，通过值班或服务台检查巡检工作的落实情况等。

告警快速响应 是值班第二项底线工作。监控已经深入运维的方方面面，监控工具已经作为一个机器运维岗位贯穿在数字化运维体系中。由于大部分故障由监控工具发现，监控告警响应效率直接影响故障处置效率。评价一个运维组织的监控能力，最主要的不是各个层次的监控工具是否完善，而应该从监控覆盖程度、准确性、监控告警处理及时性等维度评估是否做到“不漏报、少误报、快处理”。围绕“不漏报、少误报、快处理”，监控工具要尽可能减少对运维人员人工操作的依靠，依靠技术实现监控。

协同作战 是第三项值班底线工作。故障管理包括事前、事中、事后三个环节，应急处置主要围绕在事中，故障处置效率直接决定运维组织、IT组织的KPI，直接影响公司效益、客户体验。运维组织很大一部分工作是增加无故障时长，并让故障恢复时间尽量缩短。同时，由于当前信息系统越来越复杂，很多故障并不一定由自身引发，且自身引发的故障也容易影响其他职能型团队运维管理对象，所以运维组织要建立具备故障军事化响应的协同作战能力。

运维手册是容易被忽视的环节，应急预案是运维手册中的底线要求 。应急过程包括异常发现、非常规应急、协作、沟通等已知规程，目标是更快、更顺畅地完成运维工作。在实际实施过程中，因为运维涉及的问题很多，应急预案容易演变成一个越来越复杂的文档，当文档复杂到一定程度时就会变成负担，很难保证及时更新，出现准确性与快速定位问题。

缩小应急预案范围 ：优先保证最小主机、应用程序等层面的重启、切换、回切。

优化应急预案 ：将文档转化为标准化策略卡片，并将策略卡片线上化，以支持更高效的精准定位，并通过提高线上化策略卡片的使用频率、利用反馈等进行优化。

整合在应急场景 ：将线上化策略卡片整合在应急场景，提高利用率，有助于形成不断反馈的闭环，提高预案准确性。

自动化应急预案 ：线上化应急预案有助于将标准化动作自动化，比如针对主机、应用服务、容器等最小运行单元的应急。

（2）架构高可用

架构高可用并不要求运维人员对每一个组件的实现方式很了解，而是要求对何时用、如何用这个组件有准确判断，并能够争取各方资源推进优化，即什么时候优化、如何优化、如何推动。在架构优化过程中，有些思路可以借鉴，比如：

将运维工作前移。

从冷备向热备、负载均衡、分布式改进。

纵向扩展的性能优化，比如增加服务器，换性能更强的服务器等。

横向扩展的性能优化，比如增加节点，拆分数据库，数据库读写分离，增加负载均衡的服务节点，按地区分析应用，同步改异步，限制峰值等。

通常来说，基于纵向扩展的性能优化相对简单，但对于快速扩展的业务系统来说，横向扩展的性能优化效果更好，具体选择哪种需要视实际情况来定，可能有时候几个简单的SQL优化即可快速解决性能问题。

（3）数据备份

“数据”是运维的第一道生命线。对于数据不丢的目标，仅仅做好架构高可用还不够，须设置数据传输、数据存储、数据交换等环节，因为任何一个环节出问题都可能造成数据丢失，需要对关键数据进行备份。下面介绍备份策略与备份手段。

备份策略指需要备份哪些数据、数据的重要性级别、备份数据位置、备份周期、应急方案等信息。备份数据至少包括应用程序、数据库日志、业务数据、配置数据等，备份数据位置包括源数据与目标数据的存储方式，备份周期是针对不同等级的数据实现实时复制、日备、月备等，应急方案是针对备份数据失效的应急方案。

备份手段指建立工具与流程，落实备份保障。在工具方面，针对不同类型的数据，运维组织可以选择不同的解决方案进行备份。除了备份工具外，运维组织还需要制定相关备份流程，比如数据可靠性的保障措施，包括前期保障策略的标准化、备份介质与工具的定性、备份覆盖率，以及备份介质的可用性检查等。

（4）资源交付与成本管理

基础设施资源交付与成本管理主要围绕基础设施资源准备、资源服务交付、资源服务计量3方面。

基础设施资源准备主要准备网络、计算、存储、数据、中间件、数据库等资源。其中，网络、计算、存储资源构成硬件平台。我们通常需要关注硬件资源池，推进应用和硬件的分离，以资源池形式实现对上层应用的灵活支撑；在数据、中间件等软件层面关注多种数据库存储、数据计算、中间件等的建设。在企业资源云化的背景下，上述基础设施资源成为云化要素。基础设施资源准备包括机房设备摆放规划、设备带外网络建设、微码管理与固件升级、设备到货上架、硬件资产登记、OS定期深度巡检和优化、定期关机重启、虚拟化群集资源池规划、资源池容量评估与扩容实施、服务器和存储硬件配置标准制定、虚拟机配置、资产入库管理等。

资源服务交付是以服务交付方式建立资源供需双方的协同。采用一切皆服务的方式交付资源能够高效实现资源交付，以及资源服务弹性、安全、高可用。资源服务产品通常采用IaaS层的服务器、虚拟化、混合云等方式管理，PaaS层的容器、结构化存储等方式管理。云计算支持资源和服务的自助式交付，以便业务人员按需在线申请资源，减轻操作性工作。

资源服务计量是从服务成本角度评估与管理资源，从资源角度围绕SLA、SLO、SLI设计资源分配规则。资源管理团队持续分析相关度量指标，推动服务成本与效率的平衡，促进IT部门从单纯的成本部门转变为服务运营部门。

（5）变更交付

快速达成变更交付是IT的核心价值创造，运维组织需要平衡生产变更的IT交付价值与生产故障影响。一方面，运维组织需要结合自身对基础设施高可用、资源交付、平台软件容量与性能、应用系统稳定性、生产运行指标、生产环境、应用技术架构等全面观测，将运维底线涉及的稳定性要求前移到设计阶段。另一方面，把握每一次重要变更，提前做好资源交付支持、变更前评审、变更影响面分析、变更方案制定、变更关联方协调、变更前演练和压测、变更准入条件评估、变更过程中的实施、变更后的技术及业务检查。

（6）IT服务请求快速响应

严格意义上来说，IT服务请求快速响应可以不作为底线工作，但业务咨询占用了运维组织大量资源，是运维组织对外的一个窗口，这扇窗口做得好不好有时直接影响客户体验。IT服务请求的底线要求是针对服务台或一线应用管理员建立首问责任制，严格落实服务请求及时反馈。在IT服务请求底线要求之上，企业可以考虑让运维人员走进业务、了解业务对应用的期望，并做出反馈。

不同组织还会设置其他一些底线工作内容，比如平台软件运维岗位涉及的容量管理，终端业务运维岗位涉及的终端客户体验管理等。此处简述底线工作是为了强调组织在资源有限的背景下，要优先将资源聚焦在重要的底线工作上。

6.2 横向优化型岗位

横向优化型团队通常是服务于纵向职能型团队，可以是虚拟组织或实体组织，也可以是临时性或长期性组织，具体设立方式需要根据实际决定。下面将横向优化型团队岗位分为横向专项类与工程项目类。

1.横向专项类

运维组织能力的持续改进，需要有专项人员进行横向分析、服务支撑，比如，提高纵向职能型团队工作效率、防范操作风险，需要有运维开发团队搭建合适的监控、巡检、自动化操作等工具；纵向职能型团队要实现运营目标，需要运维开发团队建设更好的数据分析平台；管理规范的有效落地需要不断优化流程，以及建立ITSM。金融企业通常会设立以下横向优化型岗位：IT服务台、流程管理（事件经理、变更经理、配置经理、可用性经理等）、CAB评审委员会、性能管理、容量管理、效能管理、架构管理、运维开发等。下面以变更经理岗位职责为例子进行介绍。

虽然ITIL最佳实践一直被吐槽不够敏捷，但不管是传统企业还是互联网企业的运维组织仍然借鉴ITIL最佳实践，并结合自身特点建立事件管理、问题管理、配置管理、变更管理、发布管理、服务级别管理、可用性管理、服务持续性管理、知识管理及供应商管理等的工作机制。以成长型思维看，组织需要建立流程机制，制定可量化的绩效指标，主动监测分析指标，发现存在的问题，制定优化方案，并跟踪优化方案的最终落地。变更经理就是为了持续提升变更管理水平而设置的岗位角色，是运维组织变更管理的运营角色，是运维组织变更管理的策划与组织角色。变更经理主要负责建立变更管理规范、工作机制、整体实施计划，统筹资源配置，并对变更管理过程工作有效性进行监测，主要的岗位职责如下。

落实决策层要求的变更管理目标，负责对接IT组织对IT交付、IT风险防范等的要求，并适配到变更管理规划、里程碑、实施计划、实施方案。

负责制定、修订、发布具体的制度、规范、标准，并对变更管理涉及的制度、标准、流程等执行情况进行监测，主动持续优化。

负责变更管理具体的流程设计，并推动流程线上化，以及线上流程中标准化工作的自动化。

制定变更日常工作机制，并确保常态化工作机制的落地，比如：建立规范前移工作机制，制定并发布生产变更管理窗口，推动变更窗口的变更评审、重大项目的工作汇报，落地变更管理流程，验证变更效果等。

负责制定可衡量的变更管理绩效指标，并持续复盘变更管理执行情况，定期组织评价变更管理工作效果，制定考核制度。常见的指标包括变更总数、变更失败量/率、未按计划执行变更量/率、紧急变更量/率、被拒绝或退回变更量/率、变更负责人平均处理变更数量/时长、引发事件的变更数/率、未准时执行CAB评审的变更数/率、客户满意度、变更文档不全数/率、非CD发布的变更次数、发布导致事件数/率、按时发布数/率、平均带缺陷发布的数/率、不在制品库的软件包。

对决策层制定的战略、目标以及实施计划等工作进行监测、督促，确保常态化变更管理工作得到落实。

变更经理是一个需要综合能力的岗位，具备以下特征：有项目管理经验，沟通协同能力较好，熟悉运维工具体系，了解一线运维工作，有数据运营思维，学习能力较好。

2.工程项目类

运维工作中，满足有明确目标、有时间要求、可落地、涉及多方协调的工作基本都适合用项目管理方式管理，比如机房搬迁、重要业务系统上线、数据库基线管理、平台软件补丁升级、定期应急演练、行业演练、重要系统运行分析等。下面以重要系统运行分析工作为例进行介绍。

重要系统运行分析项目目标是帮助重要系统运维负责人主动掌控运行状况，落实运维分析计划。以项目管理方式，安排项目经理牵头，组织一个虚拟的、不同领域的技术专家小组制定技术方案，项目经理控制好进度、范围、质量与成本，统一获得组织资源，横向推动相关方案的落地，并让纵向运维团队持续进行运维分析。

进度管理 。根据参与运维分析涉及的系统重要程度与评估主题，建立不同周期的评估计划，比如月度、季度分析评估。为了将评估有效落地，将评估工作任务化，项目牵头人负责整体监督任务执行。如果这项工作是首次发起，还要制定一个相对通用、可落地、可持续的运维分析方案，并挑选个别系统作为试点落地。

范围管理 。围绕SLA、SLO、SLI确定系统稳定性保障目标，从应用系统的可用性、重点业务功能稳定性与运营指标，抽象影响稳定性的量化指标，比如系统资源、数据库、中间件、交易性能（交易量、成功率、耗时）、客户体验、容量、应急效率等，建立指标的运行基线，通过对指标与基线进行比对，发现影响稳定性的潜在风险。

质量与成本管理 。持续复盘运维评估结果对风险防范的影响，以及给组织带来的成本收益比，一方面根据分析情况调整进度、评估范围、优化执行，另一方面加强工具平台的赋能，减少评估工作成本。

另外，由于运维分析工作涉及关联系统的协作，为了让运维分析更加高效，除了联合应用运维管理员参与，企业还需要联合其他团队支持，比如：为了分析数据库的性能，需要DBA提供一些可操作的标准化方法；为了试点方案可行，还需要领导决策层支持等。

6.3 从SRE到BRE

适应性运维系统建设是一个围绕“需求、改变、风险、适应”4个节点，螺旋上升的循环。这个方法同样适用于组织里个人岗位能力的持续提升。

1.运维组织的需求、改变、风险、适应

IT部门面临加快交付效率、提升运维质量的挑战 。以金融行业为例，按照金融业信息技术“十三五”发展规划目标，“十三五”期间金融经营机构的重点任务主要包括：进一步完善金融信息基础设施，健全网络安全体系，推动新技术应用，深化金融标准化战略，优化信息技术治理体系，提供更加 集约、高效、安全 的金融信息技术服务。信息化时代，国内领先的金融企业构建了大量IT系统，并利用金融信息化契机获得成功。随着市场复杂性与不确定性不断增加，线上应用的寿命越来越短。以苹果应用市场为例，2019年上半年平均每天下架的应用接近2300款，环比增长45.58%。前端应用只有快速响应政策环境、监管要求、用户需求，才能在复杂的大背景下获得竞争力。但在信息化传统封闭架构下，金融企业IT系统形成一个个烟囱，缺乏信息互联和共享，为了满足日益多样化的业务需求，主要采用先竖向满足业务，再横向打通的方法，导致交付业务需求的成本越来越高。所以，如何确保在系统稳定和业务合规的前提下提高交付能力，是金融企业IT部门面临的第一个挑战。另外，生产系统业务连续性保障不容乐观。以证券行业交易所为例，2022年以来，全球各地交易所技术故障风险事件频发：德国证券交易所于2022年4月和7月出现软件故障，导致中欧及东欧几个国家衍生品和股票交易受阻；2022年8月新西兰交易所连续6天受到网络攻击，被迫多次中断交易；2022年10月东京交易所系统切换异常，导致全天暂停交易；2022年10月墨西哥交易所交易引擎断开，暂停交易。如何在企业快速发展过程中加强业务连续性保障，是第二个挑战。

基础架构云化、云原生应用兴起正当其时 。交付效率与运行质量的挑战可以转换为以下目标：降低运营成本，让业务保持高效弹性，保障信息安全，提高交付效率、降低业务连续性风险等。这需要引入架构云化、云原生技术。当前，大部分中大型企业确定了基础设施层面云计算战略，一些有能力或对信息安全要求高的企业，重点推进私有云建设，并结合大型云服务厂商提供的公有云或行业机构提供的行业云，打造混合云的运营模式。可以预想，云计算集中了企业资源，通过集约化带来的成本优势，将为企业提供更稳定、高弹性、低成本的基础设施、数据库、中间件，及其他平台层的PaaS组件。随着云基础设施的落地，企业不是简单地将现有应用系统分步搬上云，还面临如何更好地利用云计算弹性扩展、分布式、按需获取、安全可靠等优点的问题，这就迫使在设计应用架构时要考虑将来能够运行于云环境，由此带动了云原生应用的兴起。对于云原生，云原生计算基金会（CNCF）做出以下定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。”云原生架构的大规模应用对平台技术、人员技能、研发与运维方法等的要求极高，容易产生稳定性风险。

云化基础设施、云原生方法提高了上层应用的交付效率，但将复杂性落在了运维侧 。云化基础设施使得企业不再需要按项目或需求去购买、部署、维护硬件和系统软件，无须资源消费方参与复杂硬件及系统软件的维护，实现了基础设施、系统软件运维标准化，用自动化替代了原来大量操作性工作。但云化基础设施需要对企业原有系统进行改造。传统企业大部分重要交易系统均采用烟囱式部署架构，且运行多年后，现有系统架构越来越复杂，“动则生变，变则异常”已成常态。云原生技术虽然能帮助业务快速迭代，但广泛使用的开源技术与分布式节点让架构更复杂了，同时软件代码与项目交付流程也发生了改变，提升了业务运维复杂性。在技术应用上，运维组织还需要关注新技术的选择时机，因为引入新技术带来的“坑”需要经过一系列质量内建手段、线上生产事件来填。

以业务为中心，推动运维能力提升，配套运维平台化建设是当前行之有效的手段 。行业不同，对业务连续性的理解并不一样，比如Google提出的一个DevOps原则——愿意承担一部分试错带来的损失，在金融行业则不适用。以证券实时交易为例，业务停滞一秒均可能带来巨大损失，证券自身的业务特点以及外部监管“零容忍”要求决定信息系统业务连续性诉求会高于其他行业。确保业务连续性成为证券行业IT运维的核心任务。业务连续性管理的总体目标是提高公司的风险防范能力、有效降低非计划的业务中断、运维操作风险，对于首次出现的未知异常能够量化分析并快速定位，确保在重大灾难性事件发生后能按计划恢复业务。在这样的行业背景下，运维团队肯定不是仅会用应急工具，而应该深耕业务并运用工程能力。运维平台化是对运维组织赋能，而不是替代运维组织。运维平台需要围绕运维组织的价值创造链，持续丰富“监、管、控、析”工具平台体系，不断推进工作线上化、自动化、服务化的落地。运维岗位不仅要具备平台设计能力，还要深入理解信息系统架构、逻辑、业务。在当前系统越来越多而人员规模基本不变的背景下，企业对运维人员能力要求极高。

2.从Google SRE到BRE

为了应对上述风险，企业需要推动运维岗位能力建设。Google SRE岗位能力要求经常被用来作为目前运维岗位能力建设的方向。下面结合金融企业的特点落地SRE岗位能力。

（1）SRE岗位能力

与传统运维岗位相比，SRE（Site Reliability Engineering，站点可靠性/稳定性工程师）更加强调可靠性与工程能力。SRE的主要职能是保障信息系统平稳运行。SRE鲜明地强调了“可靠性”保障，聚焦资源到尽可能增加MTTF（不出故障的时间）和缩短MTTR（出故障后的恢复时间）两个指标上。SRE需要围绕这两个关键指标提升系统运行风险排查与解除以及事件发生后的应急能力。

SRE日常工作重点包括需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、值班、应急事件响应、故障处置、影响分析、应急复盘、软件研发、项目站立会、系统设计、项目进度推进、工具落地推广等。可以看到，SRE区别于传统运维岗位的第二个特征是“工程能力”，狭义地讲是软件开发能力，但又与业务开发有些区别，SRE的开发偏向于提升业务连续性的开发，业务开发偏向于业务功能开发。

（2）BRE能力

首先，金融行业更加强调业务连续性，因此运维角色必须懂业务。去掉业务属性，运维团队就失去了灵魂。一个好的运维人员不仅能操作各类监控工具、应急恢复、咨询解答、变更操作等，还应该在整个IT团队中 掌握全局， 包括所负责系统应用部署架构、上下游系统关系、最小功能模块失效影响、容量性能分析等。

其次，从Google SRE来看，SRE是一支独立成长于原有运维团队的组织，是一支全新投入的人力资源。但金融企业的运维团队通常比较稳定，相比研发团队根据业务需求不断扩大，运维团队规模通常不变。所以，运维团队的转变重点是对现有运维人员进行能力建设。

另外，运维团队中资深工程师比较多。资深说明运维人员沉淀了更多经验，而经验有助于在业务连续性保障工作中更快定位问题。但从现实情况看，资深导致个人学习意愿与学习能力下降，所以让现有运维团队人员都掌握软件开发技能并不现实。如何既发挥好运维人员的经验，又培养团队成长型思维，是一个难点。

所以，运维团队可以基于BRE角色建设，提高业务连续性保障能力，再推动提高业务交付效率、辅助提升客户体验、提升IT服务质量。如果要勾画BRE角色，我们可以考虑以下5个能力（见图6-2）。

系统架构师 ：清楚应用系统部署架构，懂应用逻辑架构，掌握上下游系统架构、高可用架构、容灾架构等。

业务架构师 ：清楚核心业务功能逻辑，当核心业务功能不可用，或者一笔关键交易异常时，能够及时发现，并快速应急解决，或利用混沌工程挖掘业务风险点。

可用性工程师 ：善于利用工具，落实可用性改进、容量规划、延时优化、性能优化、业务架构优化、应急演练、应急预案编写等工作。

运营分析师 ：具备数据思维，能够让系统运行、业务运行、客户体验提升、流程管理等数字化，并利用掌握的运营数据驱动研发、测试、业务持续优化。

运维操作员 ：落地各类监控发现、舆情感知、故障应急、根因分析、系统巡检、咨询反馈、变更交付、IT服务等工作。

3.加强适应性能力

结合上面提到的系统架构、业务架构、可用性、运营分析、运维操作5个维度，我们可将运维工作分为被动性与主动性两类。

被动性工作：根据事件增加监控指标，扩大监控覆盖面，提升监控处理及时性，提升故障应急处置自动化，优化故障应急协同机制，落实故障后问题的闭环跟踪，提高生产变更发布自动化水平，建立生产问题咨询反馈的服务机制等。

主动性工作：制定系统架构标准，前移运维工作到系统设计阶段，构建可视化的应用上下游调用链路，持续推进业务逻辑评估，加强对业务核心功能及数据的理解，推进混沌工程，挖掘系统风险点，落实故障应急复盘机制，推进系统性能与容量、终端拨测、客户体验等分析工作，加强系统效能分析，推动低效系统退出机制。

可以看到，被动性工作主要面向传统运维的业务连续性保障工作，主要实现业务线上化、自动化；主动性工作主要是利用运维人员对架构、业务、运行数据的分析能力，提升全局可控能力，主要实现业务数字化、服务化。

最后，虽然金融企业的BRE岗位不强调软件开发能力，但要具备善于运用运维平台提升被动性与主动性工作的适应性能力。建议由一支独立职能的运维工具研发团队，根据BRE实际工作场景，构建自动化、数据驱动的运维平台。运维工具研发团队的定位是一支赋能BRE的工具开发团队，需要具有以下能力。

理解BRE的工作场景，对BRE及管理决策岗位的痛点保持敏感，能够抽象高频、高价值的通用场景。

沉淀“监、管、控、析”平台能力，具备快速落地应用的能力。

保持对新技术及外部技术应用的热情。

建立运维平台能力成熟度模型，推动平台化持续提升。 BNRwMRWKlzOebv2+zt0kgCuj/ks0iu5nwJbjuvo90QBldMEnKoTlAlIgJtcLyth4