系统运行管理方案

系统运行管理方案

1.监控管理

监控管理主要是通过对被管对象的配置数据、性能数据、告警数据的统一采集，实现对IT基础设施、应用软件以及业务的监控，主动发现被管对象当前的故障或告警信息并进行处理，保障系统的稳定运营。 1.1. 基础设施监控

基础设施监控是指对所有主机、数据库、中间件、网络、存储、备份等设备及软件进行统一监控，及时发现平台类的告警。 1.1.1. 统一采集与控制

根据运维监控管理平台技相关的要求，基础设施监控数据采集的范围包括各种设备的告警、性能、配置数据。 1.1.2. 数据采集

★信息点采集模板界面化配置

根据监控对象可灵活配置改对象需要监控的信息点、采集频率等信息，并支持模板的远程下发、更新。

★ 采集代理远程下发、启停与集中监控

可在下发采集模板时同步下发采集代理并进行友好的下发过程的可视化能力，下发后可自动启动采集代理。

提供集中的采集设备监控代理运行监控界面，便于维护人员实时监测各个代理的运行情况，并提供便捷的重启、模板和代理

程序更新功能。

★ 采集代理组件化封装

根据不同的监控对象和采集方式的差异化，对目前的监控代理进行组件化封装： ➢ 主机设备监控代理 ➢ 数据库库监控代理 ➢ 中间件监控代理 ➢ 网络设备监控代理 ➢ 日志监控代理 ➢ 存储设备监控代理 ➢ 备份设备监控代理 1.1.3. 告警处理

告警处理是针对来自IT基础设施的告警信息进行统一处理，以便快速确认故障，缩短排障时间，为及时恢复系统运行打下良好基础。包括：告警定位、告警过滤、重复告警压缩、告警信息丰富、告警前转、告警操作等。

 告警定位

告警定位是通过对告警信息的查看确定故障可能发生的位置。

 告警过滤

告警过滤是指对大量重复的告警信息和次要、无意义的告警信息进行过滤，以避免告警风暴和无效告警或非关心告警的干扰，

以提高监控与处理的效率。

 告警压缩

告警压缩是对不同时间产生的相同告警，将其合并成一条告警信息，同时累计该告警的次数，更新最后发生时间等。

 告警信息丰富

告警丰富功能主要是对告警信息增加描述，使得告警信息更加详细和直白，方便系统维护人员更快的了解告警信息。

 告警前转

告警前转将告警信息以各种手段（手机短信、EMAIL等）转至指定的维护人员。

 告警操作

告警操作主要包括告警确认、告警清除、告警级别调整、转事件单等。 1.1.4. 性能处理

 性能数据计算与汇总

对预处理后的数据进行必要的计算、汇总形成所需的性能指标。

处理后的性能数据保存到数据库中，供分析和呈现使用，性能数据的保留时间可配置。

针对部分不需要保留较长时间的性能数据，在统计汇总后，可将历史数据进行清理，减少系统对存储空间的浪费。

 性能数据阀值预警

性能数据反映了系统及应用的运行状况，是判别被管资源运行是否正常的关键数据。性能数据一旦超出预先设定的阀值时，可及时触发性能阀值越限告警，该告警称为性能阀值告警。

提供基于应用系统性能指标趋势数据的分析处理功能，实现性能预警，并为分析优化工作提供必要的依据。

提供设定、查询、修改、删除性能阀值的工具，针对统一性能指标，可设多个阀值进行分级告警。

性能阀值告警的内容应能比较全面地描述该性能数据超出阀值的情况，方便分析、排除事件。

 性能数据梯度预警

系统提供梯度告警的功能，也就是两个时间点的性能数据差值如果超过了门限，则应该上报告警。这种告警不同于性能数据的阀值告警，性能数据的阀值告警只是对一个时间点上的性能数据设定了门限，而梯度告警则是对两个时间点的性能数据的差值设定了门限。梯度告警能够迅速发现性能数据的异常变化。

 性能数据汇总统计

为了性能数据分析和呈现，以及事件的分析，系统应能定期生成统计数据。通过分析历史指标的情况，预测未来的发展，提升管理层次，达到面向服务品质的管理。

1.1.5. 拓扑处理

拓扑图的生成可支持手工配置或导入，也可通过系统自动发现并注册实现，以上几种方式都是以CMDB为基础，进而获取每个节点在拓扑图中的位置和它们间的依存关系，从而构建出整个IT运营网路，通过实时刷新拓扑图，可反映出当前网络中节点的最新状态，帮助运维人员从宏观上对对整个IT支撑系统的运行情况有直观的掌握，进一步提高运维的效率。

 拓扑管理

通过CMDB对象实例树，可方便的对拓扑图中的节点，及节点间的关系进行维护，系统支持对节点的增加、删除、修改属性 ，状态及更改不同节点间的依附关系等。

 拓扑监测

拓扑监测是根据拓扑模型，对在模型上定义的关键节点，节点关键性能、质量指标数据进行实时监控，将业务系统运行中出现的告警、预警信息直观呈现在拓扑模型中，来实现对应用系统运行状态的专题式监控，及时发现用户关注的异常。

支持通过拓扑图关联到应用节点详细信息页面，可根据时间段来查询该节点的告警信息列表，进而进行相关告警处理如告警确认、告警级别调整、告警清除等操作；

支持通过拓扑图关联到应用节点详细信息页面，可根据时间段来查询该节点的历史指标数据，以表格或走势图的方式展现，

支持业务指标数据导出功能，导出格式包括但不限于文本、EXCEL等文件格式；

拓扑视图支持定时无闪烁刷新功能，刷新频率不宜过高，以不影响系统性能和展现效果为基准，也不宜过低，否则无法达到监测的实时性要求。

 应用拓扑

