售后服务方案

XXXXX网络设备项目。

1.2 项目背景描述

随着互联网应用的快速增长，以及下一代互联网的加速推进，短信、网游、语音以 及视频宽带业务的日益火爆，电子商务的再度兴起， IDC 市场迅速升温， IDC 业务收入 迅速增长，IDC 业务的客户群也迅速增大。 为了抢占潜在客户资源， 大力推广 IDC业务， 这样就需要建设一个侧重中、高端客户，兼顾低端客户需求的 IDC 机房系统。

1.3 服务期限及范围

为 XXX核心网络设备(含 2 台防火墙， 2 台交换机， 2 台路由器)，其检修和维护。我公 司将按质按量完成 XXX核心网络设备维护修理维护服务。

1.4 实施目标

为 XXX核心网络设备提供优质的维护修理服务，并对 2 台防火墙， 2 台交换机， 2 台路 由器统提供卓越的技术支持与运行维护服务。保证 2台防火墙， 2 台交换机， 2台路由器运 行稳定。

1) 我方通过严格的修理维护服务， 保证相关本次所涉及的相关软硬件的高效稳定运行。 2) 我方具备应急处理能力并制定了完善的应急预案， 减少计划内和计划外的停机时间， 最终能

够保障电力业务核心系统每周 7 天×24 小时不间断稳定运行。

3) 我方定期对现有软硬件平台系统运转状况进行巡检、跟踪和分析，科学地预测和掌 握软硬件

平台系统的性能状态，提出科学合理的扩容和升级建议。

4) 我方在维护中熟悉各主机上承载应用系统， 结合 IT 系统和业务应用的具体实际情况， 查漏

补缺，提出整改建议，配合应用厂商不断优化系统整体性能，提高系统运行整体效 率。

1.5 术语定义

1) 业主方： xxxxx 团有限公司。 2) 故障级别定义如下：

P1级故障：重大故障，系统瘫痪，无法运行，业务丢失。 P2级故障：系统部分设备故障，影响和了部分业务运营。

P3级故障：一般性技术故障，发现系统和设备的技术问题，但系统和业务仍可正常 运行。 P4级故障：在系统功能配置、运维管理方面需要信息或支援，对用户的业务几乎无 影响。

2. 总体实施方案 2.1 服务流程

xxx 有限公司将根据 XXX核心网络设备(含 2台防火墙，2台交换机，2 台路由器) 服务内

容制定了相关的服务流程， 以下流程适用于本项目的含防火墙， 交换机， 路由器 流程。

2.1.1 高级故障诊断及检修流程

1) 针对系统、设备发生的一级、二级故障进行响应，分别在规定时间内进行维修、恢 复服务。其

中紧急重大故障要求 15 分钟内到达现场处理。

2) 我方提供服务相当于原厂技术服务水平。 并提供电话或现场技术咨询和技术支持服 务。

服务流程图

服务流程说明

序号 步骤名称 责任人 说明 服务台人员接受来自用户上报的故障以及各类服务请 求。在验证用户基本信息后，服务台人员在服务管理平台上登 记一条故障信息并进行跟踪和处理，并创建故障事件单。 服务台人员判断故障是否重大事件，如重大事件将立 1 服务台响应 服务台 刻通知现场支持人员到现场。如不是重大故障，将根据故障级 别及故障类型，安排工程师进行故障处理 如果是一条重复事件，则新建该事件记录后，更新原 有事件为“主事件” ，并建立重复事件与原有事件的关联关系。 如果是一条复发事件，则创建一个新的事件单，复制 原始事件单的内容，并说明这是复发的事件。 2 故障现场相应 现场支 持人员 根据服务台所描述的基本故障情况，现场支持人员将 在 15 分钟内到达故障现场，为用户处理故障 服务台人员根据事件分类表确认事件的分类，根据事 件的影响度和紧急度，为事件分配优先级。 分析故障原因，在知识库中查询是否有解决方案，制 定3 远程调查与诊 断 服务台 支初步的故障处理方案。 持人 员 如故障是由于设备硬件引起或远程无法处理时，将通 知现场维护人员，到现场处理处理故障。 进行调查诊断，尝试解决，必要时联系第三方供应商 协助处理。 现场支持人员在现场判断故障情况，根据故障的具体 情4 现场调查诊断 现场支 持人员 况，制定解决方案。 判断故障是否需要更换部件，如需更换备件，我方将 联系仓管调出设备配件，并负责设备的安装和卸载。 5

更换设备或部 件 现场支 持人员 更换完设备后再对故障进行检测，如故障未被处理， 将继续对故障进行分析，彻底解决故障问题。 序号 步骤名称 责任人 说明 按照制定好的解决方案对故障进行处理。 6 解决与恢复 服务台、 现场支 持人员 判断实施解决方案是否可行，并制定变更方法。 实施成功后，详细记录解决方案或变通方法。 将故障处理情况提交至知识管理。 7 事件关闭 服务台 支持人 员 计划。 关闭事件。并对故障记录进行归档，再制定用户回访 向用户确认故障是否已得到解决。 8 用户回访 服务台 支持人 员 确认用户是否报告其他问题。 用户反馈故障处理情况，并对本次服务进行评价。 2.1.2 设备调优流程

1) 针对长期出现资源瓶颈的设备进行分析，提出解决方案或优化方案。 2) 对系统进行定期评估，给出评估优化方案。

服务流程

服务流程说明

利用有效的工具对设备进行检测。 1 设 备 性 能 检 服务器、存储支持 工程师 测 对设备进行健康检查，标记存在资源瓶 颈的设备。 根据标记的资源设备进行设备统计 对资源瓶颈的设备进行故障原因分析， 2 统计资源瓶 颈的设备数 量 服务器、存储支持 工程师 判断资源瓶颈的问题是由何种原因所引起。 分派问题到各个专业工程师设计解决方 案。 3 硬件问题分析 服务器、存储支持 工程师 分析设备硬件上的资源瓶颈问题，列出 引起此故障的原因 分析操作系统上的资源瓶颈问题，列出 4 系统问题分析 操作系统支持工程 师 引起此故障的原因 分析应用平台上的资源瓶颈问题，列出 5 平台问题分析 应用平台支持工程 师 引起此故障的原因 分析数据库上的资源瓶颈问题，列出引 数据库问题分 数据库支持工程师 起此故障的原因 对列出服务器、存储硬件问题逐条给出 处理意见与优化方案。 对列出操作系统问题逐条给出处理意见 与优化方案。 6 析 设计服务器、 服务器、存储支持 工程师 7 存储解决方 案 设计系统解 决方案 设计平台解 决方案 设计数据库 解决方案 操作系统支持工程 师 8 应用平台支持工程 师 对列出应用平台问题逐条给出处理意见 与优化方案。 9 数据库支持工程师 对列出数据库问题逐条给出处理意见与 优化方案。 10 整合各技术支持工程师给出的解决方 案。 11 整合方案 我方项目负责人 对解决方案的内容进行审核，确保处理 意见的安全和有效。 制定实施计划，并将方案提交给业务部 门。 业务部门负责人对整合的方案进行审 12 业务部门审 批 设备负责人 批。 按实施计划通知每个人设备负责人。 工程师按照最终的实施计划和方案对设 优化实施 13 各技术支持工程师 备进行调优工作。 2.1.3 备件保修和更换流程

1) 当设备出现故障时，我方应及时进行检查、维修或更换故障部件。

