湖北BOSS系统维护作业指导.doc

维护作业指导书
湖北BOSS系统

版本

宏智科技股份有限公司版权所有，保留一切权利。未经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档的部分或全部，并以任何形式传阅。
维护作业指导书 版本:

文 档 控 制 页

日 期
修改说明
版本
作 者
审批人
审批日期
12/22/2002
湖北BOSS系统维护作业指导
初稿
李春晖

目 录
1. 简介 4
1.1. 目的 4
1.2. 范围 4
1.3. 文档约定 4
1.4. 参考资料 4
2. 服务体系建设 5
2.1. 公司层面服务体系结构 5
2.2. 事业部层面服务体系结构 6
3. 服务联合团队建设 7
3.1. 项目相关方 7
3.1.1. 宏智公司项目相关方 7
3.1.2. 用户项目相关方 7
3.2. 联合团队组织结构 7
3.3. 人员构成与工作职责 8
3.3.1. 领导小组 8
3.3.2. 执行小组 8
3.3.3. 业务维护小组 8
3.3.4. 系统维护小组 9
3.3.5. 质量监督小组 9
3.3.6. 支持小组 9
3.4. 工作场地 9
3.5. 团队成员名单 10
4. 项目维护规范 11
4.1. 工作流程 11
4.1.1. 日常维护流程 11
4.1.2. 故障信息传递与处理总流程 13
4.1.3. 重大故障处理流程 15
4.1.4. 一般故障处理流程 16
4.1.5. 沟通汇报流程 16
4.1.6. 新需求管理流程 17
4.2. 工作制度 17
4.2.1. 维护计划制度 17
4.2.2. 巡检制度 17
4.2.3. 沟通汇报制度 17
4.2.4. 新需求管理制度 18
4.2.5. 上线管理制度 19
4.2.6. 绩效考核制度 20
4.2.7. 建立用户系统档案制度 21
4.2.8. 机房出入管理制度 21
4.2.9. 安全管理制度 21
4.2.10. 其它管理制度 21
4.3. 言行规范 21
5. 维护过程控制 21
5.1. 日常维护检查 21
5.1.1. 重要命令类（待细化） 21
5.2. 文档管理 22
5.2.1. 工程移交文档管理 22
5.2.2. 运行维护文档管理 22
5.2.3. 验收文档管理 23
5.2.4. 文档的应用管理 24
6. 服务预案 24
6.1. 一般问题 24
6.2. 较严重问题 24
6.3. 严重问题 24

1. 简介
本维护作业指导书，是针对公司各产品事业部已进入维护阶段的项目编写的，主要是对维护项目进行项目管理，从维护方面的体系建设、团队建设、相关的流程、制度、言行规范、操作规范、文档管理、服务预案几个方面进行阐述，用来规范维护工作的指导性文档。
1.1. 目的
为了使各项维护工作进行的有条不紊，需要进一步规范与维护活动相关的环节，为维护工作提供可靠的工作方法，特编写该维护作业指导书。该维护作业指导书是指令性文档，维护人员的各项维护工作必需遵照该规范进行。
1.2. 范围
该指导书适用于公司所有产品事业部所有维护阶段项目，涉及所有维护活动及与维护活动相关的流程，在用服部日常维护工作中使用。
1.3. 文档约定
正文运用正文（首行缩进）这种格式，用于详细解释说明标题的内容，可在各级目录中加以应用，详略程度视情况而定。编写完正式文档后请进行目录的更新域”操作。蓝色字体为需要依据实际情况修改部份，修改后采用蓝色字体。

1.4. 参考资料
《客户服务规范》

2. 服务体系建设
2.1. 公司层面服务体系结构

宏智客户服务体系是完全开放式的。体现了宏智对服务的高度重视，是服务型的软件企业。上层领导为执行总裁、分管服务副总裁，中间执行层为客户服务中心对应的受理部和维护部到产品事业部，底层由服务项目经理承担的维护责任人。由产品事业部针对维护项目组织解决问题的专家组和维护责任人，对维护项目提供各种用户服务。客服中心的工作贯穿整个客户服务过程的始终，负责对服务问题进行受理，负责对受理的问题进行跟踪，对维护质量进行监督检查，直到客户满意确认为止。

2.2. 事业部层面服务体系结构

3. 服务联合团队建设
3.1. 项目相关方

3.1.1. 宏智公司项目相关方

销售部门

客户关系

用服部
客户服务中心

湖北维护中心
监督服务质量及产品质量