以IT系统内的业务类型作为索引来组织被管资源的业务拓扑结构。典型的业务拓扑图是一个树型结构，实现业务与IT基础设施关联关系的直观展现。系统提供方便的图形化配置修改工具，允许管理维护人员灵活修改相关联资源等基本配置信息。

以应用系统作为索引来组织应用软件包含的被管资源的拓扑结构。应用拓扑体现应用软件被管资源的分布和关联情况。系统通过提供方便的图形化配置修改工具，允许管理维护人员灵活修改组成应用系统的相关联资源等基本配置信息。拓扑图能够展现应用软件被管资源的运行状态，包括应用软件的配置信息、告警信息和性能信息，且可以实现相关拓扑图的自动生成。 1.1.6. 操作控制

主要完成运维监控管理平台控制模块与被监控对象之间的操作指令传递与结果反馈通道，以便完成对被管对象的自动化控制,在运维监控管理平台中的主要应用为进程、服务的启停和调用等。

操作控制主要是通过以下方式登录到设备上执行操作。 SNMP 方式：支持SNMP接口的系统，可以此方式得到； telnet方式：通过telnet等方式对网元进行操作； Agent方式：通过在服务器上安装Agent控制服务器的操作；

ssh方式：大量操作控制采用安全的ssh执行； FTP/TFTP方式：FTP等文件方式传输配置文件； rlogin方式：远程登录后执行；

Rsh、rexec方式：直接远程执行相应的操作； NT登录方式： 登录到NT上执行相应的操作； HTTPS方式：通过HTTPS对相应的网元执行操作； Web service方式：对于支持web service的应用系统采用本方式； 1.2. 应用软件监控

应用软件监控是通过对各IT应用（进程池、进程、接口和数据文件、日志等）进行监控，及时发现系统应用软件的异常，并确定故障原因，进行故障定位和处理，保证应用软件正常运行，提高IT应用软件运行管理水平。 1.2.1. 进程监控

提供对应用进程的监控管理，确保系统可靠、稳定地运行。支持对各进程运行状态进行监视，能够实时查看进程名称、进程

号、进程启动路径、进程状态、进程说明信息等相关运行信息。当进程异常终止时，能够生成相应告警。

在UNIX操作系统上，经常出现由于资源竞争而导致死锁的一些进程，从操作系统的进程状态上看这些进程是正常的，但从业务功能角度，这些进程实际已处于僵死状态，因为它们已不能处理任何业务逻辑。运维监控管理平台支持对进程日志是否增长等方式发现僵死进程并告警。

系统支持对某一时刻的进程状态进行记录拍照，在后续时刻发现与拍照记录不一致时，可按拍照状态复原；发现进程运行状态与拍照状态不符时的及时告警，通知运维人员。 1.2.2. 进程池监控

进程池监测是指对若干个具有相关性的应用进程进行集中管理监控，进程池的主要作用是在有多个客户端并发请求时提高服务器的处理效率。

 系统能够进程池的配置信息进行管理，包括最大进程数量、最小进程数量以及进程池对应的日志文件。

 系统能够通过进程池所应当包含的进程数量等性能数据的处理与分析，及时发现进程池的异常情况，保障系统正常运行，并为分析优化工作提供必要的依据。在性能数据处理过程中，保证处理的完整性和连续性。

 当出现异常情况时，应能够生成相应告警并转发对应处理人员。

1.2.3. 文件积压监控

对应用系统间文件类传输接口进行积压监控，及时发现进程异常和接口异常。 1.2.4. 应用服务监控

提供对中间件的应用服务和ORACLE的job进行监控，当中间件的应用服务异常，或者ORACLE的job异常时，能够生成相应告警。

1.2.5. 侦听监测

可集中监测CRM、服务开通等系统后台侦听的运行状态信息，当侦听异常时，系统可提供集中的操作功能，重启目标侦听进程。 1.2.6. 队列监测

可集中监测服务开通后台消息队列的实时运行信息，当当前队列深度接近系统设置的最大队列深度时时，系统可及时触发告警，提醒业务支撑人员进行及时处理。 1.2.7. Web应用监测

可集中监测前台Web应用的运行状态、挂起线程数、超时时长，当挂起线程数较多时，系统可及时触发告警，提醒业务支撑人员进行及时处理。 1.2.8. 接口平台监测

系统可及时监测各个接口平台运行服务的运行状态和响应性能信息，针对运行异常和性能较差的服务系统可及时触发告警，

并能够对服务当天的探测性能和历史响应能力进行图形化的展示。

1.3. 业务监控

业务监控主要是对业务受理、充值缴费、停复机等端到端的客户感知度强的业务流程进行监控，主动发现这些业务流程中影响客户感知度的因素，如开通时长、充值可用性等，并不断优化系统，逐步提升内外部客户的满意度。

业务监控主要包括对业务建模、业务运营指标实时监控、业务运营质量分析、业务可用性探测等。 1.3.1. 业务建模

业务活动模型的要素包括业务关键点、业务指标、关键点间的关联关系，业务活动模型是指通过对业务进行梳理，建立业务过程模型描述关键点间的逻辑关系，并以过程模型为基础描述业务关键点与指标的关系，关键点间的关联关系。构成业务关键点、业务指标、关键点间关联关系的关系模型。

业务活动建模采用从业务活动监控需求出发、至上而下的方法，建模从过程上大体可以分为以下几个步骤：梳理需求、建立过程模型、建立关键点与指标的关系、建立关键点间的关联关系。

 业务过程建模

业务过程建模首先通过对关键业务的流程梳理，确定业务处理过程中的监测关键点，以业务处理过程的视角描述关键点之间

的关系，形成业务处理过程模型。然后根据监测需要建立相应的监测指标体系，指标通过对业务基础数据的抽取和计算，来体现业务关键点的业务状态。

 梳理需求