2) 如果硬件设备故障， 保证在 2 小时内提供不低于故障设备规格型号档次的备用设备 替代使

用，直至故障设备修复为止，以最大限度保证业务系统不间断地正常运行。

3) 若需要更换部件，其更换的部件必须是原厂的部件，与原有部件具备同等的质量和

性能

服务流程图

服务流程说明

现场检查，判断故障引起的原因和故障位 1 故障设备检查 现场支持人员 置 判断故障是否能现场处理，例如通过配置 等方法解决故障，即现场处理。 2 现场维修 现场支持人员 对故障进行处理，通过技术手段等解决故 障问题。 故障由于设备的硬件引起，难以现场立刻 3 提供备件 现场支持人员 处理，我方提供同等设备型号和功能的配件给用户 使用。 现场卸载故障的设备。 4 现场安装与卸载 设备维修人员 安装我方提供的备件设备。 判断设备是否已经过保。并制定维修计 划。 5 故障设备维修 设备维修人员 设备未过保，通知设备的提供商对故障设 备进行修复。 设备已过保，我方提供或采购相应的备件 和部件，对设备进行维修。 6 设备提供厂商维修 设备提供厂商 设备提供厂商对故障设备进行修复 我方安排专业对技术人员更换或维修故 障7 提供所需的备件或 部件进行维修 设备维修人员 设备。 将拆卸的故障部件进行封存，交还给设备 提供商。 设备维修成功后，我方现场支持人员到现 场对修复好的设备进行复位。 8 故障设备复查 现场支持人员 检查设备的运行情况，如设备还存在故障 问题，我方将继续对故障进行处理与解决。 2.1.4 特保服务流程

1) 按照公司要求，对于特殊时期必须保障设备运行的， 我方根据要求驻场值守和服务， 完成特

殊时期保障任务。

2) 需预计每年安排约有 2 个月的特保时间 服务流程图 服务流程说明

现场值班人员制定值班服务计划 1 制定特殊时 期值班计划 现场支持人员 值班计划包含人员的联系方式与相关设备系 统的负责人的联系方式 业务部审批值班服务计划 2 业务部门审 批 设备负责人 如服务计划未能满足用户的需求， 将退回现场 值班的人员重新设定值班计划。 按计划是时间地点到现场进行值班工作。 3 值班 现场支持人员 记录值班所需的相关表格 遇上重大事件及时通知设备负责人员 提交设备巡 检汇报设备出现的安全隐患。 设备维修人员 提交当天的值班记录和相关资料。 4 报告 2.1.5 系统补丁通知及推荐流程

1) 预防式补丁服务：我方在已知服务器、存储软、硬件缺陷可能导致潜在问题的情况 下，将通过

配置管理或巡检等方式对用户服务器进行增补软件分析并提出版本升级 建议，并由用户进行相关业务、客户影响分析后确认进行。

2) 响应式补丁服务：当设备出现故障后，我方对故障进行分析并确认是软件缺陷所导 致的故障，

我方将提供针对该软件缺陷的软件补丁程序，并由用户进行相关业务、 客户影响分析后确认进行。

服务流程图 服务流程说明

制定补丁通知及推荐计划。 1 制定补丁通知及 推荐计划 现场支持人员 判断是否有由于补丁问题造成的故障。如 没有由于补丁造成的故障， 将实行与预防式补丁服 务，如由于补丁发生故障， 将实施响应式补丁服预防方式的补丁服务以预防、排查隐患为 2 预防式补丁服务 服务台支持人 员 主，对现有设备的安全、 性能隐患制定补丁更新计 划。 对用户所发现的故障进行处理，并且向用 响应式补丁服务 现场支持人员 户提供可处理此故障的补丁程序 在预防式补丁服务中，对以往出现故障的 3 设备故障数据统 计与分析 服务台支持人 员 4 设备进行统计，总结普遍的故障现象 在预防式补丁服务中，通过配置管理与巡 5 配置管理与巡检 常发故障设备 现场支持人员 检的方式， 检查系统运行情况， 定位常发故障设备 的位置， 查明故障发生的原因， 制定相关补丁的更 新计划。 结合故障数据统计结果与巡检所发现的 故6 增补软件分析 各技术支持工 程师 障情况， 对增补软件进行评估与分析。 得出适合 增补的软件列表。 7 各技术支持工 程制定版本升级建 议 师 根据分析结果制定版本升级建议与实施 计划 业务部门对实施计划的内容进行审核，如 8 业务部门审批 设备负责人 发现补丁版本升级不符合要求， 将返回重新制定补 丁升级计划。 在响应式补丁服务中，对故障进行的处 9 处理和分析故障 现场支持人员 理，在发现可以通过更新补丁来消除隐患时， 我方 将制定补丁更新计划，寻找相关的软件补丁。 对寻找相关的软件补丁进行测试，通过测 10 提供软件补丁程 序 各技术支持工 程师 试后，我方将测试报告与软件补丁程序提交给用 户。 经过审批通过后，我方安装实施计划的方 11 补丁更新实施 现场支持人员 案与内容，对相关设备进行补丁更新工作。 2.1.6 季度巡检流程

1) 每季度提供一次健康巡检，对设备硬件、系统运行状况进行检查，排除隐含错误或 安全隐患，

并提交健康巡检报告。

2) 巡检的具体时间由双方协商确定。

服务流程

服务流程说明

1 制定季度健康巡检 计划 根据要求制定监控巡检计划与方案， 内容 现场支持人员 包括巡检方式、操作步骤等。 业务部审批巡检计划 2 业务部门审批 现场支持人员 如服务巡检计划未能满足用户的需求， 将 退回重新设定巡检计划。 实施设备的健康巡检。 3 提供健康巡检报告 现场支持人员 记录巡检中发现的设备问题 提交健康巡检报告， 汇报设备存在的安全 隐患。 4 排除隐含错误 与安全隐患 设备维修人员 对报告中存在安全隐患进行处理。 问题处理后将对系统进行再次检测， 检查 问题处理情况。 2.1.7 培训服务流程

1) 我方定期进行运行维护技术培训，并定期与业主方技术人员进行技术交流。 服务流程

服务流程说明

序号 步骤名称 责任人 说明 询问用户的培训需要。 了解用户对培训的 要求。 判断用户是否对新或难度高的技术开展 技1 咨询业务部门 需求 咨询受理人员 术交流。 收集业务部门提出的培训要求。 按培训要 求的内容、等级进行分类，组织相关人员开展培 训准备工作。 2 制定培训计划 与培训内容 根据培训内容、培训的深度制定培训计 咨询受理人员 划，并提交业务部门进行审批工作。 业务部门对培训内容进行审核工作， 对培 3 业务部门审批 设备负责人 训内容存在异议或不满意的地方，将返回修改培 训计划或培训方案。 相关技术人员对培训方案的内容准备培 训4 安排培训议程 与材料 各技术支持工程 师 资料，并安排培训所需场地与准备相关的设备 或软件。 2.1.8 系统规划（非建设项目）流程

1） 根据硬件、应用软件环境完成数据库的初步规划、安装配置工作

服务流程 服务流程说明

1 硬件、应用环境分 析 对运行环境进行硬件、 软件的运行分析， 现场支持人员 检查运行环境是否符运行要求。 记录硬件、应用环境的基础参数。 根据运行环境评估与硬件、应用环境的 2 制定实施方案 技术支持工程师 基础参数，制定实施方案和初步规划。 提交业务部门对方案进行审批 业务部门审批实施方案。 3 业务部门审批 设备负责人 如实施方案和规划未能满足用户的需 求，将退回修改实施方案。 根据实施方案到现场进行安装、配置工 作。 4 实施安装配置 技术支持工程师 2.1.9 备份恢复测试流程

