F
运维流程管理：结合实际按规 范建立六大流程故障，问题， 提数，发布，变更，交接流程。 定义流程各角色职能协作流转。
K
M
运维过程监控：对于运维事件 协作过程分层级（红色，橙色， 黄色等）进行监控预警。触发 点事件环节流传点通知提醒， 事件处理时间超期提醒，事件 紧急处理提醒，事件升级告警
R
运维事件升级管理：事件在规 定的时间内不能由一线支持小 组解决，那么更多有经验的人 员和有更高权限的人员将不得 不参与进来。
监控点采集
预警 流程
预警分析
自动调度
信息推送
涉及到运维流程 中的事件到达提 醒，事件将超期 提醒，事件逾期 通告
对采集点进行监 控，通过预设定 规则，区分紧急 度，信息接收对 象生成预警信息
依据时间，事件 紧急程度等实际 情况，系统智能 按频率触发监控， 推送流程
依据接收人不同 的角色信息，推 送相应的预警信 息
内部流程是运维团队内部人员在巡检，稽核，或者使用过程中发现的故障，问题。本流程为外部流程
输入 电话,邮 件,QQ, 工单
客户
开始
服务台
维护工程师
运维经理
输出
发 起 阶 段
事件发起
有效 性
Y
ITIL单登记 FAQ 解决 单独 处理
ITIL事 件单
N
Y
事件升级
N
Y 处 理 阶 段
反馈客户结果 验证结果 ITIL归档
无法完成事件 协调资源
协调资源
N 职能性升级 解决
结 构 性 升 级
组织团队解决
Y
解决方案
运维流程->制度规范
运维过程中，运维工作如何界定，项目交接给运维团队时机以及交接要求，运维人员对事件如何正确处理等 都属于运维制度规范内容。
工作内容界定
涉及运维过程中已经交接运维团队项目提数，咨询，查证，数据库库巡检，数据稽核，服务 器巡检,服务器漏洞修复，应急演练，故障处理，故障发现，数据修改，项目报告等
1
流程规范
2
提数要素
提数规范模式借鉴软件开发规范中的快速开 发模式，必须由主提数人，副提数人各自提 数进行对比校验，确定统一口径后由审核人 员审核。 1
风险评估
提数过程中，交接给下一审批人必须完成以
提数流程
下要素的填写:提数周期，数据简介，数据 量，数据SQL脚本（包含SQL脚本注释）， 数据说明等
编写处理方案 执行处理方案
FAQ
运维流程--故障，问题流程二
本流程是内部流程
团队成员
开始 事件发起
服务台
维护工程师
运维经理
输出
ITIL单登记
FAQ 解决
N
单独 处理
ITIL事 件单 N
事件升级
处 理 阶 段
Y
Y
编写处理方案 执行处理方案 反馈结果
FAQ
验证结果 ITIL归档
运维流程-提数，发布，变更流程
按运维流程紧急度，严重度，相应处理时间限制将预警级别划分为红，橙，黄 警告 根据流程紧急度，严重度，处理时间限制等规则化时间升级条件，满足条件事 件流程自动升级，并进行预警
运维流程->事件升级
如果某一事件不能在规定的时间内由一线支持小组解决，那么再多有经验的人员和有更高权限的人员将不得 不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别, 升级分为职能性升级和结构性升级。两者的区别如下：
服务时间响应规范：规范服务方式，故障级别相应 服务行为规范 现场服务支持规范 ITIL单操作规范
运维监控->监控平台
目前ITC自建系统应用较多。影响业务流程可用性因子很多。如何变被动为主动，对事件进行事前管理，快 速发现问题，智能分析故障，减少运维过程中事件带来不良影响力以及大量运维工作量。 建立完善的运维监控平台，以电子监控的形式辅助运维，提升运维效率以及业务功能可靠性。
运维流程-运维知识管理
整个运维过程中，知识的积累沉淀，传承至关重要，可以有效的避免对同一事件重复运维以及由于人 员流动导致知识流失。 良好的知识库体系应当包含知识广泛的收集渠道能力，知识强大的管理能力，知识有效的应用能力。
客户
运维团队成员
ITC人员
使用 用户
知识 渠道 展现在线考试Fra bibliotek电脑平板
手机
智能检索
知识地图
知识视图
业务培训
问卷调查
知识 应用 能力
知识版本管理 常用FAQ管理
知识分类 知识评价
知识采集 知识推荐
知识共享 知识传播
知识审核 知识服务组件
知识 管理 能力
人工收集
其他知识系统收集
智能分析知识收集
知识收集能力
运维流程-预警监控
预警监控主要对运维流程监控，通过设定预警规则，生成预警信息，后台自动调度的方式将预警信息推送。 预警过程的紧急度以及影响度，根据具体处理情况以及历史预警日志，系统智能将预警信息升级。
交接规范
新项目需稳定运行3个月以上时间才能交接给运维组 新项目交接给运维组必须对接手维护的同事做系统业务培训 项目交接必须提供 《项目需求文档.doc》 《项目操作手册.doc》 《项目维护手册.doc 》 《项目常见问题处理.doc 》 《项目详细设计文档.doc 》 《项目数据字典》
管理制度规范
职能性升级:需要具有更多时间、专业技能或访问权限（技术授权）的人员来参与事件的解决
结构性升级:当经授权的当前级别的结构不能保证事件能及时、满意地解决时，需要更高级别的机构参与进来 运维过程中应当尽量在运维团队内解决，避免结构性升级
运维工程师 项目经理 内部专业工程师 外围开发团队/ 移动技术部门 产出
发起人: 发起时间 发起人描述
节点一
到达时间
处理人 预期完成时间 实际完成时间 处理情况描述 处理评分
当前节点
到达时间 处理人 预期完成时间 实际完成时间 剩余处理时间
节点三
预计到达时间 预计处理时间
展现渠道 WEB门户 手机WIDGET 桌面WIDGET
运维流程-故障，问题流程一
故障，问题流程根据发起人的不同分为外部流程与内部流程。外部流程发起人为运维项目使用人员，
运维流程-流程呈现
通过目前流行的地图呈现形式，将运维流程各关键流程节点直观展现，详细描述已经流转节点以及预计 描述未来节点走向。节点中呈现相关节点信息。 【MPT20152011200001】属于提数流程，目前处于正在处理状态，完成度为50%,当前处于 第二节点，距离预警时间为2小时，工单紧急度为一般 流程发起
运维管理体系
运维团队
团队角色 角色职责 素质要求 人员组成
运维流程 知识管理
安 全 管 控 质 量 管 控
运维监控
对象界定 采集平台 监控中心 应用中心
运维过程
流程协作 协作监控 事件升级
ITIL 运维体系 制度规范
工作内容界定 运维规范 质量考核规范
运维流程-概述
运维流程主要是通过流程协作的形式对于运维过程中运维事件进行处理。建立维护工作平台管理积累 运维知识，记录运维流程轨迹，并对整个运维过程管控。 包含四个部分： 运维流程管理，运维知识管理，运维过程监控，运维事件升级管理。 运维知识管理：运维过程知识 体系，包括项目文档，常见业 务咨询问答，常见故障问题解 决,支撑服务台人员对于事件甑 别，事件初检。 运维过程事件职能分析成知识。
操作系统
•监控点: CPU使用、内存使用、硬盘使用、用户数、进程数等 •适用系统:windows,unix •监控频率:实时监控
业务系统
•监控点: 系统状态、占用内存、链接数、关键业务状态等 重点 •监控方式:间隔频率监控 关注
接口系统
•监控点: FTP可用性、web service可用性、servlet等 •监控方式:间隔频率监控
运维流程-运维交接流程
开发团队将软件项目交接给运维团队进行项目运维，该过程是一个责任过度的过程，需要严格的规范以及 流程进行支撑。该部分叫做运维交接流程。
开发 团队
提交运维 申请
提交软件 文档
运维 团队
检查文档 质量
合格？
测试软件质 量
填写 测试结 果
合格？
输出
重新 交接
交接 成功
注:
交接过程中，提交的软件文档一般包含需求说明书，概要说明书，详细设计说明书，数据字典，测试报告， 试运行情况报告分析，部署文档等，必须保持项目实际情况与文档一致性。 运维团队测试包含功能测试，用户测试，业务逻辑测试，集成测试，压力测试，需要在流程中填写相关的测 试总结以及上传测试报告，不合格需要说明不合格原因。 以上过程需要再严格的规范下进行，不然，流程会因为只是个形式而失败，达不到预期效果
运维流程->监控中心
在IT日益发展的当今，业务与IT已经紧密结合.一个IT项目的关联着系统，数据库，应用，网络，业务，用 户等多方面因素。对单个IT资源进行监控已经越来越满足不了IT运维需求。集成传统的监控方式，将整体业务 作为主体，构建业务监控视图。 监控主要体现为四字原则:看、监、析、告
1 监 控 中 心 成 功 四 要 素
展现渠道
电脑 平板 手机
应用中心
监控视图
报表中心
安全审计
智能提数
监控中心
监控规则
告警级别
告警调度
告警规则
信息推送
采集平台
采集工具集成
采集方式
采集调度
数据中心
监控对象
网络系统
操作系统
业务系统
接口系统
运维流程->监控对象
网络系统
•监控点: 网络互通、端口开放情况、网络权限、网络延迟等 •监控频率:实时监控
4