建模的首要工作是通过业务活动监控的需求分析，明确监控的业务范围和要点，然后对范围内的业务及监控要点间关系进行高度概括性的描述，把相关监控要点与业务处理过程的具体环节进行映射，形成业务活动监控的需求模型。需求模型梳理是为过程建模做准备，它没有统一的标准，主要依据是业务过程的实际情况及业务人员的经验。

 建立过程模型

业务活动监控的基本任务是监控平台完成的业务交易和信息处理情况，控制业务差错，保障业务质量，为业务流程优化提供依据，提高业务运营能力和管理水平。而业务交易和信息处理是以业务流程的方式进行的，因此将业务处理过程作为业务活动监控的视角，对关键业务进行深层次的信息整理和展现，将业务监控深入到业务过程内部，关注业务处理过程的细节，通过细节信息的展现，展示关键环节的业务处理状态，找出业务流程瓶颈，进而发现业务存在或潜在的问题，是业务活动监控的有效手段。

业务过程建模作为业务活动监控的实现基础，通过对关键业务流程的梳理，将关键的业务流程展开，确定业务处理过程的监控关键点，以业务处理过程的视角描述关键点之间的关系。

业务过程建模的主要工作为：基于需求梳理的结果，根据功能综述、分类和规则，确定业务过程的关键点（即为业务过程的关键处理环节），定义关键点之间的关系，并绘制业务流程图，体现关键点间的过程与逻辑关系。

 建立关键点与指标的关系

根据过程模型，遵照规范化思想建立关键点与业务指标之间的关联关系。

对于所抽取的业务过程关键点，抽取关键业务指标，如业务处理量、积压量、处理效率及业务准确性指标，抽取的关键业务指标能够对关键点的业务处理状态进行直观准确反映。

 建立关键点间的关联关系

关键点间的关联关系包含某几个关键点间的关联关系、具体的关键点与整个业务过程的关联关系。

关键点间的关联关系，具体体现为不同关键点的同类指标间的关系，通过对关键点指标进行分类及规整，形成相关指标类，根据过程模型，并结合业务经验积累定义相关关键点同类指标的关联关系，进而建立关键点间的关联关系。关键点间的关联关系是业务活动监控的分析要点，如某业务过程的关键点一的业务处理量和关键点二的业务处理量存在固定比值关系，某业务过程的关键点一的处理时长指标和关键点二的处理时长指标存在构成关系。

关键点与业务过程的关联关系具体体现为关键点业务指标

与整个业务过程同类业务指标间的关系，通过对关键点业务指标的归并形成整个业务过程的关健业务指标，定义具体关键点指标与业务过程关键指标的关联关系，进而建立某一关键点与整个业务过程的关联关系。如某业务过程的关键点1的处理时长指标和整个业务过程的处理时长指标存在占比关系。

 业务支撑关系建模

业务支撑关系建模主要是指对业务与模块、业务与底层的IT基础设施以及应用之间的关系进行梳理，建立业务的支撑关系模型，描述不同层次之间的物理和逻辑支撑关系，从而把业务的可用性和业务状态，与支撑业务的模块以及底层IT基础设施和应用的状态关联起来，构成业务与模块的支撑关系模型以及业务与应用、IT基础设施支撑关系的模型。

业务支撑关系建模主要包括支撑关系模型管理、指标聚合规则管理、告警影响规则管理、告警关联规则管理等。

 支撑关系模型管理

关系模型管理是以数据模型的方式在系统中建立业务与应用及IT基础设施的关系模型，并在系统中以模型的方式进行存储。

 指标聚合规则管理

指标聚合规则管理指在业务与模块的业务支撑关系模型中设置基本监测指标向父元素聚合的规则管理功能。父元素根据聚合生成的新指标的数据取值以及该新指标设置的告警规则得到

影响该元素可用性状态的告警数据，呈现在业务支撑关系模型展现视图中，直观的反映父元素的业务状态以及底层元素状态之间的支撑关系。

 告警影响规则管理

告警影响规则管理指设置业务支撑关系模型中监控对象的告警状态变化，引起其父元素状态发生变化的影响规则。如支撑业务的服务器或者应用出现影响业务的严重告警时，可直接或间接的影响到该业务的出现预警，在业务监控视图中体现出父关键点的状态变化，以颜色、文字等方式给以提示。

 告警关联关系管理

告警关联规则管理指设置不同业务之间、业务与应用以及底层基础设施被管对象之间的告警关联关系，当不同层面的多个告警同时出现时，系统会根据告警关联规则进行处理，自动定位出根源告警并突出显示。

能够提供可视化界面新建、编辑、删除构成业务支撑关系模型的各类监控对象的告警信息关联关系，告警关联关系 ：关联关系、从属关系等，以支持告警数据的关联过滤与分析。 1.3.2. 业务数据采集

数据采集功能统一走统一采集与控制模块。

针对端到端业务数据的采集，本产品主要提供两种数据采集方式：

（1）JSON文件方式：由被监控业务系统按照运维监控管理

平台的约定要求，定时生成JSON文件信息点，并主动ftp到运维监控管理平台指定的采集目录，由运维监控管理平台负责实时解析、预警、入库；

（2）JDBC方式：由业务系统提供特定权限的数据库访问用户，运维监控管理平台通过JDBC使用该用户连接到业务系统数据库，利用JOB并通过SQL语句或者存储过程实现对业务数据的定时采集。

1.3.3. 业务运营指标监控

业务运营指标监测是通过业务监控视图将业务运行中的各个关键点的业务指标数据以及支撑业务的底层IT基础设施和应用的性能指标数据加载到业务模型上，并对这些指标数据进行预警分析生成告警数据，将告警状态呈现在业务模型中，来实现对业务运行状态的实时监测。

业务运营指标监测按照功能可以划分为：业务过程指标监测、业务支撑关系监测。

 业务过程指标监测