信息共享、
协作
信息共享、
支持
系统维护
支持
需求开发及
支持
产品开发部
系统集成
事业部
移动产品
事业部

项目

3.12. 用户项目相关方
3.1.3. 其它相关方
IBM公司
BEA公司
ORACLE公司
3.2. 联合团队组织结构

支持小组
系统维护小组
业务维护小组
执行小组
质量监督小组
领导小组

3.3. 人员构成与工作职责
3.3.1. 领导小组
（1） 人员构成：
（2） 湖北移动公司、宏智公司双方高级领导人员各1-2人。
组长由湖北移动公司方面担任，副组长由宏智公司方面担任。
（3） 工作职责：
（4）
l 审核批准项目维护计划。
l 负责项目维护过程中的重大事件的决策。
l 根据项目维护过程中的质量技术、资源、风险等实行宏观监控。
l 协调涉及与工程服务有关的各方工作关系。

3.3.2. 执行小组
（1）人员构成
湖北移动公司、宏智公司双方项目维护总负责人（即执行小组组长）各1人。
组长由青海移动公司方面担任，副组长由宏智公司方面担任。

（2）工作职责
l 根据项目进展及工作要求制定维护计划，并监督实施。
l 协调项目组内人员的分工合作，资源分配。
l 提出并确立业务整体需求，并对业务新需求进行需求管理。
l 负责制定项目验收内容，报领导小组审批。
l 负责工作质量监督。
3.3.3. 业务维护小组
（1）人员构成
湖北移动公司、宏智公司熟悉业务的维护人员1－2人。组长由宏智公司方面担任，副组长由湖北移动公司方面担任。

（2）工作职责
l 负责BOSS系统业务方面日常维护。
l 按照制定的维护计划对项目进行维护。
3.3.4. 系统维护小组
（1）人员构成
湖北移动公司、宏智公司熟悉主机、网络、数据库的维护人员2－4人。组长由宏智公司方面担任，副组长由湖北移动公司方面担任。

（2）工作职责
l 负责系统日常维护。
l 按照制定的维护计划对项目进行维护。
3.3.5. 质量监督小组
（1）人员构成
由有管理经验、熟知管理规范的人员组成。
组长由湖北移动公司方面担任，副组长由宏智公司方面担任。
（2）工作职责
l 对项目维护过程中的服务质量与产品质量管理进行监督。
l 对发现的质量隐患进行引导监督纠正。
l 定期向项目领导小组通报质量状况。指出存在问题，协助执行小组提出解决方案。
3.3.6. 支持小组
（1）人员构成
支持小组成员由各相关方的技术资深人士或相关活动支持人员组成。

（2）工作职责
l 为执行小组业务实现、技术问题的解决提供技术支撑或咨询。
l 为执行小组其它相关活动（如：技术交流、方案编制、扩容谈判）提供支持。
3.4. 工作场地
领导小组：不在现场工作。
执行小组：在现场工作。
业务维护小组：在现场工作。
系统维护小组：在现场工作。
质量监督小组：不在现场工作。
支持小组：一般进行远程技术支持，必要时到现场工作。

3.5. 团队成员名单
组织
角色划分
公司
联系电话
E-mail
领导小组
组长：
移动公司

副组长：
宏智公司

质量监督小组
组长：
移动公司

副组长：黄东青(服务质量)
宏智公司

副组长：邱新强（产品质量）
宏智公司

执行小组
组长：
移动公司

副组长：李春晖
宏智公司

副组长：
宏智公司

业务维护小组
组长：杜建刚
宏智公司

副组长：
移动公司

组员：刘伟、
宏智公司

系统维护小组
组长：
宏智公司

副组长：
移动公司

组员：李满意、朱大妙、董昆伦、陈林春
宏智公司

支持小组
销售经理：刘斌
宏智公司

开发组： 林勇军
宏智公司

系统集成：
宏智公司

技术配合及业务支撑：

移动公司

宏智公司服务热线：
7*24小时服务热线：13871028731
5*8小时服务热线：027－65657035 传真：[phone]
EMAIL：lich@
4. 项目维护规范
4.1. 工作流程
41.1. 初验完到终验工作总流程

说明：
该流程是对系统已初验并移交用户的项目，在运行维护一段时间达到合同终验标准进入终验的流程。在系统运行维护过程中，维护人员需要保证系统稳定运行，对系统不断进行优化调整以达到符合终验标准，在终验前向用户提出系统终验申请，经双方确认同意后对系统进行终验。终验后通过后根据合同签订情况，判断是否继续提供无偿维护，若没有规定提供无偿服务需要提醒用户签订维护合同，并由项目经理组织服务合同的签订或者向用户提交《单次服务收费标准》，以便于继续提供维护支持。
4.1.2. 日常维护流程

