3.4 原有功能调整

文章插图

对应系统原有功能 ， 客户提出的改进意见 ， 要求及时响应 ， 及时反馈 ， 同时和客户评估可行性 。 正对可行性意见 ， 评估交付时间 ， 提交研发完成功能 ， 交付客户使用 。
3.5 业务支撑
针对提出的业务问题 ， 要求及时响应 。 对系统业务要有一定了解 ， 确保客户的问题能够得到回应 ， 不懂的业务可以咨询项目研发人员 ， 项目经理等 。
3.6 升级交付
系统有功能需求升级时 ， 要求支撑人员熟悉系统部署 ， 了解部署架构 。 做到快速完成升级部署 ， 不影响系统正常使用 。 所以要求支撑人员能够属性各应用服务器 ， 各系统 ， 数据库等软件的安装调试 。
3.7 日志查看


文章插图

主要是定期检查各系统模块日志 ， 包括服务器运行日志 ， 系统应用运行日志 ， 数据库处理日志 ， 发现异常能够分析 ， 定位问题 ， 分析问题级别 ， 及时提交研发处理 。
3.8 异常监控处理
支撑人员日常巡检时发现异常 ， 要求能够异常分析 ， 分析完成后提交研发或者自己处理 ， 处理完成后 ， 制定更新计划 ， 及时更新 。 减少客户对系统功能使用时的问题 。
3.9 系统使用报告
定期做系统运维报告 ， 包括系统健康状况 ， 异常问题焦点 ， 运维中遇到的困难 。 并作出相应处理方法 。
四 支撑工作流程
系统运营支撑的建设是一个循序渐进的过程 ， 应加强与运营部门 ， 项目研发部门的沟通、合作 ， 全面考虑运营支撑系统的建设思路 ， 并在运营支撑系统的计划、建设、运行及取得成效整个周期里 ， 层层推进、逐步部署并不断改进 ， 只有这样运营支撑系统才能适应运营商不同阶段的需要 ， 为其持续发展提供不竭动力 。
4.1 人员要求
4.1.1. 可以在原有平台项目组中抽调部分人员 ， 包括产品人员 ， 开发人员 ， 测试人员等 ， 要求熟悉平台功能和架构 ， 能够针问题做定位 ， 对需要做分析 ， 提出解决方案 。
4.1.2. 招聘部分新的成员 ， 要求技术面广泛 ， 基础功底深厚 ， 能够接受支撑工作 ， 沟通 ， 应变能力强 ， 并能够发现系统中存在的问题 ， 并解决发现的问题 。
4.1.3 做定期的项目功能 ， 业务培训 。 能够做大对每一个系统大部分功能的了解 。
4.2 工作流程
支撑工作主要对接客户 ， 及系统使用者和项目研发组及系统开发者 。 工作流程主要是：客户提出要求—->支撑人员承接要求 ， 分析要求—->研发人员解决要求 。 所以支撑工作处于中间位置 ， 至关重要 。
支撑工作主要流程如下：
4.2.1 支撑人员对接客户
支撑人员对接客户 ， 要求及时响应客户需要 。 对客户提出的需要记录 ， 分析 ， 评估 ， 及时反馈给客户 。
客户提出需求 ， 故障—->及时反应—->承接需要 ， 故障—->记录需求 ， 故障—->分析需求 ， 故障—–>评估需求 ， 故障 ， 确定故障 ， 需求优先级别—-反馈处理建议 ， 处理时间给客户
4.2.2 支撑人员对接研发
支撑人员对接研发 ， 主要是需要研发更改程序 ， 研发新需求 。 要求能够详细描述需求 ， 故障 ， 使研发人员能够快速接手 ， 做开发 。
支撑人员提交需求 ， 故障给研发—>详细描述 ， 说明故障 ， 需求 ， 确定交付时间—->督促研发按照故障 ， 需求优先级处理
4.2.3 支撑人员本身