业务过程指标监测是指根据业务过程模型对各关键点上定义的关键业务指标以及整个业务过程的关键质量指标数据进行监控，如订单处理失败率、平均处理时长等数据，并对这些业务数据进行预警分析生成告警信息，将告警状态呈现在业务过程模型中，来实现对业务流程运行状态的实时监控，及时发现业务流程中出现的异常。

 业务支撑关系监测

业务支撑关系监测是指根据业务支撑关系模型对业务以及支撑该业务的业务模块、底层IT基础设施和应用的状态进行监控，并对这些业务数据进行预警分析生成告警信息，将告警状态呈现在业务支撑关系模型中，根据定义的业务影响规则来实现对业务的影响性分析。 1.3.4. 业务运营质量分析

业务运营质量分析是在业务建模和业务运营指标监测的基础上对业务过程的状态变化情况进行跟踪，对各关键点指标数据以及业务过程关键质量指标数据通过异动、趋势、对比、构成等分析方法来实时或准实时地发现业务异常，及时掌握业务运营质量，并对业务未来变化趋势进行预测，提前发现业务可能出现的问题并及早做出预防措施，找出影响业务的主要因素，解决问题。 1.3.5. 全流程可用性探测

全流程可用性探测是通过模拟客户端运行全流程业务的过程以及模拟外部系统调用服务的过程，以界面、短信、服务调用等方式针对全流程业务进行探测，从而对业务可用性状态、响应时间及其他指标进行实时监视。

全流程可用性探测使用业务建模中已经设置好的业务流程顺序，采用仿真Socket、Http、WebService、短信、客户端程序等数据交易的方式直接对全业务过程发起模拟探测，模拟产生

业务交易并分析交易最终结果，从而发现关键业务流程潜在的性能和可用性问题，建立预警机制，并通过系统监测生成告警事件。

通过分析探测结果，发现关键业务流程中潜在的性能及可用性问题；同时建立预警机制，生成可用性探测告警事件。

通过模拟端到端的请求，替代传统的人工检查，弥补系统监控管理的缺陷，先于系统使用者找出业务流程的隐患。

 探测用例管理

探测用例管理提供对探测用例和探测动作的定制、修改、删除。每个探测用例包含若干探测动作，每一个探测动作表示探测时对相应服务接口发起一次服务请求，针对每一探测动作都要记录其探测结果，并对每个探测结果依照参照标准进行判断分析出告警。

 探测处理功能

探测的处理功能包括业务活动模拟功能、手动探测与定时探测、探测点部署、探测告警、探测回退。 1.4. 监控展现 1.4.1. 网络拓扑展现

拓扑是实现将各种配置项（CI）及各种配置项间的关联关系以拓扑图的方式展现，使用户能够在拓扑图上直观的掌握整个配置项的拓扑结构及各种配置项状态，并能够通过拓扑图灵活建立配置项间的关联关系。

网络拓扑视图支持以地理分布、网段或应用系统划分作为索

引来组织被管网络的逻辑拓扑。 1.4.2. 分级展现

系统支持按照资源利用率分级显示设备运行状况。如空闲（<50%）、一般（50%-70%）、繁忙（70%-90%），超负荷（>90%） ，可根据客户需求进行利用率的范围设定。

系统支持按照资源的使用率如CPU使用率、内存使用率、SWAP使用率、文件系统使用率等，按照上述分级要求，显示设备的总体运营状态。 1.4.3. 告警展现

拓扑图在结合网络的性能数据和事件数据后，用于监视网络的设备运行状态和运行状况，反映网络设备配置的变更情况，及时呈现网元的告警信息和性能数据，为运维人员提供直观的对网络的观察和处理手段。

拓朴图监视能够实时反映网元告警类别与告警级别，告警要以可视、可闻的形式提醒维护人员。告警信息未确认则相应的网元图标一直闪烁。

 告警显示

告警监视界面能显示所有的活动告警事件，每条告警事件以不同得颜色标识相应的告警级别。告警事件的颜色标识与拓扑显示保持一致。

在根据管理需要定制增加警告级别时，告警监视界面能够定

制或增加警告级别，并以适当的颜色表示。

默认颜色：

告警级别 紧急告警 严重告警 重要告警 一般告警 提醒告警  声音告警定义

系统可以根据告警级别和告警类别的不同组合设置告警音。 可自定义每种报警声音的声音类型、开关状态，系统提供修改维护界面。

 告警事件入库

所有数据采集层告警事件和数据处理层的性能超门限告警事件/相关处理事件全部存在数据库中，以便于审计、分析和统计。

 显示过滤

对单位时间内发生的大量告警，系统能够按定制的条目（可包含告警元素、告警级别、告警类别或告警节点等）进行过滤，过滤信息是用户自定义的，可以根据多种情况组合。

告警过滤提供灵活的过滤规则：可按告警网元、告警级别、告警类别或告警标题等设置过滤规则；可根据某一具体告警设置

颜色 红色 橙色 黄色 蓝色 青色

过滤规则。

告警数据过滤用于过滤掉从底层提取的告警信息中监控人员认为不重要的信息，从而减少轻微告警的干扰，以提高监控与处理的效率。

2.运维管理

运维管理主要为IT人员提供统一的协同式工作环境。通过IT流程的梳理及固化，实现IT内部纵向、横向，以及其他专业的有效协同。通过与各类IT专业工具的集成，为IT人员提供日常工作的集中处理环境，实现各项IT工作的规范化、标准化、集中化处理，提高IT人员工作的效率质量。 2.1. 流程引擎 2.1.1. 流程设计

流程设计的灵活性和可配置性是运维管理流程实施的基础和保障，目前在建系统的工作流引擎由本系统公司自主研发，在灵活性和可配置性上已可满足当前运维管理的需要，并可根据特殊要求进行相应的定制化功能开发。

 图形化、拖拽式的流程绘制

