系统宕机处理流程规范及方法
1.目标
随着公司客户数量增加，医院业务规模复杂，应用程序交互关联频繁、客户使用业务系统频率提升，客户定制化功能增多、多应用服务业务发布结构、软硬件平台环境异构，客户业务系统宕机概率增大。

为在客户发生系统宕机的情况下，实现公司层面及时提供相关应急处理服务、规范公司内部应急操作流程、及时客户系统能宕机时，对相关信息数据的有效收集，及时处理宕机处理，实现内部业务（集成、接口、DBA、二次开发）组任务准确记录、分发、协同、处理、跟踪、反馈。

统一系统宕机出入口，便于系统宕机的问题分析、处理经验总结、知识共享，提升客户满意度。

2.宕机处理流程图
（1）规范宕机处理流程、统一由客服组受理相关系统宕机问题事宜从接收、协调处理、跟踪与反馈。

在客户生产系统发生宕机事件，第一时间由客户、项目经理、项目实施人员进行宕机申报及协助请求。

（2）客户、项目经理、项目实施人或现场人员、远程按操作人员，第一时间按操作文档收集相关应用日志信息，并重启应用服务(而不是应用服务器，绝不允许直接重启数据库及数据库服务器)。

客服中心提供根据相关宕机操作标准文档，配合进行相关信息的收集或要求项目经理、项目实施人员、客户协助收集系统相关信息。

（3）在重启相关应用服务后，系统宕机问题依然存在和无法解决，客服中心根据宕机时收集的相关信息，按操作文档说明进行故障的预判，并将宕机时收集的相关信息发送给特定的业务分组、分配宕机处理任务，并记录和跟踪。

（4）各业务分组在收到客服中心分配的宕机处理任务，应及时响音并处理、应在半小时内恢复业务、并初步明确宕机原因，处理过程和原因需要部门整理和修订评估后，以书面形式告知客户宕机原因、处理方法和建议。

（5）若业务分组成员在下达宕机任务的半小时内未能完成业务恢复和宕机原因查明，应及时向业务小组负责人告知，并准备好相关收集信息并请求小组负责人协助处理。

（6）若业务小组负责人在已分配宕机任务的处理过程中，发现宕机原因不明或明确宕机原因不在业务小组工作范围，可要求进行多业务部门负责人进行会诊，并告知客服中心。

（7）在多业务部门负责人会诊宕机原因、处理宕机任务的过程中，必须形成相应讨论记录，处理过程文档，已形成过程资产，在各业务部门之间进行知识共享。

（8）系统宕机处理在一小时内未完成，大区负责应该协调实施人员去客户现场，对外进行沟通，对内进行。

（9）宕机任务处理结果必须在规定时间内反馈给客服，由客服反馈给客户、项目经理、项目实施人员。

3.信息收集分类和方法描述
客服中心在收到宕机处理请求后、按宕机流程处理进行相关信息收集，并进行预判和评估，并将相关预判结果确认分配给特定业务组。

系统集成部：主要负责包括服务器，操作系统等硬件、操作系统、网络等相关故障的分析和评估，并提供标准判断方法，明确原因（针对公司销售的硬件和系统集成项目提供全方位服务，而由客户自行采购的设备和系统，告知和建议客户从第三方获取支持服务。

（1）首先判断是否有硬件故障，直观上能够就能够识别。

目前所有市场主要业务硬件都提供自我检测组件，因此在相关硬件出现故障时，其面板都会有报警灯显示(黄
色或红色)。

（2）网络故障和性能判断：连通性、稳定性、吞吐量。

连通性判定首先采用PING的方式初步确定，若无问题需要看一下中间件和数据库的网络服务。

采用TCP/IP
应用服务在网络上都有通讯接口，因此从服务地址及端口能够判断相关业务是否
正常。

（3）操作系统日志收集方式方法：根据不同操作系统类型，系统相关日志收集的方式方法有所不同，具体见操作细则。

数据库组：主要负责数据库宕机时，数据库服务的重启和数据库机器的重启，以及数据库相关日志、空间、归档、用户、备份等检查，分析和问题处理工作。

二次开发组：主要负责电子病历相关应用程序和中间件宕机时日志收集、分析和问题处理。

接口组：主要负责电子病历相关产品宕机时涉第三方应用系统接口的日志收集、分析和问题处理。

4.信息收集操作细则
（后续完善）
系统集成组：
DBA 数据库组：
二次开发组:
接口组:。