信息系统管理工程师-运维人员管理与核心运维过程（上篇）

一、引言

1. 知识点定义与定位

运维人员管理与运维过程管理是软考中级信息系统管理工程师考试中信息系统运维管理模块的核心内容，分值占比约 10%-15%，同时也是 IT 服务管理体系落地的核心支撑要素。其中运维人员管理是运维服务能力的核心载体，解决 "谁来做" 的问题；运维过程管理是运维服务标准化的核心主线，解决 "怎么做" 的问题，二者共同构成了 IT 服务管理体系的基础框架。

2. 发展脉络

运维管理的发展经历了三个核心阶段：第一阶段为 2000 年之前的被动运维阶段，以设备维护、故障抢修为核心，无标准化人员与过程管理要求；第二阶段为 2000-2015 年的标准化运维阶段，以 ITIL v2、ITIL v3 为核心框架，明确了人员岗位划分、过程管理规范，形成了服务级别管理、事件管理等标准化过程；第三阶段为 2015 年至今的智能化运维阶段，在标准化基础上融合大数据、人工智能技术，人员能力要求向复合型升级，过程管理向自动化、智能化演进。

3. 内容覆盖

本文将系统讲解运维人员管理的核心框架、4 个核心运维过程的实施方法、行业标准、典型案例及软考考点，覆盖考试中选择题、案例分析题的核心命题范围。

运维人员管理与过程管理关系框架图

二、运维人员管理核心框架

1. 人员储备管理

（1）核心定义与目标

人员储备是指组织为应对人员流动、技能缺口、业务扩张等风险，提前开展的人员能力备份与梯队建设活动，核心目标是保障运维服务的连续性，避免因关键人员缺失导致服务中断。

（2）三个实施阶段

• 人员储备需求分析：需综合三个维度要素，一是风险维度，包括人员年离职率（运维行业平均离职率为 15%-20%）、关键岗位集中度；二是容量维度，包括现有人员负荷率、未来 6-12 个月业务增长带来的人员需求；三是能力维度，包括现有人员技能覆盖率、骨干人员占比。最终输出关键岗位清单，通常运维核心关键岗位包括核心系统数据库工程师、核心网络工程师、服务项目经理三类。
• 制订人员储备计划：由人力资源部门联合运维管理部门共同编制，核心内容包括：关键岗位储备数量（通常关键岗位储备比例不低于 1:1.2）、储备方式选择、培养周期定义、考核指标（如储备人员转正率、上岗后 3 个月绩效达标率），计划需经管理层审批后生效。
• 执行监控与优化改进：将储备计划执行情况纳入人力资源部门和运维部门的绩效考核指标，每月跟踪储备人员到岗率、技能达标率，每季度对储备效果进行评估，优化储备方式与数量。

（3）常见储备方式对比

储备方式	核心特点	适用场景	优点	缺点
增量机动储备	额外招聘 10%-15% 的机动人员，在岗参与实际工作	人员流动率高、业务增长快的中大型企业	响应速度快，人员能力匹配度高	人力成本较高
人才梯队储备	建立初级 - 中级 - 高级 - 管理岗的梯队培养体系	长期稳定的运维团队	人员归属感强，技能沉淀充分	培养周期长（通常 1-2 年）
合作机构储备	与培训机构、人力资源外包机构签订储备协议	季节性需求波动大的场景	按需调用，固定成本低	人员适配度低，响应速度慢
岗位角色备份	同一技能方向配置至少 2 名人员，交叉备份	关键技术岗位（如数据库、核心网络）	连续性保障能力强	人力成本较高

人员储备阶段流程图与储备方式对比表

2. 岗位结构管理

（1）核心分类与职责

运维岗位根据工作性质分为三类，三类岗位的人员配置比例通常为管理岗：技术支持岗：操作岗 = 1:3:6：

• 管理岗：核心职责是运维服务的全生命周期管理，包括客户需求挖掘、服务级别协议谈判、服务质量监控、团队资源协调，典型岗位包括服务总监、服务项目经理、质量经理，要求具备较强的沟通能力、项目管理能力、风险控制能力。
• 技术支持岗：核心职责是运维技术体系建设、复杂技术问题解决、技术方案制定，典型岗位包括主机工程师、网络工程师、数据库工程师、应用系统工程师，要求具备对应领域 3 年以上技术经验、故障排查能力、技术文档编写能力。
• 操作岗：核心职责是按照运维规范和操作手册执行标准化运维任务，典型岗位包括呼叫中心热线工程师、系统监控工程师、机房值守人员，要求具备基础 IT 知识、较强的执行力、规范遵从能力。

（2）典型案例