说明：
该流程是维护过程工作流程，对进入维护阶段的项目（包含已上线未初验项目）都需要制定每月的维护计划，并按照计划安排每月的主动维护工作，同时也存在突发性的被动维护需求。不管是主动维护还是被动维护总体上分为三类：升级工作、故障处理、日常维护，对于每一类工作具体流程各有差异。
升级工作：对于升级工作在升级之前需要提交用户关于升级的通知书，在用户同意后安排升级具体工作，并与用户共同协商升级过程，升级完成后进行工作总结与用户确认本次升级工作情况，提交系统升级确认报告由用户签字确认。
故障处理：故障处理工作有用户发现的和我方人员发现的，用户发现的投诉后需做相应的投诉记录《问题报告单》，维护人员根据用户的投诉情况描述或我方发现问题的现象进行分析，决定维护方式是采用远程维护还是现场维护，若远程维护需要与用户进行充分沟通，提交远程维护操作通知，用户同意后进行远程登入维护。在故障处理完成后维护人员需要及时填写故障分析报告，与用户方进行交互。
日常维护：日常维护工作分为主动维护与被动维护，主动维护工作按月计划进行，完成后填写维护日志；被动维护工作基本属突发性工作，完成后填写服务完成反馈表。
4.1.3. 故障信息传递与处理总流程

1）说明：
系统发生重大故障时，用服经理在第一时间获得有关信息后，在通知相关人员采取紧急处理措施同时，将信息传递部门内部客服人员。客服人员及时将故障的发生时间、地点、现象、处理预案传递公司客服中心，通过客服中心备案信息及时转达公司领导。同时客服中心跟踪故障处理，故障处理结束用服经理组织相关维护人员填写故障分析报告，将故障造成的影响、处理情况、原因分析、采取的纠正预防措施等及时反馈用户及客服中心。
2）故障定义：
故障级别
故障级别定义

A级
系统故障造成应用停止，对客户业务产生严重影响
B级
系统虽可运行，但丧失部分功能或关键部分性能严重下降，
对客户业务产生中等程度影响
C级
系统次要部分出现问题，对客户业务产生较小影响
D级
查询信息或使用方面的问题，对客户业务基本没有影响
其中A、B级别故障列入重大故障。
4.1.4. 重大故障处理流程

支持小组
系统维护小组
业务维护小组
执行小组
领导小组
10分钟内口头上报
系统故障
当日内书面上报
业务故障
立即进行支援，
分析并确立解决方案
立即解决，当日内书面上报
立即解决，当日内书面上报
获取相关配合
10分钟内口头上报
10分钟内口头上报

系统故障如：硬件损坏系统中断、操作系统宕机、网络故障等。
业务故障如：业务进程中断、数据库死锁、数据库宕机、计费错误（不准确、话单丢失）等。

4.1.5. 一般故障处理流程

业务故障
系统故障
每周书面上报
立即进行支援，分析并确立解决方案
立即解决并故障记录
立即解决并故障记录
获取相关配合
支持小组
系统维护小组
业务维护小组
执行小组
领导小组
故障汇总、分析并组织
制定相应纠正预防措施

4.1.6. 沟通汇报流程

按制度约定周期上报
周报、月报、会议
相关信息共享
系统维护小组
业务维护小组
执行小组
领导小组

按制度提交周报、月报及召开会议

按制度提交周报、月报及召开会议

4.1.7. 新需求管理流程
市场部
计费中心
支持小组
确认
新需求开发
分析并确立解决方案，制定
计划书，并向执行小组反馈
业务维护小组
按约定周期汇总并审核提交
需求的可管理性
需求的计划性
业务需求

执行小组
收集汇总

应用
测试

4.1.8. 版本控制流程
Y
N
审核
发布
发布
进入配置库
进入配置库
开发、测试
开发、测试
是否纳入核心版本
核心版本开发修改
本地化版本开发修改
需求或适应完善性问题