1) 根据业务重要性及数据安全等级要求，定期对备份数据进行恢复测试，保障备份数

据完整、有效、可用

服务流程 服务流程说明

技术支持工程师检查备份数据，病句业 1 数据时效性检查 技术支持工程师 务重要性及安全级别，判断数据的有效期，如数 据已过保存期， 我方将对系统业务数据进行备份 2 备份系统业务数据 现场支持人员 对系统的数据进行全备份，以保证数据 的完整。 对备份的数据进行恢复测试，并对相关 功能进行操作，检查数据的准确性。 3 数据恢复测试 技术支持工程师 如备份数据存在异常，我方将到现场排 除故障原因，分析系统故障还是备份失误导致， 如不是备份失误， 我方将通知相关业务部门进行 故障处理。 备份数据测试成功后，我方对备份数据 4 备份版本控制 技术支持工程师 尽可能保存最近 5 个版本的存档。 对备份数据进行版本控制，按系统、安 全级别、重要性、备份时间对备份数据进行存档。 2.1.10 专家现场技术支持流程

1) 包括数据库紧急救援服务。

2) 如出现故障，导致数据库不能正常工作，服务方须尽快安排资深工程师到现场先回 复应用，并

保证持续跟进直到问题完全解决。

3) 如果不能解决问题， 服务方需自行请专家或其他高级技术人员对系统情况进行分析， 直至解

决问题。

4) 服务方在接到现场系统维护请求后 1 小时内响应，对宕机或紧急恢复等严重问题， 要求立即

响应并在 15 分钟内到达现场。

服务流程 服务流程说明

进行紧急救援服务，安排资深工程师到 1 现场情况调查 技术支持工程师 现场进行调查响应。尽快提出故障处理方案。 我方根据故障的级别、安全性对故障采 取应急的处理情况。 2 故障应急处理 现场支持人员 由于设备硬件造成的故障，我方立即启 动热备件。及时恢复系统的正常运行。 由于软件或设置造成的故障，我方对设 置进行初始化操作，保证系统的正常运行 根据提前准备好的设备热备件，我方对 3 启动热备件 技术支持工程师 设备进行更换和切换操作。恢复设备的运行。 在现场对故障设备进行一般的修复处 4 故障设备修复 设备维修人员 理，如不能处理，我方将故障设备提取回维修中 心进行维修。 故障设备修复成功后，我方把完成修复 5 更换备件 现场支持人员 的设备安装回原位置。 并把正式服务切换回正式 环境。 对数据库的运行环境进行初始化配置操 6 恢复初始化设置 技术支持工程师 作。恢复系统的运行环境。 7 日志文件检查 技术支持工程师 检查数据库的日志，找出数据库中存在 的故障问题。 根据存在的故障问题对数据库的配置进 8 软件配置修复 技术支持工程师 行修改和故障处理。 故障修复后对故障进行检查，排查存在 的安全隐患。 9 修复检查 现场支持人员 2.1.11 技术支持服务流程

1) 提供电话或现场技术咨询和技术支持服务。 服务流程 服务流程说明

服务台响应用户的咨询请求，对用户做 1 服务台响应咨询 技术支持工程师 出快速的请求响应。 了解用户的需要，提供有效的技术支持 与咨询服务。 我方派出工程师到现场对用户的疑问进 2 现场技术支持 现场支持人员 行解答。 为用户现场处理用户的故障问题。 现场技术支持完成后，我方电话回访用 3 用户回访 技术支持工程师 户对服务的满意度， 并咨询是否需要更还现场支 持服务或变更服务 如用户需要电话直接支持，我方将采用 4 电话技术支持 设备维修人员 电话的方式立即响应用户的请求， 并尽可能完成 用户的需求和远程处理用户的故障。 2.2 服务管理

2.2.1 实施规范管理

我方按照业主方的管理制度、修理维护规范、操作指导等相关规则制度开展 修理维护服务。 为保障修理维护服务规范化的顺利执行， 同时修理维护服务各个环节清晰可 追述，我方任何操作必须严格按照业主方相关流程进行操作，尽量减少对业主方 正常业务的干扰，每步操作须有明确的成果反馈记录，禁止任何不按流程处理的 任何操作，一经发现将严肃处理。

2.2.2 人员工作规范

我方对运维人员进行明确分工及职责定义，避免运维人员无序混乱工作，职 责分工需符合运行单位运维工作要求。

2.2.3 项目风险与责任

我方谨慎和用心履行合同责任，并对其员工的过失承担责任。由于我方实施 人员服务不及时(没有按照合同约定时间规定)或服务操作不当，造成大量在线 数据遭受不可恢复性损失，我方应负责恢复数据，并承担所有费用。由于我方原 因服务不到位，我方应向业主方作出书面解释，并提出整改措施。造成损失的， 我方承担全部责任。

2.2.4 人员稳定性

鉴于信息系统及设备重要性以及安全保密性， 我方保证服务期内修理维护团 队人员稳定，避免人员流动对业主方业务系统及设备造成安全隐患，特殊情况下 人员变动需经业主方同意后方可变动，禁止未经业主方同意人员直接变动。

2.2.5 人员质量控制

我方所派出的服务人员，应能熟练胜任相关维护工作。业主方拥有向所提供 的实施人员进行面试的权力。如我方人员业务能力如不符要求，业主方有权要求 我方更换人员。服务人员资质要求如下：

a) 大学专科或以上学历，有 3 年以上类似产品维护经验。 b) 具有相应产品认证证书。

2.2.6 项目进度控制

我方技术服务团队每周向业主方项目管理部门提交维护工作周报， 并抄送我 方项目管理部门。为了更好的让业主方了解项目的进度和目前的情况，我方将向 业主方进行以下工作：

每月提交工作月报，维护工作月报的内容必须包括以下内容：主要的已 完成工作内容、未完成工作内容、故障处理报告、维护建议及工作计划 安排。

技术服务团队每月度对相关工作进行总结提炼， 提交运行维护工作月报。 技术服务团队每季度对相关工作进行总结提炼， 提交运行维护工作季报。 技术服务团队每年对全年工作进行总结，并对下一年度工作进行规划， 提交运行维护工作年报，协助系统管理员完成系统年度维护总结。

除上述文档整理工作外，我方承担业主方相关维护文档的修编配合工作。

2.2.7 项目安全控制

提供现场服务时，我方将确保其现场人员遵守业主方有关安全规定，前提是 我方收到业主方提供的有关安全规定。我方有为业主方保密的义务，未经业主方 许可， 我方服务人员不得对业主方的业务经营数据进行增删、 修改、复制、 传送、 记录；我方不得向任何第三方泄露业主方业务数据内容或在公开场合引用业主方 数据。

2.2.8 质量控制

为保障服务质量及服务适应性，在服务期内，我方需根据服务内容发生的变 化进行适应性的改进，并在修理维护过程中根据业主方的要求进行服务改进。

2.2.9 项目质量保证

服务质量要达到可衡量必须制定严格的服务 业主方协商制定切实可行的服务 务标准如下：

一、紧急情况 当服务器宕机，数据库无法读写等一级紧急事件时，我方在 1 小时内响应，