某省级政务云运维团队共 50 人，其中管理岗 5 人（服务总监 1 人、服务项目经理 2 人、质量经理 2 人），技术支持岗 15 人（主机工程师 3 人、网络工程师 3 人、数据库工程师 4 人、应用系统工程师 5 人），操作岗 30 人（热线工程师 10 人、监控工程师 12 人、机房值守 8 人），岗位配置比例符合行业最佳实践，2023 年服务可用性达到 99.95%，SLA 达标率 99.2%。

三、核心运维过程（上篇）实施框架

运维过程管理遵循 ITIL 4、ISO/IEC 20000-1:2018 国际标准，核心目标是通过标准化流程将人员、技术、资源进行整合，实现运维服务的可量化、可重复、可改进。本次讲解前 4 个核心过程：服务级别管理、服务报告管理、事件管理、问题管理。

1. 服务级别管理

（1）核心定义与目标

服务级别管理是对运维服务的级别进行定义、记录和管理，并在可接受的成本之下与客户达成一致的管理过程，核心目标是平衡服务质量与服务成本，确保运维服务满足客户的业务需求，避免服务过度或服务不足。

（2）核心实施步骤

• 服务目录编制：服务目录是组织为客户提供服务内容的列表，需以客户业务语言描述，避免技术术语，核心内容包括服务名称、服务内容、服务级别、服务价格、响应时限，例如某企业服务目录中 "核心业务系统运维服务" 明确说明 "服务可用性 99.9%，月度停机时间不超过 43 分钟"，而非描述 "采用双活架构、集群部署" 等技术内容。
• 服务级别协议（SLA）签订：SLA 是运维服务提供方与客户之间的正式书面协议，核心内容包括：服务范围、服务时间（如 724 小时 / 58 小时）、服务目标（可用性、响应时间、解决时间）、双方职责、变更控制机制、投诉处理流程、违约罚则。例如某金融企业 SLA 中明确 "核心交易系统故障 P1 级别，10 分钟内响应，30 分钟内恢复，每超时 1 分钟扣除当月服务费的 0.1%"。
• 服务级别监控与改进：建立 SLA 指标监控体系，每月统计 SLA 达标情况，针对未达标的指标分析原因，制定改进措施，形成 "定义 - 监控 - 报告 - 改进" 的闭环管理。

服务级别管理闭环流程图

2. 服务报告管理

（1）核心定义与目标

服务报告管理是对运维服务绩效、服务成果、存在问题进行系统性整理并向相关干系人汇报的过程，核心目标是实现运维服务的透明化，让客户、管理层及时了解服务执行情况。

（2）关键成功因素

• 清晰的受众定位：针对不同受众设计不同报告内容，面向客户的报告重点展示 SLA 达标情况、业务价值、问题改进情况；面向管理层的报告重点展示成本投入、资源利用率、风险情况；面向技术团队的报告重点展示技术指标、故障详情、技术改进需求。
• 明确的报告周期：通常分为日报（面向内部运维团队，展示当日故障、监控情况）、周报（面向管理层，展示周度服务情况）、月报（面向客户，展示月度 SLA 达标、服务成果）、年报（面向客户高层，展示年度服务价值、下年度服务计划）。
• 简洁的呈现形式：优先采用图表化展示，核心指标用数据量化，避免大段文字描述。

3. 事件管理

（1）核心定义与目标

事件管理是对运维过程中发生的所有意外事件进行快速处理的过程，核心目标是尽可能快地恢复服务，最小化对业务的负面影响，事件管理的范围包括三类：一是故障类，如应用系统不可用、磁盘占用率超过 90%、服务器硬件停机；二是服务请求类，如申请新云主机、密码重置、账号开通；三是咨询类，如系统操作咨询、服务内容咨询。

（2）核心实施步骤

• 事件接收和记录：通过服务台统一接收所有事件，记录事件发生时间、上报人、事件描述、影响范围、优先级，所有事件必须全程留痕，不得遗漏。
• 分类和初步支持：对事件进行分类（故障 / 服务请求 / 咨询）和优先级定级（通常分为 P1-P4 四级，P1 为最高优先级，影响核心业务正常运行），服务台能直接解决的事件（如密码重置、操作咨询）直接处理，无法解决的派单给对应技术支持岗。
• 调查和诊断：技术工程师对事件进行排查，定位故障原因，若超过规定时限仍未解决，启动升级流程，上报更高层级技术专家。
• 解决与恢复：找到解决方案后执行恢复操作，验证服务恢复正常后告知用户。
• 事件关闭：用户确认服务恢复正常后关闭事件，完善事件记录，包括故障原因、解决方案、处理时长。

（3）行业最佳实践

