统一运维
人机协作
开发过程不规 范导致程序质 量较差，相应 维护工作太多
分散
随意
量多 维护纯人力手工， 效率低下，效果 很差
手工
维护只注 重结果， 过程未管 控
软件过程管理
运维过程管理
统一运维
•成立专业运维团队，负责整个维护相关工作.
人机协作
• 通过程序系统对一些维护工作（监控类，审计类等），提高运维质量以及效率
职能性升级:需要具有更多时间、专业技能或访问权限（技术授权）的人员来参与事件的解决
结构性升级:当经授权的当前级别的结构不能保证事件能及时、满意地解决时，需要更高级别的机构参与进来 运维过程中应当尽量在运维团队内解决，避免结构性升级
运维工程师 项目经理 内部专业工程师 外围开发团队/ 移动技术部门 产出
目前提数流程目前有支撑系统综合支撑平台，一单清平台，两平台对于提数流程支撑能力充足。在 现有资源的基础上，对于提数流程进行相关流程关键点进行强制执行，对流程短板进行补充，确保流程 执行正确性以及可恢复性。 变更流程在2011年综合支撑平台根据运营管理室意见进行改善，已经比较完善。暂时利用已有资 源。发布流程也有相应流程易平台进行支撑，在原有基础上对于发布流程的短板进行补充。 1
ORACLE DBA 服务台
良好的沟通能力以及服务态度 接收系统使用者反映事件，包含咨询， 团队建设是基础，运维团队必须 查证，故障，并对时间进行ITIL单初 项目故障相关基础故障知识 是一个多角色，角色人员素质高， 步填写以及相关症状初判 良好问题描述能力
运维经验丰富的高效成熟团队！
j2ee维护工程师 C++维护工程师 WIDGET维护工程师
发起人: 发起时间 发起人描述
节点一
到达时间
处理人 预期完成时间 实际完成时间 处理情况描述 处理评分
当前节点
到达时间 处理人 预期完成时间 实际完成时间 剩余处理时间
节点三
预计到达时间 预计处理时间
展现渠道 WEB门户 手机WIDGET 桌面WIDGET
运维流程-故障，问题流程一
故障，问题流程根据发起人的不同分为外部流程与内部流程。外部流程发起人为运维项目使用人员，
软件过程管理
• 采用CMMI指导思想，面向软件过程管理，降低软件风险与减少程序BUG，大大降低维护工作量
运维过程管理
•采用ITIL思想体系，通过建立系统流程规范运维过程，加强运维过程管控.对运维过程产生知识 进行积累沉淀
目录
01
现状分析
02
愿景目标
03
运维管理
04
软件过程管理
愿景目标
组建运维团队主要目的就是将运维进行规范，将各梯队人员从运维中解放出来，运维团队保证运维 95%以上工作。同时提升运维效率，提高运维质量。间接要求软件本身质量的提升，对软件质量起到 项目监理作用。在保证运维结果的情况下，本次运维方案目标应达到以下目标: 成立专业运维团队，团队内部职能明确，团队接管整个运维过程中90%以上工 作，与维护相关梯队人员（开发人员，项目经理，业支人员）将维护相关工作 缩短到目前的20%以下。
编写处理方案 执行处理方案
FAQ
运维流程--故障，问题流程二
本流程是内部流程
团队成员
开始 事件发起
服务台
维护工程师
运维经理
输出
ITIL单登记
FAQ 解决
N
单独 处理
ITIL事 件单 N
事件升级
处 理 阶 段
Y
Y
编写处理方案 执行处理方案 反馈结果
FAQ
验证结果 ITIL归档
运维流程-提数，发布，变更流程
按运维流程紧急度，严重度，相应处理时间限制将预警级别划分为红，橙，黄 警告 根据流程紧急度，严重度，处理时间限制等规则化时间升级条件，满足条件事 件流程自动升级，并进行预警
运维流程->事件升级
如果某一事件不能在规定的时间内由一线支持小组解决，那么再多有经验的人员和有更高权限的人员将不得 不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别, 升级分为职能性升级和结构性升级。两者的区别如下：
目录
01
现状分析
02
愿景目标
03
运维管理
04
软件过程管理
运维管理体系
运维团队
团队角色 角色职责 素质要求 人员组成
运维流程 知识管理
安 全 管 控 质 量 管 控
运维监控
对象界定 采集平台 监控中心 应用中心
运维过程
流程协作 协作监控 事件升级
ITIL 运维体系 制度规范
工作内容界定 运维规范 质量考核规范
开发团队将软件项目交接给运维团队进行项目运维，该过程是一个责任过度的过程，需要严格的规范以及 流程进行支撑。该部分叫做运维交接流程。
开发 团队
提交运维 申请
提交软件 文档
运维 团队
检查文档 质量
合格？
测试软件质 量
填写 测试结 果
合格？
输出
重新 交接
交接 成功
注:
交接过程中，提交的软件文档一般包含需求说明书，概要说明书，详细设计说明书，数据字典，测试报告， 试运行情况报告分析，部署文档等，必须保持项目实际情况与文档一致性。 运维团队测试包含功能测试，用户测试，业务逻辑测试，集成测试，压力测试，需要在流程中填写相关的测 试总结以及上传测试报告，不合格需要说明不合格原因。 以上过程需要再严格的规范下进行，不然，流程会因为只是个形式而失败，达不到预期效果
测试工程师
故障处理后测试，或者项目交接过程 测试验收工作执行者
3年测试经验，熟悉黑盒，白盒测试方法， 熟悉各类测试工具
运维流程-概述
运维流程主要是通过流程协作的形式对于运维过程中运维事件进行处理。建立维护工作平台管理积累 运维知识，记录运维流程轨迹，并对整个运维过程管控。 包含四个部分： 运维流程管理，运维知识管理，运维过程监控，运维事件升级管理。 运维知识管理：运维过程知识 体系，包括项目文档，常见业 务咨询问答，常见故障问题解 决,支撑服务台人员对于事件甑 别，事件初检。 运维过程事件职能分析成知识。
职能明确
过程规范
整个软件过程规范，包含开发过程，运维过程 项目开发采用CMMI成熟度模型，达到开发过程BUG，风险可控,开发轨迹可 在文档中清晰呈现 项目运维参照ITIL体系，运维过程事件，质量可管控。运维事件可追踪，可 分析，流程轨迹可以在系统中直观呈现。同时运维过程知识可传承
响应及时
整个运维事件中，时效性对于运维效果是一个非常重要的指标，运维事件 相应及时包括运维事件触发及时，运维事件处理过程协作畅通，运维团队 与对外反馈沟通及时。
运维流程-流程呈现
通过目前流行的地图呈现形式，将运维流程各关键流程节点直观展现，详细描述已经流转节点以及预计 描述未来节点走向。节点中呈现相关节点信息。 【MPT20122011200001】属于提数流程，目前处于正在处理状态，完成度为50%,当前处于 第二节点，距离预警时间为2小时，工单紧急度为一般 流程发起
知识地图
知识视图
业务培训
问卷调查
知识 应用 能力
知识版本管理 常用FAQ管理
知识分类 知识评价
知识采集 知识推荐
知识共享 知识传播
知识审核 知识服务组件
知识 管理 能力
人工收集
其他知识系统收集
智能分析知识收集
知识收集能力
运维流程-预警监控
预警监控主要对运维流程监控，通过设定预警规则，生成预警信息，后台自动调度的方式将预警信息推送。 预警过程的紧急度以及影响度，根据具体处理情况以及历史预警日志，系统智能将预警信息升级。
监控点采集
预警 流程
预警分析
自动调度
信息推送
涉及到运维流程 中的事件到达提 醒，事件将超期 提醒，事件逾期 通告
对采集点进行监 控，通过预设定 规则，区分紧急 度，信息接收对 象生成预警信息
依据时间，事件 紧急程度等实际 情况，系统智能 按频率触发监控， 推送流程
依据接收人不同 的角色信息，推 送相应的预警信 息
无法完成事件 协调资源
协调资源
N 职能性升级 解决
结 构 性 升 级
组织团队解决
Y
解决方案
运维流程->制度规范
运维过程中，运维工作如何界定，项目交接给运维团队时机以及交接要求，运维人员对事件如何正确处理等 都属于运维制度规范内容。
工作内容界定
涉及运维过程中已经交接运维团队项目提数，咨询，查证，数据库库巡检，数据稽核，服务 器巡检,服务器漏洞修复，应急演练，故障处理，故障发现，数据修改，项目报告等
流程规范
2
提数要素
提数规范模式借鉴软件开发规范中的快速开
发模式，必须由主提数人，副提数人各自提 数进行对比校验，确定统一口径后由审核人 员审核。 1
风险评估
提数过程中，交接给下一审批人必须完成以
提数流程
下要素的填写:提数周期，数据简介，数据 量，数据SQL脚本（包含SQL脚本注释）， 数据说明等
2
恢复机制
业支服务台
ITC接口人
开发经理
开发人员
维护人员
处理效率慢
由于对自建系 统业务不非常 了解，工单总 是需要转多次 才能转正确人 那边
职责偏离
本应该对项目 软件过程整体 把控，但深陷 维护漩涡出， 做事太琐碎， 偏离职责定位
维护安排困难
维护的不固定性， 以及小项目维护量 工作量偏少，对于 团队的开发经理维 护人力合适安排是 一个比较大的挑战
相关j2ee项目故障，问题原因分析， 故障处理等工作执行者 相关C++项目故障判断，故障处理等 工作执行者 相关手机安卓系统WIDGET客户端相 关故障判断，故障处理工作执行者