SLA，我方在服务期开始时须与

SLA，并严格遵守 SLA 进行修理维护服务。其服

2 小时内协助解决该情况。并在因外部原因无法立即解决时（例如服务器所在机 房受到黑客攻击，

服务器硬盘读写失败等事件），向客户报告情况并提供具体解 决的时间。并提供一套完善的应急解决方案，帮助客户及时解决突发事件，最大 程度的挽救因服务无法使用导致的损失。

、重要情况

系统服务上线过程后， 有时会出现在验收过程中没有察觉的 bug，这个时候， 我方积极协助客户解决该 bug ，具体的响应时间根据 bug 造成的影响程度而定。 根据 SLA 服务标准， bug 的等级亦可进行进一步的划分并制定相应的解决方案。 这里不予以赘述。

三、标准情况 在系统部署阶段，因工作人员协作环节的不一致性，有可能出故障问题和兼 容性问题。 以及由于临时需求的变更和新增， 都会对系统服务产生新的维护需求。 我方按照需求的难易性和工作量制定相应的响应标准，保证客户满意度。

四、次要情况 包括服务的小调整，如数据库、中间件的配置更替等，通常在 应，双方商议的时间内进行解决即可。我方以

24 小时内响

SLA 服务体系为出发点，为 IT 服

务提供完善、标准、科学的解决方案，尽可能不影响客户满意度。

2.2.10 制定全年的支持服务计划 我方客户经理应主动地和业主方共同协商、制定全

年的支持服务计划。服务 计划包括以下主要内容：

a) 业务 /IT 系统概况，业务系统对服务的需求 b) 服务合同的工作内容，设备清单和响应服务级别 c) 我方的工作团队和职责 d) 支持服务的流程

e) 运维服务活动的计划， 包括：增值服务实施、 服务总结报告、 回顾会议、 巡检、 技术

交流等

f) 服务计划双方的确认

2.2.11 项目总结会议

我方客户经理至少每季度会安排与业主方一起召开系统运行和服务情况定 期总结回顾会议，内容包括但不限于：

a) 总结前一段时间服务实施的情况 b) 回顾升级问题 / 重要问题的处理过程 c） 听取运行单位对服务的反馈意见和服务需求 d） 同业主方运维经理们讨论服务改进措施 e） 讨论、修订服务计划。 2.3 维护内容

我方将根据 xxx 有限公司服务器、存储设备、虚拟化服务器、

A 认证系统服

务内容简要的介绍常见故障所采用的维护解决办法，在实际的应用中，我方会根 据实际情况进行相应的修改与优化。

2.3.1 服务器故障诊断

计算机故障类型以及故障的诊断手段有很多， 故障采取以下 2 种诊断方式：

对于服务器（ IBM 服务器为例）

2.3.1.1 硬 件故障诊 断

诊断并排除由硬件引起的故障，先从外观上检查硬件情况，检查设备故障灯 是否有亮。各种设备上都有故障指示灯，通常为橙色并有

?标记。对于高端服务

器，应检查 UEPO开关上的系统故障指示灯是否亮， 检查部件故障灯， 如 I/O drawer 、 PCI 卡，硬盘等。

所有安装的部件（如 CPU book）所对应的绿色 LED 应长亮。任何故障指示 灯（橙色）都应不亮，设备发生故障时通常伴有出错代码，必须把所有故障代码 记录下来。除此以外还应注意有否其他异常情况（如硬盘、风扇异常的声音、电 缆破损、系统出风是否顺畅、气流是否因为异物遮挡而影响散热效果等）。 ?

检查服务器网卡状态、 IP 地址是否正常。网卡的设置应与交换机端口的设 置匹配。检查网卡通信是否正常，如是否丢包，速度是否正常等。并且检查路由 表是否正常、 /etc/hosts 文件或 DNS设置是否正常等。

2.3.1.2 软 件故障诊 断

诊断并排除由软件（操作系统和应用软件等）引起的故障可以先查看系统日 志相关软件报错的记录，同时登录软件检查当前应用使用状态、软件应用进程等 进行多方面的诊断。

2.3.2 检测服务器、存储设备运行情况

对于一个系统而言资源总是有一定限度的，而任务总是要消耗系统资源的。 关键是要找出哪些资源不能满足应用程序运行的需求。 这里存在一个性能瓶颈的 问题。不同的应用程序可能会有不同的资源要求，可能会产生不同的瓶颈。系统 资源中的 CPU、内存、磁盘或是网络都有可能成为瓶颈。系统性能调优需要找出 这些资源成为瓶颈的原因，是资源的不足，是系统设置不合理，还是应用程序的 问题。

查找性能瓶颈的顺序非常重要，正确的顺序是： CPU> 内存 > I/O > 网络， 如下图所示：

是

2.3.2.1 查 看 CPUC瓶PU颈

采

通取过对查策看当前服务器 否PU使用情况判断 CPU的使用情况， 般情况下 CPU使

用率不应该长期超过 80%，如出现 CPU使用率长期处于甚至超过 初步可判断是 CPU资

是

否

80%的情况，则

是

2.3.2.2

内存瓶颈

检测内存问题

务器在内存使用上模式默认最大化使用，

/O 瓶颈

否因此内存

作为是否存在内存瓶颈的依据。如果达到内存瓶颈，此时检查系统内存交换区的 是使用，会发现使用率较高。

由于有大量的内存页面写入内存交换区，这会导致

采取对策

但此时并非 I/O 瓶颈引起。

当内存交换区使用率超过

否

网络瓶颈

I/O 等待）值上升，

继续测试

区

70%时需要增加交换区的大小。但增加内存交采换取 对策

相反，内存交换区使用越多， 系统性能下降越多。

的大小并不会提高系统的性能。

当内存不足时，正确的方法是增加物理内存的数量或优化应用程序。

2.3.2.3 查 看系 统的 I/O 情况

磁盘的数据流量很大程度上与应用程序的 I/O 方式相关。某些应用程序的

I/O SIZE 可能非常低，而且产生大量的随机读写操作，从而使硬盘的读写效率 大大降低，导致 CPU的 I/O 等待增加。

有时 I/O 问题是 I/O 带宽不足引起的。 当所有连接在一块 I/O 卡上的硬盘的 流量总和达到 I/O 卡带宽的 70%以上时，应考虑增加更多的

I/O 卡

数据的分布也是很重要的因素 通常把数据分布到更多的硬盘上更有利于提

高 I/O 性能。

2.3.2.4 查 看网络的 情况：

对于网络问题可以通过检查服务器端口情况、网线速率、端口模式，甚至通 过服务器与服务器、服务器与测试设备之间进行链路测试、传输速率测试检测服 务器网络上的问题， 必要时需要网络工程师检查交换机层面的健康情况加以分析 判断。

如果都没有发现系统有资源上的瓶颈，则很可能是应用程序的问题，需要应 用程序开发商进行进一步的分析。

2.3.3 服务器备件检修

服务器备件保修主要以更换设备为主， 并对造成备件故障的原因作出分析， 最后通 过分析的故障结果。 对所有故障进行排查， 不能单单只是更换备件这么简单， 服务器备 件一旦发生故障不一定是其本身问题， 极大情况下是外部环境所造成。 因此，服务器备 件检修需要考虑其使用环境，从根本上解决故障问题，防止其它备件的损坏。

2.3.3.1 服 务器备件 硬件故障 维修

对于一般的设备硬件的故障，我方采用以下方式采取维修处理