可从画板上拖拽流程的起始节点、流程环节、子流程、连接线到画板区进行流程图的绘制。

 流程数据项管理 (1) 流程数据项定义

可针对每个流程设计的流程数据项，流程数据项是构成流程表单的基本要素。

(2) 离散值

为了规范特定数据项的取值范围并实现与集团编码的一致性，系统还提供离散值定义功能，管理员可按照集团和业务的要求，自主定义离散值，具备离散值的数据项一般采用下拉框的方式进行展示。

(3) 数据项联动机制

系统同时支持两个数据项之间的联动功能，当A数据项选值发生变动时，联动数据项B的显示数据将随之发生变化。

(4) 计算数据项

针对需要根据某两个数据项的取值自动计算的数据项，如下图所示，预算可根据工作人日和单价的运算自动生成对应的值。

 流程文档模板管理

为了简化操作人员填写流程表单的复杂度，并将现有的管理机制与流程引擎进行结合，系统可灵活定义当前流程在流程实际运转过程中的各类文档，如：需求说明书、发布测试、测试报告等，并根据各类文档的重要性设置文档的必要性，以便在流程运转过程中进行必要性。

 子流程管理

为方便省、市之间的工作互动需要，系统支持在主流程中嵌套子流程的功能，子流程作为主流程的环节出现，在设计流程时，

可指定子流程引用的目标流程。换言之，针对需求管理我们可以设计省级需求管理流程和地市级需求管理流程，当省级需求管理流程涉及地市需求的时候可以在对应的环节中引用地市级需求管理流程，流程在流转时，可在对应的环节和条件下创建地市级需求单，该需求单在地市级需求管理流程中进行的闭环管理，当对应的工单流转完毕后，可返回给省级需求管理流程对应的触发点，省级需求管理单则继续向下继续流程，这样既实现了省、市两级工作的互动，又保障了两级管理流程的性和闭环性。

子流程在满足“一级平台、两级应用”的基础上，也可实现多个流程之间的嵌套情形，如：在需求管理流程中可能会触发发布管理流程，发布管理流程中可以触发测试管理流程。

这样可以保障多个管理流程的串行执行和制约性管理措施的落地，为规范日常的IT运营提供了充分的平台保障。

 流程任务管理 ➢ 流程任务定义

流程任务是流程参与人在流程流转环节需要办理的事情，参与人需要在流程执行时填写相关的任务反馈信息，流程任务填写的数据项信息在一定程度上影响着流程的流转。

流程任务也可以定义对应的任务数据项，任务数据项可与流程数据项建立关联关系，以方便任务执行后可直接影响流程的流转状态。

➢ 流程任务参与者

流程任务参与者为流程任务的执行人，当符合对应的条件时，相应的任务将会分配给对应的执行人。

人员参与的方式可选择“推方式”和“拉方式”，“推方式”为符合条件的员工必须办理的任务，“拉方式”为共享任务，只要工作组内的人员办理即可。

➢ 流程任务文档

根据管理的需要，流程执行人在办理具体任务时需要提交对应的文档，以方便时候查验。

➢ 任务超时配置

当任务分配给执行人后，当对应的任务在规定时间内仍未办理的，系统需要进行超时提醒，并将相应的工单升级或转派给相关人员进行处理。

【不处理】 超时后不采取任何行动。 【提醒】 进行邮件或短信提醒 【终止】 超时后直接终止工单的流转

【转办】 由其他人员进行处理，一般由处理人的上级主管处理

➢ 任务关联动作

为体现流程间的差异和较少流程执行时不必要的操作，系统支持定义在执行具体任务时可出现的动作选项，如“工单合并”、“工单拆分”、“工单关联”、“回访标志”、“通知标志”等功能，在流程执行时，涉及到的任务才会出现对应的动作，不涉及的则

不予以体现。

用户通知：在流程执行过程中需要通过邮件、短信、公告的方式通知本工单的关联方，为落实相关事宜提供及时、便捷的手段，如应用更新时可能会影响到关联系统在某段时间内与本次发布相关的应用、接口无法正常使用时，则可通过此方式在制定发布计划时发起相应的通知信息。

用户回访：针对发起请求或流程的人员进行邮件回访，对应环节的执行人员可查看受访人反馈的邮件信息，以便对相关事宜的执行效果得到真实、有效的反馈。

工单拆分：在需求管理及测试管理过程中因业务和管理的需要，存在将一张需求单或测试单拆分为多张流程单进行流转的情形，为适应该要求，系统支持在流程需要的环节上出现“工单拆分”动作，以方便使用人员操作，拆分后的工单自动建立与原单的关联关系，拆分单的内容可根据业务的需要进行内容的调整和修改，并可指定人员进行向下继续处理，当拆分单都完成后，原单也将自动关闭，同时系统提供从拆分单、原单多个角度的关联工单查看功能。

工单合并：对不同部门提出的类似的多张需求单、问题单进行合并，合并后的工单将合并原单的关键要素，并可进行修改，并作为新单继续流转，当合并单流转关闭后原单自动关闭。

➢ 接口条件

向集团或其他外围接口上报或发送工单信息的条件，当流程

执行过程中一旦流程数据符合预设的接口触发条件时系统即可自动调用接口将对应的工单信息自动进行上报或发送。系统支持定义触发的目标服务以及调用的条件信息（可基于任意流程数据项进行配置）。

 流程超时提醒机制

当流程在规定的时间内还未处理完成时，需要进行提醒和转办处理，任务超时只是对当前环节的任务办理情况进行超时判断。

 流程关注人配置

流程关注人为流程超时的短信、邮件、工单的接收人，可以为具体的某一个或某几个人，也可以是某个工作组。 2.1.2. 流程角色权限管理

➢ 流程发起权限

根据管理和业务需要的不同，系统可设置不同人员发使用的流程，以减少误发单和规范管理的目的。

➢ 流程角色管理

