项目管理实践设备通讯平台运营管理规范.docx

项目管理实践设备通讯平台运营管理规范.docx

《项目管理实践设备通讯平台运营管理规范.docx》由会员分享，可在线阅读，更多相关《项目管理实践设备通讯平台运营管理规范.docx（9页珍藏版）》请在冰豆网上搜索。

项目管理实践设备通讯平台运营管理规范

设备通讯平台运营管理规范

v1.0

编写人：

审核人：

批准人：

1引言1

1.1目的1

1.2适用范围1

1.3定义1

2职责1

3产品运营管理工作内容2

4产品问题解决3

4.1产品问题解决流程图3

4.2流程描述4

5产品运营周期示意图5

5.1服务请求单5

5.2变更评估6

5.3版本规范应用6

5.4上线申请单6

5.5发布前准备和检查6

5.6发布执行6

5.7发布验证6

5.8发布反馈7

5.9需求跟踪7

1引言

1.1目的

“按照规范去做事，出问题是偶然的；不按照标准操作，出问题是必然的”

平台运营管理规范，是对公司软件项目产品维护工作过程的说明，包括产品成功上线及后续的维护工作过程。

本文件定义了产品维护流程，用于指导公司上线产品维护过程的工作。

建立运营管理规范，推动运营管理执行，指导运营管理精细化，提升运营维护文档化。

1.2适用范围

本文适用于公司所有已经上线的软件项目产品。

以及自主研发的平台产品。

1.3定义

●Log：

即日志，通常是系统或者某些软件对已完成的某种处理的记录，以便将来做为参考，它并没有固定的格式，通常是文本文件，可以用记事本打开以查看内容，当然很可能是其它格式，直接打开就是乱码。

●BUG：

系统或程序中存在的任何一种影响正常运行的问题或者缺陷。

●SIT：

SystemIntegrationTest系统集成测试，即验证过程。

●UAT：

UserAcceptTest客户验收测试，即客户的确认过程。

2职责

研发总监：

是部门主管、测试主管及开发工程师的直接上级，对整个产品维护过程负有监督权利。

研发部：

●开发产品

●分析问题

●从内部BUG系统获取运营平台上的bug

●给出解决方案

●SIT测试及UAT测试支持

●上线支持

产品运维管理组：

（面向产品）

作为一个中小公司，通常在产品运维管理工作方面，并不一定要保持一个正式的运维管理机构。

但是在软件研发部门中确立一个非正式的委员会性质的运维管理机构则是非常必要的。

●产品日常运营状态监控和维护管理工作

●收集并记录来自各渠道反馈的问题，并作分析。

●定位问题

●反馈解决方案

●安排问题解决负责人

●进行新产品培训并逐步独立解决问题

客服及运营业务管理：

作为一个中小公司，在产品运营期间，业务管理工作，需要有人负责，有一部分工作类似于CALLCenter中心；同时掌握产品的功能、性能、熟悉产品运行的软硬件环境特点，能对用户进行培训教育；对于运营周期内，一切客户申请或咨询等业务，可以为平台客户提供好的试用体验或是使用服务。

●接收销售、客户申请

●添加企业、添加用户、业务运营监控

●响应客户要求并帮助客户。

收集客户提出的新需求和功能改善建议。

●客户在使用中发现的问题，有专人第一时间响应并尽可能重现，确认是否是问题，还是操作有误造成。

●为客户咨询或提取一些数据信息；

●提取运营业务数据汇报给管理层；

●其他工作。

测试部：

●重现问题

●接收研发部提交的新版本并进行测试

●UAT测试支持

●上线支持

项目经理：

●协助研发部及测试部间工作

QA：

●产品维护全过程的监督与跟踪

配置管理员：

●负责版本的发布及控制

3产品运营管理工作内容

产品运维管理组日常维护工作内容：

1）主动式监控系统运行状态。

2）监控IT资源包括中间件/数据库/应用软件/日志/硬件/磁盘空间资源等；

3）定期备份，清理历史数据和日志；

4）解决生产环境出现的紧急问题，恢复系统应用到正常；

5）协助开发或测试部确认或检查一些设置或信息；

6）在生产环节出现的各类临时任务，原则上由产品运维管理组（委员会性质的机构）进行分析协调，提出服务请求单，申请研发部的同事负责解决，研发部人员目前需要综合产品规划计划，支持产品运维管理组来完成相关工作内容。