1 2 3 4 5 6 7 8 9 10 11 内存条损坏 主板元器件损坏 阵列 损坏 电源损坏 指示灯损坏 直接更换 直接更换 现场更换 现场更换 数据恢复需离 开先进行数据恢复，再更 换硬现场。 盘 备件现场更换 直接更换 先检测健康状态，再更 换指示灯 直接更换 直接更换 直接更换 直接更换 直接更换 直接更换主板 现场更换 现场更换 现场更换 现场更换 现场更换 现场更换 现场更换 现场更换 CPU风扇损坏 数据线损坏 CPU损坏 光驱损坏 电源线损坏 相关数据接口损坏 对于服务器的软件方面故障，我方采用以下方式采取维修处理

1 2 3 4 系统崩溃 中木马病毒 驱动不匹配 软件不兼容 重装操作系统 安装杀毒软件杀毒 安装正确的驱动 安装兼容软件 现场操作 远程操作 远程操作 远程操作 2.3.3.2 服务器软件故障维修

2.3.3.3 服 务器备件 修复与后 续保养

如以下因素导致备件的故障， 我方在处理完备件的维修后， 再对备件周边的环境进 行保养处理工作。具体可参考以下几个方面：

服务器备件受潮短路。

备件受潮湿因素导致的故障， 我方对服务器周边的环境进行除湿处理。 主要以空调 除湿或吸湿海绵为主。

服务器备件受过热短路。

备件受过热短路因素导致的故障， 我方对服务器周边的环境进行降温处理。 主要以 空调降温或更换服务器散热风扇。

服务器备件积尘导致短路。

备件积尘短路因素导致的故障， 我方对服务器周边的环境进行除尘处理。 主要以吸 尘机或毛刷工具为主。

服务器备件是否电源电压不稳定造成短路。 备件电源电压不稳短路因素导致的故障，我方

对服务器周边的环境进行电压检测， 看是否有漏电的情况，并更换电源。

2.3.4 特保服务

我方按照公司要求， 对于特殊时期必须保障设备运行， 并根据业主方要求驻场值守 和服务，完成特殊时期保障任务。并且每年安排约有 2 个月的特保时间。

2.3.4.1 特 保服务常 规服务内 容

我方值班人员要认真检查设备的运行情况，包括电源、服务器指示灯及一切隐 患。确保服务器设备的一切安全。

做好安全监控工作。预防各种事故和事件的发生。 检查软件的日志文件是否完整。 检查设备的电压及温度。

值班人员做好值班记录，并记载重要事情。 有重大问题及时向上级设备管理人员报告。

2.3.4.2 特 保服务工 作责任

我方值班人员值班期间，不能脱岗，认真值班。全天 24 小时确保有人在值班 监控设备的运行。

做好交等有关工作。

值班人员要做好安全防范工作， 遇设备周围环境的变化， 应及时做出相应处理； 保证值班人员人员及相关技术工程师的电话畅通。

坚守值班岗位，不擅离职守。时刻提高警惕，做好值班期间的工作。 值班严格按照操作手册执行，不违反值班制度和操作章程。 值班人员在特殊假日放假值班期间为设备运行及安全工作的第一责任人。

2.3.4.3 特 保服务保 证

值班人员提高自觉性与主动性，确保设备安全、稳定运行。 在值班期间坚守工作岗位，不得无故让他人替岗，严禁饮酒。 值班期间保证电话畅通，遇到重大事情，必须报告上级领导并做好临时处理措 施，积极处置。

认真做好值班记录，对设备异常及安全防火情况等，必须认真检查。 值班员工在值班时间内，坚守岗位，不迟到、早退和缺岗。

2.3.5 系统补丁通知及推荐

我方将对以下补丁采取相关的补丁更新通知与补丁更新操作的服务。 并对需更新的 补丁进行测试工作。以下系统补丁服务的相关内容。

2.3.5.1 补 丁收集与 整理

我方对以下补丁通过不同的途径进行补丁资源的收集， 补丁的出处要求是官方的补 丁，如补丁不是官方提供，将对非官方补丁进行测试。

1 2 3 4 服务器硬件 BIOS补丁 存储设备补丁 服务器厂商提供 服务器厂商提供 微软官方网站 官网或论坛 由官方通知 由官方通知 微软最新公告 论坛公告 Windows操作系统补丁 Linux 操作系统 5 6 7 8 9 10 Aix 操作系统补丁 Unix 操作系统补丁 Oracle 软件补丁 Weblogic 软件补丁 Tomcat软件补丁 其他软件补丁 ⋯IBM官方网站 官网或论坛 官网或论坛 官方网站 官网或论坛 官网或论坛 ⋯IBM官方网站公告 论坛公告 论坛公告 官网公告 现场更换 现场更换 ⋯11 2.3.5.2 补 丁更新测 试

补丁更新之前 , 有必要对其进行完整的测试 , 确保其适合于当前运转的设备或系统 , 否则有可能带来不必要的麻烦。但是对补丁进行测试是一项繁琐的工作 技巧和脚本 , 快速有效地测试补丁。

为针对如此多的产品以及不同版本的补丁， 我方使用一套自动化补丁测试过程， 建 立一套完整的系统环境，模拟设备或系统的运行状态，确保补丁更新测试的可行性。

, 我方使用测试

2.3.5.3 补 丁更新操 作

在部署补丁之前 , 我方确保已进行补丁测试 , 以确保它们不会破坏系统现有的功能。 在补丁测试前对系统或相关资源进行备份处理， 确保补丁更新万无一失， 并且我方有专 业的专家支持，在补丁更新出现故障时，保证能快速有效进行系统恢复。

2.3.6 月度巡检

为了更好地落实现巡检工作， 我方制定了月度巡检工作， 并对月度检查做出书面报 告。进一步保障了设备正常运行和预防了设备发生故障事故的风险。 同时，通过月度巡 检能尽早的发现安全隐患。具体措施如下：

2.3.6.1 月 度巡检检 查

月度巡检检查主要包括设备周边环境、 周边设备、 通讯及网络设备、 服务器设备的 检查，其检查内容如下：

设备周边环境检查

检查设备周边的温度是否正常、痕迹是否存在异常、有否异响、温度是否正常、清 洁是否符合要求、是否存在异味等。

设备周边设备检查

检查 UPS电源是否正常、 空调是否正常、 电池组是否存在异常、 消防是否符合标准 和要求等。

通讯及网络设备检查

防火墙及流量控制方面， 网络通讯状态是否正常、 网络流量是否过多等。 而网络口 检查主要包括数据指示灯有否异常、 网络通讯状态是否正常、 端口及网线状态是否正常 等。

服务器设备的检查

服务器硬件故障灯是否正常、 如发生故障将记录详细的故障现象与解决方法， 补丁 是否已经更新、 防病毒软件的病毒库是否已经升级、 文件系统是否出现错误， 日志文件 的设置及运行是否正常，磁盘卷组是否存在失效状态。

2.3.6.2 巡 检数据整 理

经过季度巡检后， 我方将把巡检的记录进行同一的整理， 把巡检中发现的故障或异 常情况进行统计与分析， 形成季度巡检记录。 并将总体的巡检记录提交给设备管理员或 业务部门。

2.3.6.3 提 供健康巡 检报告

通过对季度巡检发现的故障数据进行分析， 结合目前业主方已用的资源与工具， 提 供完整的健康巡检报告与可行的故障解决方案。 解决方案内容需要业主方进行审核。 并 对存在的问题我方能提供专业技术支持解答。