系统支持针对流程设置角色的机制，不同流程各定义管理上需要的角色，流程角色作为流程环节的参与者进行配置。

2.1.3. 表单管理

系统可基于流程数据项进行图形化拖拽方式进行排版，自定

义一个流程表单，可根据管理上的要求对数据项进行的排序和调整，以便更好地方便操作人员使用。 2.1.4. 流程控制

控制流程的实例运转，产生和流转用户的任务工单。支持以下流程的流转方式：

 正常流转：表示流程的正常向下一环节流转，即用户选择“完成”的情况。

 回退：流程往上一环节流转，即用户选择“回退“的情况。  转办：表示用户操作时请求其他用户协同办理。即用户选择“转办“的情况。转办的时候环节实例表的状态不会改变。

 撤回：当流程实例的当前实例尚未被“执行“时，前面环节的用户可以撤回。

 接收：支持对于共享任务和非必办任务提供“接收“功能，共享任务一旦接收则其他用户不能办理，非必办任务一旦接收，变成必办。 2.1.5. 流程监控

通过收集和分析流程运行实例的统计分析数据，实现对流程运行实例运转情况的监控、分析。统计分析可针对某一个流程实例进行，也可以对基于同一模板的某一类流程进行，通过对流程执行时长，执行数量及超时时长，超时数量等指标的统计分析，

可有助于流程管理者监督流程的运行情况，制定流程优化方案等。

图形化的流程流程流转轨迹查看：亮色表示流经环节，灰色表示没有流经的环节，绿色表示当前驻留的环节。

执行明细集中展现：按流经的先后顺序展示各个环节任务的办理用时、办理人以及提交的附件信息，并提供查看对应任务办理明细。

2.1.6. 流程查询

提供所有流程对应的流程单信息，系统提供“基本查询”和“高级查询”功能，前者可提供基于工单编号、工单标题、工单创建时间、创建人信息进行查询，后者可提供基于流程表单项的多个条件的组合查询功能，查询条件可自定义。 2.2. 运维管理流程 2.2.1. 事件管理

事件管理流程是对 IT 生产环境中导致IT 服务中断或潜在中断的事件进行管理，快速恢复IT 服务能力的管理流程。事件的来源包括IT 用户报告的事件、监控系统自动转发的事件、客服系统自动转发的IT 类事件等。它的目的是尽快恢复被中断或受到影响的IT 服务，是以恢复服务为首要目的，可能采取临时解决方案，而不在于查找根本原因。

主要业务环节包括事件的登记、事件的分配、事件的处理、事件的升级和事件关闭等。

2.2.1.1. 管理目标

事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：

1．确保各类IT事件能够在成本允许的范围内，按照事件的优先级，快速、有序地解决，从而减少IT服务中断造成的影响。

1) 多渠道快速响应服务请求（电话/Web/邮件/即时通信工具等）。

2) 根据事件的优先级，影响度进行综合分类排序，如果判断事件优先级是紧急，则启动紧急事件管理流程进行处理。

3) 为客户提供及时的事件处理状态信息。

4) 监控事件处理过程，必要时进行管理和技术升级。 2．确保IT事件处理过程中的关键信息能正确记录，为后续事件处理提供知识支持，为流程持续优化提供准确的数据信息。

1) 按规范记录事件信息及解决过程信息。 2) 服务台及后台技术资源利用情况。 3) 服务台、技术支持团队的工作效率。 2.2.1.2. 业务需求点

登记各种渠道上报的事件，并对其进行分类和分级；按照对业务的影响程度和优先级分配事件；支持工程师解决该事件，并记录详细的解决方案；对超期事件进行升级处理；事件处理的解决方案可以形成知识，为后续工作提供参考；对历史事件进行趋势分析，形成问题；根据事件记录考核相关人员的绩效；对于重

复上报的事件，能够进行关联处理；对事件处理的过程进行跟踪审计；事件单能够和问题单、故障单等其他流程工单关联。 2.2.1.3. 流程设计

1．角色及职责说明 1) 事件经理

事件经理负责事件解决过程中的协调和监控，事件升级的判断和具体执行。

职责：

(1) 负责对事件的解决协调资源，保证事件的最终排除。 (2) 确保和问题管理流程经理的有效合作。

(3) 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。 2) 服务台人员

服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的二线支持工程师。与服务台一起工作进行事件处理的技术人员定义为一线人员。

职责：

(1) 负责24×7的值班和系统监控。

(2) 响应客户投诉工单、热线电话、邮件、传真等事件报告。

(3) 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等。

(4) 对事件进行适当的分类、为事件分配优先级等。 (5) 尝试使用工具对事件进行初步诊断，分析相关信息并解决问题。

(6) 对服务台解决不了的事件，分配给最合适的二线支持小组/人员来处理。

(7) 检查事件的处理进度，保持与事件报告人的联系，适时通知事件处理进展。

(8) 与用户确认事件解决结果，关闭事件。 3) 二线支持人员

二线支持人员是内部相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

职责：

(1) 验证事件的描述和信息，进一步收集相关信息。 (2) 进行深入调查研究或协调厂商支持，提供有效的解决方案。

(3) 实施事件解决方案。

(4) 更新事件解决信息，将已解决的事件转回服务台。 4) 三线支持人员

包括应用开发厂商的后端研发团队、提供远程支持的设备厂商、或厂商的现场服务。

职责：

(1) 提供远程接入方式的支持，协助进行事件诊断及恢复。 (2) 必要时提供现场支持和深入调查研究，提供有效的解决方案。

(3) 参与重大事件解决方案的实施。 2.2.1.4. 流程功能

1．各种渠道事件登记

登记各种渠道上报的事件工单，并对其进行分类和分级。 WEB方式，由请求人通过运维监控管理平台自助填写事件工单并提交，并在表单上填写请求分类和紧急程度。