4产品问题解决

4.1产品问题解决流程图

产品问题解决流程图

4.2流程描述

1、销售部、工程部、质量部、CallCenter中心在发现问题时第一时间响应客户并尽可能重现，确认是否是问题，还是操作有误造成。

收集问题反馈给映翰通产品运维管理组。

2、产品运维管理组记录问题，并定位问题（可自行解决/无法自行解决）

1）可自行解决的问题，如属于客户使用问题，反馈正确使用方法；如需要更改相关配置参数，参照相关技术文档进行修改（遇到没有相关技术文档参照的特殊情况时，可以联系研发部协助解决）。

2）无法自行解决的问题，产品运维管理组决定此问题的分派流程，分为两种情况：

a）如需要重现问题，则转由测试部主导重现问题，确定是系统bug后，由测试人员记录，并协调研发部相关负责人。

b）如判断不需要重现问题，则直接反馈给研发部，由研发部主导分析解决问题。

3）在问题进入下一环节的同时，需附上问题解决过程记录，供下一环节人员参考。

3、研发部负责人接收到问题后进行分析，分析结果分为三类：

1）第一类，确认问题为当前项目不包含的需求，与客户协商，遵照变更流程执行；

2）第二类，确认是项目问题，但无需修改代码，提供解决方案给产品运维管理组，并反馈给客户；

3）第三类，确认是项目本身存在的bug，需要提交变更报告，修改代码发布新版本，后续遵照变更流程执行。

4、测试部接收新版本进行测试，遵循测试流程执行，输出测试报告。

5、在测试过程中，产品运维管理组负责版本的发布及控制。

6、部门主管负责研发部及测试部之间的协调工作。

5产品运营周期示意图

5.1服务请求单

《服务请求单》的应用，客户通过邮件，电话，截图等向相关部门人员提出各种服务请求，请耐心仔细获取信息，并进行登记，填写《服务请求单》，属于待处理问题，对问题进行分析，提交到产品运营管理维护负责人，进行后续处理。

《服务请求单》的属性：

编号，来源，负责处理部门，子系统类别，服务请求简称，请求内容描述，影响度，调查分析，紧迫性，状态，解决办法，负责人，创建人，创建时间。

5.2变更评估

《服务申请单》报告将由产品运维管理组成员来研究处理。

依照变更流程，评估相应的软件修改任务，汇总为《变更报告》，指明：

∙所需修改变动的性质；

∙申请修改的优先级；

∙为满足某个维护申请报告，所需的工作量；

∙预计修改后的状况.

∙修改之后所发布的版本号

5.3版本规范应用

首先发布新版本到运营平台是由几个严谨的步骤组成的，我们需要把每个步骤的动作形成标准规范。

产品升级管理。

当某个需求执行完上线前的所有流程时，该需求功能会添加到版本升级version中，后续实施人据此提交升级计划进行升级申请，负责人审核通过后即可实施，同时记录相关升级信息和文档。

版本管理。

在升级完成后进入需求管理的下一个流程即版本管理，版本管理提供及时录入本次升级项目的版本变更情况及归档的功能，大大方便了日后的检索和查询。

在规范性的运营管理模式指导下，经过一定时间的积累，我们可以逐步量化运营管理工作。

例如响应时间，故障分级，解决问题时长，问题分类，每个岗位独立解决问题个数，多岗位共同参与解决的问题个数。

5.4上线申请单

通过《上线申请单》样式，邮件方式发出上线申请，说明版本特点。

5.5发布前准备和检查

发布前配置管理，对源代码，库文件，版本检查整理，更新相关文档，包括发布说明书，并配合《安装部署说明书》。

5.6发布执行

发布配置，包括发布名称，版本号，发布说明与通告（邮件，网站等形式），上传程序包，备份运行环境版本。

5.7发布验证

发布时刻，立即验证系统是否正常运行，是否存在兼容性问题，是否发现新的Bug。

5.8发布反馈

主动监控运行状态，收集新版本运行反馈。

产品运行使用过程中可能还会发现一些Bug。

在不影响正常使用的情况下，这些Bug将在下一版本发布时解决；如果Bug严重影响使用，必须打补丁或者按照流程重新发布。

5.9需求跟踪

在整个生命周期中，始终要做好需求跟踪任务。

《变更报告》就是一种跟踪方式。

维护好新一轮版本规划工作。