2.3.7 培训服务

为了保证设备能在运行中良好工作和人员的运维水平， 提供有针对性专业技能培训。 使其能够熟练掌握存储设备的维护工作， 并能及时有效的解决常见的大部分故障。 经培 训后能熟练掌握硬件维护工作，并能及时排除大部分的故障。

工程技术人员经培训后， 除能熟练管理硬件， 排除硬件故障外， 还应具备能阅读硬 件清单，分析硬件故障等工作。

2.3.7.1

制 定培训服 务事项

制定培训服务包括以下事项：

培训的课程安排建议：包括人数、时间、课程、入学要求等； 培训所需要的教材，课件； 讲师资料；

培训场地（由 xxx 有限公司和 xxx 有限公司共同商议再定）。 选择培训方式，集中培训或现场培训。

2.3.7.2 培 训事项准 备工作 我方将提供教材、教师、场地，由 xxx 有限公司参加的培训，

如教材较多将 选择投影设备或电子资料为主，培训场地将会按照用户的实际情况准备，一般集 中在

xxx 有限公司技术人员所在场地或授权培训中心中进行。 2.3.7.3

开 展培训课 程 我方将利用可使用资源为其维护技术人员提供专业的培训课程， 其培

训课程 内容主要以下几个方面：

IBM存储知识培训

IBM 存储知识培训

培训周期为 1 天，培训对象面向存储产品操作维护

/ 技术支持人员，培训人

数控制在 10 人，学员具体要求：了解计算机硬件基础知识、熟练使用 Linux 操 作系统、具备网络通信基础知识。如完成培训课程可达到了解 础知识、了解存储的几种架构以及相关协议的目的

IBM 存储产品的基

IBM 一体机交换机知识培训 交换机知识培训主要以交换机产品与工作原理介绍、 交换机

产品日常维护技 术介绍为主， 培训周期为 1 天，培训对象面向存储产品操作维护 / 技术支持人员， 培训人数控制在 10 人，学员具体要求：了解计算机硬件基础知识、熟练使用 Windows 操作系统、具备网络通信基础知识。如完成培训课程可达到了解交换机 产品的基础知识、了解交换机产品线概况及产品功能、掌握交换机产品日常维护 技术的目的。 数据库知识培训

Oracle 数据库知识培训

培训周期为 2-3 天，培训对象面向 Oracle 数据库操作维护 / 技术支持人员， 培训人数控制在 10 人，学员具体要求：了解计算机硬件基础知识、熟练使用 Windows 操作系统、

Linux 操作系统、具备网络通信基础知识。如完成培训课程 可达到了解 Oracle 数据库产品的基

础知识、 掌握 Oracle 数据库产品日常维护的 目的。 虚拟化知识培训

HC3虚拟化知识培训

培训周期为 2-3 天，培训对象面向虚拟机操作维护

/ 技术支持人员，培训人

数控制在 10 人，学员具体要求：了解计算机硬件基础知识、熟练使用 Windows 操作系统、

Linux 操作系统、具备网络通信基础知识。如完成培训课程可达到了 解虚拟化产品的基础知识、掌

握

H3C虚拟化产品日常维护的目的。

2.3.8 数据库故障诊断及检修

以 Oracle 数据库物理结构故障为例，首先要判断问题的起因，如果是硬件故障则 首先要解

决硬件问题。在无硬件问题的前提下按照下面的处理方发来进一步处理。

2.3.8.1 数 据库故障 检查

数据库出现故障， 基本上是由于文件损坏所导致， 可以通过安装以下分析方法检查 文件损坏的情况：

检查控制文件损坏情况 检查损坏的单个控制文件 检测所有的控制文件 检测重做日志文件损坏情况 确定损坏的重做日志的位置及其状态

2.3.8.2 数 据库文件 损坏检修

数据库文件损坏后， 可通过基本的配置将其修复，具体方法如下：

可以通过以下方法检修以下位置 的错误， 打开数据库并且用适当的 1 方法进行数据库全备份 进行数据库全备份 若损坏的数据文件属于非 system 表空间， 则数据库仍 然可以处于打开状态可以进行操作，只是损坏的数据 文件不能访问。这时在数据库打开状态下可以单独对 损坏的数据文件2 部分数据文件损坏 进行恢复。 若是 system 表空间的数据 文件损坏则数据库系统会异常终止。这时数据库只能 以 Mount 方式打开，然后再对数据文件进行恢复。可 以通过查看数据库日志文件来判断当前损坏的数据文 件到底是否属于 system 表空间。 (1) 确定损坏的文件名字： (2) 将损坏的数据文件处于 offline 状态： (3) 从相应的备份结果集中恢复关于这个数据文件的 最近的非 system 表空间的数据文 3 件损坏 备份。对于没有采用带库备份的点可以直接从 磁带上恢复； 对于用带库备份的点用相应的 rman 脚本 来恢复。 (4) 恢复数据文件： (5) 使数据库文件 online ： 用适当的方法进行数据库全备份。 (1) 以 mount 方式启动数据库 (2) 从相应的备份结果集中恢复关于这个数据文件的 最近的system 表空间的数据文件 4 损坏 备份。对于没有采用带库备份的点可以直接从 磁带上恢复； 对于用带库备份的点用相应的 rman 脚本 来恢复。 (3) 恢复 system 表空间： (4) 打开数据库： (5) 用适当的方法进行数据库全备份。 若非 system 表空间已经损坏， 则数据库仍然可以处于 打开状态可以进行操作， 只是损坏的表空间不能访问。 这样在数据库打开状态下可以单独对损坏的表空间进 行恢复。 若是 5 表空间损坏 system 表空间损坏则数据库系统会异常 终止。这时数据库只能以 Mount 方式打开，然后再对 表空间进行恢复。可以通过查看数据库日志文件来判 断当前损坏的表空间是否是 system 表空间 . (1) 将损坏的表空间处于 offline 状态： (2) 从相应的备份结果集中恢复关于这个表空间最近 的备6 非 system 表空间损坏 份。对于没有采用带库备份的点可以直接从磁带 上恢复； 对于用带库备份的点用相应的 rman 脚本来恢 复。 (3) 恢复表空间： (4) 使表空间 online ： (5) 用适当的方法进行数据库全备份 . (1) 以 mount 方式启动数据库 (2) 从相应的备份结果集中恢复 system 表空间最近的 备7 system 表空间损坏 份。对于没有采用带库备份的点可以直接从磁带上 恢复；对于用带库备份的点用相应的 rman 脚本来恢 复。 (3) 恢复 system 表空间： (4) 打开数据库： (5) 用适当的方法进行数据库全备份。 整个数据库所有文件的损坏一般是在共享磁盘阵列发 生无法整个数据库的所有文件损 8 坏 恢复的灾难时才发生，这种情况下只能对数据 库进行恢复。若数据库的归档目录也已经丢失，则数 据库不可能做完全恢复，会有用户数据的丢失。 2.3.9 系统部署规划

我方根据硬件、应用软件环境完成数据库的初步规划、安装配置工作。具体的规划 要求按实际情况制定，以下是系统规划的相关内容：

2.3.9.1 制 定数据库 、中间件 的部署 规划