电话方式，请求人拨打服务台统一热线，由服务台受理后代发事件工单。

邮件方式，请求人可编写固定格式的请求邮件发送到运维监控管理平台的系统邮箱中，邮件接口程序解析后生成事件工单。

即时通信，请求人通过在线客服模块与服务台工作人员在线点对点沟通并由服务台人员代发事件工单。

2．根据影响程度和优先级分配事件

根据事件工单填写的影响程度和优先级，分配紧急的和影响范围大的事件单给专人优先处理。

3．事件处理过程记录

流程引擎对事件的每个处理环节保存该环节的处理信息，包括环节派发时间、处理开始时间、处理结束时间、处理人、处理结果、处理意见。并以图形的方式展示整个事件的处理过程。

4．对超期事件进行升级处理

根据事件的紧急程度，设定事件工单业务超时时间，在达到超时时间时可根据预设规则进行升级，包括：通知当前人、通知服务请求管理员、通知当前人上级领导、将工单转办其他人。

5．事件处理的解决方案可以形成知识

在事件回顾环节配置知识库关联规则，回顾人可点击“入知识库”按钮对事件处理结果进行知识入库。

6．对历史事件进行趋势分析，形成问题

可定期统计历史事件单，获取还存在问题的事件并发起问题工单进行关联跟踪，分析角度包括：统计长期未处理完成的事件、统计大量重复发生的事件、统计影响严重的事件单、统计解决方案为变通解决的事件。

7．考核支持工程师的绩效

配置事件考核报表，统计支持工程师的绩效，包括：支持工作量、支持效率、重复处理情况、请求人反馈满意度

8．关联处理重复事件单

在每个办理环节，均可以对当前工单进行重复关联，当选择重复关联时，本单将同步原重复单的处理状态：

原单正在处理，则本单锁定等待原单处理完成后本单同步完成，并通知请求人原单已处理完成，则本单直接结束并通知处理结果给请求人

9．对事件处理的过程进行跟踪审计

在事件管理流程最后增加“处理审批”环节，进行事后跟踪审核处理。

10．事件单能够和问题单、故障单等其他流程工单关联 事件处理结果，可选择“发起问题跟踪”或者“发起变更解决”的选项，当选择该两个选项的其中之一后，进入子工单启动环节，可设置为人工启动也可以设置为自动启动，从而启动关联的问题单或者故障单进行关联处理。 2.2.2. 故障管理

主要由事件/问题人工升级到故障管理流程，分配给故障经理进行跟进处理，由系统自动记录故障处理/分派过程，故障的关闭由升级人进行。

故障管理流程即上节事件管理流程图中的紧急事件处理子流程。

1．故障处理过程记录

流程引擎对故障的每个处理环节保存该环节的处理信息，包括环节派发时间、处理开始时间、处理结束时间、处理人、处理结果、处理意见。并以图形的方式展示整个故障的处理过程。

2．对超期故障进行升级处理

根据故障的紧急程度，设定故障工单业务超时时间，在达到超时时间时可根据预设规则进行升级，包括：通知当前人、通知服务请求管理员、通知当前人上级领导、将工单转办其他人。

3．故障处理的解决方案可以形成知识

在故障回顾环节配置知识库关联规则，回顾人可点击“入知识库”按钮对事件处理结果进行知识入库。

4．对历史故障进行趋势分析，形成问题

可定期统计历史故障单，获取还存在问题的事件并发起问题工单进行关联跟踪，分析角度包括：统计大量重复发生的故障、统计影响严重的故障单、统计解决方案为变通解决的故障。

5．考核支持工程师的绩效

配置故障考核报表，统计支持工程师的绩效，包括：支持工作量、支持效率、重复处理情况、请求人反馈满意度

6．关联处理重复故障单

在每个办理环节，均可以对当前工单进行重复关联，当选择重复关联时，本单将同步原重复单的处理状态：

原单正在处理，则本单锁定等待原单处理完成后本单同步完成，并通知请求人原单已处理完成，则本单直接结束并通知处理结果给请求人

7．对故障处理的过程进行跟踪审计

在故障管理流程最后增加“处理审批”环节，进行事后跟踪审核处理。

8．故障单能够和问题单等其他流程工单关联

故障处理结果，可选择“发起故障跟踪”的选项，当选择该两个选项的其中之一后，进入子工单启动环节，可设置为人工启动也可以设置为自动启动，从而启动关联的问题单进行关联处理。

2.2.3. 问题管理

问题管理流程是确定某一事件或具有相同症状的一组事件的根本原因，制定和实施解决方案，从而防止事件再次发生的管理流程。问题管理流程的目的是找出事件根本原因，尽可能的给出解决方案或者临时应对措施。

主要业务环节包括问题的登记、问题的审核、问题的分配、问题的处理、问题回顾和问题关闭等。 2.2.3.1. 管理目标

问题管理流程的目标是降低生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。其目的包括：

1．分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生。

2．通过对已知错误进行标识，最小化不能被消除事件的影响。

3．提高IT服务的可靠性，降低IT支持成本。

4．问题管理过程得到正确记录，满足审核和统计的管理要求。

2.2.3.2. 业务需求点

登记紧急事件和事件分析整理出来的问题，并对其进行分类和分级；按照对业务的影响程度和优先级分配问题；分析该问

题的根本原因，并记录已知错误、详细变通方案或者生成变更请求单；对超期问题进行升级处理；问题处理的解决方案或者变通方案可以形成知识库，为后续工作提供参考；能够将问题分析产生的变通方案发布到帮助台和所有用户；能够分析回顾问题解决方案的效果；根据问题记录考核支持工程师的绩效；对问题处理的过程进行跟踪审计；问题单能够和事件单、变更单等其他流程工单关联；支持问题信息在集团和省公司 IT 服务管理系统之间的纵向传递。 2.2.3.3. 流程设计