根据 ITIL 4 最佳实践，事件管理的核心指标包括：事件响应及时率（P1 级不低于 99%）、事件解决及时率（P1 级不低于 95%）、服务台一线解决率（不低于 70%）、事件平均解决时间（MTTR）。某互联网企业通过事件管理流程优化，将 P1 级故障平均解决时间从 45 分钟降低到 22 分钟，年减少业务损失约 2000 万元。

事件管理流程示意图与优先级定义表

4. 问题管理

（1）核心定义与目标

问题管理是对导致事件发生的根本原因进行分析和解决的过程，核心目标是消除根本原因，减少同类事件的重复发生，与事件管理的核心区别是：事件管理关注 "快速恢复服务"，问题管理关注 "从根源解决问题，避免再次发生"。

（2）核心实施内容

• 问题控制：对重复发生的事件、重大故障进行根本原因分析，常用方法包括 5Why 分析法、鱼骨图分析法，定位问题的根本原因，例如某系统每月出现 3-4 次内存溢出导致的系统宕机，经问题分析发现是应用程序内存泄漏导致，而非简单的重启服务器。
• 错误控制：对定位到的根本原因制定解决方案，实施修复，验证修复效果，例如针对内存泄漏问题，研发团队修复代码缺陷后上线，后续未再出现同类故障。
• 主动问题管理：定期对事件数据进行分析，识别潜在的问题隐患，提前进行优化，避免事件发生，例如某企业通过分析近半年的事件数据，发现存储 IO 使用率接近阈值，提前进行存储扩容，避免了后续可能出现的存储性能瓶颈。

（3）适用范围

凡是不能容忍再次发生的事件、故障、问题或错误，都可以纳入问题管理的范畴，通常 P1 级故障、重复发生 3 次以上的 P2 级故障、可能导致重大业务损失的潜在隐患都必须启动问题管理流程。

事件管理与问题管理关系对比图

四、行业标准与工具支撑

1. 相关标准要求

上述过程均符合以下国际国内标准要求：

• ITIL 4：将服务级别管理、事件管理、问题管理纳入服务运营核心实践，明确了过程的核心输入输出、角色职责、关键指标。
• ISO/IEC 20000-1:2018《信息技术 服务管理 第 1 部分：服务管理体系要求》：明确要求组织建立服务级别管理过程、事件管理过程、问题管理过程，并形成文件化的流程规范。
• GB/T 24405.1-2009《信息技术 服务管理 第 1 部分：规范》：等同采用 ISO/IEC 20000-1:2005，是国内 IT 服务管理的核心国家标准。

2. 常用工具支撑

• 服务台工具：如 ServiceNow、 Zendesk、国产 ITSM 工具，支持事件接收、记录、派单、跟踪全流程管理。
• 监控工具：如 Zabbix、Prometheus、Grafana，实现系统性能、故障的自动监控，自动生成事件告警。
• 数据分析工具：如 ELK Stack、Tableau，支持事件数据统计分析、服务报告自动生成。

运维过程工具支撑架构图

五、软考考点与应试指南

1. 高频考点梳理

• 选择题考点：人员储备的三个阶段、三类运维岗位的职责区分、服务级别管理的核心定义、SLA 的核心内容、事件管理与问题管理的区别、事件管理的范围、问题管理的核心目标。
• 案例分析考点：给出企业运维管理的案例场景，要求分析人员管理存在的问题、事件管理流程的缺陷、SLA 签订的注意事项、问题管理的改进措施。

2. 易错点提示

• 注意区分服务目录与 SLA：服务目录是服务提供方公开发布的服务内容列表，SLA 是与特定客户签订的针对具体服务的协议。
• 注意区分事件与问题：事件是已经发生的影响服务的意外情况，问题是导致事件发生的根本原因。
• 注意运维三类岗位的职责边界：管理岗不负责具体技术操作，技术支持岗不负责标准化操作任务，操作岗不负责技术决策。

六、总结与展望

1. 核心要点总结

• 运维人员管理核心包括人员储备与岗位结构两部分，人员储备分为需求分析、计划制定、执行监控三个阶段，三类岗位分别为管理岗、技术支持岗、操作岗，各司其职。
• 服务级别管理核心是通过服务目录、SLA、监控改进的闭环，平衡服务质量与成本。
• 事件管理核心是快速恢复服务，问题管理核心是从根源解决问题，避免同类事件重复发生。
• 服务报告管理核心是根据不同受众需求，量化展示运维服务绩效。

2. 后续预告

下一篇文章我们将学习运维过程的后五个管理过程：配置管理、变更管理、发布管理、可用性和连续性管理、系统容量管理，覆盖运维过程管理的剩余核心考点。

课后小测

（）是对运维服务的级别进行定义、记录和管理，并在可接受的成本之下与客户达成一致的管理过程。

A. 服务级别管理

B. 服务报告管理

C. 事件管理

D. 问题管理

答案：A