根据硬件、应用软件环境，制定数据库、中间件的安装部署规划。数据库与中间件 的资源消耗离不开硬件设备， 硬件性能的高低与数据库、 中间件性能高低是一致的， 因 此，首先要调查服务器的硬件、应用软件运行环境与性能。评价服务器的性能好坏，再 根据系统运行的需求，制定数据库、中间件的安装部署规划。

2.3.9.2 制 定数据库 、中间件 的安装 部署 方案

制定数据库、中间件的安装部署方案，安排项目开发计划。在调查分析硬件设备性 能的基础上，提出数据库、中间件的总体结构方案， 根据之前的部署规划， 确定数据库、 中间件安装部署次序及时间安排。

2.3.9.3 合 理分配硬 件资源

在数据库、中间件的安装部署完成后， 需进行优化配置， 根据系统的实际使用需求， 对数据库配置及中间件的配置进行调优设置， 力求用最少的资源实现最大的效果， 做好 系统的搭建工作。

2.3.10 备份恢复测试

备份与恢复是系统管理一项不可缺少的工作。备份工作的目的是为了尽可能快速和 方便地恢复单个文件或整个文件系统及相关数据 , 备份对于文件和数据的安全恢复是非 常重要的。 我方将提供良好的备份服务， 将对于以后的系统遇到意外紧急故障能否安全 恢复运行起着非常关键的作用。

2.3.10.1 数 据备份

数据备份的是系统安全的重要保证，我方将对数据分成两类，一类是应用系统中的 数据，另一类是数据库存放的数据， 我方将在每次的备份工作时， 对这两种数据进行备 份和整理。

系统数据备份

对系统数据备份，其实就是实现系统和应用程序的备份。此处指的是中间件、应用 平台或业务系统的程序等。做好系统数据备份，能保证系统的运行环境等完整。

数据库数据备份

数据库数据会由于用户的数据变动更加频繁一些， 几乎不可能精确到每分钟的备份。 因此，数据库数据备份我方将采取定时的方式对数据库的数据进行备份。

做好数据备份，合理的进行系统数据与数据库数据的备份，当出现任何问题如误删 除某些文件或者存储设备发生故障时，就可以进行系统恢复操作。

2.3.10.2 数 据恢复及 测试

在遇到系统异常或数据丢失的情况，我方将利用备份的系统数据及数据库数据进行 数据恢复工作。 数据恢复的前， 我方严格进行数据的恢复测试， 尽可能地对系统进行完 整地还原。

系统数据恢复

我方将最近的一个系统数据备份版本进行恢复，在系统恢复后，对系统的一般功能 进行测试， 验证其系统功能或应用服务功能是否正常， 如系统数据恢复不正常， 将采用 第二个备份进行恢复，力求把系统恢复成正常状态。

数据库数据恢复

我方将最近的一个系统数据备份版本进行恢复，其数据恢复可完成以下修复，其中 包括系统崩溃只剩下数据文件的情况下的恢复 , 甚至没有 system 表空间而只有数据表 空间的情况下的恢复。 Oracle 碎片重组数据恢复 , 如文件被删除或者文件部分被覆盖。 数据库数据被恢复后， 我方将力求将丢失的数据进行比对分析， 测试数据库数据的完整 性，尽力恢复系统的业务数据。

3. 项目管理 3.1 服务组织结构

xxx 有限公司的 IT 服务团队，在 IT 运维服务领域，由资深的技术工程师组成，通 过

咨询专家、值班人员和投诉处理人员等有效配置，实现对客户 IT 运维服务需求的全 面支持。

通过统一有效的服务台管理， 现场派驻支持人员， 后台核心技术支持小组等有效配 置，实现对客户 IT 运维服务需求的全面支持。

3.2 人员职责 项目负责人：

负责项目团队的整体管理及各项资源协调， 定期与客户沟通了解并反馈运维工作情 况，统筹运维团队工作；

与客户保持沟通，了解并满足客户的合理需求； 领导运维工作相关员工，领导整个运

维工作的开展； 定期向客户提交运维相关报告； 重大故障及时跟进处理情况，定期通知客户最新的处理详情。 服务台小组：

负责对客户提出的重要咨询内容提供解答及解决方案； 负责远程支持现场工程师、热

线电话支持工程师工作的开展； 必要时将客户咨询服务升级到核心技术工程师处理；、 接受并记录客户投诉及意见，进行深入了解并将信息反馈公司管理层； 现场服务小组 ：

驻点客户现场，处理需求及故障； 负责对客户设备进行性能评估、性能调整、设备巡检等工作； 负责各系统的日常监控，基本故障处理，无法解决时将故障升级到核心 技术工程师； 设备需要更换备品备件时，跟踪处理并记录备品备件更换记录。 必要时将问题升级到核心技术小组工程师处理； 对客户技术问题进行解答，及对客户提供咨询服务；

负责对客户的咨询服务进行基本整理并解答，必要时将客户需求升级到 核心技术咨询顾问；

核心技术小组： 对服务台小组与现场服务小组未能解答客户的咨询问题进行解答； 对服务台小

组与现场服务小组进行全面的技术支持； 必要时到达故障现场，对故障分析定位并解决问题； 监督现场服务工程师的服务质量； 整理与编写运维工作的相关报告。

4. 项目交付项

xxx 有限公司将在合同规定时间内，向 xxx 有限公司提供更多原厂技术文档 与服务报

告，包括：

产品

技术规范书 技术操作手册

xxx 有限公司定期将相关报告通过客户服务经理提交给 xxx 有限公司服务报 告包括：

服务计划 服务团队季度服务回顾报告 季度服务回顾会议记录 服务项目工作情况月报 单次故障修复报告 月度巡检报告

4.1 交付时间表

产品 1 技术规范书 2 技术操作手册 3 服务计划 4 服务团队年度工作总结报告 5 6 服务团队季度服务回顾报告 按时间要求提交 按时间要求提交 按时间要求提交 按时间要求提交 项目结束 按时间要求提交 7 8 9 季度服务回顾会议记录 服务项目工作情况周报 服务项目工作情况月报 按时间要求提交 每周 每月 按时间要求提交 即时交付 服务项目工作情况季报 10 11 单次故障处理报告 4.2 交付物样例

故障处理单

设备信息 接障时间 处理方式 故障排除时间 处理时间 到达现场时间 故障等级 远程 现场 故障 现象 描述 分析 及处 理方 法 遗留 问题 资料更新情况 软硬件更新情 况 处理人 客户签名 设备巡检表

服务器名称 硬件故障 IP 查看服务器设备故障灯 □正常 □异常 如发生故障此处详细说明现象与解决方法 补丁 整体检查 是否有新补丁需要测试安 装 □是 □ 否 如有如装补丁 请详细登记补丁名称与对应服务器名称 （登 记与服务器对应文档上） 防病毒 病毒库日期 系统事件 日志文件 磁盘卷组 数据库服务 器 功能 病毒库是否升级为最新 □是 □ 否 无错误事件与不明登陆事 件 设置以及运行正常，数据量 正常 无处于失效状态的逻辑卷 远程登陆正常工作 数据库正常工作 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 □正常 □异常 数据备份 存储设备 系统事件 日志文件 应用服务器 磁盘卷组 服务

最近备份时间： 年 月日 状态指示灯，硬盘指示灯检 查 无错误事件与不明登陆事 件 设置以及运行正常，数据量 正常 无处于失效状态的逻辑卷 Weblogic 、 Tomcat 服务项目工作情况周报