4.2. 工作制度
4.2.1. 维护计划制度
维护计划包含：年度维护任务、年度维护计划、月度维护计划及总结。用服人员的日常各项维护工作开展必需遵照相应的计划进行，同时允许适当的突发性维护任务。
4.2.2. 巡检制度
用服部通过组织技术专家组的检查、抽查的方式，到用户现场进一步检验和提高用服人员产品的维护质量。巡检分为两部分内容：
1、 系统巡检：此巡检主要由宏智公司系统集成部负责组织，主要针对主机、数据
库、中间件、网络等的巡检，必要时可邀请原厂商来负责巡检。巡检的步骤如下：
1） 制定巡检计划，并报送维护领导小组。巡检计划包含巡检的内容、时间、地点、目的等。
2） 按巡检计划进行巡检。
3） 巡检完毕后编写巡检总结报告，并报送维护领导小组，巡检报告包括巡检的情况、巡检中发现的问题，所发现问题的预防及纠正措施等。
2、 应用巡检：此巡检主要由宏智公司应用软件的开发人员组成，主要针对应用软
来进行巡检。
宏智公司或系统原厂商进行巡检时，移动公司必须积极进行配合，准备巡检所必备的条件，一起参与巡检的实施，积极向巡检人员汇报系统存在的问题，并和巡检人员一起编写巡检报告。对于巡检过程中发现的问题而采取的纠正预防措施，要与宏智公司的维护人员一起积极实施。

4.2.3. 沟通汇报制度
系统进入维护阶段后，相关配合方必需有畅通的沟通汇报机制，才能提高工作的效率，提高服务质量。为此，特别强调沟通的会议制度、周报制度及月报制度。这三项沟通制度必需得到很好的落实，随着系统的逐步移交过渡，沟通汇报制度的周期由短期到中期到长期逐步取消，以系统的维护周期及生命周期为终点。
1）会议制度
会议制度分两种情况：一种是当系统出现重大故障、新需求量较大实现有难度、相关方重要工作开展协调、阶段工作汇报、重要信息汇报等，无法通过周报、月报等书面方式得到很好得沟通协调时，必需通过会议方式召集相关方协商。另一种是根据相关方的约定定期例会制度。
2）周报制度
在维护前期，维护任务较繁重的情况下，每周维护人员必需写工作周报，将项目上的工作任务完成情况及存在的问题、需要相关方的配合在周报中及时体现，周报提交用户及部门内部领导查阅，以便及时提供有效的支持配合。
3）月报制度
月报形式与月度维护计划及总结为主，主要是明确每月的维护任务、时间安排、参与人员、各项任务的风险预测、实际完成任务情况与计划比较，做到每个月工作都能够有计划的进行。由用服经理或维护项目经理来组织编写，维护人员负责执行计划任务。
4.2.4. 新需求管理制度
对于用户提出的新需求，我们必须引导用户进行有效的管理：一、组织由用户市场部需求策划人、运行支撑部门、我方参加的新需求讨论会和定期沟通制度的建立，成立三方新需求管理工作小组；二、倡导需求提交工作流程化，由用户集中审核汇总，统一接口人员，筛选出一些无关的需求，按照约定的时间、周期性的将需求传递我方，在双方共同协商后明确哪些可实现哪些不可实现，实现的时限等明确后方可进入开发阶段。三、引导用户提高对新需求管理的计划性，根据用户年度的经营目标和竞争环境，逐步引导用户由无计划的需求发起中，转于到有计划性的提需求，从被市场需求牵着走的被动模式向主导市场需求的经营模式转变。逐步实现大部分需求有计划，小部分需求突发产生；四、与用户一起分析新需求的有效应用情况，逐步消灭无效的新需求的开发；五、与用户一道制定新需求的推广计划，保障新需求的应用。
4.2.5. 上线管理制度
1、每次上线都必须填写好“BOSS系统应用软件上线审批表”，以测试报告作为附件，报移动公司相关负责人批准以后才能上线。上线时间以每2周一次为宜，需要紧急上线的情况例外。
“BOSS系统应用软件上线审批表”包括以下内容：
l 要求上线时间
l 申请人（签名）
l 需求描述
l 上线公告(如果没有可以填无)
l 上线涉及程序及版本号
l 风险分析（上线程序可能影响到在线系统的那些功能）
l 应对措施（一旦发生上线程序引起的故障，应采取的处理措施，如回退等）
2、配置测试人员工作
在程序上线的前一天，配置管理员通知执行组组长有新程序上线，便于安排维护值班和营业厅调查人员；提交2份文档给执行组组长，《新上线程序异常处理表》和《新上线功能调查反馈表》。要求填写的栏目如下：
新上线程序异常处理表：
l 上线程序名称（注明前台、后台）
l 上线功能描述
l 新程序获取方法
l 老程序获取方法
l 异常处理方法
新上线功能调查反馈表：
l 程序名称（前台客户服务、前台业务支持）
l 菜单类名称
l 菜单项名称
l 功能名称及功能描述
在线测试 对于新上线程序中不能在测试环境中进行测试的功能，执行组组长必须安排进行在线测试，在线测试时间在程序上线后立即进行，测试结果报告执行组组长。对于不能通过测试的程序，经执行组组长授权后，进行在线程序更新或回退。
第二天值班 在新程序上线的第二天，执行组组长安排配置管理员早上值班，处理异常情况。发生需要回退的情况时（包括连带影响的问题），经执行组组长授权后，进行在线程序更新或回退。
3、维护值班
新程序上线后，执行组组长安排维护人员早上维护值班，并将《新上线程序异常处理表》和《新上线功能调查反馈表》交给该维护人员。
维护人员进行以下工作：
l 根据《新上线功能调查反馈表》验证新功能；
l 根据《新上线程序异常处理表》处理申告；
发现新上线程序问题时（包括连带影响的问题），立即报告执行组组长，同时通知配置管理员。
4、上线功能调查
在程序上线的当天（如果是晚上上线，则是第二天），执行组组长视情况安排一名员工到营业厅，对新上线程序涉及到的功能进行调查，填写好《新上线功能调查反馈表》，交给执行组组长。对严重影响营业厅正常工作的情况（包括连带影响的问题），要立即报告执行组组长。
4.2.6. 权限管理制度
权限管理的时段划分以初验为界限，初验前权限管理双方共有，以宏智公司为主，移动公司个别人员也可掌握系统权限。初验后权限管理由移动公司控制，宏智公司需要权限时，必须向移动公司维护负责人申请，移动公司维护负责人批准后，将权限下放给宏智公司，宏智公司使用此权限完毕后，移动公司将权限收回，此过程必须做好详细的记录。

4.2.7. 绩效考核制度
维护工作质量的考核，实行多层监督机制，维护质量目标层层分解层层落实。自上而下由公司层面客服中心到事业部到用服部到维护经理到维护人员的压力传递。
由移动公司和维护经理对维护人员进行业绩考核，考核结果的权重各占50％，维护质量好坏直接与维护人员绩效工资挂钩。客服中心通过巡检、抽查的方式对维护经理维护计划的制定、实施、维护质量进行考核。
4.2.8. 建立用户系统档案制度
在部门内部建立用户系统健康档案管理，分为原始配置、动态配置、性能优化记录等方面，维护人员将信息反馈至项目经理，每个月由项目经理负责更新一次。
4.2.9. 机房出入管理制度
遵守移动公司的机房出入管理制度。
4.2.10. 安全管理制度
遵守移动公司的安全管理制度。
4.2.11. 其它管理制度
遵守移动公司其它管理制度。

4.3. 言行规范
参见《客户服务规范》
5. 维护过程控制
5.1. 日常维护检查
5.1.1. 重要命令类（待细化）
1) 停止系统操作命令
在系统日常维护工作中对于停止系统命令的操作，必需通过书面的方式与用户方执行小组组长确认，在用户领导或领导指定负责人员同意后方可进行操作，参与操作现场的人员必需至少2人，命令操作同时确认，用户方若无特别说明至少要求有一人在场，一方面以防万一出现意外牵扯不清，一方面为谨慎操作提供了保障。系统重要操作命令举例如下：
1、主机reboot、shutdown等重启或停机；
2、数据库shutdown；
3、后台应用程序退出重启，影响业务正常运行；
4、主机、网络设备、后台应用平台的连接线路、通信线路、电源的拔插等；
2) 易造成故障命令
对于易造成故障的命令也需谨慎操作，举例如下：
1、以root用户进入主机使用任何操作；
2、操作系统delete、rm等删除性操作；
3、在数据库进行delete、update、drop等操作；
4、更改系统参数配置操作；
5、业务繁忙时段进行数据库大事务操作禁止，如：全表select、update；全库select、update；数据库备份bcp。
5.2. 文档管理
有关于文档输出过程在上述两流程中已阐述，下面主要针对文档的填写要求和管
理进行阐述。
5.2.1. 工程移交文档管理
1） 初验
初验工程移交工作由工程建设小组人员组织完成，具体移交提交文档参见《建设与维护移交说明》，移交用户同时也移交维护人员负责签收接管。
2） 终验
系统终验工作由维护人员负责完成，具体提交文档根据维护阶段变更情况，对初验提交文档进行更新提交用户，在部门内部备案。
5.2.2. 运行维护文档管理
1） 维护日志
维护日志填写要求按实际维护情况如实填写，主要是为了便于今后维护提供查询依据，维护日志在维护现场与产品事业部内部分别进行备案。
2） 系统运行分析报告
根据系统日常运行情况，至少每个月或每季度需要知道系统阶段性的运行状况，对运行状况进行分析及优化，完成后填写系统运行分析报告提交用户同时部门内部备案，做到厂商与用户双方都放心系统是正常运行并且可以继续正常运行。
3） 系统升级通知书
在用系统的维护往往涉及到升级，它将影响系统的正常业务运行，这时需要与用户沟通，通过书面形式发送升级通知书与用户确认，在许可的条件下进行升级工作的开展，确认后的升级通知一式两份，用户一份部门备案一份。
4） 系统升级确认报告
系统升级完成后，将升级涉及的相关操作范围完成情况及目前的版本号，相关培训工作的开展与用户充分交流，确保系统正常运行的情况下，用户能够熟练操作。一切升级带来的工作完成后与用户进行确认，填写系统升级确认报告，确认后的系统升级报告一式两份，用户一份部门备案一份。
5） 远程维护操作通知
在系统发生故障，需要远程登入系统进行相关的维护操作，必需填写远程维护操作通知书，通过书面方式传真至用户，在用户确认后获取登入系统的权限方可进行操作。
6） 故障分析报告
当系统发生重大故障时，维护人员在第一时间将信息汇报用户主管领导和部门内上级领导，在故障处理结束在规定的时限内及时填写故障分析报告，填写有关故障涉及的范围、发生原因、处理情况、拟采取的纠正预防措施等，抄送用户方相关领导同时，部门内部备案处理。
7） 服务完成反馈
在日常的被动维护工作中，维护人员维护工作完成后必需填写服务完成反馈表，将所做的操作、配置及完成情况与用户负责人反馈，在用户负责人签字确认后方可离开，服务完成反馈表提交部门内部备案管理。
8） 用户系统档案
遵照上述制度。
5.2.3. 验收文档管理
1） 系统终验申请报告
终验申请报告需要充分说明系统符合终验的各种条件，最好具备有说服力的实际运行数据，与用户充分沟通达成终验的目的，报告提交用户同时本部门备案。
2） 系统终验报告
系统终验通过后，应记录参与验收的单位及人员、验收内容、验收结论、验收备忘、涉及到的相关附件文档等，最后用户签字盖章。终验报告一式两份，用户一份公司备案一份。
5.2.4. 文档的应用管理
所有的文档记录要清晰、适用、一目了然，维护人员在运行维护阶段，对于技术工作要逐步养成先通过查阅用户系统档案的工作习惯，然后再进行相关的维护配置更改，更改后再将配置更改记录于用户系统档案库。其它事务工作可以通过运行维护相关的文档了解情况，维护工作杜绝盲目操作习惯，一切工作力争遵循流程、规范、制度照章进行。
6. 服务预案
6.1. 一般问题
问题描述：应用系统基本正常, 偶尔出现一般性的错误, 业务处理不受影响。
举例：1、前台监控系统系统偶尔出现输出信息残缺
2、系统告警窗口出现错误警告，但是系统能正常处理事务
处理方法：分析问题原因，并提供解决方法或替代方案。如果是产品问题，在以后的升级版本中最终解决。
6.2. 较严重问题
问题描述应用系统基本正常, 偶尔非致命性错误, 只要及时处理，业务基本不受影响。
举例：1、后台进程由于某种原因退出，或者死掉。
2、由于物理原因，导致采集系统和联机指令系统无法及时处理业务，如网络故障等。
处理方法：系统维护人员根据情况重新启动后台进程，或者上报硬件系统维护人员，及时解决出现的硬件问题。
6.3. 严重问题
问题描述：应用系统不能启动或启动后不可操作, 系统业务无法正常处理。
举例：1、由于数据库等原因导致应用系统无法连接数据库，应用系统无法启动。
2、系统硬件出现重大故障，操作系统运行严重异常。
3、由于应用软件的原因导致系统业务处理严重异常，如联机指令错误解析指令等。
处理方法：工程人员在第一时间到现场，及时、连续响应解决，采取相应解决方案直至系统正常运行为止。
机密 ÓWholewise，2002
宏智科技移动产品事业部
第 27 页 共 28页