1．角色及职责说明

问题管理流程主要包括问题请求人、问题经理、问题处理专家三个角色。 1) 问题请求人

问题请求人主要负责问题的提出。 2) 问题经理

问题经理负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。

职责:

(1) 确认、审核和监视问题处理过程。 (2) 必要时协调所需资源。 3) 问题处理专家

问题处理专家通常由各专业组技术人员、厂商人员承担，负

责问题的诊断和解决。

职责：

(1) 定期对事件记录进行分析，发现潜在问题，发起问题管理流程。

(2) 进行问题诊断和分析。 (3) 开发、确认、实施解决方案。

(4) 关闭问题、整理解决方案并提交知识库。 2．与其他流程关系 1) 与事件管理的交互

对于重大事件或者统计分析得到的事件发生趋势，可以产生相应的问题记录。主要功能包括：

(1) 支持通过重大事件生成问题记录单，将事件中的相应信息自动拷贝到问题单中。

(2) 支持事件单和问题单的关联，一个问题单可以关联多个事件单。

(3) 当关闭问题单时，应能够自动通知关联的所有事件单。 2) 与知识库管理的交互

(1) 在任何环节都可以查询知识库系统。

(2) 在关闭问题时，应可以将解决方案标记为备选的知识，提交给知识管理审核。

2.2.3.4. 流程管理

1．登记紧急事件和事件分析整理出来的问题

可定期统计历史事件单，获取还存在问题的事件并发起问题工单进行关联跟踪，分析角度包括：统计长期未处理完成的事件、统计大量重复发生的事件、统计影响严重的事件单、统计解决方案为变通解决的事件。

2．根据影响程度和优先级分配问题

根据问题工单填写的影响程度和优先级，分配紧急的和影响范围大的问题单给专人优先处理。

3．对已知错误生成变更工单处理

在问题单开发实施环节，配置变更工单关联启动规则，用户在工单处理时，可选择采用启动功能变更单的方式来解决该问题。

4．对超期问题进行升级处理

根据问题的紧急程度，设定问题工单业务超时时间，在达到超时时间时可根据预设规则进行升级，包括：通知当前人、通知服务请求管理员、通知当前人上级领导、将工单转办其他人。

5．问题处理的解决方案可以形成知识

在问题回顾环节配置知识库关联规则，回顾人可点击“入知识库”按钮对问题处理结果进行知识入库。知识入库可选择处理意见的描述，也可选择问题处理过程中的方案文档。

6．对问题处理的过程进行跟踪审计

在问题管理流程最后增加“处理审批”环节，进行事后跟踪审核处理。

7．问题单能够和事件单、变更单等其他流程工单关联

问题单可选择启动变更子流程进行开发解决。

问题单在录入时可通过前向工单关联规则，选择其前向事件单（关联来源事件单）。

问题单可由事件单主动触发生成，并关联。 2.2.4. 知识管理

知识管理主要是实现知识管理流程的管理功能，将各个系统运行维护的案例、经验等信息沉淀到一个统一的知识数据库中，使之能够为日常的维护工作提供信息支持。在故障自动处理和人工处理的过程中通过在知识库中检索相关故障维护的分类和快速定位，找到匹配的处理案例，加快故障和问题的解决速度。

主要业务环节包括知识分类、知识录入、知识回顾、知识检索查询、文档管理等。 2.2.4.1. 管理目标

通过知识库的支持，在处理事件问题时，可以快速定位问题,并查找对应解决办法。

知识库具有的业务帮助功能，使相关人员可以通过关键字查询业务帮助、产品、市场活动、发生过的处理流程、电子文档等。

知识库管理也包括对其他管理流程产生的文档的存储和应用。

所有流程均可以累积知识，知识管理可以为所有流程提供知识支撑。

2.2.4.2. 业务需求点

文档资料管理、分类，知识的增加、修改和删除。知识的审批管理；知识的发布管理；知识的检索服务。 2.2.4.3. 流程设计

1．角色及职责说明 1) 知识管理员

知识库管理员主要负责知识库信息的维护工作。 职责:

(1) 确保进入知识库系统的数据分类正确，关键字定义正确以及知识有效性、唯一性。

(2) 将需要新增、修订、删除的知识报知识经理审核。 (3) 对过期的知识定期进行删除。 (4) 对相似的知识定期进行合并整理。 2) 知识经理

知识库经理是知识管理具体活动的负责人。 (1) 对发布知识的合理性、唯一性、效益负责。

(2) 负责知识定期回顾，审核知识回顾报告，评价知识回顾结果。 2．与其他流程关系

1) 为其他功能模块提供创建新知识的入口

运维管理各流程都可以作为知识管理的输入，如事件管理、问题管理、故障管理，将IT支撑中的解决策略、方案、经验进

行采集从而形成知识草稿。 2) 为其他功能模块提供访问入口

运维管理各流程在处理各类工单时（包括：解决事件、问题、制定策略、方案、学习操作规范）可以通过知识库进行支撑。 2.2.4.4. 流程功能

1．文档资料管理、分类

知识库的分类为树形结构，可按照地区、专业、性质进行分类并对各个分类节点进行权限设置；知识包含文字描述类知识和文档类知识。

2．知识的增加、修改和删除

知识库存在模块，知识管理员可对已经入库的知识进行修订、删除、批注。

新的知识也可通过申请知识工单进行入库。 3．知识的审批管理

知识管理员可对已经申请的知识进行审阅，对于满足条件分类明确的知识进行审批通过。只有审批通过的知识才会入库。

4．知识的发布管理

新入库的知识为“待发布”状态，此时其他人员为不可见，当知识管理员对该知识发布后即生效可使用

5．知识的检索服务

知识检索由搜索引擎支撑，在系统首页、工单办理页面均可输入关键字通过搜索引擎检索相关知识标题、关键字、正文或者

文档。