（简要描述本周已完成的工作内容） 本周未完成工作 （简要描述本周未完成的工作内容） 故障处理报告 （详细描述清楚故障的处理经过与情况） 维护建议 （对本周的维护工作总结与提出建议） （填写下周工作安排） 其他说明 （其他补充说明或需要配合的工作）

5. 考核与评价

为实现对我方的有效管理， 提高管理制度和管理流程的执行力， 绩效 考核是非常重要的管理手段。 因此， 制定了五个方面的绩效考核关键业绩 指标 KPI（Key Performance

Indicator）

分成服务工作量 服务水平 信息安全支持 系统可用性 人员培训

，其中等包括以下几点：

针对这以上五个方面， 业主方通过相应的 KPI 对我方进行考核， 并制 定相关制度保障 KPI 考核的有效执行。 以下考核子表因应实际情况可进行 响应改动。

表： IT 修理维护服务商效考核指标

服务工作量 一定时期内各种技术支持响应次数。 包 括各种定期、例行和临时性的技术支 持，非现场支持和现场支持要分开计 算。 服务水平质量 用户满意度 每季度 每季度 响应次数≥ 95% 用户满意度≥ 98% 信息突发事件支持 力度 信息系统潜在风险预警， 预防提醒及时 每季度 率 系统平台可用性 （由服务商支持的） 信息系统平台的月 可用率，（即评价由 IT 修理维护服务 商修理维护的系统部件的可用性， 非修 理维护商负责的系统的部件导致不可 用的情况不计算为故障时间） 人员培训 每月 信息系统平台 的月可用率≥ 95% 重大信息突发事件次数支持次数 每季度 次 及时率≥ 98% 支持次 数≥ 12 IT 运维服务商履行合同过程中，对运 维每半年 人员培训的次数、 覆盖的内容和培训 质培训次 数≥ 12 次

量。 表：服务指标考核表

1 2 3 4 5 6 7 8 9 故障响应时间 故障发生后，到达客户现场时间 解决故障的时间与速度 硬件故障时，备件的供应程度 是否在一次服务中解决问题 对问题的跟踪与总结，文档质量 服务态度，与客户的沟通情况 服务工程师的技术水平 每个季度的巡检服务质量 ≤15 分钟 ≤30 分钟 ≤ 12 小时 ≤ 24 小时 第一解决率≥ 95% 文档完整性 98% 用户满意度≥ 98% 资格考试 100%通过 巡检次数≥ 60 次

6. 知识产权保证

所有运行在服务器端的各种非平台功能特性的产品 xxx 有限公司拥 有全部源代码和知识产权，我方在进行技术支持时，未经书面许可，不复 制、传播以及将此招标结果作为应用案例进行宣传。

7. 保密措施 7.1 保密范围与要求

我方鉴于在提供系统维护服务期间，需要开放信息系统的访问权限， 为加强信息系统的信息安全管理，我方保证做到以下保密要求：

我方在访问信息系统期间， 负有保护业主方企业的网络安全、 信息安 全和系统数据的义务和责任； 负有保护所持有、 接触的属于或涉及业主方 企业商业秘密的信息安全的义务和责任。

7.2 保密类型

我方对业主方的商业情况、 商业秘密等敏感信息一律保密。 商业秘密 是指因其信息泄露会影响企业生产和发展、 影响企业营销活动、 影响企业 技术进步、 使企业在商业竞争中处于被动或不利地位、 使企业经济利益受 到损害、影响企业对外交流和商业谈判顺利进行、影响企业稳定和安全、 影响企业对外承担保密义务的事项。

8. 应急服务流程及响应措施

xxx 有限公司已经针对本项目制定了详尽的设计、 应急处理预案， 整个流程 严谨而有

序。但是，在服务维护过程中，意外情况将难以完全避免。下面，我 们将对项目实施的突发风险进行详细分析，并且针对各类突发事件，设计了相 应的预防与解决措施，同时提供了完整的应急处理流程。 应急基本流程

维护服务应急处理流程

预防措施

针对可能遇到的各种各样的风险， xxx 有限公司总结多年维护服务经验， 针 对一些可能出现的情况，制定了一系列预防处理措施，举例如下：

类型 事件 预防措施 各项目相关人员提前准 无法启动软件可执行 文件 备好各类需维护软件安 装程序 将应用软件数据文件备 份后，重新安装 处理 应用软件 软件打开过程中或运 行中异常错误关闭 各项目相关人员准备好 安装程序，操作系统优化 和修补软件，查杀病毒软 件 判断出错原因，备份数 据，采取相关修复措施 使用者本机操作系统 异常或系统资源占用 严重 操作系统 告知使用者错误原因可 准备好系统检查程序及 修能类型，提出解决方案， 补程序，以及查杀病毒 软经使用者认可后采取相 件 应措施 B/S 结构系统， IE 浏 准备流氓软件清理程序、 检查 IE 浏览器选项设 览器异常或无法下载 控修复浏览器软件、查杀病 置，分析原因进行修复 件 毒软件 检查网络流量，流量异 网络或服 务器

B/S 结构系统网络流 量异常或服务器登录 异常 判断服务器是否异常，否 则准备杀毒软件 常小则报修网络服务 商，流量异常大则查杀 病毒 突发事件应急策略

系统运维应急方案是对中断或严重影响业务的故障，如宕机、数据丢失、 业务中断等，进行快速响应和处理，在最短时间内恢复业务系统，将损失降到 最低。在系统维护过程中，突发事件的出现将是很难完全避免的，针对这种情 况， xxx 有限公司设计了完善的突发事件应急策略。

系统巡检人员要定期规范检查各硬件设备的运转情况和应用软件运行情况， 同时做好日常的数据增量备份和定期全备份。对发现的问题在报各级负责人的 同时，要协调相关资源分析

问题根源，确定解决方案和临时解决措施，避免造 成更大的影响。问题得到稳定或彻底解决后，要形成问题汇报，避免以后类似 重大紧急情况的发生。

对发现的问题在报负责人的同时，要协调相关资源分析问题根源，确定解 决方案和临时解决措施，避免造成更大的影响。问题得到稳定或彻底解决后， 要形成问题汇报，避免以后类似重大紧急情况的发生。

xxx 有限公司不但拥有经验丰富的技术支持工程师，而且根据长期以来的 客户服务工作

经验，建立了常用知识库，其中包括多种常见技术故障和突发事 件的应急策略。当获悉出现突发事件时，技术支持人员可以立即从知识库中获 取相应的应急策略，并综合用户方的具体情况，给出相关解决方案，然后在第 一时间以电话、邮件支持或现场服务的方式帮助用户解决问题，尽最大努力减 小突发事件对用户日常应用的影响。

紧急情况 预防措施 应急策略 在磁盘数据未丢失情况下，保证数据安全 硬件损坏 项目单位操作用电脑硬件损坏 性，建议项目单位替换相关硬件。 加强培训力度，掌握培训效果， 检操作失误 验操作人员操作水准，提示注 意事项。 培训时强调使用前配置方法和步 配置丢失 派出上门维护、 培训人员重新配置， 并耐心 骤，并特别提示需在使用前按要 求讲解。 操作 培训时强调使用过程中注意定期 备数据丢失 份重要数据， 日常维护过程中， 上协调有关部门， 进行补救， 无法补救， 提门服务人员实时备份数据并告 知用户 交 报告说明原因。 操作失误未造成即成结果或数据未丢失情 况下，保障数据安全， 反之，协调相关部门， 进行补救。对操作人员强调注意事项 突发事件应急策略服务流程图如下: